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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).