On Thu, 19 Oct 2006 19:01:58 -0400, Aaron Bentley wrote: > I don't think this is true. The abandoned mainline does not need to be > destroyed. It can be kept at the same location that it always was, with > the numbers that it always had. So the number + URL combo stays > meaningful. Sure that's possible, but it gets rather unwieldy the more repositories you have involved. I've been arguing that bzr really does encourage centralized, not distributed development, and you were having trouble seeing how I came to that conclusion. Do you see how "maintain an independent URL namespace for every distributed branch" doesn't encourage much distributed development? > Additionally, the new mainline can keep a mirror of the > abandoned mainline in its repository, because there are virtually no > additional storage requirements to doing so. And this part I don't understand. I can understand the mainline storing the revisions, but I don't understand how it could make them accessible by the published revision numbers of the "abandoned" line. And that's the problem. > > But for these communications, revision numbers will not provide > > historically stable values that can be used. > > They certainly can. > > The coder says "I've put up a branch at http://example.com/bzr/feature. > In revision 5, I started work on feature A. I finished work in > revision 6. But then I had to fix a related bug in revision 7." "I've put this branch up" isn't historically stable... > As long as that coder is active ...which is what you just said there yourself. On the other hand, git names really do live forever, regardless of where the code is hosted or how it moves around. When I'm talking about historical stability, I'm talking about being able to publish numbers that live forever. It sounds like bzr has numbers like this inside it, (but not nearly as simple as the ones that git has), but that users aren't in the practice of communicating with them. Instead, users communicate with the unstable numbers. And that's a shame from an historical perspective. > This is true, but his code is likely to all land in the mainline at > once. Since his own revnos are more fine-grained, he's not likely want > to use the mainline revnos. What I'd like to be able to do, is advertise a temporary repository, and while using it, publish names for revisions that will still be valid when the code gets pushed out to the mainline. That is supporting distributed development, and everything I'm hearing says that the bzr revision numbers don't support that. > I felt that you were mischaracterizing my _statement_ that "it's > exceedingly uncommon for [revnos] to change" as an _argument_ "it's > exceedingly uncommon for [revnos] to change". The reality is that we > keep saying revnos don't change because git users keep saying "but what > if the revnos change?". OK. The original claim that sparked the discussion was that bzr has a "simple namespace" while git does not. We've been talking for quite a while here, and I still don't fully understand how these numbers are generated or what I can expect to happen to the numbers associated with a given revision as that revision moves from one repository to another. It's really not a simple scheme. Meanwhile, I have been arguing that the "simple" revision numbers that bzr advertises have restrictions on their utility, (they can only be used with reference to a specific repository, or with reference to another that treats it as canonical). I _think_ I understand the numbers well enough to say that still. Compare that with the git names. The scheme really is easy to understand, (either the new user already understands cryptographic hashes, or else it's as easy as "a long string of digits that git assigns as the name"). The names have universal utility in time and space, (for definitions of the the universe larger than I will ever be able to observe anyway). And the natural inclination to abbreviate the a name when repeating it, (note the recent post with bzr UUIDs exhibiting the same inclination), doesn't make the names any less useful since the abbreviation alone will work most always. The naming in git really is beautiful and beautifully simple. It's not monotonically increasing from one revision to the next, but I've never found that to be an issue. Of course, we do still use our own "simple" names for versioning the releases and snapshots of software we manage with git, and that's where being able to easily determine "newer" or "older" by simple numerical examination is important. I've honestly never encountered a situation where I was handed two git sha1 sums and wished that I could do the same thing. > If you're interested, it's called "Bugs Everywhere" and it's available here: > http://panoramicfeedback.com/opensource/ > > New VCS backends are welcome :-D Thanks, I hope to take a look at that at some point. > So actually, not all branches are treated equally by Git users. Public > branches are treated as append-only, but private branches are treated as > mutable. (It's the same with bzr users, of course.) Well, some users treat all branches as append only and shun rebase. [snip of remaining agreement of similarity between the tools] -Carl
Attachment:
pgpwJD95xuBW7.pgp
Description: PGP signature