[darcs-users] tailor bug and possible fix

[Lele Gaifax]

Benjamin Franksen wrote:
> (Apologies if this is not the appropriate place to discuss tailor issues.)

A better place is the tailor ML list, to which I'm forwarding this 
thread. You have to sign up to write there though.

> I discovered a serious bug today when using tailor to convert from darcs to
> CVS. The problem is that 'cvs commit' sometimes changes files in the
> working directory, due to CVS keyword expansion. This can lead to conflicts
> during the next 'darcs pull' operation and tailor will commit (to CVS)
> versions of files that contain (darcs-) conflict markers. This is very
> unfortunate as it means I manually had to roll back the CVS branch
> (using 'cvs admin -o', bäh). At least tailor should recognize conflicts
> whenever they happen and abort with an error instead of going straight on
> (and failing later anyway).

Oh, I'm sorry about that. I'll try to figure out what's going on about 
the conflicts. Best would be a little example that exposes the problem.

> Tailor also commits files like .#xyz.1.12 that CVS automatically creates
> during update, whenever the file in the working directory is modified. This
> latter problem can be avoided by 'cvs commit'ing only files that are
> affected by the darcs patch that has been pulled. (Which is an information
> that is readily available from the darcs patch).

Eh, I always thought that was a better way to invoke the final commit, 
but there are corner cases where the exact list doesn't fit. Maybe 
tailor should create/augment a .cvsignore file on its own and put that 
pattern in it?

> I managed to circumvent the problem when converting manually by doing 'darcs
> revert' in tailor's working copy after each CVS commit. Then I do 'darcs
> pull' for the next patch and then I 'cvs commit' with all files affected by
> the darcs patch listed as arguments. I did this up to (and including) the
> point where I had removed all CVS keywords from the source files (in the
> darcs history). From that point on I could again use tailor to do the rest
> of the conversion automatically. Hopefully I will get no more conflicts in
> the future... unless someone (accidentally or out of stupidity) adds a CVS
> keyword again).
> 
> BTW, -ko or -kk CVS options did no good either (nor did freeze-keywords =
> True). This may be because I had (already expanded) CVS keywords /in my
> darcs repo/, and these keywords did not coincide with the ones that were
> produced by CVS on commit, because the commit was to another branch.

Uhm, I don't understand the reason for which -kk isn't doing what I'd 
expect... but surely and expecially with CVS my "I don't understand 
that" bag is way bigger than the "ok, I got it" :)

> Would it be possible, in principle, to change the behavior of tailor
> according to teh above procedure, when converting from darcs to CVS? I
> would even try to fix this myself, however tailor seems to be quite generic
> in it's working and I am not sure how this would interact with all the
> other conversion ways. Which source files would be affected?

Since the same may happen with Subversion (and probably others), I'd be 
inclined to think a generic way to do it. I cannot say right now if it's 
reasonable to *always* do a revert on the source backend after the 
commit on the target, so maybe it should be an option, say 
"revert-after-commit" on Project instances. Then I'd add a 
"_revertToPristine" abstract method to the UpdatableSourceWorkingDir 
class, and execute it at some point near the end of the loop in 
applyPendingChangesets().

I'd recommend opening a ticket or two on these issues, at 
http://progetti.arstecnica.it/tailor

hth,
ciao, lele.