converted to 1.6 markup
use as template
|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|## page was copied from DraftSpecs/SimpleCheckouts|
Created: 2009-04-20 by IanClatworthy
This specification recommends that checkouts should be lightweight and lightweight only.
Most users, particularly those coming from cvs and Subversion, expect checkouts to be lightweight.
Having both heavyweight checkouts and bound branches is redundant.
Having both lightweight and heavyweight checkouts makes explaining checkouts harder than it ought to be. If you think a lightweight checkout is a heavyweight checkout with zero history cached (like the spec author initially expected), you're missing a key semantic difference:
lightweight checkout = tree & a reference to a branch
heavyweight checkout = tree+branch & a bind to a second branch.
That's simply too much magic/complexity for 95% of new users. It also leads to unexpected problems. Consider:
work (lw checkout) switched to trunk (branch) bound to upstream (branch).
Running bzr bind in work needs to change what trunk is bound to, not the link between work and trunk. If you accidently made work a heavyweight checkout (the current default), you're confused when the wrong link is changed.
Proposed UI enhancements
Here are the proposed changes:
Remove the --lightweight option from the checkout command and always create a lightweight checkout.
Add --bind to the branch command.
Some changes may also be required to the reconfigure command.
If you want to use the lockstep development workflow with local history and/or make local commits, use a bound branch.
We probably want to remove --local from the commit command. The reason behind that is the update command gets ugly and confusing because local commits bring 4 trees into play, instead of the usual 3, so multiple merges are needed. Strictly speaking though, this change is quite independent from the other changes proposed in this spec.
We might need to tweak something to make diff against the basis tree faster for lightweight checkouts. But the answer to that is a better lightweight checkout implementation (when time permits), not a heavyweight checkout. It's perfectly acceptable to say that checkouts are designed for small, drive-by fixes to projects, and for setups where the branches are accessible over a high speed LAN.