From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Steffen Prohaska <prohaska@zib.de>,
Git Mailing List <git@vger.kernel.org>,
Alex Bennee <kernel-hacker@bennee.com>
Subject: Re: Warning: cvsexportcommit considered dangerous
Date: Mon, 5 Nov 2007 00:05:28 +0100 [thread overview]
Message-ID: <200711050005.28561.robin.rosenberg.lists@dewire.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0711042133330.4362@racer.site>
söndag 04 november 2007 skrev Johannes Schindelin:
> 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
next prev parent reply other threads:[~2007-11-04 23:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-04 16:41 Warning: cvsexportcommit considered dangerous Johannes Schindelin
2007-11-04 18:16 ` Steffen Prohaska
2007-11-04 21:35 ` Johannes Schindelin
2007-11-04 23:05 ` Robin Rosenberg [this message]
2007-11-04 23:46 ` Johannes Schindelin
2007-11-15 11:59 ` Alex Bennee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200711050005.28561.robin.rosenberg.lists@dewire.com \
--to=robin.rosenberg.lists@dewire.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=kernel-hacker@bennee.com \
--cc=prohaska@zib.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.