Changesets feature complete

[Aaron Bentley]

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

John Arbash Meinel wrote:
| Aaron Bentley wrote:
|
|>John Arbash Meinel wrote:
|>
|>>>Aaron Bentley wrote:
|>>>
|
| # Bazaar revision bundle v0.7
| #
| # message:
| #  Add ghosts to TODO
| # committer: Aaron Bentley <aaron.bentley at utoronto.ca>
| # date: Sat 2006-05-20 19:04:49.732064009 -0400
|
| It would be nice if bzr went ahead and dropped the resolution on commit
| timestamps. I really don't think we need better than 1s resolution
| there. And at best would be 1ms. Having 1ns resolution is a little bit
| silly. (I realize some of that is just needing to round-trip a float).

Another thing we could do is split the commit date into two fields, and
make the top one extremely readable.  E.g.

date: 7:04:49 p.m. Sat May 20 2006

|>Another alternative would be to generate both diffs, see which was
|>shortest, and use that.  (bases can be overridden on a per-revision basis)
|
|
| I don't think that pure shortest is always best.

Yeah, I'd prefer to be very consistent, at least when there's a chance
of it being read by a person.

|>This is true.  But what it shows is the changes the committer
|>originated, which I think is more interesting.  So if they had to do a
|>lot of conflict resolution, you would see that.
|
|
| You see conflict resolution, but don't you see the entire set of changes
| bundled up as well?

You see the conflict resolution, plus all changes originated by the
committer up to that point.


| If I do:
|    A-B-C-D-H-I
|     \     /   \
|      E-F-G-J-K-L-M
|
| Then the common ancestor for submitting M should be I, and the L change
| would be a rollup of all of J,K, and L. You still need to send J and K
| because of I doesn't have them in the ancestry. So you end up sending
| J, K, (J+K+conflict resolution), M
|
| The alternative would be to send
| J, K, (H+I+conflict resolution), M
|
| I don't specifically see duplication in the alternative version. Though
| I guess H+I is already known to I.

H+I is essentially unrelated to the E-M branch.  If E-M is a branch of
TreeTransform work, H+I is a branch locking fix, three new commands, a
new repository format, Twisted, and some documentation updates.  It's
not something you'd ever want to review when looking at E-M.

Here's a worse case:

A-B-C-D-H-I-J-K-L-M
~ \     \     \     \
~  E-----F-----G-----O

In the E-O branch, nothing has changed.  We've just got a bunch of
merges.  If you go with leftmost parents, then F is B+C+D, G is H+I+J
and O is K+L+M.  This isn't an unusual case.  It tends to happen to my
bzr.ab branch.

Basically, the logic is that a text

|
| Any way that we could perform the merge, and then just have 'L' be the
| changes between that and the merge? Then it would be:
|
| J, K, conflict resolution, M
|
| It would require that merges are deterministic, which we probably don't
| have. But it should would be a nice display. :)

Well, we'll have deterministic merges once you integrate that fix for
the Patience SequenceMatcher. :-)  But I agree, we don't want to prevent
future merge improvements.

| Yeah, I wonder about base64-encode of the compressed patches. (Since if
| you are encoding, you might as well save some space).

Yeah, that might be nice.

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

iD8DBQFEdi+B0F+nu1YWqI0RAl18AJ4/nCFHi1RmbeoZWbE0mNSo4KlbPgCdFeOx
3t95IWzVDmA7KK5XXpK24W4=
=gkBI
-----END PGP SIGNATURE-----