Lobbying for -p1 diffs

[John Arbash Meinel]

Michael Ellerman wrote:
> On 3/1/06, John Arbash Meinel <john at arbash-meinel.com> wrote:
>> Michael Ellerman wrote:
>>> On 2/28/06, Wouter van Heyst <larstiq at larstiq.dyndns.org> wrote:
>>>>> --- work.orig/arch/powerpc/kernel/setup-common.c
>>>>> +++ work/arch/powerpc/kernel/setup-common.c
>>>> Hmm, will branch nick work with "Aaron's integration" type nicks?
>>>> +1 on using -p1, just need to figure out sensible labels.
>> Well, you could always just make it the last component of
>> WorkingTree.basedir/Branch.base. Those have to be a valid path.
> 
> Yeah, except that will look like the branch nick *most* of the time,
> until you change the nick to
> "really-important-name-thats-a-valid-path" and you wonder why it
> doesn't show up in the diff. But it's still a reasonable option.
> 

Well, we could do the opposite, and use branch nick, unless it is an
invalid path. :)

But I think if we leave it as part of the path, then it will always
*look* like the last portion of the url. Which happens to be the branch
nick. I think most people would see the URL association before they saw
the nick association.

>> If I read what you had correctly, you want to use
>>
>> SOMETHING.orig/path/inside/branch
>> SOMETHING/path/inside/branch
>>
>> Is that correct? You prefer the prefixes SOMETHING.orig and SOMETHING?
> 
> I'm really not fussy, I just thought branch nick would look nicer and
> impart a little more info, but if it gets problematic I don't think
> it's a biggy.
> 
>> I was actually thinking, if it is available, we could use revision
>> numbers. so you would have 'work.1500/' and 'work.1501/' with fallbacks
>> to 'work.orig' and 'work.mod' if a revision number was not available.
>> (Say you diff'd against a merged revision, or for the working tree).
> 
> Hmm, that'd be kinda cool. Except it'd often be work.1500 and
> work.working-tree. And actually having to fallback to work.orig and
> work.mod kinda sucks - users who don't understand about merged
> revisions not having a revno are going to wonder what the hell's going
> on.

But 99% of the time, you won't diff against a specific revision. You
would diff against another tree. Which means we would want to show:

--- bzr.dev.1500/bzr
+++ bzr-jam-integration.1483/bzr

> 
>> I don't care whether we use ., -, {}, whatever to denote it.
> 
> Spot the arch user ;D
> 
> cheers

True enough, though technically, Martin was never truly an Arch user,
and he *liked* and *used* {} to denote revision-ids. (If you look
through the code, there are a lot of places where revision ids are
formatted as "No revision id: {%s}" % (rev_id,).

So {} can exist outside of Arch. But yes, this one was from me. :)

The problem I specifically have with '.revno' is that it depends on how
people name their branch. If they numbered by revision you would get:

--- bzr-0.7.1.1500/
+++ bzr-0.8.1600/

(Actually, I think the above looks pretty cool, but if your revision
numbers were low, it might be confusing whether the final number was an
actual release number, or a revno)

And I use '-' to denote my branches, while Martin uses '.'. Hence
'bzr-jam-integration' versus 'bzr.mbp.integration'.

Ultimately, I might prefer to use path separators (once we have
repositories) to give us "bzr/jam/integration/", and that doesn't
translate well into -p1 paths.

Oh, and branch-nicks can certainly contain slashes, so we would need to
be extra careful in using them.

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/20060228/fc0ecbe2/attachment.pgp