Naive questions re hard-linking repositories

[John Arbash Meinel]

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

Martin Pool wrote:
> 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.
> 

The dependency issue is a pretty major one, IMO. It was one of the
reasons that Arch ended up losing history pretty regularly. The default
mode was to "stack" on all the other repositories, and pretty soon your
history is distributed across the Internet, and someone goes offline.

Now, I think we can do better, but honestly, I think stacking is a hack
because we didn't want to put shared repos on Launchpad. They only
really work when you have either

1) Everything on one machine
2) An official central location that people stack on.

It actually works fairly well when you have something like Launchpad, or
an official trunk (we could all stack on bazaar-vcs.org/bzr/bzr.dev and
do quite well).

But the more distributed a project is, pretty soon stacking starts
breaking down.

Even consider something like "brisbane-core". Pushing up a new branch of
bbc to Launchpad started to get pretty expensive, because you are now
pushing up the whole divergence. Which makes you think "well, why not
stack on this", and suddenly your stack depth just increased. When it
gets much beyond 2...


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

I'm pretty firmly against stacking by default. There are a few cases it
handles better than alternatives, but there is an increased risk of
history loss.

...

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

I think this is a good thing to keep in mind.

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

iEYEARECAAYFAknl2ewACgkQJdeBCYSNAAPWrACbBJ3erRSqBRf1273oVEIyu8WF
kVgAnA/BXrARXOCdycCn+NJF2Dthe+Wt
=K40E
-----END PGP SIGNATURE-----