Re: [Gnu-arch-users] [RFC] New branching method proposed (semi/delta-branching)

[Tom Lord]

    > From: Christian Neumair <address@hidden>

    > Branches are usually as huge as the original repository, since you
    > star-merge the "master" repository and commit the stuff to your custom
    > branch. This could be very data-intensive, especially when managinng big
    > projects like Xouvert. I gained my experiences using Rhythmbox, an
    > excellent audio archiving software you might know. My idea is some
    > semi-branching method where every patch in my private semi-branch is
    > against a particular patch of a master repository. I have no idea
    > whether this will work or how a possible implementation would look like,
    > it would de-facto be a delta-branch containing only some patches that
    > has a reference branch/repository/patch.
    > Note that this is just an idea by a naive person that doesn't know much
    > about how arch really works internally and whether this is doable.
    > Comments, suggestions?


Amusingly enough, the shell version of arch (larch) has this
capability.  It wasn't carried over to tla only because it was
underutilized, undersupported by merging commands, and was confusing
people.

The relevant internals here are pretty simple.   A revision in arch
consists of one of three things:

        1) a full source copy

           These are created by `import' and are stored by tla
           as just a .tar.gz of the entire tree.


        2) an ordinary patch (changeset)

           These are created by `commit' and are stored by 
           tla as a .tar.gz of a changeset.   The changeset
           is understood to apply to the previous patch level.


        3) a continuation revision (changeset plus continuation)

           These are created by `tag' and are stored by 
           tla as (a) a CONTINUATION file that names the
           immediate ancestor revision and (b) a .tar.gz of
           a changeset that applies to that immediate
           ancestor.


In tla, the only way to create a continuation revision is with `tag'.  
The changeset part of a revision created by `tag' is very limited: it
does nothing more than add a patch log.

There used to be another way to create continuation revisions:

        % cd project-tree
        % larch commit --continuation ANCESTOR

which would make ANCESTOR the immediate ancestor of the new revision
(the revision named in the CONTINUATION file) and make the delta from
that ancestor to the project tree (plus the new patch log and any
changelog updates) the changeset.

That's exactly what you're asking for.

It's straightforward enough to "manage" such a revision by using
`replay' carefully.  In general, `update', `star-merge' and `replay'
can do some pretyt strange things when confronted with such revisions,
though.

Depending on how seriously you want this, and perhaps even just on the
basis of "first principles" (don't arbitrarilly limit the CLI) perhaps
the thing to do is to put back the --continuation option to `commit',
let people interested in it play with it, and offer feedback about
what new convenience commands (for merging, for example) might be
desirable as a result.

-t