Hi Avi,

Thanks for your very quick response!

Avi Bryant <avi at beta4.com> wrote:
> On Mar 21, 2004, at 2:22 AM, bernhard at pieber.com wrote:
> > The Merge Browser lists first all conflicting methods in bold and then
> > the non-conflicting methods. The button Reject seems to only have an
> > effect on the conflicting methods. If I select a conflicting method and
> > press Reject it is striked out in the list and the method is not merged
> > in when I press Merge later. Is there also a way to do this for
> > non-conflicting methods?
> No.  That's probably the most frequently denied feature request for MC 
> :). The problem is that once you have rejected an item from the merge, 
> you'll never be able to merge it in again - as far as MC is concerned, 
> you saw that method and don't have it, so you must not have wanted it.  
I see. Hmm... I don't fully understand why this would be a problem. On
the contrary, this is exactly what I want. I would not want to merge it
in again, if I say during the merge that a certain method, conflicting
or non-conflicting, is not needed anymore. What about allowing to reject
non-conflicting methods and warning the user about the consequences when
he presses Merge?

> This isn't what people likely expect when they use the merge browser.
Well, it seems that at least I expected it. And weren't you saying this
was a frequent feature request? ;-)

> (I think they usually want that feature when they need to cherry pick a 
> few items from another version now, and would like to be able to cherry 
> pick a few more later).  I think having to explicitly merge in and then 
> remove those methods is more clear.
I can see why this might be clearer. It is just that the work flow is
more complicated. If I press Merge the Merge Browser is closed. Then I
have to find those methods again in order to delete them. Now that  I
think about it, this is even more of a problem with some conflicting
methods. If neither of the two versions is a correct merge I have to
manually change the code. As it belongs to the merge it could be argued
that this should be done in the Merge Browser. A simpler alternative
would be to have a third button named Later. After the merge you get a
method browser with all methods which were marked that way.

> That said, it *would* be nice to have a cherry pick interface, but I 
> think it has to be without semantics - that is, a way to copy changes 
> from one branch to another without actually affecting the ancestry.  If 
> you find yourself doing this a lot you probably need to be separating 
> your branches out more (ideally, each independent change should be on a 
> branch from the last stable release).
I agree this feature would be nice. It would even be required for
separating branches out more. I often start implementing some
functionaliy and realize only later that there are separate features.
Therefore I often moved changes between ChangeSets in the pre-monticello
days.

> > I try to merge Monticello-bp.65.mcz into Monticello-avi.146.mcz in the
> > following way: I only want to keep non-conflicting changes, i.e. 
> > changes to methods which were not changed in the meantime. I do not want to get
> > methods which were in version 64 but were deleted afterwards. Is there 
> > a way to achieve this with the current UI?
> That sounds like a standard merge to me.  In other words, if you load 
> -avi.146, select -bp.65, and then choose Merge, that's exactly what I 
> would expect to see.
Hmm. Perhaps something did not work as expected? For example, the method
MCRepositoryInspector>>pickRepository is listed as a non-conflicting
method which would be created by the merge. (The source is red.)
However, I am 99% sure that I did not touch this method in my version.
First I thought that it is there because it was in version avi.64 and
not anymore in avi.146. But now that I think about it, I don't
understand why Monticello hasn't identified this as a non-conflicting
delete. There are seven methods like that.

I looked again at the histories of each version and found out that
avi.64 is not an ancestor of avi.146. There is a hole in the ancestors
of avi.146 between avi.65 and avi.48. So it seems that avi.48 is the
last common ancestor of bp.65 and avi.146. Might this be a reason? Is
this a case for Adopt maybe?

> > By the way, is there a way to compare two versions with each other even
> > if none of them is in the image? That would be very useful.
> Yes.  Use the History view on the later one, then bring up the 
> context-menu on the earlier version name in the list of ancestors and 
> you can choose to see a diff.  If you're browsing History and you want 
> to diff two arbitrary ancestors, you can spawn a new History for the 
> later ancestor and then do the same thing.
Thank you very much! I knew it had to be there somewhere.

- Bernhard