On lack of support for convergence (was: Some thoughts on loom)

[Robert Collins]

On Tue, 2008-04-15 at 11:36 -0400, Forest Bond wrote:
> Hi,


> Right, my subject was "Some thoughts on loom", and I originally intended to
> expand beyond what was more-or-less a bug report.  I believe that there is some
> real impedance between what I'm trying to do (use loom as a VCS-aware quilt) and
> what loom is designed for.
> 
> The simple fact that I have to perform a commit every time I do `up-thread'
> after committing on a lower thread is very tedious, considering I'll sometimes
> have a loom with 6 or 7 threads.  If I make a change near the bottom, I have
> 12-14 commands (!) ahead of me to propagate those changes up the stack, even if
> the changes aren't anywhere near each other in the tree.  That doesn't feel
> right.

This is a lack of automation in loom; there is no new information added
by you during this process - a simple for loop in the up-thread command,
triggered by some flag like '-a' would remove all the tedium.

> Actually, if I have live changes in my working copy, this operation can
> sometimes be destructive.  Suddenly I'm sitting in a pile of pending merges
> intermixed with scattered changes that I want to keep, but commit in a different
> thread.  Now what?  Well, I just have to get in the habit of shelving changes
> before moving up to the next thread.  No biggie, just add an additional two
> potential commands I have to type before moving around the loom, plus the
> additional complexity of being so aware of how loom might trash my changes, or
> (at the very least), complicate things to an extent that quilt wouldn't dream
> of.

How does quilt handle 'uncommitted changes that conflict with the next
patch up' ?

> Not that I'd prefer to do without loom, of course.  I do appreciate the fact
> that I'm actually performing fairly complex operations with relative ease.  It
> just seems like it could be done better.

I'm glad we've got as far as relative ease :P.

> I'm wondering if loom is the right plugin for what I really want, which is to
> manage a stack of mutable commits in a queue and then roll them off,
> one-at-a-time, when they are fully baked.  Loom adds all kinds of complexity to
> this model because I have to use full branches as my "mutable commits", which
> means each one carries a certain amount of branch maintenance overhead.  I
> understand why it's done this way, but I'm pondering whether loom is for me.

The threads in a loom avoid nearly all of the full branch complexity -
they have a tip revision and thats all - no configuration, no separate
location to push too etc. In fact, given the history store we can at any
point we need to treat them as a delta.

> Is anyone else after the workflow that I'm trying to achieve?  Would another
> plugin ("commit queue", or so) be needed to achieve this, or is this within the
> realm of what can be reasonably expected from loom?

I'm happy to modify loom to do what you need; other than not wanting to
collaborate on your mutable commits, what you are doing is what loom is
intended to support.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080416/00a6d8b5/attachment.pgp