Michael Olson <[EMAIL PROTECTED]> writes:
> I guess what I meant to ask was: Can I get a listing of patches that
> are in my local repo but not in upstream? I guess if I could apply
> the below method to "bzr missing" and/or "bzr log" that would be
> sufficient.
What's wrong with bzr missing?
/tmp/bar$ bzr missing ../foo --line
You have 1 extra revision(s):
2: Matthieu Moy 2006-06-20 bar
You are missing 1 revision(s):
2: Matthieu Moy 2006-06-20 upstream
/tmp/bar$ bzr missing ../foo --line --mine-only
You have 1 extra revision(s):
2: Matthieu Moy 2006-06-20 bar
/tmp/bar$
> Hmm, interesting. Can I use the branch nickname instead of
> "/the/branch/"?
No, because there's no branch registry as in GNU Arch. Furthermore, it
would indeed be very inconvenient to type, since branch nicks often
contain shell meta-characters.
The thing that approaches the most what you're looking for is probably
export dvcupstream=http://....
and
bzr diff -r "ancestor:${dvcupstream}.."
It might be worth having a system of shortcut built into bzr, but I'm
not sure it would really be supperior to shell variables. If you want
to discuss this, I suggest doing this on bzr's mailing list (if we end
up with a decent proposal, the developers might be interested ;-) ),
but it's probably better to implement that in front-ends (i.e. use
your shell variables for CLI, DVC's bookmarks for Emacs, a menu for a
GUI, ...). Not sure about that.
>>> So what are branch nicknames supposed to be used for, then, if not
>>> names of branches?
>>
>> OK, I missunderstood you. I thought you meant put your email address
>> as the branch nick. OK, a hashtable "branch nick" -> "submission
>> email" could be OK to me.
>>
>> That said, the branch will eventually contain the submission email,
>> and there will also probably be a way to specify that address in
>> ~/.bazaar/branches.conf, which allows wildcards on the branch
>> location, so it will be possible to specify several submission
>> adresses at the same time. This should be used when available.
>
> Certainly. I didn't realize that bzr already had a facility for
> associating submission addresses with branches.
It does not already have, it's being discussed. But if you add this to
DVC today, will you be willing to remove it when it's available in bzr
upstream (i.e. most probably before the first stable official release
of DVC)?
If you want to spend time now on a "branch -> submission address"
mapping, you should contribute it to bzr, not to DVC.
As I've said a while ago, Xtla contains a lot of hack and workaround
to implement things that should have gone into tla, but that Tom
didn't want to include. But we shouldn't reproduce this error since
the supported back-ends are today in active development. DVC is the
interface, not the system.
In particular, I think people should let the choice of the tool to use
to their contributors. In the case of patch submission, there are 4
cases (more indeed, because there will also be DVC and non-Gnus users
for example) :
1) A non-DVC user submits to a non-DVC user,
2) A DVC user submits to a DVC user.
3) A DVC user submits to a non-DVC user,
4) A non-DVC user submits to a DVC user,
It's easy to manage cases 1) and 2), but the more stuff we put into
DVC instead of bzr, the worse are cases 3) and 4). And I believe DVC
users will be the minority, so the large majority will be 1), most DVC
use-cases will involve 3) and 4), and only a few lucky persons will be
in case 2).
If we have a clean interface/back-end separation, we can get all the
benefits of DVC even in 3) and 4), because the message sent will be
the same, and only the way to compose it and to process it will be
different.
> Would this branches.conf file associate the URL with the email
> address,
This is the plan currently. You probably already have this
branches.conf (which is being renamed to locations.conf), you can have
a look to see what it looks like.
> or the branch nickname with the email address? If it's the former,
> we might have to encapsulate that information in the patch
> submission email somehow so it can be used to correctly apply the
> patch (unless we do a reverse lookup on the submission email address
> to find the branch ... hmm).
On the recipient side, the problem is much more complex, because the
recipient might decide which branch to apply the patch to depending on
the patch content (like: will it go to the branch preparing a minor
bugfix release, or to the dev branch ?), but it sounds reasonable to
provide a default if it's overrideable.
In any case, the sender doesn't know the branch location to which the
patch will be applied, because it will typically be
"/home/moy/emacs-lisp/dvc-main/" which you couldn't have guessed.
What's possible is that you request a merge in
http://public/address/of/my/branch, and I can have a local mapping to
/home/moy/something.
The branch nick doesn't help you much because the sender will probably
have his own branch nick (by default, the name of the directory
containing the branch).
Probably bzr itself should provide a mechanism to automate the choice
of the branch to merge into.
--
Matthieu
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
