Changesets feature complete

[Aaron Bentley]

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

John Arbash Meinel wrote:

> Now that we are using Testaments, I'm not planning on trying as hard to
> be able to pre-validate the changeset before we install stuff. As long
> as we add in signatures, and check them before we pull a new revision,
> we can be reasonably guaranteed that the changeset is valid.

Well, signatures prove changesets are authentic, but not that they're
valid, because a changeset that failed to properly represent changes to
the last-modified attribute would produce a revision with a correct
Testament that was not a true copy of the source revision.

My most recent changes add a new StrictTestament that includes
last-modified, and we should probably also include the execute bit in
StrictTestaments.

> Well, I guess I would like to say "set it for every change, but consider
> the default to be 'no' for new files".
> I think it is a very reasonable default, and in my head, when the file
> didn't exist, it certainly wasn't executable. :)

That's fine with me, as long as the changes are in
ReadChangeset._update_tree, rather than ChangesetTree.

> Well, in my mind, the text format won't change much after the
> refactoring. It is just changes to the internal code. So how about we
> merge it, and just make sure that we are clear it needs to be cleaned up.

In that case, I will make a few tweaks, and get a merge request together.

> The point of the serializer was just to have a factory which could be
> used to read and write changesets. The api for a ChangesetSerializer was
> *very* simple, just a read() and write() function.
...
> As far as what 'read' would return, I wasn't fully clear on that myself.
> At one point, I was thinking that it should be a set of ChangesetTrees,
> where each tree was equivalent to a RevisionTree (it has the revision
> info, and the inventory info).

But the problem is that the trees use each other as bases, so
Serializer.read() would have to install them in a repository.

> However, I could also see returning a more complicated object than a
> list, (similar to ChangesetReader/ChangesetInfo). This object would have
> the information to create a ChangesetTree on request by revision_id.
> This makes it easier to do late parsing of the changeset, which helps in
> the case that you already have some of the changeset revisions.

I think this is a better way to go.  How about this API:

ChangesetInstaller(object):
    def install(repository, revisions=None):
        pass

    def revision_ids():
        pass

    def target_revision_id():
        pass


> In my refactoring, I was working on moving non-parsing stuff out of
> ChangsetReader and into ChangesetInfo, and making that the return value
> of read().
> 
> (I also changed the upfront merge command, so that it could grab a
> changeset over a Transport).

Cool.  And now that branches use leftmost ancestors for revision
history, we can implement pull, too.

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

iD8DBQFEdbmY0F+nu1YWqI0RAojTAJ48JnifcU4BJckbagC4a1cuXk66AACfWlZn
Rkg9HcYKtszE0sR2uNak/B0=
=5BMY
-----END PGP SIGNATURE-----