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 conclusion. 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? -Carl
Attachment:
pgpviwXXREE2d.pgp
Description: PGP signature