Naive questions re hard-linking repositories

[John Arbash Meinel]

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

Martin Pool wrote:
...

>> We could, except on Windows where hardlinking is less often supported,
>> and the GUI environment doesn't understand the at all.
> 
> I'm given to understand it does work on NTFS.  If in some environments
> it fails with "not supported on this filesystem" it's easy enough to
> fallback to copying.
> 
> Presumably GUI tools should never or very rarely be looking around
> inside the repository directories, and even more rarely trying to
> change them.  So unless they actually cause the tools to blow up,
> linking the files seems harmless.  fwiw we're told that hg does use
> hardlinks on Windows and they apparently work.

Sure, and I would assume it isn't supported on VFAT under Linux either.

...

>>> This has some disadvantages compared to having a shared repository,
>>> because they're only sharing storage at one point in time: once they
>>> start to diverge or if one of them is repacked, they'll start using
>>> more disk space.  Still, it will have saved space at that one
>>> particular point in time, and future access should be no slower than
>>> it would be.
>> It will be suprising to people when the first repack operation happens,
>> or if they run 'bzr pack'. It's much more efficient to be using a shared
>> repo, and I think focusing on that is a better way to address the
>> issues.
> 
> Well, the first repack should be no slower, and probably will cause no
> noticeable impact on disk use.

The first *autopack* won't be appreciably slower, and won't have a
significant impact. The first "bzr pack" will double disk space and
completely break all links between the two repositories.

Note, we *could* just symlink the '.bzr/repository' directory, which has
the advantage of also working across filesystems. (The major
disadvantage being lack on Windows support.)


> 
> It will be a problem though if people have many branches of a large
> project, which gradually diverge to the point where they're using
> nearly N*M disk space.  To fix that we do need to address the level 1
> problem of guiding people towards having just one repository.
> 
> If someone gets up steam to make bzr (optionally?) hardlink pack files
> and the patch is reasonably clean and not excessively risky I'd
> consider merging it.  I think fixing the higher level problem is
> probably a better use of time though.
> 

So, a somewhat bigger problem is the "bzr branch plugins/bzrtools"
effect, where you have a tiny project inside a large one, and this
suddenly copies the entire repository because you are working on FAT32.

git/hg generally say "don't mix projects in your repo". We can push
towards that, but I sort of like the way we are. And really, I'd prefer
just making it easier to get a shared repository.

>> Did you see my proposal about changing branch? It got disappointingly
>> small amounts of feedback.
> 
> I'll look for it; I might have been away.  I'll try to catch up soon
> on that and the easy setup stuff.
> 

I did look it over, I just haven't had quite a chance to figure out what
the actual implications would be. It might be better to do something
like Ian suggested, and have clone != branch.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknl2K0ACgkQJdeBCYSNAANgHQCdF/gVWL3LVRV1chGgRCqMvvx2
+WUAn242uq4mB7H7zCPfzAywbgrV7jzq
=YvQo
-----END PGP SIGNATURE-----