Re: [Gnu-arch-users] Re: Working out a branching scheme [was: tag --seal --fix]

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    >> A tactic that you might consider: use CVS or RCS or (least likely but
    >> possible) SVN to hold the annotate database.   The problem is reduced
    >> to plumbing and namespace mapping.

    > Another possible tactic: use Arch.  Tag the revisions to be annotated, 
    > (with --no-cacherev) and store the annotations in the patch-log of the 
    > tag revision.

Holy Cow!  That's close to an idea that I think could be _really_
sweet.  Are you sure this isn't what you meant?:

Have annotation work on a particular version, possibly on a linear
list of versions.  Make tool like `patch' but that updates an
annotated file (it only has to work for known-to-be-exact patching).

Now, derive a new version from the one you want to annotate.   So:

        tla--devo--1.3          =>      Annotated-tla--devo--1.3

with a 1:1 mapping of revisions.

You'd also need some fanciness to get the base-0 revision right.

That'll roughly doubles the archive storage needed and puts more
pressure on revlibs --- but that's _all_ it does.

In fact, that's really nice for the few reasons that:

~ existing mechanisms already work for mirroring the
  annotate-optimized database.  For example, I could mirror one that
  somebody else builds rather than having to send particular viewing
  queries to their server.  And: the existing revlib mechanism can
  optimize queries.

~ browsing annotated trees is trivial

~ you get a convenient way to view annotations as of a particular 
  revision --- e.g., no new mechanism is made to keep track of what
  a given file was called at a particular point in history



Best of all: the whole thing looks _very_ simple to implement.  I
might even do it myself (by which I don't mean to discourage anyone
from beating me to it).

-t