Recommended use of Bazaar for single-committer multiple-machine projects?

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> On 12 Dec 2008, "Matthew D. Fuller" <fullermd at over-yonder.net> wrote:
>> On Fri, Dec 12, 2008 at 06:31:27PM +1100 I heard the voice of
>> Mary Gardiner, and lo! it spake thus:
>>> OK. so essentially you don't in this model do a lot (or any) --local
>>> commits. It may be that this is an improvement in terms of avoiding
>>> the various two-merges problems that working directly in the
>>> checkout cause.  I'll give it a go. (Still interested in other
>>> workflows though.)
>> That's the sort of thing I'd aim at too.
>>
>> I consider --local to be far more of an escape hatch, and far less a
>> daily tool.  It's an inherently schizophrenic thing to do; branches
>> can be shared (as in a checkout) or independent; --local users the
>> former to emulate the latter.  Certainly it has unnecessary bugs like
>> you've mentioned, but even with them fixed, it's [IMAO] much better
>> considered a special-case stopgap, than a regular-use device.
> 
> I was just wondering (in the light of Mary's bug reports) whether we
> should in fact remove the --local commit feature.  It was a good
> experiment, and I think checkouts are really useful, but local commits
> not so much.
> 
> It feels like they really want to be adding a new default or mode of
> use, and at one level they do, but actually they work quite differently.
> They create some additional complexity in code, in bugs, in
> documentation and in the kind of situation users can get into and how
> they understand them.
> 
> Getting rid of them would mean we could still have checkouts, but
> committing to a checkout would always go into its branch, whether that's
> on the same machine or elsewhere.  So this would mean checkouts of a
> remote branch would only really work if you had access to the server,
> much like in svn, though you would be able to do wt-only operations with
> no connection.
> 
> We wouldn't need the four-way merge of wt-basis, wt, local branch,
> remote branch, that can currently happen in updates.
> 

I think it would be worthwhile to explore alternative solutions. For
example, being able to create something like "bzr-local-branches" or a
loom when you realize that you are offline and still want to commit.

I don't think loom is designed this way, but as an example, you could
have the bottom thread be a bound branch. You go offline and create an
"offline" thread. And commits there are local only.

Then when you get back online, you issue "bzr collapse" which tries to
push the changes down a thread and get rid of the actual thread. (Note
I'm *very* unclear about which way is 'up' versus 'down' with looms, so
forgive me if I'm getting the directions wrong. 'base' to me is the
bottom-most object, and you build upwards. Loom may be implemented as
building down. Also, IIRC collapse-thread is actually just delete-thread)

At least one reason loom doesn't work like that, is because I believe if
a loom is bound, then you are actually binding the loom itself. So bzr
up is supposed to update all threads, and "bzr push" is supposed to push
all the various threads as well.

'bzr-local-branches' actually works better for this, because it
maintains them as real branches.

Some things I really like about this:

1) It makes it clear which commits are in sync, versus what is only
   local.

2) Namespace. You can do this with a shared repo and no-trees branches,
   but there is a huge namespace available once you go out of "../",
   compared with the obvious subset that is available underneath "./*"

   For example, all of my branches are available as ../1.11/*, it isn't
   obvious which one is the 'offline' branch of my current working
   branch.

   However, if "1.11/foo" is the branch, and then "1.11/foo/offline"
   would obviously be the offline commits pertaining to only 'foo', and
   not any other branch.

3) A 'stack' like loom works well here, because it provides you the
   direct "pop the top of the stack and push it to the next one down".
   Which isn't really possible in a generic collection of branches.

   Again if you have the hierarchal namespace then
     bzr/feature/subfeature
   Has an obvious direction, and would even allow you to create a tree
   of dependencies.  Given a branch structure

     bzr
       split-inventory
         chk_hash_prefix
         fetch
       btree
         pyrex-btree

   You can tell that the split-inventory work depends on
   chk_hash_prefix, but not on the btree code.

That said, nobody I've talked to seems to think that having a namespace
of "branch/subbranch/subsub" is anything but confusing. At least, 90% of
people seem to prefer

   bzr		 # A repo
     trunk
     branch1
     branch2

rather than

   bzr/		 # The mainline branch
   bzr/branch1
   bzr/branch2

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklC8EUACgkQJdeBCYSNAAM5rACdEoprRAbcbHiVp5HynKt3e1vW
XcQAn1xMFu1zo49kb5C+KUifYRzO6hWH
=YUPk
-----END PGP SIGNATURE-----