K.S.Sreeram wrote:
> Hi Everybody,
>
> TracDarcs is very important for one my projects (http://cspace.in), but
> this issue (htt
p://progetti.arstecnica.it/trac+darcs/ticket/1) is a
> major blocker. So i've decided to get my hands dirty
and i've been
> trying to grok the relevant code.
>
> From my initial analysis so far, one critical problem
lies in the way
> tracdarcs converts darcs changesets into its internal
Node & Changeset
> structures. This is done in the
'changesets_from_darcschanges' function
> in tracdarcs/changeset.py. The code fails to handle the
case where a
> directory gets renamed. Darcs represents this as a
single 'move' patch
> for the directory. Tracdarcs fails to apply the move
operation to the
> contents of the directory.
Uhm, no, I don't think the problem hides in that function,
but it's
rather a shortcoming of the way the plugin tries to mimic
darcs in
*understanding* the metadata extracted by c_f_d().
> It should be rather easy to change this particular
function to fix this
> error, but i've only spent a few hours trying to
understand the
> internals of trac and darcs, and i'm not yet
comfortable in changing the
> code. So i thought i'll share my findings with others
just to know if
> i'm going in the right direction or not...
I think that what needs to be fixed is the workhorse
function
_getPathHistory(), and maybe even
_getCachedContentLocation(). Those
functions are in fact responsible of yielding back the right
nodes name,
taking into account renames and such.
>
> I have a few other questions ...
>
> 1) Changeset revision numbering
> Trac requires a sequential revision number, but darcs
doesn't have any
> concept of a revision number. Tracdarcs handles this by
assigning
> revision numbers sequentially to the changesets listed
by 'darcs changes
> --reverse'. Is this a valid approach? Is it possible
in darcs, for a
> patch to get inserted in the middle of the existing
changesets? Or is it
> possible for the changesets to get reordered somehow?
Yes, darcs can reorder the patches at any time while
applying them, but
once done, it requires an explicit "darcs
optimize" to have the reorder
happen.
While I do know that's a weak assumption that the patch
order will
remain unchanged *in the repo dedicated to trac*, I fail to
see a
workaround that would fit the trac environment (without
resorting to
referring to any patch by it's hash, that would quickly
become annoying)
>
>
> 2) Caching
> What is the caching approach followed? I would prefer
to cache the
> entire revision metadata when run for the first time.
On any subsequent
> run, a check for newer changesets can be performed, and
the revision
> cache can be updated if any new changesets are found.
Ofcourse, since
> only the revision metadata is cached, we need to use
darcs to fetch file
> contents whenever needed. Is this the approach that is
currently followed?
Yes. Whenever you hit the trac environment, it asks to the
backend if
there's something new, and in such case it calls the
changesets_from_darcschanges() function and cache its result
in the
database. This is for metadata. For actual file contents,
the mentioned
function provide a way to obtain a possibly already computed
content of
a file at any given patch.
>
> 3) 'token replace' patches
> Darcs has a special 'token replace' patch type. How
do we handle this?
> I'm currently planning to ignore this patch type since
none of my
> repositories have such patches! 
>
> 4) 'merger' patches
> 'merger' patches are created by darcs during certain
types of merges.
> None of my repos seem to have this, and i've not
gotten around to
> creating test repos with such patches. I've not fully
understood this
> patch type, and if anybody has more insight on how
these can be handled,
> please let me know.
Uhm, I fail to see how these two point impact on what we are
talking.
Neither trac nor the backend are interested in such details.
ciao, lele.
_______________________________________________
darcs-users mailing list
darcs-users darcs.net
http://www.abridgegame.org/mailman/listinfo/darcs-users
|