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

[Christian Neumair]

Am So, den 02.11.2003 schrieb Tom Lord um 22:09:
> 
>     > 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.
[...]
> 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.
Yes, that would be a great idea. Thanks for the inital reaction, I'd
really like to get this into tla.

regs,
 Chris