[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] [RFC] New branching method proposed (semi/delta-bra
Re: [Gnu-arch-users] [RFC] New branching method proposed (semi/delta-branching)
Mon, 03 Nov 2003 19:44:31 +0100
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
> 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,
> 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.