[MERGE] Implement hard-link support for branch and checkout

[Ian Clatworthy]

Robert Collins wrote:
> On Wed, 2008-01-02 at 19:38 -0500, Aaron Bentley wrote:

>> But more importantly, it's not a special case, it's a recommended
>> workflow: feature branches.  You branch (or cbranch), commit, maybe
>> merge, and submit.  I think we should promote this workflow, so I
>> think
>> we should try to make it very convenient to use.  Just because we can
>> do
>> it the inconvenient way doesn't mean we shouldn't do it the convenient
>> way.  People should feel free to branch at the drop of a hat.
> 
> If you consider built files such as object files, configure output and
> the like, separate working trees become extremely costly. Users in those
> environments want 'switch' functionality much more than hardlinking.
> 
> I completely agree about making branches at the drop of a hat easy; I
> think solving it for the C++ crowd will require really good switch-like
> behaviour, and having that behaviour recommended will further reduce the
> need for hardlinking source files.

While not for everyone, I think this is an important feature. I agree
with making switch better as well but space efficient branching remains
very desirable IMO. For example, many developers in commercial teams
using switch for bug fixing will still have at least 3 full trees
around: the current trunk, the current maintenance branch and their
'feature under development'. In other words, both approaches have value.

We also want to be encouraging feature branching as the default, i.e.
making switch a workflow choice rather than our only answer for space
efficiency on large projects.

I've attached some test results showing the positive impact of this
patch. The first CSV file shows the times and space usage of bzr.dev
3151 on the kernel, Firefox and OpenOffice trees. The second CSV file
shows the same for 3151 with this patch applied. Here is a sample of the
results on the largest tree (OpenOffice):

* space usage drops from 3398M to 1451M
* branch time drops from 87.3 secs to 68.3 secs

(Space usage is of a shared repo with an initial tree, branch, checkout
and lightweight checkout included.)

I'm going to double check the speed gains because they are higher than I
expected. With or without them though, the space usage improvement is
more than enough for me to support this patch in principle.

Ian C.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ut-bzr-3151-gutsy-large.csv
Type: text/csv
Size: 1948 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080103/7d1bac01/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ut-bzr-3151+hardlinks-gutsy-large.csv
Type: text/csv
Size: 1944 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080103/7d1bac01/attachment-0003.bin