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

[John Arbash Meinel]

Matthieu Moy wrote:
> Aaron Bentley <aaron.bentley at utoronto.ca> writes:
> 
>> 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.
> 
> That would be nice also, still, it doesn't provide the solution when
> the revisions belong to different branches.

Does yours actually work in that circumstance? I don't remember all the
details of the internals of diff. Probably it doesn't have to have the
information locally, as long as it can extract a RevisionTree.

> 
>>> 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.
> 
> Well, matter of taste, but I don't find my proposed syntax
> non-user-friendly ;-).

I find it a little convoluted that suppling 'revno:' allows you to
specify the branch, but only a revision number. There is no way to
specify a branch & a revision id, for example.

> 
>>>>>> 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.
> 
> Because it does this local fetch. But that's internal implementation
> "detail", it doesn't make a difference for the user.
> 
> And it makes the same UI problem. What does
> 
> $ bzr cat http://some/branch/some/file -r branch:http://some-other.branch/
> 
> mean for example ?

Well, in the current 'bzr', it means grab the revision id of the tip of
'http://some-other.branch', and look up 'some/file' in
'http://some/branch' at the specified revision.

You make it a little more convoluted than perhaps necessary, but say you
are using simple branches as 'tags'. Then the '-r
branch:http://some-other.branch' is just defining a revision id, just
like if you did:
bzr cat -r tag:foo http://some/branch/some/file

So I think it does have merit. Obviously it can't really do a fetch, and
it might fail at this point. But it does have meaning.

> 
>>> The difference beign that "branch:..." does a local fetch.
>>> That's conveinient in some cases, but [...]
>> 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.
> 
> Agreed. In the vast majority of the time, the fetch is useful. Still,
> in the long term, I'd like to see this "branch:" not do a local fetch
> if the branches are unrelated for example, and "branch:" could work
> also when called from outside a branch.

It also stems from a time when fetch was much more expensive (weaves).
At that time we had to download all of the inventory.weave (which could
be really big) just to extract one entry from it.
Now that we are using Knits, we don't have to download the complete
ancestry every time, so it isn't as necessary to do a full fetch.

> 
>> There is another way: allow two branches to be specified.  That would be
>> much more consistent with what we already do.
> 
> I don't think this is the perfect solution either (disclaimer: I'm not
> claiming my solution is perfect!):
> 
> $ bzr diff -r 4..4 branch/ other-branch/
> 
> At a glance, you see "4..4" and may think you're diff-ing twice the
> same revision. The information about the first and the second revision
> to diff are interleaved on the command line, I find it really strange.
> 
> $ bzr diff -r 4 branch -r 4 other-branch/
> 
> would be a bit more natural in this regard, but then it raises the old
> "should a second -r override the first one", ...

Right. And you also have issues like is this valid?

bzr diff -r 4 -r 4 branch other-branch

What about:
bzr diff branch other-branch -r 4 -r 4


> 
>>> 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.
> 
> Well, here, I don't know what best to do. So, I'm really open to
> proposals. Indeed, (cf. above), the problem already exists with
> "branch:".
> 
> I'd probably like something like
> 
> usage: bzr cat FILENAME [BRANCH]
> 
> instead of the existing, but that means breaking the existing
> behavior :-(.
> 
>> Remember that we already have the revid: revision spec, so we already
>> permit most of our commands to accept totally arbitrary revisions.
> 
> True, I forgot about that.
> 
> That said, for log, I just tried "bzr log -r revid:xxx..revid:yyy",
> with xxx and yyy beign two unrelated merges in a branch, it seems to
> fall back silently to "bzr log".
> 

Well, log has a couple bugs in it, but what would you define as valid
behaviour if source and target are unrelated merges?

Wouter van Heyst was working on fixing log so that it could handle
revisions that weren't in the mainline.
But beyond that, 'bzr log -rX..Y' is defined as the logs along a line.
How do you define the line between two unrelated merges?

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/20060808/4c54dca6/attachment.pgp