From: Yann Dirson <ydirson@altern.org>
To: Martin Langhoff <martin.langhoff@gmail.com>
Cc: GIT list <git@vger.kernel.org>, cvsps@dm.cobite.com
Subject: Re: remaining git-cvsimport problems: robustness when cvsps feeds strange history
Date: Sat, 27 May 2006 18:35:55 +0200 [thread overview]
Message-ID: <20060527163555.GM1164@nowhere.earth> (raw)
In-Reply-To: <46a038f90605270823qdea766fxcf2327ae0bf7373a@mail.gmail.com>
On Sun, May 28, 2006 at 03:23:01AM +1200, Martin Langhoff wrote:
> I want to see if we can close these gaps. Have you got a public repo
> that shows this problem so can look more into it?
No, it holds proprietary code - I can only try to reproduce the
history pattern, but I have not succeeded in that yet. And that's not
something I can do on customer time :)
> On 5/28/06, Yann Dirson <ydirson@altern.org> wrote:
> >As a sidenote, I'm wondering why there is no precise information on
> >the branchpoint in "cvsps -A". I guess the semantics are "fork a new
> >branch from the ancestor one" at whatever point it currently is - that
> >would look quite risky to me, and could be part of the reason why
> >cvsps did not notice the inconsistency: it just did not try to find
> >out where the new branch was to be grafted exactly.
>
> It is perfectly possible for cvs to branch at a "point" that is not
> really a patchset/patchlevel. Just like it is to tag something that
> has never been a patchset.
>
> It is something we currently fudge a bit (or a lot, depending on your
> point of view). If the branch was made on a checkout with an
> inconsistent tree, we cannot really represent that in git matching
> what happened in CVS.
Yes, I know that too much. I've already thought that it could
possibly be represented by a merge commit taking as parents all
patchsets that contain a file revision holding the tag. But such
patchset synthesis ought to done at cvsps level IMHO.
> OTOH, the cvsps output you are showing us seems to be in the right
> order... patchset 20 should go on top of patchset 3... is cvsimport
> truly mishandling this?
That's the problem. I had just copypasted the logs for handling at
home, and then I discovered in the cvsps log that the timestamp for
patchset 2 is the same as the one for patchset 1, which is obviously
wrong. I'll look at the cvs repo next week to understand whether that
comes from the RCS file, or whether it is cvsps misunderstanding
something.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
next prev parent reply other threads:[~2006-05-27 16:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-27 12:01 remaining git-cvsimport problems: robustness when cvsps feeds strange history Yann Dirson
2006-05-27 15:23 ` Martin Langhoff
2006-05-27 16:35 ` Yann Dirson [this message]
2006-06-01 21:28 ` Yann Dirson
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=20060527163555.GM1164@nowhere.earth \
--to=ydirson@altern.org \
--cc=cvsps@dm.cobite.com \
--cc=git@vger.kernel.org \
--cc=martin.langhoff@gmail.com \
/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).