Re: VCS comparison table

[Andreas Ericsson <ae@op5.se>]

Matthew D. Fuller wrote:
> 
>> 3. pull from each other frequently to keep in sync.
>>
>> this changes the topology to
>>
>>    Master
>>    /   \
>>  dev1--dev2
>>
>> if they do this with bzr then the revno's break, they each get extra
>> commits showing up (so they can never show the same history).
> 
> These two are either/or, not and; either they pull (in which case
> their old mainline is no longer meaningful), or they merge (in which
> case they get the 'extra' merge commits).
> 
> 
>> in git this is a non-issue, they can pull back and forth and the
>> only new history to show up will be changes.
> 
> In git, this is a non-issue because you don't get to CHOOSE which way
> to work.

Yes they do. They can (and in this case probably will) create a 
topic-branch named "the-other-dev/featureX" and keep it solely for 
tracking the other peers changes, keeping their own topic-branch for 
their own changes, and another branch where they merge both changes in, 
or cherry-pick from each branch to get to the desired result fast. This 
works easily because in git
a) branches are as cheap as I can ever imagine an SCM making them.
b) the "slice the DAG and view anything you like from any branch you 
like any time you like and mix them however you want" approach of the 
visualizers makes it trivial for a 10-year old fledgling programmer to 
see what changes what, and where, and by whom, and why.

The "b" above was a feature I didn't know I needed until it became 
available to me. Thanks to Paul Mackerras (spelling?) for creating the 
wonderful gitk tool, and to Marco Costalba for making a faster and, imo, 
more capable version of it.

>  You always (if you can) pull and obliterate your local
> mainline.  In bzr, it's only an 'issue' because you CAN choose, and
> CAN maintain your local mainline.

Git puts emphasis on code. Bazaar puts emphasis on developers and 
branch-structure. Depending on your preferrence, I imagine one suits 
some people better. I really, really, really don't care if my branch-tip 
gets moved because I hadn't made any changes to it while the other dev 
hacked away or if it causes a merge because we had decided to work on 
different parts of the feature. Perhaps this is a result of the insanely 
good visualizers (kudos again to Paul and Marco) that easily lets me see 
who did what when and where anyways. What I *do* care about is being 
able to easily make sure all the devs have the same code to work and 
test with.

>  You CAN choose, right now, to do a
> git and pull back and forth and only new history show up as changed by
> creating a 'bzr-pull' shell script that does a 'bzr pull || bzr merge'
> (though you'd be a lot better off adding a '--fast-forward-if-you-can'
> option to merge and aliasing that over).
> 
> More basically, though, I don't think that "histories become exactly
> equivalent" is a necessary pass-word to enter the Hallowed City of
> Truely Distributed Development.

The only issue I have with bzr's revno's and truly distributed setup is 
that, by looking at the table, it seems to claim that you have found 
some miraculous way to make revnos work without a central server. Since 
everyone agrees that they don't, this should IMO be listed as mutually 
exclusive features.

On a side-note, git has made my life easier, so I childishly want to 
defend it and see it on top of every list in the world. Something I'm 
sure I share with more people on this list and with some of the bazaar 
users/devs. ;-)