[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: UNS: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

From: Bob Archer <Bob.Archer_at_amsi.com>
Date: Mon, 13 May 2013 18:35:35 +0000

> On Mon, May 13, 2013 at 12:23 PM, Andreas Krey <a.krey_at_gmx.de> wrote:
> > On Mon, 13 May 2013 11:32:13 +0000, Les Mikesell wrote:
> > ...
> >> Maybe it is just my misconception, but I've always thought of the
> >> difference between svn and git as being that svn conceptually tracks
> >> complete revisions although sometimes it might generate or store
> >> differences for some operations or internal storage convenience,
> >> where git tracks changesets although it often has to generate
> >> complete revisions.
> >
> > That indeed is just a misconception. git even goes to define exactly
> > how each commit (aka revision) is stored including its checksum.
> > This even though is it then going to internally store that in a dense
> > packfile format.
> What it computes internally or uses as an internal storage isn't quite the point.
> Svn would also always compute the differences even though
> it really only cares about the full revisions. What does git do if
> you try to double-merge a change? Does it know about the previous merge by
> its changeset commit id, look at the contents that are already present, or just
> do it twice?

Been a while since I have really got into the git internals, but I think each changeset has a SHA1 hash... if a changeset with that hash is already in a branch merging won't do anything... there will be nothing to merge.

That said, I don't even think you can specify in git "what" to merge it just merges all the changes. I think it is possible to do a cherry-pick, but I think that creates a diff basically and applies that to the target.


> >> The nature of branches seems to relate better to
> >
> > No, the basic difference is that VCS operating on the whole tree can
> > only have branches (and thus merge info) on the whole tree either, so
> > you *can't* go like subversion does and map branches into the tree and
> > need to have them (and tags) as a separate concept.
> I can see why it might be a problem to support concurrent nested branch
> changeset roots but that scenario is problematic any way you look at it. Why
> would it be a problem to support parallel branching roots - perhaps with some
> enforcement on the source/dest top levels having some common parent?
> > SVN, instead of having branches as a separate concept, also stores
> > whole trees, but instead additionally stores 'this came from there' or
> > 'that was merged here' as a separate concept.
> But does 'that was merged here', really know about the commit changeset
> where the change originated?
> --
> Les Mikesell
> lesmikesell_at_gmail.com
Received on 2013-05-13 20:36:08 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.