Re: Warning: cvsexportcommit considered dangerous

From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Date: Nov 4, 2007, 23:05 UTC
Message-ID: <200711050005.28561.robin.rosenberg.lists@dewire.com>
In-Reply-To: <Pine.LNX.4.64.0711042133330.4362@racer.site>

söndag 04 november 2007 skrev Johannes Schindelin:

Show 33 quoted lines

> Hi,
> 
> On Sun, 4 Nov 2007, Steffen Prohaska wrote:
> 
> > On Nov 4, 2007, at 5:41 PM, Johannes Schindelin wrote:
> > 
> > > 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