Stacking policy

Aaron Bentley aaron at aaronbentley.com
Tue Apr 1 16:48:56 BST 2008


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

Hi all,

My team at Launchpad wants stacking to happen by default.  We don't want
creating a branch to be tricky, and we don't want people creating
non-stacked branches by accident.  That would lead to bad user
experiences, and it would waste a lot of space.

As far as Launchpad is concerned, we could pursue some sort of
launchpad-specific solution, but I believe that handling this policy on
the client side is the best way.

Bazaar should have sane defaults.  It should give a good first
impression.  I think enabling stacking is a sane default that will
improve the impression we give.

Handling this policy on the client side instead of in Launchpad will
also mean that clients can override the policy if necessary.

Launchpad is a branch host, but there are others like Savannah or
personal sites like aaronbentley.com.  Branch hosts deserve the right to
enable revision reuse, so that space usage doesn't explode.

We already have a precedent of controlling policy remotely; the presence
of a shared repository remotely causes that shared repository to be used
when creating new branches.

So here's the policy I've got in mind.  When creating a new branch

0. If the user specifies a stacking policy, select that policy.
1. Open containing folders looking for a shared repository or stacking
   configuration.  If a shared repository is found, select that shared
   repository.  If a stacking configuration is found, select that
   policy.
2. If no policy has been selected, and the branch is being created from
   another branch (i.e. bzr branch), and the other branch has the same
   URL prefix (including hostname, if applicable), select the other
   branch as the stack-on branch.

The justification is:
0. The user should always be in control
1. Remote sites should be able to enable revision sharing either using
   shared repositories or stacking.
2. Branches on the same machine are usually equally visible, so access
   to one implies access to the other.

Advantage:
- - creating branches locally is efficient
- - pushing to Launchpad or other well-configured hosts is efficient

Possible pitfalls:
- - If the user doesn't understand that the stacked-on branch is required
for the stacked branch to work, they may delete the stacked-on branch.
- - A stacked branch might have different visibility from its stacked-on
branch.  For example, the stacked branch might be in /var/www/html,
making it visible via http, while the stacked-on branch might not be
visible via http.

We can reduce the amount of confusion by notifying the user when we're
automatically choosing to stack.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH8lln0F+nu1YWqI0RAnaJAJ9wPVpk4NY5AgKLgJV4Pm5vLwRUlwCeJsaQ
3otYrhCknVF+yrZF1ZZIfok=
=gjRX
-----END PGP SIGNATURE-----



More information about the bazaar mailing list