[rfc] [merge] removal of support for reverse changeset application

[Aaron Bentley]

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

John A Meinel wrote:

> I'm guessing Aaron's idea is that you have to have a path to define what
> you are working on. (I think BaZing didn't track file-ids in the same
> way, you'll probably notice a lot of the merge code is path based rather
> than id based).

No, there's always been a strong id-orientation.  The file paths are
provided because they're nice to display, but only the filename was used
if at all possible.

Probably my choice in making inventory changes implicit while filesystem
changes are explicit was influenced by Arch, where the same was true.

> Why did you remove the Composition code? I'm guessing it wasn't being
> used, but other than having specific discussions with Aaron, I wouldn't
> want to see them removed.

He did say:
>> Aaron additionally suggested that I remove support for composing
>> changesets.

 Now I believe you have talked to Aaron, and he
> has approved your changes, but your short description doesn't include
> some of these changes, so I just wanted a short discussion about it.

We don't need it, and I can't see us ever needing it.    Dead code makes
it harder to understand the live code.

For a Python Arch implementation, sure it might be useful, if it handled
enough of Arch's quirks.  It's considerably faster than Arch when you've
got lots of changesets to apply

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

iD8DBQFDqzQt0F+nu1YWqI0RAq3YAJ4g4yWxdW167Dk6rnh6bwQDr1uQIQCdEeT/
4ZuJfFpAgcW53FBvuFWsnnU=
=h05t
-----END PGP SIGNATURE-----