Difficulty of reconstructing a branch whilst deleting/fixing a broken revision

[Aaron Bentley]

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

Jules Bean wrote:
> For merges with other sub-branches of the *broken* revision, I
> couldn't merge (that would bring the large file back in)

It would bring it in temporarily, but if you didn't commit the revision
as a merge (e.g. revert --forget-merges), then it would not be part of
history and would be easy to get rid of.

> Actually I think this was misguided anyway since bzr shelve would have
> lost the file-ids of added files,

No, it preserves file-ids.

> On some sufficiently complex changesets, bzr shelve doesn't work
> even though bzr commit does.

I'm not sure how you got that error, but it's because it was trying to
"bzr add" a file that didn't exist.

> Explicitly support an externalisable 'rich diff' which includes file
> renames, additions, deletions and binary changes. This is probably
> just the 'shelve' format, and not very different from the external
> patchset format.

We already have merge directives and bundles.  I don't think we want
another format.  The only reason you want this is to avoid preserving
history, but we want our tools to preserve history wherever possible.

Perhaps a "merge --no-history" option would serve better.  It would be
an explicit way to apply changes without preserving history, and would
work with our existing formats.

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

iEYEARECAAYFAktxbcwACgkQ0F+nu1YWqI2gdQCcCh/gcPSeSdADXAUR6FN8hbzE
6XUAn3G5VdheUGeJ4lliyAzsjVcR8o7S
=lQw2
-----END PGP SIGNATURE-----