[RFC] branch --bind

[A. S. Budden]

Having posted what might have been one of the more awkward responses
early on in this thread, I thought I ought to join in again...

2010/1/9 Ian Clatworthy <ian.clatworthy at canonical.com>:
> Robert Collins wrote:
>
>>> * OTOH, bound branches are easy to explain

Except they confuse the hell out of me and most of the other people in
my department who are used to the centralised model and not interested
in using Bazaar in a distributed manner.

>> I dispute that this is a point of difference - they are precisely as
>> easy to explain as a heavy checkout, because they are the same thing
>> with the exception of *one* command.

I find the heavyweight checkout easier to explain as it is much easier
to compare lightweight and heavyweight as the two types of checkout
than to start talking distributed branches etc.

> The differences are far deeper than one command. See my other email and
> http://wiki.bazaar.canonical.com/MatthewFuller/BoundBranches.
>
>> Which provoked a long thread, and I don't see consensus here.

I must say that having read all 74 messages in this thread, I'm more
confused than ever about how Bazaar works, what the mass of
terminology all means and where we're going, but that's probably more
of a failing of my understanding than anything else.  It probably
doesn't help that we use "branch" to mean "make a new feature branch
on the server and start making changes to it" and the command that
actually does that is "switch -b" (in fact halfway through writing
that sentence, someone just came up to me for help as they couldn't
figure out how to create a new branch - now there's timing!).

> In term of people objecting to adding --bind to branch, I recall Al
> Budden and yourself objecting. Anyone else? On deeper analysis:
>
> * Al is after a nicer way of setting up a cbranch-style setup in
> Explorer (which is semi-related but not blocked by this change).

I have no intrinsic objection to the concept of adding --bind to
branch, although I'll have to take your word for it on the
"cbranch-style setup" thing as I have no idea what that means.  My
only concern with "branch --bind" is that it reduces the likelihood of
the heavyweight checkout option ever making back into the checkout
dialog.  My desire is that it is easy (with the GUI) to:

1. Create a new project stored on a separate server like this:
    bzr init-repo --no-trees remote-location
    bzr init remote-location/trunk
    bzr co remote-location/trunk local-location

2. Get a copy of an existing project like this:
    bzr co remote-location/trunk local-location

3. Use "feature branches" with each feature branch stored on the
server and the local copy pointing at it:
    bzr switch -b feature-abc # Switches to remote-location/feature-abc
    # hack hack hack
    bzr ci -m "Message"
    bzr switch trunk # Switches to remote-location/trunk
    bzr merge remote-location/trunk
    bzr ci -m "Merged stuff"

4. Ensure that all of the checkouts above have a full cache and thus:
    a) Accesses to logs and diffs etc are fast
    b) They can be converted into an unbound branch if the need
arises, without accessing the network.

5. Do exactly the same as item 1, but make the trunk a copy of another
trunk from another project.

At the moment, a lot of this is rather convoluted with either the CLI
or the GUI.  My remote-feature-branches patch to Bazaar Explorer makes
item 1 extremely quick and easy with the GUI, but item 2 is currently
very difficult with the GUI (you currently have to disable the custom
qgetnew dialog in the options and then manually open the checkout
after carrying out the operation).

Regarding the underlying implementation of bound branches c.f.
heavyweight checkouts I can honestly say that I don't care in the
slightest.  If there was an option in the branch dialog that made it a
bound branch and an option in the checkout dialog that said "keep a
local cache of the whole branch" or something, that would be fine.
I'd never use the former, but the latter would make a perfectly
acceptable substitute for the term "heavyweight checkout" (subject to
item 4 above).

Most of the people I work with aren't in the slightest bit interested
in the way version control systems work.  They come from a background
of using (mostly) PVCS and (partly) subversion.  The single most
important reason we chose Bazaar as our trial alternative to PVCS is
that it supports the centralised mode of operation with local history
storage to speed up operation: the heavyweight checkout.  Having a GUI
was also essential, but any other consideration was a distant third.
To be honest, I've got a bit of an up-hill struggle to persuade them
(especially my boss) that not having file locking as part of the
version control system is A Good Thing and that open-source VCSs are
okay for use in a commercial environment...

Al

-- 
http://sites.google.com/site/abudden