K.S.Sreeram wrote:
Hi Everybody,
TracDarcs is very important for one my projects (http://cspace.in), but
this issue (http://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
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
