Re: Proposal for the transition timetable for the move to GIT

["Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>]

On 02/01/2020 02:58, Alexandre Oliva wrote:
> On Dec 30, 2019, "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com> wrote:
> 
>> Right, (and wrong).  You have to understand how the release branches and
>> tags are represented in CVS to understand why the SVN conversion is done
>> this way.
> 
> I'm curious and ignorant, is the convoluted representation that Maxim
> described what SVN normally uses for tree copies, that any conversion
> tool from SVN to GIT thus ought to be able to figure out, or is it just
> an unusual artifact of the conversion from CVS to SVN, that we'd like to
> fix in the conversion from SVN to GIT with some specialized recovery for
> such errors in repos poorly converted from CVS?
> 
> Thanks in advance for cluing me in,
> 

I think it mostly comes from cvs2svn.  You probably could manufacture
something similar directly in SVN, but you'd have to try very hard to
create such brain damage.  Some thing like

svn cp ^/trunk ^/branches/foo
svn rm -f ^/branches/foo/fred.c
svn cp ^/branches/bar/fred ^/branches/foo/fred.c
...
svn ci

Which would create a copy of trunk in foo with a copy of fred.c from the
bar branch etc.

Normal SVN copies to a branch use a simple node copy of the top-level
directory, which is why branching in SVN is cheap (essentially O(1) in
time).

R.