Wiki Incorrect?

[John A Meinel]

Florian Weimer wrote:
> * John A. Meinel:
>
>
>>Now, when that is committed, you have 2 parents. If you do the diff
>>against one parent, you will get the rollup of the opposite branches
>>changes.
>>
>>For example:
>>
>># A - B - C - D - E
>>#   \           /
>>#     F - G - H
>
>
> But this is just a special case.  What happens if I merge too early,
> or commit an unrelated bugfix on the same branch?  Is it still
> possible to create a cohesive changeset which only reflects the
> functionality change I was originally working on?
>
> My main concern is that James' description suggests a level of
> cherrypicking support which doesn't seem to be there.
>

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

Are you talking about something like this? And you want the rollup for
F-G-H-J-K?

There is always "bzr diff -r revid:F..revid:K" (which may not work as
currently implemented, unless F and K are in the revision-history of the
current branch).

No, we don't explicitly have cherrypicking. But we do have the
"changeset" plugin.

My question, though, is how would you get "a cohesive changeset which
only reflects the functionality change I was originally working on". If
you have a branch that you were doing the development on, you have that
branch. "bzr merge -r base..tip" will merge only a selected set of
revisions, it just doesn't have the ability to mark that they have been
merged.

So if you had

# a - b - c - D - e - f

And D was an accidental/unrelated commit, you could do:

bzr branch -r c ../new-dir
cd ../new-dir
bzr merge -r D..f ../old-dir

And you would end up with a tree which was

# a - b - c - g

Where "g" would contain the contents of e-f

But it wouldn't have a back pointer to 'f' because e and f were cherry
picked, not ancestors.

At its core, bzr does not think like Arch with patches. It saves
snapshots of the entire tree. When you compare 2 snapshots, then you
have a "changeset" (a collection of patches, renames, additions,
file-ids, etc).

You can generate any "changeset" you want, with either 'bzr diff -r
base..target' or my changeset plugin (though some functionality might be
missing from my plugin)

Think as to why do you need a "changeset". Is it because you want to
submit it to someone else?
In Arch, with all of its patches, you still had a bogus commit
inbetween. So you have to create a new branch, and merge everything that
is not that patch. I think bzr would let you do it, with this topology

# OTHER_TREE   1 ... 200
#                      |
# YOUR PATCHES         + a - b - c - D - e - f - g
#                      |
# CLEANUP              X

bzr branch http://OTHER local
bzr branch local working
cd working
<hack hack, commit a-g>
cd ..
# Oops, I shouldn't have done D
# and I want a single changeset to give back
# to OTHER
bzr branch local cleanup
cd cleanup
bzr merge -r 200..c ../working
bzr merge --force -r D..g ../working
bzr commit -m "A cleanedup commit, which has exactly the changes I want"

Now the difference between "200" and X is exactly your rollup changeset.
And your changeset won't list anything as its ancestor, since you did
the "cherrypick" merge (supplying an explicit base).

If you don't mind a little bit of ancestry, then you could change the
first merge to:
bzr pull -r c ../working

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051004/f1eb3bc7/attachment.pgp