Naive questions re hard-linking repositories

[Martin Pool]

2009/4/15 Ian Clatworthy <ian.clatworthy at canonical.com>:

> Just like pull vs merge vs update, the *intention* is different so it's
> arguably good to have separate commands. For 2.0, perhaps "branch" ought
> to always stack by default and "clone" ought to not stack, rather than
> just be an alias for branch?
>
> We can always stick with a single command, giving branch an option
> something like --stack-if-local (and making that the default mode).
> But I typically prefer explicit over implicit and I think it will help
> new users to think about clone vs branch as achieving different things.

I think stacking has some similar problems to hardlinking, that the
branches will gradually diverge and use more and more space, and there
are some risks that people won't understand the dependency of the
stacked branch.  (eg they'll think they've made a full backup but they
haven't.)  Those can be mitigated by making it clear in the output
what's going on, but I'm not convinced it should be the default.

I think I would be convinced that stacking should happen by default if
this came out of some reasoning about the user model at level one:
"ok, we really think each directory should hold a branch, working tree
and repository, and the repositories will commonly stack upon each
other."

>
> BTW, I also like Robert's idea of making a shared repo implicitly
> but I'd like to think about it more.
>
>> Whether you prefer one or the other, the fact that bzr is still
>> oriented towards a mode of operation that isn't what we generally
>> recommend is a problem.  I think this lies behind complaints that
>> there are too many ways to use bzr.
>
> And equally importantly, just using the tool in the simple, obvious way
> performs terribly and chews disk space unnecessarily.

Right, and I think that's a fairly predictable consequence of having,
through this process of evolution, the tool's default mode not be the
way it's currently intended to be used.

> Right. So the usability goals needs to be:
>
> 1. working well straight-out-of-the-box
>
> 2. retaining our adaptability *but* improving the UI for getting to
>   and changing between commonly used workspace models.

Well, I'd certainly agree with that, but I think underlying both of
them is that there should be really one main model that corresponds
both to the tool defaults _and_ to what we think is really best for
most people, with the advanced cases appearing as other options being
turned on, rather than reworking things from scratch.

The cases in the easy workspace setup spec are pretty good, but even
with the proposed solution they have a bit of a problem that going
from the basic case through the more advanced ones requires
rearranging what you already have, whereas ideally it should be
additive.

-- 
Martin <http://launchpad.net/~mbp/>