[RFC] branch --bind

[Stephen J. Turnbull]

Martin Pool writes:
 > 2010/1/8 Stephen J. Turnbull <stephen at xemacs.org>:

 > >  > We would intentionally *not* call it that.
 > >
 > > Too bad for A Budden and others whose workflows *require* the
 > > centralized model, but allow users the *option* of lightweight or
 > > heavyweight checkouts, then.  I dislike the model intensely myself
 > > :-), but I thought Bazaar was committed to supporting what the users
 > > want to use.
 > 
 > Those are kind of loaded words.

Of course -- this is *entirely about words*.  Somebody (I think it was
John himself) proposed an alternate layout, I riffed on that, but the
point is that what is wanted by the OP is a single, high-level word
that describes what we currently call "checkouts."  This makes writing
policy simpler for the OP.

In case you didn't notice the words you quote above, John claims the
use of the words "heavyweight checkout" is already deprecated (in
favor of what, I'm not sure).  This lack of a substitute worries the
OP, and seems unnecessary to me.

I claim it would be cheap to support the use of the *phrase*
"heavyweight checkout" without having that correspond to a
configuration of a *single* version control object.  Rather it would
be a complex object composed of a "hidden" bound branch and the
"normal" workspace in a (lightweight) checkout (with the UI hiding the
complexity until the user actually starts to do VC work offline).

 > > If so, I agree with him that "checkout" has the right
 > > connotations to make describing his workplace's policy straightforward;
 > > using "checkout" only for the lightweight version and calling the
 > > heavyweight version something else is unnecessarily confusing IMO.
 > 
 > What we would probably suggest for his current state is making a local
 > repository with bound branches; then he can make new purely local
 > branches when disconnected, switch his checkout onto them, and
 > continue, or unbind the branch.

Yes, yes, yes, isn't that what I described?  But what worries him is
trying to explain that to the users he is supporting, some important
fraction of whom are apparently GUI-bound types with no interest or
facility for learning command-line stuff or even navigating multiple
screens at branch setup.[1]  I'm proposing making that setup automatic,
calling it a "heavyweight checkout", and then he can tell his users

(1) You *must* use a *checkout*, not a branch.

(2) You have the option of a "lightweight" checkout, which is simple
    and uses few local resources, but will be painful or impossible to
    use (depending on the operation) if you do not have a fast network
    connection.  Alternatively, you can specify a "heavyweight"
    checkout, which maintains a local cache of history, and can
    therefore be used offline.  The disadvantages of a heavyweight
    checkout are use of substantially more local resources (mostly
    disk space, little impact on network usage, some on CPU), and to
    take advantage of the cache you need to learn to use local
    branches.  [N.B. As I understand the OP, he does *not* intend to
    even mention the possibility of unbinding or commit --local;
    rather the "local cache" (the normally "hidden" bound branch) is
    used as a source branch for a local private branch.]

 > This can be seen as making conherency with the master a persistent
 > mode of the branch rather than a one-off setting for the commit.

Indeed, AIUI that is precisely what he wants for functionality.  The
issue here is what to *call* it, and to give his users "one checkbox
support" for the functionality that has previously been supplied by
"heavyweight" checkouts.

Footnotes: 
[1]  Sure, that's exactly what free software people don't want to
hear.  But for whatever reason, the OP is in a position of needing to
help those people Just Get Work Done with a minimum of pain^Wlearning
involved.