Re: [Monotone-devel] Re: Branch naming conventions

[Brian P. Campbell]

On Dec 12, 2004, at 3:00 AM, Nathan Myers wrote:

> How about "Zebulon Carter, 411 Grant Rd., Eugene, Oregon, USA".
> Awkward and unfamiliar, isn't it?  Of course, Russia does it the
> other way, but I'm not sure what side that argues for.  UK e-mail
> addresses used to be half-big-endian, back in the 80s -- user name on
> the left, but big-endian domain on the right; they seem to have given
> those up.  Likewise UUCP paths, on both counts.

There are examples of both little- and big-endian naming systems in all 
kinds of fields. There's no real reason to prefer either one 
intrinsically, but big-endian matches how we sort numbers and words, so 
it's somewhat natural to extending that to other things we want to 
sort. As has been pointed out, people frequently put names of people 
into big-endian form to make sorting easier. And while written 
addresses are in a little-endian representation, for zip codes we use 
big-endian representation. Dates (in the US), are mixed M/D/Y, while 
elsewhere they are little endian, but time is big-endian. When defining 
standard date and timestamp formats, however, people generally make the 
dates big-endian for clarity and consistency.

It seems to me that in general, it's fairly arbitrary what is chosen 
when there are a fixed number of fields, but when you can keep adding 
more, the direction it can be extended in must match the direction text 
goes. For instance, in specifying location, people use a little endian 
system, since you can always specify a superset of a location. "Zebulon 
Carter, 411 Grant Rd., Eugene, Oregon, USA, North America, Earth, Sol, 
Milky Way" etc. But when the specifiers need to get more specific as 
you add more on, you use a big endian system (like filesystems). I 
think this may be part of the reason why people generally don't use 
domain names very hierarchically; it's an unnatural order, to have 
things extend in the opposite direction from the way text is read.

Or maybe I'm just making stuff up. I don't really know. But it seems to 
me, somehow, that big-endian is better for branch names than 
little-endian, although I agree that the reversed domain name style is 
awkward. I think that URIs, or URIs without a scheme, would work much 
better. Actually, URIs without a scheme could just be arbitrary / 
separated hierarchies with the convention that the first element is the 
domain name of the entity that "owns" the branch.

> Incidentally, it was a big mistake in Java to use domain names at all,
> just as it's an equally big mistake to use any trademarked name in a
> C++ namespace name.  Software changes ownership frequently, domain
> names moreso.  If there's something worse than having some defunct
> company's name plastered all over your source files (and your
> customers'), it _might_ be having it unalterably in the branch names
> of your SCM.  But I don't understand monotone well enough to know
> whether this could actually be a nuisance.

I don't think this would be a problem in monotone. If the company 
changes, or changes domain, or whatever, just create a branch with the 
new name. Problem solved. You'll have lots of certs of the old code 
being in the old branch, but it seems pretty reasonable to keep track 
of where the code came from. None of the new commits will happen to the 
old branch, so the only place you'll notice it is in the history. This 
is much better than naming classes with the domain name, where that 
fixes an API that other people depend on, and can only be fixed with a 
global search and replace.