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

[John A Meinel]

Aaron Bentley wrote:
> 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

Good enough. I merged it into jam-integration, revno 1489
Revno 1490 will fix some of the whitespace issues.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051222/29d8ae46/attachment.pgp