Stacked branching question

Nicholas Allen nick.allen at onlinehome.de
Tue Jul 22 09:54:49 BST 2008


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


|
| The name 'cache' seems to imply it's something from which data can be
| evicted to reduce space etc.  As long as we make sure it's guaranteed
| to be also stored somewhere else appropriate this should be no
| problem.
|
| Of course this would mean some data will be stored twice on the
| client, once in the cache and once in the real local repository.  And
| even if it's only a cache the behaviour might be confusing if for
| example sometimes you can see all of history on your laptop, but when
| a cache purge happens you no longer can.
|

I don't think that would be confusing. The user will not purge their
cache often (maybe never unless they are running out of disk space) and
it is no different to a web browser cache. If they purge the cache then
presumably they did that manually and so should not be surprised to find
that some operations need to access the network after that.

I think the potential for speed up on all commands and making them all
more off-line friendly far outweighs this small chance of potential
confusion that may arise.

It would make bazaar seem a lot more intelligent too. If I branch
without creating a shared repo and then do another branch from a remote
location it would be lightning fast without even accessing the network.

Storing data twice on a machine is not a problem. Disk space is so cheap
now - my time is much more important to me than disk space. If others
disagree with this they can always set the cache to a smaller size (or 0
to completely disable it and get the exact same behaviour as bzr
currently has).

Cheers,

Nick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIhaBZ1+i51gqqEGkRAkVVAJ9jsjYCvKamMTMPnJoREAGGwGiX+QCfSUbS
kI3erRw2VgbLTpN2LetDxcg=
=2ivG
-----END PGP SIGNATURE-----



More information about the bazaar mailing list