Changesets feature complete

[Aaron Bentley]

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

John Arbash Meinel wrote:
> Aaron Bentley wrote:
> I'm not talking about signing the changeset. I'm talking about including
> the revision signature. Which should have been generated on the original
> revision, and would thus prove that the revision matches the original.

I'm talking about signing the revision too.
What I'm saying is that the testaments used in signing aren't meant to
prove that the source revision is identical to the target revision.
They are only meant to prove that they are close enough.

> (I do think we want to be able to sign a changeset, but that can be done
> at a higher level)

I think we want to sign the message that says "please apply this
changeset", but I don't know about the rest.

If you sign a changeset containing your own revisions, that's the same
as signing the revisions themselves.  If you sign

> If the execute bit wasn't in Testament, I think that is a bug. I'm also
> not sure about the last-modified.

last-modified was deliberately left out.  I'm not sure about the execute
bit.

> I don't see the problem with changing ChangesetTree. you just have a
> 3-conditional if statement:
> 
> if file_id in self._executable:
>   # It was present in the changeset
>   return self._executable[file_id]
> elif file_id in self._base_inventory:
>   return self._base_inventory[file_id].executable
> elif:
>   # This is a new addition, default to non-executable
>   return False

Ugh, ugh, ugh.  The semantic in ChangesetTrees is always "same as base,
except where changes are indicated".  If we keep ChangesetTrees simple,
we can use them for multiple revs of the Changeset format.

If we start encoding very format-specific details into them
 - You wind up with behaviour that doesn't really make sense by itself
 - Debugging gets harder, and you miss certain types of problems.
 - You have to create a new kind of ChangesetTree when you want to
   change that behaviour.

> We could change the reader so that it always supplies the executable bit
> to the ChangesetTree, but that seems unnecessary.

Not always, just for new files and execute-bit changes.

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

> We certainly could. Actually the trickiest part is that Transports
> return all sorts of things when you 'get()' a directory. Http might
> return an index,

(or might raise 403)

> LocalTransport raises an exception, and sftp doesn't
> raise an exception until you try to read() the directory. (I don't know
> what Ftp does).

Yeah, that's a pretty nasty combo.

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

iD8DBQFEdch00F+nu1YWqI0RAix5AJwJUtQXB/fJvRfBE4b7Lo9Z7s+5OwCffCnk
JrbDwWvjuUMBR4hwRJZVHY4=
=zYlS
-----END PGP SIGNATURE-----