Extra revisions in a branch (was Re: How to get the diff between two arbitrary remote revisions?)

[Aaron Bentley]

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

Matthieu Moy wrote:
> diff -r branch:XXX
> 
> Also fetches the revisions.

Yes.  Since this discussion started off with the assertion that we
should stop supporting branch:XXX, I thought it would be circular logic
to use that example.

It can also happen when you uncommit, of course.

> It seems a bit strange to me.

> This seems to me like a local cache (comparable to GNU Arch's revision
> libraries or Bazaar 1's cache ?), and I'm not sure the right place to
> store it is the current working directory.

I agree.  We have the goals that
1. we want to make bzr easy for beginners, so we don't require initial
setup of a cache directory
2. we want to make bzr fast, so we need to cache any data that might
come from remote sources
3. it would be nice if the cache were persistent, so that repeated
operations using the same data (e.g. pull, then merge) could be fast
4. it would be nice if successful merges or pulls did not leave behind
extra cached data.

So, sticking the data in the branch seems like the least bad option.

When we have repository branches, the data will go in the repository
(unless we change something), so if you use them, you'll have at most
one copy of the data per repository.

> Also, I'd have expected a kind of garbage-collection (or cache
> expiry), to keep only the ancestors of the head of the current branch.

Oh, but then it wouldn't be append-only...
I understand the motivation, and such a thing could be done.  But
realistically, the extra data is only significant when you fetch from an
unrelated project, or when you accidentally commit confidential data
(e.g. nuclear launch codes) to a public branch.

Actually, with knits, it would be possible to have a second set of
directories in the repository containing unmerged knit hunks.  You'd
need to combine the 'base' knit with the extra hunks to reconstruct the
text.  But it would always be safe to destroy the cache directory, then.

> Did I miss something, or is it just "on the todo list" ?

Well, I agree it's a bit of a weird thing to do, but a better solution
isn't immediately apparent.

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

iD8DBQFDe0/V0F+nu1YWqI0RAmD7AJ9MCN1RCfL/nQAGVVg0W9+uP0DshACggBhX
XC+Q6NafT8PGeXiEVDFYqvE=
=X2bh
-----END PGP SIGNATURE-----