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. ;-)
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html