This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposal for the transition timetable for the move to GIT
- From: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: Alexandre Oliva <oliva at gnu dot org>
- Cc: Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, GCC Development <gcc at gcc dot gnu dot org>, Joseph Myers <jsm at polyomino dot org dot uk>, "Eric S. Raymond" <esr at thyrsus dot com>, Jeff Law <law at redhat dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>, Mark Wielaard <mark at klomp dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Thu, 2 Jan 2020 10:58:45 +0000
- Subject: Re: Proposal for the transition timetable for the move to GIT
- References: <20191216133632.GC3152@gate.crashing.org> <20191216135451.GA3142@thyrsus.com> <20191216140514.GD3152@gate.crashing.org> <alpine.DEB.2.21.1912161407130.3352@digraph.polyomino.org.uk> <20191216153649.GE3152@gate.crashing.org> <a16acfd7be55efb17ebd767d03eec6bea4159ffe.camel@redhat.com> <or36d83jv0.fsf@livre.home> <20191225120747.GA96669@thyrsus.com> <orh81n1uv0.fsf@livre.home> <alpine.DEB.2.21.1912261054320.27097@digraph.polyomino.org.uk> <20191226111633.GJ10088@tucnak> <5DCEA32B-3E36-4400-B931-9F4E2A8F3FA5@linaro.org> <155B5BFD-6ECF-4EBF-A38C-D6DD178FB497@linaro.org> <2b6330f2-1a00-ac89-fd3c-4b70e5454f4b@arm.com> <9B71A0F7-CD93-4636-BFC7-1D1DBC040F07@linaro.org> <ba0755ff-496c-4d7b-268c-b0d5dab1aa9e@arm.com> <6EE7BD53-6677-49D2-BCDD-56CD7DA855E9@linaro.org> <f767537a-4a9a-4116-9832-fe83cfb16914@arm.com> <ormub6wolx.fsf@livre.home>
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.