From: "Eric S. Raymond" <esr@thyrsus.com>
To: Martin Langhoff <martin.langhoff@gmail.com>
Cc: Andreas Krey <a.krey@gmx.de>, Git Mailing List <git@vger.kernel.org>
Subject: Re: I have end-of-lifed cvsps
Date: Thu, 12 Dec 2013 14:39:18 -0500 [thread overview]
Message-ID: <20131212193918.GA17529@thyrsus.com> (raw)
In-Reply-To: <CACPiFCJ22xiedXAoQktMLd=gASgD0NS24Pya9TvCo9aQP5JaBQ@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com>:
> IIRC, making the output stable is nontrivial, specially on branches.
> Two cases are still in my mind, from when I was wrestling with cvsps.
>
> 1 - For a history with CVS HEAD and a long-running "stable release"
> branch ("STABLE"), which branched at P1...
>
> a - adding a file only at the tip of STABLE "retroactively changes
> history" for P1 and perhaps CVS HEAD
>
> b - forgetting to properly tag a subset of files with the branch
> tag, and doing it later retroactively changes history
>
> 2 - you can create a new branch or tag with files that do not belong
> together in any "commit". Doing so changes history retroactively
>
> ... when I say "changes history", I mean that the importers I know
> revise their guesses of what files were seen together in a 'commit'.
> This is specially true for history recorded with early cvs versions
> that did not record a 'commit id'.
Yikes! That is a much stricter stability criterion than I thought you
were specifying. No, cvs-fast-export probably doesn't satify all of these.
I think it would handle 1a in a stable way, but 1b and 2 would throw it.
I'm sure it can't be fooled in the presence of commitids, though,
because when it has those it doesn't try to do any similarity
matching. And (this is the important point) it won't match any change
with a commit-id to any change without one.
What I think this means is that cvs-fast-export is stable if you are
using a server/client combination that generates commitids (that is,
GNU CVS of any version newer than 1.12 of 2004, or CVS-NT). It is
*not* necessary for stability that the entire history have them.
Here's how the logic works out:
1. Commits grouped by commitid are stable - nothing in CVS ever rewrites
those or assigns a duplicate.
2. No file change made with a commitid can destabilize a commit guess
made without them, because the similarity checker never tries to put both
kinds in a single changeset.
Can you detect any flaw in this?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
next prev parent reply other threads:[~2013-12-12 19:39 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-12 0:17 I have end-of-lifed cvsps Eric S. Raymond
2013-12-12 3:38 ` Martin Langhoff
2013-12-12 4:26 ` Eric S. Raymond
2013-12-12 13:42 ` Martin Langhoff
2013-12-12 17:17 ` Andreas Krey
2013-12-12 17:26 ` Martin Langhoff
2013-12-12 18:35 ` Eric S. Raymond
2013-12-12 18:29 ` Eric S. Raymond
2013-12-12 19:08 ` Martin Langhoff
2013-12-12 19:39 ` Eric S. Raymond [this message]
2013-12-12 19:48 ` Martin Langhoff
2013-12-12 20:58 ` Eric S. Raymond
2013-12-12 22:51 ` Martin Langhoff
2013-12-12 23:04 ` Eric S. Raymond
2013-12-13 2:35 ` Martin Langhoff
2013-12-13 3:38 ` Eric S. Raymond
2013-12-12 18:15 ` Eric S. Raymond
2013-12-12 18:53 ` Martin Langhoff
2013-12-17 10:57 ` Jakub Narębski
2013-12-17 11:18 ` Johan Herland
2013-12-17 14:58 ` Eric S. Raymond
2013-12-17 17:52 ` Johan Herland
2013-12-17 18:47 ` Eric S. Raymond
2013-12-17 21:26 ` Johan Herland
2013-12-17 22:41 ` Eric S. Raymond
2013-12-18 23:44 ` Michael Haggerty
2013-12-19 1:11 ` Johan Herland
2013-12-19 9:31 ` Michael Haggerty
2013-12-19 15:26 ` Johan Herland
2013-12-19 16:18 ` Michael Haggerty
2013-12-19 4:06 ` Eric S. Raymond
2013-12-19 9:43 ` Michael Haggerty
2013-12-17 14:07 ` Eric S. Raymond
2013-12-17 19:58 ` Jakub Narębski
2013-12-17 21:02 ` Eric S. Raymond
2013-12-18 0:02 ` Jakub Narębski
2013-12-18 0:21 ` Eric S. Raymond
2013-12-18 15:39 ` Jakub Narębski
2013-12-18 16:23 ` incremental fast-import and marks (Re: I have end-of-lifed cvsps) Jonathan Nieder
2013-12-18 16:27 ` I have end-of-lifed cvsps Eric S. Raymond
2013-12-18 16:53 ` Martin Langhoff
2013-12-18 19:54 ` John Keeping
2013-12-18 20:20 ` Eric S. Raymond
2013-12-18 20:47 ` Kent R. Spillner
2013-12-18 17:46 ` Jeff King
2013-12-18 19:16 ` Eric S. Raymond
2013-12-18 0:04 ` Andreas Schwab
2013-12-18 0:25 ` Eric S. Raymond
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=20131212193918.GA17529@thyrsus.com \
--to=esr@thyrsus.com \
--cc=a.krey@gmx.de \
--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).