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

[John Arbash Meinel]

Stefan Ring wrote:
> Thank you so much for this detailed reply.
> 
> I already suspected that hard links would be easier to use with the
> packs format.
> 
> You are absolutely right about the shared repositories feature, but I
> would really like the option to "upgrade" a standalone repo to a
> shared one. I just tried to do this manually, and while it's not hard
> to do, it's tiresome. I would also like to have something like "hg
> clone -U" which doesn't build the tree in the cloned repository. The
> upcoming "--hardlinks" flag looks like it might help here but as far
> as I can tell, it's not yet available in the release version.
> 

I think "bzr reconfigure --shared" or something like that might work. At 
the very least "bzr reconfigure" is where we would add functionality 
like this.

> Let me share the background why I struggled so much with this. I have
> an almost decade-old directory with various stuff collected (or
> created) over the years. Now I'd really like to clean it up and also
> replicate it to multiple machines for backup purposes. I imported the
> whole directory into a bzr repository which is about 4GB large and
> unfortunately still in knits format (I started this in the 0.91 days,
> IIRC)---I know, it wouldn't be that hard to upgrade but that's not the
> point now. Also, I would not consider this to be the typical use-case
> for bzr but fast cloning is a very desirable property nonetheless.
> 
> Now the problem is this: most of the time, I work on machine1 OR
> machine2 while the other one is not reachable (powered down and in
> another physical location). I feel really nervous, however, when I
> can't replicate my changes at the end of the day because hard disks
> die quickly and at the most uncomfortable moments ;)
> 
> I thought a bundle against an older revision, that I know the other
> machine already has, would help me out of this dilemma. My problem now
> was how to create one without having to copy the multi-gigabyte
> repository on disk (I don't even have enough free space for that on my
> macbook). I have come up with three possible ways to create said
> bundle:
> 
> 1. Create a bundle against an older revision of the repository
> itself. Alas, this doesn't work. (-r can be used to specify the source
> revision, not the target revision)

Well, the old "bzr bundle -r X..Y" would have worked for this. "bzr send 
  -r" doesn't. I believe Aaron was trying to simplify the UI for good 
reasons, but it means we lost the functionality to work within a single 
branch. (We had been getting bundles which were not complete because 
people didn't guess correctly with the X revision.)


> 2. Convert the repo to a shared repository in-place and then clone it
> with -r to an older revision. This works (with quite a bit of manual
> file/directory management) but now that "clone -U" option would be
> really useful. Also, I've only tried the conversion part, not the
> cloning. I really hope that it won't read all 4GB from disk for this
> operation.
> 

Actually, you should only need to do:

touch .bzr/repository/no-working-trees .bzr/repository/shared-storage
bzr branch -r XXX . old

Which should be able to create a branch pointing at revision XXX with no 
working tree, so it doesn't have to create mess with your 4GB of files.

That is certainly where we would want "bzr reconfigure --shared" to 
work, though.

Also, we've discussed a "bzr branch --no-working-tree" override to force 
just a plain branch pointer.


> 3. Make a hard-link copy of the whole repository and manually edit the
> branch/last-revision file. This also works but again, some manual
> editing is involved.
> 
> Apart from this bundle dilemma, bzr is the best backup solution I ever
> had ;)


John
=:->