Matthew D. Fuller wrote:
On Wed, Oct 18, 2006 at 08:38:24AM -0700 I heard the voice of
Carl Worth, and lo! it spake thus:
But as you already said, it's often avoided specifically because it
destroys locally-created revision numbers.
I think this has the causality backward. It's avoided because it
changes the ancestry of the branch in question, by rearranging the
left parents; this ties into Linus' assertion that all parents ought
to be treated equally, which I'm beginning to think is the base
lynchpin of this whole dissension.
Without a differentiation of the parents, there's no such creature as
a "mainline" on a branch, so it's hard to find anything to base revnos
on from the get-go; the whole discussion becomes meaningless and
incomprehensible then.
With the differentiation, numbering along the leftmost 'mainline'
You, and others, keep saying "leftmost". What on earth does left or
right have to do with anything? Or rather, how do you determine which
side anything at all is on?
makes sense, and fits the way people tend to work. "I did this, then
I did this, then I merged in Joe's stuff, then I did this", and the
numbering follows along that. And as long as it's the same branch,
those revnos will always be the same; I can't go back and add
something in between my first and second commits. THAT'S where revnos
are useful; referring to a point on given branch.
So long as the given branch is, in git-speak, "master"? I think I'm
starting to see how this would work, but I still fail to see how you can
then come up with revnos such as 2343.1.14.7.19, since the only ones
that seem to actually make any sense are the ones that track the
strictly linear development.
In git, this can be accomplished by auto-tagging each update of any
branch with a tag named numerically and incrementally, although no-one
really bothers with it.
Let's say you have the following graph, where A is the root commit, B
introduces the base for a couple of new features that three separate
coders start to work on in their own repositories. The feature started
on in D is logically coded as a two-stage change. F fixes a bug
introduced in D. I is the result of an octopus merge of all three
branches, where the three features are implemented and all bugs are
fixed (this is btw by far the most common pattern we have in our repos
here at work).
A
|
B
/|\
C | D
| | |\
| | E F
| | |/
| | G
| H /
\|/
I
Now a couple of questions arise.
- How do I do to get to C, D, E, F, G and H?
- When these get merged, which one will be considered the "left" parent,
and why?
So there are some aspects of the bzr design that rob from its
ability to function as a distributed version control system. It
really does bias itself toward centralization, (the so called "star
topoloogy" as opposed to something "fully" distributed).
That depends on what you mean by 'bias' (and for that matter, what you
mean by 'centralization'; I think that's being used in very different
ways here). If you don't care about the ancestry changes, you can go
ahead and change it around by merging and pushing like there's no
tomorrow, and it'll keep up just fine. Some attributes of it like the
revnos which assume you do care about the ancestry simply cease to be
of any applicability.
How deep will I have to dig to get the immutable revids instead?
That doesn't make it a useless feature, any
more than diff being inapplicable in a branch I'm using to store
binary files makes diff useless; it's just not one that's meaningful
in a given case.
Binary diffs work just fine, thank you very much ;-)
bzr (the project) does care about the ordering of the parents, so it
doesn't do that. bzr (the tool) assumes that the majority of its
users will care, which is why it has revnos; because in the case where
you don't disturb the ancestry of given branches, revnos are very
useful in reference to that branch.
So even a project that's very oriented around a single, central tree
can get a lot of benefit from being able to share things arbitrarily
between any two given repositories.
I agree wholeheartedly. That's one of the reasons I'm using bzr, even
though 95% or better of what I do is very oriented around single,
central trees, after all 8-}
I'm sure it's supported. The question is whether or not bazaar makes it
easy for those developers to exchange valuable information (revids,
since their revnos will be mixed up) so they can communicate detailed
info about "commit X introduced a bug in foo_diddle(). I fixed it in
commit Y, so if you merge it we can release". If revids are always
printed anyways, I see even less need for revnos. If it's hard to get
the revids I wouldn't consider the truly distributed workflow supported
any more than I consider CVS file rename support á la "just hand-edit
the ,v-files" to actually work.
--
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