cheap branch with hardlink

[William Dode]

On 10-08-2005, Martin Pool wrote:
> On  9 Aug 2005, John A Meinel <john at arbash-meinel.com> wrote:
>> William Dode wrote:
>> > The post about mercurial remind me that something very cool in
>> > mercurial is to make very cheap branch by using hardlink.
>> >
>> > I didn't followed the recent discussions about storagebranch, so i
>> > wonder if it will be possible to make so cheap branch with bzr ? Maybe
>> > it is possible now by hand ?
>> >
>> 
>> cp -al old_branch new_branch
>> should do just fine.
>> 
>> Most files aren't modified, and those that are, are generally renamed
>> into place.
>> 
>> Certainly you can give it a shot, and report any bugs that you come
>> across. I think it is planned to support that sort of thing.
>
> That's correct; copying by hardlinking is a supported operation, and
> if there are any bugs then please report them. 
>
> Obviously because the working files will also be hardlinked, you need
> to be sure that your text editor and build system will break the links
> as necessary.
>
>> If we switch to them, revfiles would be appended in place, but because
>> of other design criteria, it should be okay to have extra information in
>> your tree. I don't know about weaves, but if it changes the whole file,
>> I'm sure Martin will do it atomically (temp file + rename).
>
> That's correct.
>
>> I don't know if there is any plan to have "bzr branch" have some sort of
>> hard-link flag.
>
> I think that would be good. 

Fine, i'll test that. It should be two options maybe, one to hardlink
everything and one to hardlink only .bzr because i'm never sure if my
editor will break hardlink or not...

>
>> But I think an even cheaper method would be to have a revision pool. So
>> that if entries are not found in the local directory, they can be looked
>> up elsewhere.
>> At least then it wouldn't have to copy all of the
>> text-store/inventory-store, etc. across.
>
> It is interesting to consider what would be needed to have a very
> large number of related branches stored cheaply (though I don't want
> too premature optimization.)  As long as the branches agree on what
> occurred in each particular revision there should be no problem in
> having either revfiles or weaves that store information for different
> branches.
>


-- 
William Dodé - http://flibuste.net