Thread (4 messages) flat view 4 messages, 2 authors, 2016-06-15
DORMANTno replies

[PATCH] git-cvsexportcommit: handle file status reported out of order (was Re: [PATCH] Make git-cvsexportcommit "status" each file in turn)

From: Nick Woolley <hidden>
Date: 2016-06-15 22:45:26

Hi,

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?

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.

Thanks,

Nick

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help