Re: [Gnu-arch-users] Re: Making microbranches popular

[Tom Lord]

    > From: Mirian Crzig Lennox <address@hidden>

    > Not a bad solution.  My only quibble there is that most of the really
    > useful Arch subcommands ('ancestry', 'star-merge', 'delta', etc.)
    > don't grok config names, so those operations become cumbersome.  We do
    > a lot of "cvs rdiff -r<ver1> -r<ver2> foo/bar/baz.c | more" around
    > here, for example, so developers would be looking for similar ease in
    > whatever new SCM we went to.

    > If it could be possible generally to specify a config name in place of
    > a revision name, that would certainly sweeten the deal.  What do you
    > think about moving Arch in that direction?

What are the "<ver1>" and "<ver2>" strings that you want to optimize
for?  Are these things like symbolic product release identifiers?

When I need that functionality, I typically use arch tags.  I create a
version (or versions) which will contain nothing but tag revisions and
map release ids to and from the names of those.

I happen to find it reasonable to make that mapping of names very
direct.  For example, I would use:


        tla--release--1.4--patch-5

to tag a revision of the tla tree that corresponds to release

        tla-1.4pre5

but, of course, if your non-isomorphic release names are a constraint
in your shop, you can't do quite that.

What you could do (just to mention one of many variations) is create a
tag version like that, but store the actual product release ids in the
"Summary:" line of the commit messages.   And then write a one-line
shell script that will let you say:


        % arel our-product-1.3alpha-5.x
        our-product--releases--0--patch-455

so that on command lines, you can say:

        `arel our-product-1.3alpha-5.x`

-t