Extra revisions in a branch

[Aaron Bentley]

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

Matthieu Moy wrote:
> Would that be acceptable to say
> 
> - By default, everything goes in the current branch (as it does now)
> 
> - But the user can specify a cache directory, and then, this directory
>   is used instead (in particular, this would allow some kind of
>   centralized storage for the cache, even for someone using individual
>   branches).

The only thing is that the cache will wind up containing lots of things
that you've merged or pulled.  There's a strong case for cache expiry
then.  It gets hairy when you want to expire a revision that a
non-expired revision depends on.  I don't believe we support sanely
removing a revision that other revisions depend upon.  You could take
the latest expiry of any dependent revisions, but that would result in
almost never expiring anything.

For myself, I can be happy using my repository as my cache.  So that's
the first thing I'm doing.

> My concern is that I like to keep "important data" and other data
> clearly distinct. Because 1) disk space is cheap, but reliable backups
> are expansive, 2) I often work with important data on a not-so-fast
> NFS server and unimportant data on a fast local disk.

Okay, but in the current regime, the unimportant information is
essentially delta-compressed, so it should be fine to back up.
Unrelated branches are the only issue.

> The current way to do will accumulate accidental accesses to remote
> branches in my .bzr directory, without a way to get this disk space
> back. If I accidentally diff from a remote unrelated branch once, then
> I'll have this information forever in my .bzr/ directory.

Yeah, I agree there are uses for cleaning up unrelated revisions.  How
and when remain open issues, in my view.

>>Actually, with knits, it would be possible to have a second set of
>>directories in the repository containing unmerged knit hunks.

> I like this solution a lot (but I don't know how hard it is to
> implement).
> 
> "push" could also take advantage of this structure to avoid pushing
> useless data (but I realize that it is already clever enough to do
> this with the current bzr).

Yes, knit will do this out-of-the-box.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDe2pR0F+nu1YWqI0RAobGAJwPXon1wFXeyBnuAJo0p276CcInfQCghMX/
3y1LBsTXDtX5YQ+vpTmK0Lw=
=9ICu
-----END PGP SIGNATURE-----