[RFC] uncommit creates bundles

Aaron Bentley aaron.bentley at utoronto.ca
Tue Mar 13 15:13:13 GMT 2007

Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>> I just had a thought.  What if uncommit created bundles?

> Well, at this point, all we really need is for 'uncommit' to spit out
> the revision id. So that you can do 'bzr pull -r revid:foo'.
> Since uncommit doesn't remove anything from the repository.

Right.  I'm assuming that one day it will be able to remove stuff from
the repo.

Merge directives also include the revision id, and I was plannning on
supporting them in "merge" and "pull".  They can be plain (no patch or
bundle) or they can include bundles.  So maybe we should emit merge
directives instead.

> Also, because we leave the working tree alone, the bundle wouldn't
> actually directly apply to the working tree. (I guess it could, as long
> as merge3 ignores exact change conflicts).

Merge3 does ignore exact change conflicts.  And Merge3 is skipped when
THIS == OTHER anyhow.

> I kind of like that 'bzr uncommit' is *really* fast. Whereas if it had
> to create a bundle it would actually be quite slow. (At least with our
> current bundles.)

Well, as long as it's not nuking revisions, I'm fine with it spitting
out a plain merge directive (no bundle, no patch).  That would still be
really fast.

$bzr uncommit -> plain merge directive
$bzr uncommit --expunge -> merge directive with bundle


P.S. It looks like not the first time I've had ideas like this:

1185.1.39.1> abentle |     In the future, uncommit will create a
revision bundle, which can then
1185.1.39.1> john at ar |     be re-applied.

Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list