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

[Forest Bond]

Hi,

On Tue, Apr 15, 2008 at 11:15:18AM -0400, John Yates wrote:
> Rob, replying to Forest Bond, writes:
> 
> > In this case bzr can't tell that B is actually meant to be successive
> > work from trunk-2 aka A.
> 
> IIUC this is a consequence of bzr's current lack of support for convergence.
> 
> As Forest's experience shows, bzr's semantics are difficult to predict for
> those who have not internalized an accurate system model.  That an accurate
> model diverges from the natural, intuitive one is unfortunate.  It is not
> dissimilar to saying:
> 
>   "Yes our system looks a lot like integer arithmetic.  We even reuse the
>    same notation and vocabulary. But, unlike other practitioners, we opted
>    not to implement associativity.  Do not be mislead by false similarities."

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.

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.

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 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.

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?

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080415/0cbffe4b/attachment.pgp