Re: VCS comparison table
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Oct 18, 2006, 00:46 UTC
- Message-ID
- <200610180246.18758.jnareb__16169.8141987019$1161134921$gmane$org@gmail.com>
- In-Reply-To
- <45357411.20500@utoronto.ca>
Aaron Bentley wrote:
Show 31 quoted lines
> Linus Torvalds wrote: >> >> On Tue, 17 Oct 2006, Aaron Bentley wrote: > >>> 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.
Show 5 quoted lines
> > 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.
Show 5 quoted lines
> > 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---*Show 6 quoted lines
> > 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.
Show 6 quoted lines
> > 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