Merge cleanup

[Aaron Bentley]

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

John Arbash Meinel wrote:
> I was looking through the merge code again, and I think one good point
> for cleaning it up would be to have it use more of the rest of bzrlib.
> 
> For instance, it has it's own Inventory class, it's own SourceFile
> (rather than using InventoryEntry), and the MergeTree doesn't descend
> from the standard Tree class.

In in principle, this is right.  But bzrlib doesn't have everything
merge needs.  For example, there's no 'interesting' flag for
InventoryEntry, and WorkingTree lists unversioned files as well as
versioned ones.  So bzrlib would need to change as well.

> I was looking at it, because I was thinking about writing a way for
> serializing changesets similarly to the earlier discussed plans. But
> while looking into it, I would have to re-learn all of the classes.

It's a legitimate question whether we're going to use that code's
changeset stuff for serializing changesets.  If we treat changesets as
trees, then we don't really need to apply them.

And since the changesets it generates are basically an improved Arch
changeset in terms of structure, serializing them the minimalist way
we've discussed would be a significant translation effort.

Ripping out support support for normal changesets, generating 'merge
changesets' from the get-go would definitely make the code easier to
maintain.

> Would there be interest if I tried to make merge.py and changeset.py use
> the other bzrlib classes?

That would be good, but could you hold off until I get this set of fixes
in?  I'm working on fixing correctness issues, and I don't want us to
step on each others' feet.

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

iD8DBQFCtbT60F+nu1YWqI0RAuY3AJ4nO84gTXThoiLZnC3q0CaaE76WvQCfUwoI
E/50GGECShKuXQ2r0NTvXHI=
=K7tk
-----END PGP SIGNATURE-----