Re: VCS comparison table

[Jakub Narebski <jnareb@gmail.com>]

Dnia sobota 21. października 2006 15:01, Matthew D. Fuller napisał:
> On Fri, Oct 20, 2006 at 02:48:52PM -0700 I heard the voice of
> Carl Worth, and lo! it spake thus:
> > 
> > The entire discussion is about how to name things in a distributed
> > system.
> 
> I think we're getting into scratched-record-mode on this.
> 
> 
> Git: Revnos aren't globally unique or persistent.
> 
> Bzr: Yes, we know.
> 
> G: Therefore they're useless.
> 
> B: No, they're very useful in [situation] and [situation], and we deal
>    with [situation] all the time, and they work great for that.
> 
> G: But they fall apart totally in [situation].

G: But revnos force centralized/star-topology development. And even in
   [situation] have [disadvantages].

> B: Yes, so use revids there.
> 
> G: So use revids everywhere.
> 
> B: Revnos are handier tools for [situation] and [situation] for
>    [reason] and [reason].

G: Shortened sha1 commit-ids are almost as handy.

> *brrrrrrrrrrrrrrrrip!!!*    *skip back to start*

There _are_ terminology conflicts. For example bzr "branch" is roughly 
equivalent to one-branch git "repository"; bzr "repository" is just 
collection of branches sharing common storage, which is similar to set 
of git "repositories" with .git/objects/ linked to common object 
repository (storage area) or appropriately set alternates file 
(although that is not common usage in git, and for example you would 
have to be carefull with running git-prune); bzr "lightweight checkout" 
is equivalent to nonexistent "lazy clone"/"remote alternates" discussed 
on git mailing list but not implemented because of performance 
concerns; bzr "normal checkout" is I think similar to git "shared 
clone" (but shared clone is limited to repositories on the same 
filesystem); bzr "heavyweight checkout" is roughly equivalent to 
one-branch-only "clone" in git or cg (cg = Cogito).

And there are differences in opinion. For example "simple namespace for 
revisions" which is important for bzr, is superficially simple for git 
(as it works only for centralized approach, and for leaf repositories 
you have to have access to central repository to get final revnos); on 
the other hand "not simpleness" of git's sha1 identifiers is not that 
complicated in everydays work, as one usually use branch and tag names, 
<ref>~<n> and <ref1>..<ref2> syntax, sometimes shortened sha1 names and 
full sha1 names only rarely. For bzr it is more important to tell from 
revno which commit on branch was earlier, for git it is more important 
that commitids never ever change; we can use git commands to check 
which commit was earlier. For bzr plugins are important, for git it is 
important to be easy to add new commands, using scripts for fast 
prototyping.

> > It may be that the centralization bias
> 
> I think it's more accurately describable as a branch-identity bias.
> The git claim seems to be that the two statements are identical, but I
> have some trouble swallowing that.

When two clones of the same repository (in git terminology), or two 
"branches" (in bzr terminology), used by different people, cannot be 
totally equivalent that is centralization bias. By equivalent I mean 
that "old history" is exactly the same (the same diagram, the same
identifiers - make it usually used identifiers).
 
The fact that you have two different commands, "merge" vs "pull"
for using in one mother/mainline "branch" vs other "branches" tells
us that there is bias towards centralization.

> > I'm still not sure exactly what a bzr branch is, but it's clearly
> > something different from a git branch,
> 
> The term is somewhat overloaded, which is why it's causing you trouble
> (and did me).  It refers both to the conceptual entity ("a line of
> development" roughly, much like what 'branch' means in git and VCS in
> general), and to the physical location (directory, URL) where that
> branch is stored, and where it'll often have a working tree.  Branches
> are always referred to by location, never by name.

I'd rather use other name then. Perhaps "forks" for physical "branch",
i.e. branch metadata (like revno to revid mapping) + object repository 
or pointer to it + optionally working area/working files. 

[...]
> > (since pull seems the only way to synch up without infinite new
> > merge commits being added back and forth).
> 
> The infinite-merge-commits case doesn't happen in bzr-land because we
> generally don't merge other branches except when the branch owner says
> "Hey, I've got something for you to merge".  If you were to setup a
> script to merge two branches back and forth until they were 'equal',
> yes, it'd churn away until you filled up your disk with the N bytes of
> metadata every new revision uses up.

And you say that bzr is not biased towards centralization? In git you 
can just pull (fetch) to check if there were any changes, and if there 
were not you don't get useless marker-merges.


Take for example two simple git scenarios:
1. Single branch repository. We have two clones of the same repository, 
both with only one branch, 'master', both working on this branch, and 
both considered equal. If only one person worked on branch, "pull" 
would result in fast-forward. If both worked on branch, "pull" would 
result in merge. This is the "diamond" example by Pasky, which 
explained why git doesn't treat first parent like special - because of 
fast forward. Bzr treats first parent/mainline/"the branch" special 
therefore it generates superficial merge commits if we preserve revnos; 
BTW doesn't "pull" clobber your changes?

2. But the preferred git workflow is to have two branches in each of two 
clones. The 'origin' branch where you fetch changes from other 
repository (so called "tracking branch") and you don't commit your 
changes to (by convention, as git doesn't protect the branch from 
commiting to, although it would refuse to fetch in non fast-forward 
case unless forced). You put your work in the 'master' branch, and you 
merge 'origin' branch into 'master'. This allows for example fetching 
changes to 'origin' but _not_ merging them immediately into 'master',
for example if you are in the middle of some larger work byt want to 
check what other side did to not to create conflict if not neccessary.

-- 
Jakub Narebski
Poland