Changesets feature complete

[John Arbash Meinel]

Aaron Bentley wrote:
> Martin Pool wrote:
> | On 20 May 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> |
> |
> |>>This is by design.  'Changeset' is a really bad word to describe what
> |>>these things have become-- they're more like a collection of revisions
> |>>in a textual format.
> |
> |
> | I agree; it's used for too many things.
> |
> | "Change pack", "patchset", "change bundle", ...?
> 
> More: Branch bundle, repository fragment, repo shard.

I can't help but think of "The Dark Crystal" when I hear shard.

The problem with changeset is that it means 'set of changes'. And the
issue with 'set' is that a set of a set is still a set. It doesn't
really have a concept of double grouping. You can think of a delta
between revisions as a set of changeset, and a group of those as a set
of changesets, or changeset set.

I'm fine trying to create a new name for it, to help move away from any
connotations.

'darcs send' calls it a "bundle of one or more patches"

We could call it 'bzr bundle', but bundle is also a verb. And most
commands are verbs.

Certainly we could just have the 'bzr send' command, and avoid the
naming issues (for now).

> 
> | But we also want the posted thing to be suitable for code review, which
> | usually wants a single diff spanning the whole thing.
> |
> | So in some cases I think we will want *both* the overall and individual
> | diffs
> 
> We do this by default.  I've attached an example.
> 
> In the example, the first diff (Test and fix...) is against the
> changeset base, which defaults to the common ancestor.  All subsequent
> diffs are against the rightmost parent.  Since the third revision (Merge
> mainline) produced a tree that was identical to its rightmost parent, it
> has no actual diff.

The rightmost parent was chosen because of patches where another branch
merges all of you, and then you merge them back. I'm not positive if it
is the best pick of base, but it is an okay one.
Will we tend to have this behavior in the real world? Obviously we have
it happen on a few of our bzr trees, when we submit to mainline, and
then later on we do a merge before we keep developing.

To draw it out:

  A-B-C-D-H-I
   \     /   \
    E-F-G-----J-K

In this case 'J' is almost always identical to I (and it is our current
failing that we cannot make it 'I' and thus have convergence).

However, I think in this case, you would not get an empty merge:
  A-B-C-D-H-I
   \     /   \
    E-F-G--J--K-L

My concern is that now the patch for 'K' actually looks like the G->J
difference. Since that is most likely the delta from I->K. Which means
you would have G->J, and then J->K looks like you re-applied G->J.
(Technically it is I->K, but you still end up with the same patch
showing up 2 times).

My other issue with selecting the rightmost parent is that it is not the
actual changes that the person developing branch 'E' was reviewing. When
you run 'bzr diff' it shows you the changes relative to your leftmost
parent, not the rightmost (though sometimes it would be nice to be able
to specify that :)

I understand why Aaron went for rightmost. He has a lot of merges like
case 1. Especially with our workflow on bzr, if you pick up a branch
after a lot of time, you may pull 100 changes in a single merge. So it
cleans up that case a lot.

I'm wondering if we could detect something like this, and switch the
base if the delta is empty, but otherwise always use leftmost. We would
have to be explicit about which base the patches are against, rather
than just using left/right implicitly.

> 
> | possibly with the individual diffs packed up (e.g. in a
> | zip mime attachment) so they don't clutter up the review.
> |
> This is something we haven't done.  It's worth considering.  It can be
> interesting to page through the various diffs to see the evolution of
> the patch, but people are sometimes embarassed by that.  They prefer to
> provide a final, cleaned-up patch that doesn't show the missteps along
> the way.
> 
> On the other hand, it's hard to know how a changeset that was largely
> opaque would be received on MLs like the lkml.
> 
> Aaron

Well, a lot of our design is based around getting it onto lkml. Since
they want things that they can directly pipe through 'patch'. However,
this sounds like a case where we need to hide all the extra patches,
since otherwise it would apply the primary patch, and then a bunch of
patches that can't be applied afterwards.

John
=:->

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