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?
>> 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:30:11 CEST