David Thornley wrote:
[...]
> .main.latest
> types easy too. (. is in the central part of the three basic rows
> of the QWERTY keyboard, and doesn't require a shift key.)
".main" is fine by me.
[...Regarding support for redundant ".latest" suffix for branch tags.]
>And similarity with the main trunk. There's no great harm in synonyms.
Except people have to write the code to support them, spend the effort
to understand that code when debugging, maintain that code, test
that code. If it doesn't add significant value, why put it in? synonyms
like this don't add real value, IMHO
[...]
>JohnC> Its nice to be able to easily figure out where your branch sprouted
from
>JohnC> using an abstract mechanism.
>>
>Or an explicit tag.
Yeah, I already started working on this a little bit, but I'm
not 100% sure my approach is sound yet.
> One thing that everybody says is to tag the base of any branch being
> cut. Any more or less mechanical thing that lots of people say should
> always be done is a prime candidate for automation.
It's clear that the revision numbers for the "origin" of a branch
tag can be calculated, so it might be better to calculate them rather
than automatically put a tag in so as not to store redundant information
that could get out of sync. That's the approach I'm taking, calculate
those revisions as needed rather than tag automatically. This also
means it will work with existing repositoires.
[....]
> I may be slow today, but I don't see how merging the metadata is going
> to accomplish all this [stuff that vendor branches do].
And how did merging (meta)data get into this thread? I'm not signing
up for _that_, no matter how many people refuse to change the
subject line. ;-) Waaaay too hard, and I'm not really sure I even like the
idea anyway.
-- steve
