On Mon, May 13, 2013 at 12:23 PM, Andreas Krey 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

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2021 Grokbase