Re: The first repository branch, "Windows linestyle fix."

[Hans-Bernhard B. <HBB...@t-...>]

Am 29.10.2017 um 20:01 schrieb Daniel J Sebald:
> I've experimented with something called cvs2git, which I believe does a 
> pretty good job of constructing branches and merges, but has some 
> drawbacks.  
[...]
> It's major drawbacks are:
> 
> 1) No corrected author info.
> 
> 2) All of the RCSid strings are replaced by empty string, e.g.,

That's not a drawback; it's a necessary consequence of moving to git. 
One way or another, all these strings (technically: RCS-style keywords) 
have to go.

For comparisons of working copies, I would therefore strongly recommend 
adding an appropriate ignore option to 'diff', such as

	diff -ur '--exclude=.git' -I '\$[A-Z]*[a-z]*'

to avoid getting side-tracked.

> In contrast, I would summarize cvs-fast-export's deficiencies as follows:
> 
> 1) I think cvs-fast-export is getting hung up on the scenario by which 
> the "Initial import of beta340." branch is the exact same time as the 
> "Initial revision".  

> I'm not quite sure how Lars managed that.  

Lars just used the feature of CVS advertised for the job he was doing at 
the time: "cvs import".  This creates a vendor branch, which behaves 
rather differently from ordinary branches.  One side effect of that is 
that the 1.1 revisions ("Initial revision") of all files that existed at 
the time have another revision at the exact same time, numbered 1.1.1.1, 
on the vendor branch.

These 1.1 revisions really only exist as an anchor point for the vendor 
branch --- they never appear in working copies.  You can still see that 
today: files that already existed back then, and never changed since, 
still have revision 1.1.1.1:

$ cvs status demo/world.cor
===================================================================
File: world.cor         Status: Up-to-date

    Working revision:    1.1.1.1
    Repository revision: 1.1.1.1 /cvsroot/gnuplot/gnuplot/demo/world.cor,v
    Sticky Tag:          (none)
    Sticky Date:         (none)
    Sticky Options:      (none)

One weird aspect of vendor branches is that the first modification of 
such a file will not get revision number 1.1.1.2, as might be expected, 
but rather 1.2.  That's because revision 1.1.1.2 is reserved for the 
next "cvs import".