On 02/01/2020 02:58, Alexandre Oliva wrote: > On Dec 30, 2019, "Richard Earnshaw (lists)" <richard.earns...@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.
