[darcs-users] fixing trac+darcs

[Lele Gaifax]

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.