[PATCH][UPDATED] Re: make "merge" work nicely with revno:N:patch

[Aaron Bentley]

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

Matthieu Moy wrote:
>>>> bzr merge -r ${REVISION}
>> The motivation for doing this still isn't clear to me.  What's wrong
>> with the other form?
> 
> Well, the main problem for which I introduced this was that
> previously, there were no way _at all_ to diff two remote revisions.

There's no reason you shouldn't be able to do "bzr diff
http://bazaar-vcs.org/bzr.dev -r -5..0".  You can't, but that's arguably
a bug.

> Command-line interface doesn't mean only /user/ interface, it's the
> interface to anything calling bzr as an executable (as opposed to
> calling bzrlib).

Yes, but the commandline should be friendly to users.  If the only way
of diffing remote revisions is by using a syntax only a shell script
could love, I think we've got a problem.

And if we provide all the operations a shell script could want, I don't
think it's cruel to shell scripts to make them use user-friendly syntax.

>>>> so it's better to have it working.
>> I really, really don't like jamming the branch info into the revision
>> spec.  
> 
> Well, I'm not the one who started this. "branch:..." has been there
> for some time before I proposed and implemented that other revision
> spec. 

By 'jamming', I meant making the branch location part of the spec's
output.  branch: only produces a revision id.

> The difference beign that "branch:..." does a local fetch.
> That's conveinient in some cases, but that also means that doing
> 
> $ bzr diff -r branch:/my/kernel/tree/..branch:/my/other/kernel/tree/
> 
> will fetch all the kernel history in my local branch, which may be
> completely unrelated from the kernel.

This is an unusual case.  The vast majority of the time, the fetch is
helpful, because you'll do 'cd /my/kernel/tree; diff -r
branch:http://example.com/my/other/kernel/tree/'.  And then subsequent
operations will not need to fetch the data from a remote branch again.

> Anyway, to say "diff this revision of this branch with this other
> revision of this other branch", I believe the two ways are to add
> branch information in revision specifiers, or to add revision
> information in branch locations, and I don't find one really better
> than the other.

There is another way: allow two branches to be specified.  That would be
much more consistent with what we already do.

>> If we're going to add this new syntax, we might as well take advantage
>> of the new options it provides.
> 
> That's an option. I went the safe and simple way and prevented it
> cleanly, since I suppose it wouldn't have worked out-of-the-box
> otherwise (indeed, I don't know how to make it work, since there may
> be several paths from one revision to another in the history).

I don't think you have to worry about that.  There are already plenty of
ways to specify two non-related revisions using revision specs. e.g.
'revid:'

> I don't like the idea of providing the full path in a single URL.

It made more sense when remote branches always had working trees.  I
agree it's a bit odd.  Still, it's a pretty compact way of representing
this information.  Maybe we can change this convention, but we shouldn't
make commands inconsistent just because you don't like the convention.

>>> +                        "Merge doesn't accept two revisions in different branches.")
>> Again, I don't see why not.  Maybe it's not useful every day, but it
>> certainly can be.
> 
> Same as above, I just went the safe way. Well, this one might work
> out-of-the-box.

It was originally designed to work this way.  Merge's commandline used
to look like this:

$ bzr merge ../basebranch at 2 ../otherbranch at 5

See, we've already had branch-and-revision specs, and we took them out.

> Will it be acceptable when bzr will record partial
> merges like this one?

No matter how you enter the revision specs, merge will do the best it
can right now.  Since we don't have partial-merge metadata, it won't set
any pending merges for partial merges, but it doesn't care which
branches the revisions came from.  It is already very easy to do partial
merges.

Remember that we already have the revid: revision spec, so we already
permit most of our commands to accept totally arbitrary revisions.

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

iD8DBQFE12kC0F+nu1YWqI0RAuaDAJsGdmuZhwK4MbcMv1Cbdf0AllaxJwCeK90/
AvfrO9LQEK8AYo8gUrhxEN0=
=0PCg
-----END PGP SIGNATURE-----