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. _______________________________________________ Tailor mailing list [email protected] http://lists.zooko.com/mailman/listinfo/tailor
