Re: VCS comparison table

Aaron Bentley wrote:

Linus Torvalds wrote:

quoted

On Tue, 17 Oct 2006, Aaron Bentley wrote:

quoted

quoted

Excuse me? What does that "throws away your local commit ordering" mean?

Say this is the ordering in branch A:

a
|
b
|
c

Say this is the ordering in branch B:

a
|
b
|\
d c
|/
e

When A pulls B, it gets the same ordering as B has.  If B did not have e
and c, the pull would fail.

Sure. But that doesn't throw away any local commit ordering. The original
order (a->b->c) is still very much there.

After the pull, it's no longer the mainline ordering for the branch.  c
is represented a revision that was merged into the branch, while d is
represented as a commit on the mainline of the branch.

Well, that is another example while generation number is/can be global,
any numbering of branches must be local-only.

quoted

The fact that there was a branch
off 'b' and there is also (a->b->d) and a merge of the two at 'e' doesn't
take away anything from the original local commit ordering.

It means the the order that revisions are shown in log commands changes,

That doesn't matter...

and the revision numbers can change.

...but that means that revision numers are totally, absolutely useless.
Unless by some miracle of engineering, or adding namespace, they can be
made unchangeable.

quoted

But that's a totally specious "record". It has no meaning in a distributed
SCM. There is absolutely zero semantic information in it.

It records the committer, the date, the commit message, the parent
revisions.

All totally empty information. What should be commit message? I have
fetched changes from remote repository? You can remove one of parents
(the one of pointing to before fast-forward "merge") without changing
reachability.

              ---------
             /         \
     *--*---x---*---*---y---*

quoted

The fact that you _locally_ want to remember where you were is a total
non-issue for a true distributed system. You shouldn't force everybody
else to see your local view - since it has no relevance to them, and
doesn't add any information.

Nobody is forced to use your local view.

But if you record "fast-forward merge", you force all people pulling
from your repository to have this purely local and without any significant
information "I have fetched then" marker.

quoted

In other words, the empty merge is totally semantically empty even in the
bazaar world. Why does it exist?

It exists because it is useful.  Because it makes the behavior of bzr
merge uniform.  Because in some workflows, commits show that a person
has signed off on a change.

Signing off the fact of fetching changes? For true merge you are signing
off the fact that there were no conflicts, or you sign off your conflict
resolution.

It's not something special-- it's just another commit, like regular
commits, and merge commits.  It would be harder to forbid than it is to
permit.

Actualy the check is very easy. And you have to do similar check when
fetchin/pushing to ensure that you don't clobber your changes.
-- 
Jakub Narebski
Poland