VCS comparison table

Carl Worth cworth at
Thu Oct 19 06:21:15 BST 2006

On Wed, 18 Oct 2006 23:10:11 -0400, Aaron Bentley wrote:
> It is fine to say all branches are equal from a technical perspective.
> - From a social perspective, it's just not true.

That's actually a very important insight, but supporting the wrong

In a healthy situation, the only thing that makes a branch special are
social issues, such as you describe. That's how it should be.

But think about your favorite example of an unhealthy social situation
around a software project and a big, nasty fork. Every example I can
think of involves some technical distinction that makes one branch
more special than another.

Now, those situations also involve social problems, and those are even
more significant. But the technical blessing of one branch does not
help. And I think it contributes to the social problems in many cases.

So, I think the technical thing that is distributed version control is
an extremely important thing for us to use to help maintain healthy
social software projects. Reducing the technical hurdle of a fork, (to
where continual forking is actually a totally expected part of the
process), is a very healthy thing.

Now, both bzr and git are distributed systems, and either one will
help a great deal in the respects I'm talking about compared to
something like cvs.

As far as the revision numbers, my impression is that the numbers
would be confusing or worthless if I were to use bzr the way I'm
currently using git, as they certainly could not remain stable.

> In bzr development, it's very rare for anyone's revision numbers to change.

Which just says to me that the bzr developers really are sticking to a
centralized model. That's fine, but it does have impacts, and the tool
really does seem to have some bias toward this.

> I think you're implying that on a technical level, bzr doesn't support
> this.  But it does.  Every published repository has unique identifiers
> for every revision on its mainline, and it's exceedingly uncommon for
> these to change.

Every argument you make for the number change being uncommon just
strengthens the argument that it will be all that more
confusing/frustrating when the numbers do change.

In cairo, for example, we've made a habit of including a revision
identifier in our bug tracking system for every commit that resolves a
bug. I like having the assurance that those numbers will survive
forever. And it doesn't matter if the repository moves, or the project
is forked, or anything else. Those numbers cannot change.

I understand that bzr also has unique identifiers, but it sounds like
the tools try to hide them, and people aren't in the habit of using
them for things like this. Do bzr developers put revision numbers in
their bug trackers? Is there a guarantee they will always be valid?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 

More information about the bazaar mailing list