Menu
▾
▴
Re: One branchpoint discrepancy
|
From: Eric S. R. <es...@th...> - 2017-10-31 17:11:30
|
Hans-Bernhard Bröker <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.
Sadly, HBB is correct. The way I modified Keith's original code was by
working from the outside in - there is a hard core, now in merge.c, that nobody
understands.
> 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.
This is good analysis. You have described the problem more clearly than
*I* undetstood it.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
|
