Re: One branchpoint discrepancy

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

Am 30.10.2017 um 20:30 schrieb Daniel J Sebald:

>  I'd sort of like to put effort into the right place.  I've cloned the
> cvs-fast-export utility and I'm willing to help on matters, so if its 
> possible I wonder if we could enhance the merging aspect of that utility.

I rather doubt any good will come from that.  Nobody understands that 
utility anywhere near well enough to be able to modify it on short 
notice without risking total break-down.  At this point it is, 
essentially, magic.

> Yes, there is a bit of ambiguity in merges with CVS, it just isn't 100% 
> accurate to identify exactly what the programmer had checked out when 
> compiling and subsequently did a checkin.

Not really, because there _are_ no recorded merges in CVS.  If merges 
happen, they do so in somebody's working copy.  To the repository, they 
only ever appear as check-ins, without any indication whether the new 
content was created by some kind of merge, or by just writing it manually.

> There might be some ambiguity about the state of other files at this 
> point, but I would say simply recall the BETA_344_989422 state from CVS 
> and call that the state for the merge and generate all git diffs 
> accordingly, perhaps that's not the exact methodology.

That won't work at all.  The primary conflict is that CVS has individual 
branch structures for every member file, whereas git branches the entire 
repository.  Those two concepts don't mix and match.  BETA_344_989422 
may be the right join point for this particular file, but that's most 
likely the _only_ file for which that's the case.  Basically every 
single tag ever made in CVS can contain one or more file joins from the 
vendor branch onto the trunk.  Some are still waiting to happen.

Normal CVS repositories would have every single file starting off at 
1.1.  I.e. the first tag would be on 1.1 revisions of every file, and 
all development would start from there.  The conversion tools have no 
problem at all with this set-up.

But our repository was started by a "cvs import", and received some 
further imports after that, and that changes everything.  It means that 
all our original files started at revision 1.1.1.1, and progressed along 
that 1.1.1.* branch, until they were first modified.  None of them ever 
got a tag on it 1.1 revision --- 1.1. was really never used for anything.

Every time a file that was on the vendor branch until that point (and 
remember, for some files that still hasn't happened today!) is checked 
in, that particular file is essentially merged over from the vendor 
branch onto the trunk --- but in the archive this merge appears as an 
ordinary check-in of a revision 1.2.

E.g. even though in a RCS revision tree, it appears like this:

	1.1 --*---> 1.2
	       \
	        +-> 1.1.1.1 --> 1.1.1.2

the real sequence of active revisions for gnuplot.rot is:

	1.1.1.1 --> 1.1.1.2 --> 1.2

Other files have different sequences, and different points in time at 
which they made their transition 1.1.1.1 --> 1.1.1.2, or 1.1.1.{n} --> 
1.2.  Some even have branches inside the vendor branch (1.1.1.2.2.1)

The vendor branch may best be grafted into the trunk _before_ the 1.1 
initial import, and replace that entirely.  I.e. we might imagine that 
the above sequence was transformed into

	1.0 --> 1.1 --> 1.2

Files with more stuff going on in their vendor branch would have to dip 
into negative numbers, i.e.

	1.1.1.1 --> 1.1.1.2 +-> 1.1.1.3 --> 1.1.1.4 --> 1.2 ...
	                    |
	                    +-> 1.1.1.2.2.1

would (imaginatively) turn into

	1.(-2)  --> 1.(-1)  +-> 1.0 ------> 1.1 ------> 1.2 ...
  	                    |
                             +-> 1.(-1).2.1

Realistically all the revision numbers in the entire archive would have 
to be shifted up such that the chain really does start at 1.1:

	1.1  -----> 1.2 --*---> 1.3 ------> 1.4 ------> 1.5 ...
  	                   \
                             +-> 1.2.2.1

Unfortunately, the way RCS ,v files are organized, this shift can only 
be performed by parsing and re-encoding every revision on the vendor 
branch.  (The direction the diffs are recorded is from the head all the 
way down to 1.1, and from there _up_ along the vendor branch).  And 
because of the way CVS uses RCS ,v files, every one of them has to be 
transformed individually.

_That_ is the transformation that needs to be done in order for 
conversion tools not to have any problems with the vendor branch.  And 
because the transformation differs for every RCS archive, it has to be 
done either directly on the CVS repository, or the importer has to 
pretend it had happened that way.

Let me reiterate: to the best of my understanding, no process working on 
an already converted git repository has any realistic chance to perform 
this operation correctly.  It has to be done on the CVS import side.