Re: Warning: cvsexportcommit considered dangerous

söndag 04 november 2007 skrev Johannes Schindelin:

Hi,

On Sun, 4 Nov 2007, Steffen Prohaska wrote:

quoted

On Nov 4, 2007, at 5:41 PM, Johannes Schindelin wrote:

quoted

ever since the up-to-date check was changed to use just one call to 
"cvs status", a bug was present.  Now cvsexportcommit expects "cvs 
status" to return the results in the same order as the file names were 
passed.

This is not true, as I had to realise with one of my projects on 
sourceforge.

Since time is so scarce on my side, I will not have time to fix this 
bug, but will instead return to my old "commit by hand" procedure.

I introduced this 'optimization', which turned out to be a bug. So, I 
feel responsible. Sorry for the trouble.

In August this was already recognized and a patch submitted:

http://marc.info/?t=118718458000004&r=1&w=2

I do not know why it wasn't applied. I forgot re-checking after my 
vacation.

It slipped by me, because of holiday, too.  (I was on my well needed 
holiday then.)

But that patch really seems like a step back to me.  The line "File: ... 
Status: ..." should be parsable enough to fix the bug properly, instead of 
undoing the optimisation.

Unfortunately it's not that easy to parse. It *can* be done by looking at the
repository path, and the CVS/Root etc, but it's not nice. 

AFAICS Robin replied with a "let's see if a proper fix materialises", and 
I kind of hope that it will materialise soon.

Still hoping :). BTW, wouldn't this err on the right side anyway, i.e. if an
existing file was not up to date and was wrongly thought to not exist or a new 
file was thought to be up-to-date, I would get an error and would not be able
to commit. I've never seen it though and I always have a clean CVS checkout
so the potential bug seems unlikely to me.

The command I always use is.

	git cvsexportcommit -u -c -w /my/cvs/checkout

Never bitten me yet (touch wood).

My real worry is on the other side, with bad conversion from CVS to git.

-- robin