-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carl Worth wrote:
quoted text
> On Thu, 19 Oct 2006 19:01:58 -0400, Aaron Bentley wrote:

quoted text
> Do you see how "maintain
> an independent URL namespace for every distributed branch" doesn't
> encourage much distributed development?

I understand your argument now.  It's nothing to do with numbers per se,
and all about per-branch namespaces.  Correct?

quoted text
>>             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.

I meant that the active branch and a mirror of the abandoned branch
could be stored in the same repository, for ease of access.

Bazaar encourages you to stick lots and lots of branches in your
repository.  They don't even have to be related.  For example, my repo
contains branches of bzr, bzrtools, Meld, and BazaarInspect.

quoted text
> 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.

I can see where you're coming from, but to me, the trade-off seems
worthwhile.  Because historical data gets less and less valuable the
older it gets.  By the time the URL for a branch goes dark, there's
unlikely to be any reason to refer to one of its revisions at all.

quoted text
> 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.

When you create a new branch from scratch, the number starts at zero.
If you copy a branch, you copy its number, too.

Every time you commit, the number is incremented.  If you pull, your
numbers are adjusted to be identical to those of the branch you pulled from.

Is that really complicated?

quoted text
> 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.

Sure.  It's the "favors centralization" thing that I don't agree with,
but I now understand your argument.

quoted text
> 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").

In my experience, users who don't understand distributed systems don't
understand why UUIDS must be used as identifiers.

quoted text
> The naming in git really is beautiful and beautifully simple.

Well, you've got to admit that those names are at least superficially ugly.

quoted text
> 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.

What's nice is being able see the revno 753 and knowing that "diff -r
752..753" will show the changes it introduced.  Checking the revo on a
branch mirror and knowing how out-of-date it is.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFOCEf0F+nu1YWqI0RAhgtAJwK4jkWFjjF2iHJb1VyXqgszsHElACff2U7
olZJiAED80tIS6kgkqFsJps=
=BkRZ
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html