Hi, On Thu, 2 Oct 2008, Nick Woolley wrote: > I've encountered a problem with the Ubuntu Hardy version of > git-cvsexportcommit (part of git-cvs 1:1.5.4.3-1ubuntu2). This seems to > be the same problem describedin August last year in the thread on this > list I referenced (Make git-cvsexportcommit "status" each file in turn). > > The problem is that cvsexportcommit rejects a patch erroneously when CVS > does not report file statuses in the expected order. It confuses one > file's status for another and says (at least in my case): > > > Checking if patch will apply > > cvs server: nothing known about XXXXXXXXX > > cvs server: nothing known about XXXXXXXXX > > File XXXXXXXXX is already known in your CVS checkout -- perhaps it\ > > has been added by another user. Or this may indicate that it exists\ > > on a different branch. If this is the case, use -f to force the\ > > merge. > > Status was: Up-to-date > > File XXXXXXXXX not up to date but has status 'Unknown' in your\ > > CVS checkout! > > Exiting: your CVS tree is not clean for this merge. at /usr/bin/git\ > > -cvsexportcommit line 235. > > I searched this list - including the release announcements - and the web > and it did not seem that anyone had applied this patch or otherwise > addressed it. > > I then found the git release repository and it *does* seem to have been > addressed in 1.6.0. However, and correct me if I'm mistaken, but the > implementation seems to assume that the committed files' basenames are > unique? This can't be guaranteed in general, can it? Please research a bit better. If the basenames are not unique, several cvs status calls are used. See commit fef3a7cc5593d3951a5f95c92986fb9982c2cc86. > Anyway, by then I'd already had a go at fixing it myself, and I had an > alternative approach, partly based on the suggestions from Robin > Rosenberg in the referenced thread. It doesn't assume basenames are > unique, and therefore I think should be more robust. > > So, attached is a patch against v1.5.4. It works for me, but has only > been tested with my particular circumstance, so there could be > assumptions I made which aren't universally true. I did try using the > test suite in git 1.6.0 but it didn't work for reasons I don't want to > spend too much more time investigating. I think the patch as it is > should be easy to follow and integrate with 1.6.0 for someone familiar > with the codebase. > > Some notes about the patch. > > - It parses the output of CVS status / update, getting the > file status much as before > > - save_pipe_capture() is modified to capture STDERR as well as STDOUT > > - The STDERR message 'nothing known about <path>' is used > preferentially to get a file's path. > > - Otherwise, uses the 'Repository revision' field, extracting the > relevant part by removing the repository root constructed from > meta-data in the CVS/Root and CVS/Repository files. > > I hope this helps. Comments welcome. I can only assume that you have not really hung out on this list for very long; this is no way near the way patches are expected here. For more help, refer to Documentation/SubmittingPatches, as has been mentioned in the notes from the maintainer quite a number of times. Or imitate how other people submit their patches. Also, given the fact that you actually verified that it was fixed in 1.6.0, what exactly is your proposed course of action? Revert the fix in 1.6.0 and apply your patch? Apply your patch to 1.5.6.5, cracking a release 1.5.6.6 with your patch? Puzzled, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
