On 12/19/2013 04:26 PM, Johan Herland wrote:
> On Thu, Dec 19, 2013 at 10:31 AM, Michael Haggerty
> wrote:
>> On 12/19/2013 02:11 AM, Johan Herland wrote:
>>> On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty
>>> wrote:
A correct incremental converter could be done (as long as the CVS use
On Thu, Dec 19, 2013 at 10:31 AM, Michael Haggerty wrote:
> On 12/19/2013 02:11 AM, Johan Herland wrote:
>> On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty
>> wrote:
>>> A correct incremental converter could be done (as long as the CVS users
>>> don't literally change history retroactively) b
On 12/19/2013 05:06 AM, Eric S. Raymond wrote:
> Michael Haggerty :
>> If you haven't tried cvs2git yet, please start it up somewhere in the
>> background. It might take a while but it should have no trouble with
>> your repos, and then you can compare the tools based on experience
>> rather than
On 12/19/2013 02:11 AM, Johan Herland wrote:
> On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty
> wrote:
>> A correct incremental converter could be done (as long as the CVS users
>> don't literally change history retroactively) but it would be a lot of work.
>
> Although I agree with that sen
Michael Haggerty :
> If you haven't tried cvs2git yet, please start it up somewhere in the
> background. It might take a while but it should have no trouble with
> your repos, and then you can compare the tools based on experience
> rather than speculation.
That would be a good thing.
Michael, i
On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty wrote:
> A correct incremental converter could be done (as long as the CVS users
> don't literally change history retroactively) but it would be a lot of work.
Although I agree with that sentence as it is stated, I also believe
that the parenthes
On 12/17/2013 07:47 PM, Eric S. Raymond wrote:
> Johan Herland :
>> However, I fear that you underestimate the number of users that want
>> to use Git against CVS repos that are orders of magnitude larger (in
>> both dimensions: #commits and #files) than your example repo.
>
> You may be right. Se
> Which will trash your history - the bugs in that are worse than the bugs
> in 3.0, which are bad enough that I *terminated* it.
Which *might* trash your history.
cvsps v2 and git cvsimport work as advertised with simple, linear CVS
repositories. I maintain a git mirror of an active CVS repo an
John Keeping :
> Which I think sums up the position nicely; if you're doing a one-shot
> import then the standalone tools are going to be a better choice, but if
> you're trying to use Git for your work on top of CVS the only choice is
> cvsps with git-cvsimport.
Which will trash your history - th
On Wed, Dec 18, 2013 at 11:53:47AM -0500, Martin Langhoff wrote:
> On Wed, Dec 18, 2013 at 11:27 AM, Eric S. Raymond wrote:
> >> Anyway I hope that incremental CVS import would be needed less
> >> and less as CVS is replaced by any more modern version control system.
> >
> > I agree. I have never
Jeff King :
> In git, it may happen quite a bit during "git am" or "git rebase", in
> which a large number of commits are replayed in a tight loop.
That's a good point - a repeatable real-world case in which we can
expect that behavior.
This case could be solved, though, with a slight tweak to th
On Wed, Dec 18, 2013 at 11:27:10AM -0500, Eric S. Raymond wrote:
> For use in reposurgeon I have defined a generic cross-VCS reference to
> commit I call an "action stamp"; it consists of an RFC3339 date followed by
> a committer email address. Here's an example:
>
>2013-02-06T09:35:10Z!
On Wed, Dec 18, 2013 at 11:27 AM, Eric S. Raymond wrote:
>> Anyway I hope that incremental CVS import would be needed less
>> and less as CVS is replaced by any more modern version control system.
>
> I agree. I have never understood why people on this list are attached to it.
I think I have ans
Jakub Narębski :
> It is a bit strange that markfile has explicitly SHA-1 (":markid "),
> instead of generic reference to commit, in the case of CVS it would be
> commitid (what to do for older repositories, though?), in case of Bazaar
> its revision id (GUID), etc. Can we assume that SCM v1 fast-
Jakub Narebski wrote:
> It is a bit strange that markfile has explicitly SHA-1 (":markid "),
> instead of generic reference to commit, in the case of CVS it would be
> commitid (what to do for older repositories, though?), in case of Bazaar
> its revision id (GUID), etc.
Usually importers use at
On Wed, Dec 18, 2013 at 1:21 AM, Eric S. Raymond wrote:
> Jakub Narębski :
>>> No, cvs-fast-export does not have --export-marks. It doesn't generate the
>>> SHA1s that would require. Even if it did, it's not clear how that would
>>> help.
>>
>> I was thinking about how the following part of git-
Andreas Schwab :
> "Eric S. Raymond" writes:
>
> > All versions of CVS have generated commitids since 2004.
>
> Though older versions are still in use, eg. sourceware.org still does
> not generate commitids.
That is awful. Alas, there is not much anyone can do about stupidity
that determined.
Jakub Narębski :
> > No, cvs-fast-export does not have --export-marks. It doesn't generate the
> > SHA1s that would require. Even if it did, it's not clear how that would
> > help.
>
> I was thinking about how the following part of git-fast-export
> `--import-marks=`
>
> Any commits that have
"Eric S. Raymond" writes:
> All versions of CVS have generated commitids since 2004.
Though older versions are still in use, eg. sourceware.org still does
not generate commitids.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8
On Tue, Dec 17, 2013 at 10:02 PM, Eric S. Raymond wrote:
> Jakub Narębski :
>>
>> Errr... doesn't cvs-fast-export support --export-marks= to save
>> progress and --import-marks= to continue incremental import?
>
> No, cvs-fast-export does not have --export-marks. It doesn't generate the
> SHA1s th
Johan Herland :
> > Alan and I are going to take a good hard whack at modifying cvs-fast-export
> > to make this work. Because there really aren't any feasible alternatives.
> > The analysis code in cvsps was never good enough. cvs2git, being written
> > in Python, would hit the core limit faster t
On Tue, Dec 17, 2013 at 7:47 PM, Eric S. Raymond wrote:
> I'm working with Alan Barret now on trying to convert the NetBSD
> repositories. They break cvs-fast-export through sheer bulk of
> metadata, by running the machine out of core. This is exactly
> the kind of huge case that you're talking a
Jakub Narębski :
> Errr... doesn't cvs-fast-export support --export-marks= to save
> progress and --import-marks= to continue incremental import?
No, cvs-fast-export does not have --export-marks. It doesn't generate the
SHA1s that would require. Even if it did, it's not clear how that would help.
On Tue, Dec 17, 2013 at 3:07 PM, Eric S. Raymond wrote:
> Jakub Narębski :
>> I wonder if we can add support for incremental import once, for all
>> VCS supporting fast-export, in one place, namely at the remote-helper.
>
> Something in the pipeline - either the helper or the exporter - needs to
Johan Herland :
> However, I fear that you underestimate the number of users that want
> to use Git against CVS repos that are orders of magnitude larger (in
> both dimensions: #commits and #files) than your example repo.
You may be right. See below...
I'm working with Alan Barret now on trying t
On Tue, Dec 17, 2013 at 3:58 PM, Eric S. Raymond wrote:
> Johan Herland :
>> HOWEVER, this only solves the "cheap" half of the problem. The reason
>> people want incremental CVS import, is to avoid having to repeatedly
>> convert the ENTIRE CVS history. This means that the CVS exporter must
>> lea
Johan Herland :
> HOWEVER, this only solves the "cheap" half of the problem. The reason
> people want incremental CVS import, is to avoid having to repeatedly
> convert the ENTIRE CVS history. This means that the CVS exporter must
> learn to start from a given point in the CVS history (identified b
Jakub Narębski :
> I wonder if we can add support for incremental import once, for all
> VCS supporting fast-export, in one place, namely at the remote-helper.
Something in the pipeline - either the helper or the exporter - needs to
have an equivalent of vc-fast-export's and cvsps's -i option, whi
On Tue, Dec 17, 2013 at 11:57 AM, Jakub Narębski wrote:
> Martin Langhoff wrote:
>
>> On Wed, Dec 11, 2013 at 11:26 PM, Eric S. Raymond wrote:
>>>
>>> You'll have to remind me what you mean by "incremental" here. Possibly
>>> it's something cvs-fast-export could support.
>>
>>
>> User can
>>
>>
Martin Langhoff wrote:
On Wed, Dec 11, 2013 at 11:26 PM, Eric S. Raymond wrote:
You'll have to remind me what you mean by "incremental" here. Possibly
it's something cvs-fast-export could support.
User can
- run a cvs to git import at time T, resulting in repo G
- make commits to cvs re
Martin Langhoff :
> On Thu, Dec 12, 2013 at 6:04 PM, Eric S. Raymond wrote:
> > I'm not sure what counts as a nonsensical branching point. I do know that
> > Keith left this rather cryptic note in a REAME:
>
> Keith names exactly what we are talking about.
Oh, yeah, I figured that much out. Wha
On Thu, Dec 12, 2013 at 6:04 PM, Eric S. Raymond wrote:
> I'm not sure what counts as a nonsensical branching point. I do know that
> Keith left this rather cryptic note in a REAME:
Keith names exactly what we are talking about. At that time, Keith was
struggling with the old xorg cvs repo which
Martin Langhoff :
> On Thu, Dec 12, 2013 at 3:58 PM, Eric S. Raymond wrote:
> >> - regardless of commit ids, do you synthesize an artificial commit?
> >> How do you define parenthood for that artificial commit?
> >
> > Because tagging is never used to deduce changesets, the case does not arise.
>
On Thu, Dec 12, 2013 at 3:58 PM, Eric S. Raymond wrote:
>> - regardless of commit ids, do you synthesize an artificial commit?
>> How do you define parenthood for that artificial commit?
>
> Because tagging is never used to deduce changesets, the case does not arise.
So if a branch has a nonsens
Martin Langhoff :
> If someone creates a nonsensical tag or branch point, tagging files
> from different commits, how do you handle it?
>
> - without commit ids, does it affect your guesses?
No. Tagging is never used to deduce changesets. Look:
/*
* The heart of the merge operation; detect wh
On Thu, Dec 12, 2013 at 2:39 PM, Eric S. Raymond wrote:
> Yikes! That is a much stricter stability criterion than I thought you
> were specifying.
:-) -- cvsps's approach is: if you have a cache, you can remember the
lies you told earlier.
It is impossible to be stable purely from the source da
Martin Langhoff :
> 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
On Thu, Dec 12, 2013 at 1:29 PM, Eric S. Raymond wrote:
> I am almost certain the output of cvs-fast-export is stable. I
> believe the output of cvsps-3.x was, too. Not sure about 2.x.
IIRC, making the output stable is nontrivial, specially on branches.
Two cases are still in my mind, from when
On Thu, Dec 12, 2013 at 1:15 PM, Eric S. Raymond wrote:
> That terminology -- "flying fish" and "dovetail" -- is interesting, and
> I have not heard it before. It might be woth putting in the Jargon File.
> Can you point me at examples of live usage?
The canonical reference would be
http://cvsbo
Martin Langhoff :
> In my prior work, the "better" CVS importers would not have stable
> output, so were not appropriate for incremental imports.
That is disturbing. I would consider lack of stability a severe and
unacceptable failure mode in such a tool, if only because of the
difficulties it cr
Andreas Krey :
> But anyway, the replacement question is a) how fast the cvs-fast-export is
> and b) whether its output is stable, that is, if the cvs repo C yields
> a git repo G, will then C with a few extra commits yield G' where every
> commit in G (as identified by its SHA1) is also in G', and
Martin Langhoff :
> On Wed, Dec 11, 2013 at 11:26 PM, Eric S. Raymond wrote:
> > You'll have to remind me what you mean by "incremental" here. Possibly
> > it's something cvs-fast-export could support.
>
> User can
>
> - run a cvs to git import at time T, resulting in repo G
> - make commits t
On Thu, Dec 12, 2013 at 12:17 PM, Andreas Krey wrote:
> But anyway, the replacement question is a) how fast the cvs-fast-export is
> and b) whether its output is stable
In my prior work, the "better" CVS importers would not have stable
output, so were not appropriate for incremental imports.
And
On Thu, 12 Dec 2013 08:42:25 +, Martin Langhoff wrote:
...
> - run a cvs to git import at time T, resulting in repo G
> - make commits to cvs repo
> - run cvs to git import at time T1, pointed to G, and the import tool
> will only add the new commits found in cvs between T and T1.
I'm prett
On Wed, Dec 11, 2013 at 11:26 PM, Eric S. Raymond wrote:
> You'll have to remind me what you mean by "incremental" here. Possibly
> it's something cvs-fast-export could support.
User can
- run a cvs to git import at time T, resulting in repo G
- make commits to cvs repo
- run cvs to git impor
Martin Langhoff :
> On Wed, Dec 11, 2013 at 7:17 PM, Eric S. Raymond wrote:
> > I tried very hard to salvage this program - the ability to
> > remote-fetch CVS repos without rsync access was appealing
>
> Is that the only thing we lose, if we abandon cusps? More to the
> point, is there today an
On Wed, Dec 11, 2013 at 7:17 PM, Eric S. Raymond wrote:
> I tried very hard to salvage this program - the ability to
> remote-fetch CVS repos without rsync access was appealing
Is that the only thing we lose, if we abandon cusps? More to the
point, is there today an incremental import option, out
On the git tools wiki, the first paragraph of the entry for cvsps now
reads:
Warning: this code has been end-of-lifed by its maintainer in favor of
cvs-fast-export. Several attempts over the space of a year to repair
its deficient branch analysis and tag assignment have failed. Do not
use
48 matches
Mail list logo
