Lele Gaifax wrote: > Benjamin Franksen wrote: >> 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.
Well, it was stupid of me to not make a copy of the CVS repo first. You can bet that have learned that lesson by now ;-) > I'll try to figure out what's going on about > the conflicts. Best would be a little example that exposes the problem. It's a bit difficult because I already moved on and got the problem solved (for us, see below). I have to admit that I've been pushing tailor quite hard. This is what I did: Start with a CVS repo, or rather a certain module within it, that has trunk and one branch. Several weeks ago I converted the module from CVS to Subversion, using cvs2svn. Development continued under Subversion, mostly on the branch, with lots of merges for the branch to the trunk. [Aside: This drove me crazy after a while, especialy the need to manually document the exact merge point(s) or else risk conflict and complete chaos on the _next_ merge. Being fed up with Subversion I finally decided to completely dump it and use darcs as the new CVS replacement. However, in order to soothe the more conservative mind of some co-workers, I promised to still maintain the CVS repo as backup so that we could switch back in case darcs later failed for us. So...] I used cvs2darcs to convert the CVS repo to darcs, but only up to the split point where the branch starts (which fortunately I had marked with a tag in CVS). I did not use tailor for that because we have very many old tags in CVS wich I did not want to re-create manually in darcs. This darcs repo was in sync with a corresponding revision of the Subversion branch. I then completed the darcs repo using tailor up to the head of the Subversion branch. What remained to be done was to bring the CVS branch in sync with the darcs repo. This is where the reported problems appeared: Somewhere during the process a conflict hapened, most probably due to CVS keyword exansion during CVS commit resp. during the next darcs pull. Note that Subversion recognizes CVS keywords and also expands them, but (of course) according to its own revision number scheme. Also note that we have a lot of files with $Log$ keywords which cause even more difficulties since added $Log$ entries cannot be hidden by not expanding keywords. Ok, this long story is probably not very helpful. I should reproduce the error and submit a small test case but it would take some work and I am already way behind my schedule with all this repo conversion stuff... >> 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. That is too bad. Just for my curiosity: What corner cases are you thinking of? > Maybe > tailor should create/augment a .cvsignore file on its own and put that > pattern in it? This would cure (at least) one of the symptoms, if not the cause ;-) >> 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" :) I learned more about it in the last few days than I ever wanted :-/ Maybe it was $Log$ generated history that initially caused the trouble. Anyway, the good news is that I managed to solve the whole problem, see below: >> 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, I really can't comment on other backends (I have no concrete knowledge of anything other than Subversion, CVS and darcs). For darcs I think it is safe to do so, at least in the case of a one-directional conversion, i.e. darcs -> X, where no third party may commit anything into X. > 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(). Well, that sounds like a nice solution. I went with a slightly less ambitious 'fix' and added a 'darcs revert --all' command at the beginning of _applyChangeset. With this small addition everything went smoothly. Cheers (and thanks for your support!) Ben -- (and sorry for the long mail) _______________________________________________ Tailor mailing list [email protected] http://lists.zooko.com/mailman/listinfo/tailor
