You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2005/11/03 03:59:02 UTC
Re: Auto-subst of repository roots (was Re: svn diff branch woprking
copy against mainline?)
Daniel Berlin wrote:
> A bunch of my gcc users are complianing that they are continually typing
> the repository root to do certain diffs.
> They are, of course right.
> Usually, we just say "you can script with the shell", but as Richard
> points out below, a substitution works everywhere, shell only works if
> you are working in the same root everywhere.
>
> Ignoring the question of what character would substitute repository
> root, would anyone be opposed to having such a substitution.
Not sure. May I ask to see a couple of realistic use cases?
> For url vs url diffs, we'd look up the info from the current directory
> (best we can do).
So you mean something like: if the current directory is a Subversion WC then
get the repository from it; if not, fail. So, for example,
svn diff --old=+/trunk/gcc/foo.c --new=+/branches/1.0.x/gcc/foo.c
meaning "diff the trunk and branch head versions of that file in the repository
for which the current working directory is a working copy". OK, perhaps.
> For url vs wc diff, one of the targets has to be in the wc, and we can
> just get the repository root for that file (in case it is switched).
So, for example,
svn diff --old=+/trunk/gcc/foo.c --new=gcc/foo.c
meaning "diff gcc/foo.c against the trunk head version of that file in its
repository". That seems good. Note that in this example the "+" idea is only
needed if the current working copy is _not_ trunk, otherwise simply "diff
-rHEAD gcc/foo.c" would do the job.
> On Wed, 2005-11-02 at 16:08 -0800, Richard Henderson wrote:
>
>>On Wed, Nov 02, 2005 at 06:39:53PM -0500, Daniel Berlin wrote:
>>
>>>Of course, the question always raised when you try to do this is "why is
>>>this better than just using shell variables"
>>>
>>>if you can give me a good answer to take back to dev@subversion, i'm
>>>happy to
>>
>>If we had something to expand to "Repository Root", then you
>>would have a mechanism that would automatically work in whatever
>>repository you're currently working in. Something that can't be
>>said about shell variables.
>>
>>Even better if we can choose something that isn't already a shell
>>meta character, and so needs no quoting itself.
>>
>>What if we let "^[+]" substitute Repository Root? We'd get
Meaning a "+" character at the beginning of a target argument, I assume.
>> svn diff +/trunk/gcc/foo.c foo.c
That's not a realistic example:
svn: Target lists to diff may not contain both working copy paths and URLs
This is where I'd be glad to see some realistic use cases, even if others feel
that this is worthwhile anyway. Use cases should state what the users are most
often trying to achieve, and what commands are currently required, and what
might the abbreviated commands look like.
Are my examples above the sort of thing you mean? If so, and a user is
commonly diffing between +/trunk/gcc and +/branches/1.0.x/gcc, then wouldn't
he/she prefer to substitute those with an environment variable or other method
of further abbreviation, thus obviating the need for abbreviation of just the
repository root? For example,
svn diff --old=$GCC_TRUNK/foo.c --new=$GCC_1_0/foo.c
I'm not saying we shouldn't do the "+" thing, I'm just asking for more concrete
data.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-11-03 12:05:17 -0500, C. Michael Pilato wrote:
> I dunno if this has been mentioned yet, but I figured I'd throw this
> idea into the mix:
>
> 'svn command root:///path/in/repos'
BTW, I've just remembered that such a form (a name followed by a ':')
is used as a path under RISC OS (and "root" is even a defined path on
my machines, so there would be a clash here!). I haven't checked what
the Subversion port does concerning the filenames, though.
However I think there would be no problems with more special characters
followed by a ':', such as '/:' (which would also be shorter).
But what about making prefixes configurable?
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff
branch woprking copy against mainline?)
Posted by Daniel Berlin <db...@dberlin.org>.
On Thu, 2005-11-03 at 05:19 +0000, Julian Foad wrote:
> Daniel,
>
> I did say in my last mail:
> > I'm not saying we shouldn't do the "+" thing, I'm just asking for more concrete data.
>
> And you are giving more data. Thank you. You sound very frustrated - which I
> can understand
Yes, but you didn't receive 5 emails from what must be random lurkers on
dev@, not copied back to the list, saying "Oh, just use the shell!. Use
the shell! SHELL SHELL SHELL SHELL SHELL".
Personally, i think saying "use the shell" misses the point entirely.
We could script pretty much everything, and turn svn's command line into
probably 5 or less commands.
You don't need diff, you've got export, cat, and /usr/bin/diff!
Just script it!
Users don't want to be scripting a lot of things. When it's not going
to cost us much to make it so they don't have to, and it's incredibly
frustrating to them otherwise, we shouldn't tell them to script it. Am
i advocating we add 700 commands to svn to cover every conceivable case?
No.
This is probably *the second most common use case for diff and merge*.
Not something 6 people do once every three years.
It's one thing when it's some major design issue. But we are talking
about something no other VCS has a problem doing, which is retyping the
repository root again and again, for simple commands people do every
day.
Telling people to use the shell to do things you *should be doing for
them* is like arguing over the theoretical niceness of some solution
that sucks in practice. When it comes down to it, it makes no difference
how easy or simple it is, or how elegant it is, because it sucks in
practice, and real everyday use is what really matters.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch woprking
copy against mainline?)
Posted by Julian Foad <ju...@btopenworld.com>.
Daniel,
I did say in my last mail:
> I'm not saying we shouldn't do the "+" thing, I'm just asking for more concrete data.
And you are giving more data. Thank you. You sound very frustrated - which I
can understand - but you seem to think I am arguing against this feature and
I'm not. I'm just questioning it. I wasn't immediately and totally convinced
that this feature is needed in the form suggested, but I'm much more convinced
after reading your and other people's feedback.
Daniel Berlin wrote:
> On Thu, 2005-11-03 at 03:59 +0000, Julian Foad wrote:
>
>>Daniel Berlin wrote:
>>
>>>Ignoring the question of what character would substitute repository
>>>root, would anyone be opposed to having such a substitution.
>>
>>Not sure. May I ask to see a couple of realistic use cases?
>
> Uh, right now, to diff the gcc 4.0 branch against a working copy file,
> one has to type
> svn diff
> --old=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
> --new file.c
>
> To diff 3.4 against 4.0
> svn diff
> --old=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
> --new=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch/gcc/file.c
>
> You can make it roughly as long as it was in cvs if you remove the
> "svn+ssh://gcc.gnu.org/svn/gcc" part
>
> Heck, it even fits on one line then
> svn diff
> --old=+/branches/gcc-4_0-branch/gcc/file.c
> --new=+/branches/gcc-3_4-branch/gcc/file.c
>
> That is all my users want. To not have to type twice or three times as
> much text as they did in cvs just to do diffs
OK. That's a reasonable request and justification.
>>Are my examples above the sort of thing you mean?
>> If so, and a user is
>>commonly diffing between +/trunk/gcc and +/branches/1.0.x/gcc, then wouldn't
>>he/she prefer to substitute those with an environment variable or other method
>>of further abbreviation, thus obviating the need for abbreviation of just the
>>repository root?
>
> No.
> Why?
Because it's shorter, of course. Instead of your
svn diff
--old=+/branches/gcc-4_0-branch/gcc/file.c
--new=+/branches/gcc-3_4-branch/gcc/file.c
you could just type
svn diff --old=$GCC_4_0/file.c --new=$GCC_3_4/file.c
If the user does diffs between those branches frequently, then the shorter form
is beneficial.
Now, I understand that this gets unwieldy if you have as many different
branches active as you (plural) do. I didn't know you worked like that; thanks
for explaining. So, I accept that you might not find that env-vars suggestion
of much benefit.
> People are used to the repository root being abbreviated if they used
> cvs. [...] We claim to be better than cvs, [...]
OK, so this is what we call a "CVS parity" issue. Making Subversion no worse
than CVS is a fairly strong reason to do this.
> Some of these people have 20 branches of gcc checked out (most people
> have 4 or 5), remote repos. We still support the 3.4 line and the 4.0
> line. So realistically, you want to find diffs against 3.3 onwards.
> That's 16 environment variables right now.
If they have the branches of interest checked out, the quickest thing, if it
worked, would be to request diffs among the checked-out working copies:
svn diff --old=branches/gcc-4_0-branch/gcc/file.c
--new=branches/gcc-3_4-branch/gcc/file.c
No "+" syntax is needed there. Unfortunately this is not supported by
Subversion yet:
svn: Sorry, svn_client_diff3 was called in a way that is not yet supported
svn: Only diffs between a path's text-base and its working files are
supported at this time
However, a non-Subversion diff can be used, even more easily:
diff branches/gcc-4_0-branch/gcc/file.c
branches/gcc-3_4-branch/gcc/file.c
Would this be a useful practice, at least in the meantime before the desired
feature is implemented? Would it be useful to enhance Subversion to support
that mode of local diffs?
Of course I understand that if the user has local modifications in their WC,
then that WC-WC diff is not the same as a repos-repos diff.
> It's not like this is a hard feature to implement, or particularly
> burdensome on maintenance or syntax.
Indeed, and it seems likely that it will soon get implemented. Nevertheless I
am finding this discussion useful in building up an idea of the contexts in
which it will most commonly be used, which is helpful for determining what the
exact requirements, limits and future extensions of the feature might be. Yes,
I know, "it's a simple enough idea so just do it". But a little extra thought
and discussion always helps.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch woprking
copy against mainline?)
Posted by Peter McNab <mc...@melbpc.org.au>.
Daniel Berlin wrote:
>As i explained later on, this would require roughly 16 environment
>variables to mainly express something subversion already knows, and
>worked fine without 16 environment variables in cvs (and perforce,
>monotone, bitkeeper, etc)
>
>
So how do you ensure you have the correct 1 of 16 possible root paths
using a shortcut?
Seems if it relies on memory it would be too easy to make a typing error
and land in the wrong repository.
Is there some info already kept in the background by svn that associates
the current WC directory with the root path.
If that is already available the "shortcut" becomes the same for all
situations and indeed would make sense.
I'm spoiled by TortoiseSVN but occasionally revert to the command line
and experience your frustration.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch
woprking copy against mainline?)
Posted by Daniel Berlin <db...@dberlin.org>.
On Thu, 2005-11-03 at 11:47 +0100, Peter N. Lundblad wrote:
> On Wed, 2 Nov 2005, Daniel Berlin wrote:
>
> > On Thu, 2005-11-03 at 15:40 +1100, Peter McNab wrote:
> > > Daniel Berlin wrote:
> > >
> > > >Uh, right now, to diff the gcc 4.0 branch against a working copy file,
> > > >one has to type
> > > >svn diff
> > > >--old=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
> > > >--new file.c
> > > >
> > > >
> > >
> > > >That is all my users want. To not have to type twice or three times as
> > > >much text as they did in cvs just to do diffs
> > > >
> > > >
> > > So is there not an equivalent in *nix to the MS world where (and don't
> > > impeach me if the syntax isn't perfect)
> > > one would quickly learn to type something like
> > >
> >
> > As i explained later on, this would require roughly 16 environment
> > variables to mainly express something subversion already knows, and
> > worked fine without 16 environment variables in cvs (and perforce,
> > monotone, bitkeeper, etc)
> >
> Daniel, I'm +1 on this feature (it has been discussed before). But why
> would anyone need 16 envars? Do you have 16 repositoryies? Or do you
> propose the substitution to be for the whole URL, not just the repository
> root?
No, I don't suggest or propose it, i simply pointed it out because
Julian suggested they might use the shell and substitute more than just
the entire repository root (which is what would require so many env
vars).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch woprking
copy against mainline?)
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 2 Nov 2005, Daniel Berlin wrote:
> On Thu, 2005-11-03 at 15:40 +1100, Peter McNab wrote:
> > Daniel Berlin wrote:
> >
> > >Uh, right now, to diff the gcc 4.0 branch against a working copy file,
> > >one has to type
> > >svn diff
> > >--old=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
> > >--new file.c
> > >
> > >
> >
> > >That is all my users want. To not have to type twice or three times as
> > >much text as they did in cvs just to do diffs
> > >
> > >
> > So is there not an equivalent in *nix to the MS world where (and don't
> > impeach me if the syntax isn't perfect)
> > one would quickly learn to type something like
> >
>
> As i explained later on, this would require roughly 16 environment
> variables to mainly express something subversion already knows, and
> worked fine without 16 environment variables in cvs (and perforce,
> monotone, bitkeeper, etc)
>
Daniel, I'm +1 on this feature (it has been discussed before). But why
would anyone need 16 envars? Do you have 16 repositoryies? Or do you
propose the substitution to be for the whole URL, not just the repository
root?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff
branch woprking copy against mainline?)
Posted by Daniel Berlin <db...@dberlin.org>.
On Thu, 2005-11-03 at 15:40 +1100, Peter McNab wrote:
> Daniel Berlin wrote:
>
> >Uh, right now, to diff the gcc 4.0 branch against a working copy file,
> >one has to type
> >svn diff
> >--old=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
> >--new file.c
> >
> >
>
> >That is all my users want. To not have to type twice or three times as
> >much text as they did in cvs just to do diffs
> >
> >
> So is there not an equivalent in *nix to the MS world where (and don't
> impeach me if the syntax isn't perfect)
> one would quickly learn to type something like
>
As i explained later on, this would require roughly 16 environment
variables to mainly express something subversion already knows, and
worked fine without 16 environment variables in cvs (and perforce,
monotone, bitkeeper, etc)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch woprking
copy against mainline?)
Posted by Peter McNab <mc...@melbpc.org.au>.
Daniel Berlin wrote:
>Uh, right now, to diff the gcc 4.0 branch against a working copy file,
>one has to type
>svn diff
>--old=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
>--new file.c
>
>
>That is all my users want. To not have to type twice or three times as
>much text as they did in cvs just to do diffs
>
>
So is there not an equivalent in *nix to the MS world where (and don't
impeach me if the syntax isn't perfect)
one would quickly learn to type something like
SET gr=gcc.gnu.org/svn/gcc/
SET sr=tigris.org.subversion/
etc. etc
then embed %gr% in the command line text?
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots
Posted by Julian Foad <ju...@btopenworld.com>.
Alan Barrett wrote:
>
> Subversion as it exists today:
> With the proposed "+" syntax (assuming that "gcc" is part of the repository
> name, not a top level directory inside the repository):
> With John Peacock's proposed syntax (ignoring ambiguity issues for now):
> With Greg Hudson's proposed syntax (and with appropriate transformation
> rules for "B#branchname"):
> With CVS:
Thank you ever so much, Alan. Those comparative examples are exceedingly
useful - especially the CVS one as a baseline for evaluating the others.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots
Posted by Alan Barrett <ap...@cequrux.com>.
On Thu, 03 Nov 2005, John Peacock wrote:
> We could simplify that command to:
>
> svn diff
> --old gcc-4_0-branch/gcc/file.c
> --new file.c
>
> (NOTE the lack of a leading slash in old).
That doesn't help much in the general case. Remember that the
"/gcc/" in the above example could easily be something more like
"/gcc/fixinc/tests/base/arch/i960/", and users don't want to type all
that stuff. Here's the example again with the long path:
Subversion as it exists today:
$ svn checkout \
svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch \
gcc-3_4
$ cd gcc-3_4/gcc/fixinc/tests/base/arch/i960
$ svn diff \
--old svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/fixinc/tests/base/arch/i960/archI960.h \
--new archI960.h
With the proposed "+" syntax (assuming that "gcc" is part of the repository
name, not a top level directory inside the repository):
$ svn checkout \
svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch \
gcc-3_4
$ cd gcc-3_4/gcc/fixinc/tests/base/arch/i960
$ svn diff \
--old +/branches/gcc-4_0-branch/gcc/fixinc/tests/base/arch/i960/archI960.h \
--new archI960.h
With John Peacock's proposed syntax (ignoring ambiguity issues for now):
$ svn checkout \
svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch \
gcc-3_4
$ cd gcc-3_4/gcc/fixinc/tests/base/arch/i960
$ svn diff \
--old gcc-4_0-branch/gcc/fixinc/tests/base/arch/i960/archI960.h \
--new archI960.h
With Greg Hudson's proposed syntax (and with appropriate transformation
rules for "B#branchname"):
$ svn checkout \
svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch \
gcc-3_4
$ cd gcc-3_4/gcc/fixinc/tests/base/arch/i960
$ svn diff -r B#gcc-4_0-branch archI960.h
With CVS:
$ cvs -d :ext:username@gcc.gnu.org:/cvs checkout -r gcc-3_4-branch gcc \
gcc-3_4
$ cd gcc-3_4/gcc/fixinc/tests/base/arch/i960
$ cvs diff -r gcc-4_0-branch archI960.h
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch woprking copy against mainline?)
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 03 Nov 2005, C. Michael Pilato wrote:
> John Peacock <jp...@rowman.com> writes:
>
> > Daniel Berlin wrote:
> > > You could always make it url syntax, like
> > > repos://
> > > which we can't get wrong in this manner
> > > Unless you think someone is about to come out with the "repos"
> > > protocol :)
> >
> > Actually, I like that a lot; this could also allow us to have an
> > environment variable fallback for when you aren't in a WC. Even the
> > Windows people could manage that...
>
> Works for me. I'd already posted this suggestion, just as 'root://'
> instead of 'repos://'.
Though I'd suggested repos:// on #svn-dev to DannyB before reading
through this thread, root:// is one less character (which I like).
--
Daniel Rall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch woprking
copy against mainline?)
Posted by Julian Foad <ju...@btopenworld.com>.
Daniel Berlin wrote (subsequently):
> On Thu, 2005-11-03 at 15:38 +0000, Julian Foad wrote:
>>Cost of a feature is not measured in lines of code.
>
> That's a very nice simple statement to make, while ignoring the rest of
> the message i wrote, and what i've written before.
OK. Responding more completely. (I didn't exactly ignore the rest, I just
responded to a part that annoyed me.)
Daniel Berlin wrote:
>
> On Thu, 3 Nov 2005, Greg Hudson wrote:
>
>> I worry that adding an auto-subst of repository roots will not be enough
>> to justify the cost.
>
> How so?
> It's like 20 lines of code.
(This is how I should have responded: "Please try to keep up the high standards
of technical discussion of which you are capable. That comment gives the wrong
impression to inexperienced developers while just annoying the experienced
ones. I know you know that's not the measure of feature cost.")
Subsequently you wrote:
> As i've pointed out, it's a very small cost in:
>
> 1. syntax
That's the most significant factor. Interpreting, say, a "+" character
specially at the beginning of a target path argument is a significant
commitment. It's not a huge commitment, but neither is it a trivial change
that can be thrown in without serious debate.
> 2. code
> 3. maintenance
>
> So where is the real cost of this feature?
The syntax. I agree that costs (2) and probably (3) are small.
> And it saves about 60-80 chars out of 200 on a gcc command line (30-35%).
Yes. That's a significant benefit. On the other hand, we may be able to
provide an addition or an alternative that saves twice as much, at which your
users surely would not sniff.
>> In http://svn.haxx.se/dev/archive-2005-05/1367.shtml I outlined a more
>> complicated proposal which saves significantly more typing. I'm not
>> sure it's a good idea, but I do think we should be aiming higher than
>> just repository root substitution.
>
> Well, we have to start somewhere.
> It's easier to get consensus for something simple that works well, than
> a large scheme.
Yes, that's a fair point. But we also need to satisfy ourselves that the small
feature isn't going to be obsoleted by a larger feature in the near future.
Given that this won't be released (in Subversion 1.4) for a few months, it is
not unreasonable to discuss it for a few days or weeks before jumping into
implementing it. On the other hand, it may be that playing with it is the best
way to get a feel for how well it will serve us in the medium to long term, so
if you'd like to submit a patch now that the basic idea is reasonably well
defined, we could try it out.
I'm sure you appreciate the benefits of Greg Hudson's proposal to refer to
branches, tags, etc. more easily. Your examples:
svn diff
--old=+/branches/gcc-4_0-branch/gcc/file.c
--new file.c
svn diff
--old=+/branches/gcc-4_0-branch/gcc/file.c
--new=+/branches/gcc-3_4-branch/gcc/file.c
... become something like ...
Rule: BRANCH /trunk /branches/gcc-$1-branch
svn diff -r BRANCH#4_0 file.c
svn diff -r BRANCH#4_0:BRANCH#3_4 file.c
Personally, I would be very keen on something like this. We need to develop it
a bit more and see whether "-r" is the right syntax and how it works with other
commands and other combinations of WC and repository targets and how the rules
are stored and found.
My current feeling is about 50-50: if we can reasonably develop a more
comprehensive and shorter method in the same time frame, then we should do
that; if not, then we should implement the repository root substitution with
something like a leading "+".
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch
woprking copy against mainline?)
Posted by Daniel Berlin <db...@dberlin.org>.
On Thu, 2005-11-03 at 15:38 +0000, Julian Foad wrote:
> Daniel Berlin wrote:
> >
> > On Thu, 3 Nov 2005, Greg Hudson wrote:
> >
> >> I worry that adding an auto-subst of repository roots will not be enough
> >> to justify the cost.
> >
> > How so?
> > It's like 20 lines of code.
>
> Cost of a feature is not measured in lines of code.
That's a very nice simple statement to make, while ignoring the rest of
the message i wrote, and what i've written before.
As i've pointed out, it's a very small cost in:
1. syntax
2. code
3. maintenance
So where is the real cost of this feature?
>
> - Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch woprking
copy against mainline?)
Posted by Julian Foad <ju...@btopenworld.com>.
Daniel Berlin wrote:
>
> On Thu, 3 Nov 2005, Greg Hudson wrote:
>
>> I worry that adding an auto-subst of repository roots will not be enough
>> to justify the cost.
>
> How so?
> It's like 20 lines of code.
Cost of a feature is not measured in lines of code.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch woprking copy against mainline?)
Posted by "C. Michael Pilato" <cm...@collab.net>.
John Peacock <jp...@rowman.com> writes:
> Daniel Berlin wrote:
> > You could always make it url syntax, like
> > repos://
> > which we can't get wrong in this manner
> > Unless you think someone is about to come out with the "repos"
> > protocol :)
>
> Actually, I like that a lot; this could also allow us to have an
> environment variable fallback for when you aren't in a WC. Even the
> Windows people could manage that...
Works for me. I'd already posted this suggestion, just as 'root://'
instead of 'repos://'.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch woprking
copy against mainline?)
Posted by John Peacock <jp...@rowman.com>.
Daniel Berlin wrote:
> You could always make it url syntax, like
> repos://
>
> which we can't get wrong in this manner
> Unless you think someone is about to come out with the "repos"
> protocol :)
Actually, I like that a lot; this could also allow us to have an
environment variable fallback for when you aren't in a WC. Even the
Windows people could manage that...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch
woprking copy against mainline?)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2005-11-03 at 12:18 -0500, Daniel Berlin wrote:
> You could always make it url syntax, like
> repos://
Although unilaterally inventing URL schemes is slightly evil, it's not a
kind of evil which is likely to cause any practical problems, so this is
fine with me.
(It's also the kind of evil which browser authors commit all the time.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch
woprking copy against mainline?)
Posted by Daniel Berlin <db...@dberlin.org>.
On Thu, 2005-11-03 at 11:48 -0500, Greg Hudson wrote:
> On Thu, 2005-11-03 at 10:26 -0500, Daniel Berlin wrote:
> > > I worry that adding an auto-subst of repository roots will not be enough
> > > to justify the cost.
> >
> > How so?
> > It's like 20 lines of code.
>
> I'm more concerned about the cost to people who happen to start paths
> with + or = or whatever. arch uses pathnames like this for its metadata
> files; I'm sure someone else has had the same idea for their project
> files.
>
> > And it saves about 60-80 chars out of 200 on a gcc command line
> > (30-35%).
>
> Yes, but realistically, it takes us from "too much typing to be
> practical" to "still too much typing to be practical". Developers will
> still have to create and remember shell variables to make diffing
> against a branch reasonable, and will have to check or remember where
> they are in the tree even so.
>
> I realize you're looking for quick, easy changes to make your
> developers' lives easier, which won't get bogged down in design. I'm
> not sure if there is one here. Your proposal creates an edge case where
> Subversion does something totally wrong once in a while;
You could always make it url syntax, like
repos://
which we can't get wrong in this manner
Unless you think someone is about to come out with the "repos"
protocol :)
> I'm willing to
> do that in order to solve a problem, but I'm not happy about doing so to
> 30%-solve a problem.
I'd be happy to try your solution at the same time. I just fear it will
have a lot more implementation corner cases in substitution, etc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch
woprking copy against mainline?)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2005-11-03 at 10:26 -0500, Daniel Berlin wrote:
> > I worry that adding an auto-subst of repository roots will not be enough
> > to justify the cost.
>
> How so?
> It's like 20 lines of code.
I'm more concerned about the cost to people who happen to start paths
with + or = or whatever. arch uses pathnames like this for its metadata
files; I'm sure someone else has had the same idea for their project
files.
> And it saves about 60-80 chars out of 200 on a gcc command line
> (30-35%).
Yes, but realistically, it takes us from "too much typing to be
practical" to "still too much typing to be practical". Developers will
still have to create and remember shell variables to make diffing
against a branch reasonable, and will have to check or remember where
they are in the tree even so.
I realize you're looking for quick, easy changes to make your
developers' lives easier, which won't get bogged down in design. I'm
not sure if there is one here. Your proposal creates an edge case where
Subversion does something totally wrong once in a while; I'm willing to
do that in order to solve a problem, but I'm not happy about doing so to
30%-solve a problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch woprking
copy against mainline?)
Posted by Daniel Berlin <db...@dberlin.org>.
On Thu, 3 Nov 2005, Greg Hudson wrote:
> On Wed, 2005-11-02 at 23:29 -0500, Daniel Berlin wrote:
>> I didn't actually count, but because i use > 80 character columns in my
>> shell, i realized this might be a wrong, and it is. The command is 95
>> characters.
>
> I worry that adding an auto-subst of repository roots will not be enough
> to justify the cost.
How so?
It's like 20 lines of code.
And it saves about 60-80 chars out of 200 on a gcc command line (30-35%).
> In http://svn.haxx.se/dev/archive-2005-05/1367.shtml I outlined a more
> complicated proposal which saves significantly more typing. I'm not
> sure it's a good idea, but I do think we should be aiming higher than
> just repository root substitution.
Well, we have to start somewhere.
It's easier to get consensus for something simple that works well, than a
large scheme.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots
Posted by "C. Michael Pilato" <cm...@collab.net>.
John Peacock <jp...@rowman.com> writes:
> Julian Foad wrote:
> > Ambiguities starting to creep in: behaviour depends on whether the
> > thing is found locally. If we suspect it is going to be found
> > locally, maybe we want a syntax to force it to be found relative to
> > the other URL instead.
>
> Then perhaps we should stop trying to shoehorn some new notation into
> the definition of the URL and just add a commandline switch like
> --relative, which would trigger the new behavior.
The problem with a commandline switch is what to do about multi-patch
commands in which "relativity" shouldn't apply to all the paths. Of
course, maybe that means that folks just don't use such commands...
I dunno if this has been mentioned yet, but I figured I'd throw this
idea into the mix:
'svn command root:///path/in/repos'
This is the same thing as the "+/some/path" syntax, but at least
attempts to look like a URL, and doesn't add additional complexities
(beyond what we already have today) such as what to do when a working
copy path begins with a plus sign.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots
Posted by John Peacock <jp...@rowman.com>.
Julian Foad wrote:
> Ambiguities starting to creep in: behaviour depends on whether the thing
> is found locally. If we suspect it is going to be found locally, maybe
> we want a syntax to force it to be found relative to the other URL instead.
Then perhaps we should stop trying to shoehorn some new notation into
the definition of the URL and just add a commandline switch like
--relative, which would trigger the new behavior.
>> 3) Then the common remaining portion of the "new" path would have the
>> two specified directories from the "old" path appended and the diff
>> once again attempted;
>
> That doesn't work if the two full paths aren't the same length. For
> example, with "--old gcc-4_0-branch/gcc/SUBDIR/file.c" it would strip
> three dirs and then not find a match.
Both paths would need to be specified relative to their common ancestor.
It may be that this is too hacky, as you say, but it seems a waste to
throw away the information encoded in the current WC admin files if we
could find a smart way to use it.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots
Posted by Julian Foad <ju...@btopenworld.com>.
John Peacock wrote:
>
> Rather than going down that road, I wonder if it wouldn't be enough to
> create a fallback to the existing path resolution. Suppose we take the
> following long query (as mentioned earlier in the discussion):
>
> svn diff
> --old svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
> --new file.c
>
> where the WC in question was, say, checked out from:
>
> svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch/
>
>
> We could simplify that command to:
>
> svn diff
> --old gcc-4_0-branch/gcc/file.c
> --new file.c
(You mean "--new gcc/file.c" I think.)
> 1) First the "old" path would be searched for in the current WC (which
> is the existing behavior) and it wouldn't be found;
Ambiguities starting to creep in: behaviour depends on whether the thing is
found locally. If we suspect it is going to be found locally, maybe we want a
syntax to force it to be found relative to the other URL instead.
> 2) Next, the "old" path would be decomposed into the two directories and
> filename, and the fully qualified "new" path (from the WC files) would
> have the last two directories stripped off;
>
> 3) Then the common remaining portion of the "new" path would have the
> two specified directories from the "old" path appended and the diff once
> again attempted;
That doesn't work if the two full paths aren't the same length. For example,
with "--old gcc-4_0-branch/gcc/SUBDIR/file.c" it would strip three dirs and
then not find a match.
> 4) If this still doesn't work, the current error could be printed along
> with a suggestion to try a fully specified URL.
>
> 5) If both "old" and "new" contained path's that do not exist in the
> current WC, then they both have to contain enough information to locate
> the actual path in the repository, as offset from the current WC location.
>
> As long as either old or new parameter contained enough context to
> specify the common path in the repository, then the WC's repos_root term
> would always be sufficient to determine the fully qualified path at any
> point.
>
> Does that make any sense, or do I need to create some ASCII art and
> pseudo-code?
I understand what you say, but I don't think you've thought it through. It
sounds too hacky. No doubt it can be refined to address some of my concerns;
do you want to try to make it into a more solid proposal?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots
Posted by John Peacock <jp...@rowman.com>.
Julian Foad wrote:
> Alan Barrett wrote:
>> On Thu, 03 Nov 2005, Greg Hudson wrote:
>>
>>> In http://svn.haxx.se/dev/archive-2005-05/1367.shtml I outlined a more
>>> complicated proposal which saves significantly more typing. I'm not
>>> sure it's a good idea, but I do think we should be aiming higher than
>>> just repository root substitution.
>>
>> I agree that we should aim higher, and your proposed syntax looks
>> promising.
>
> Yes. Sorry that proposal didn't get much attention (from me at least)
> before.
Rather than going down that road, I wonder if it wouldn't be enough to
create a fallback to the existing path resolution. Suppose we take the
following long query (as mentioned earlier in the discussion):
svn diff
--old svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
--new file.c
where the WC in question was, say, checked out from:
svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch/
We could simplify that command to:
svn diff
--old gcc-4_0-branch/gcc/file.c
--new file.c
(NOTE the lack of a leading slash in old). That would be interpreted
like this:
1) First the "old" path would be searched for in the current WC (which
is the existing behavior) and it wouldn't be found;
2) Next, the "old" path would be decomposed into the two directories and
filename, and the fully qualified "new" path (from the WC files) would
have the last two directories stripped off;
3) Then the common remaining portion of the "new" path would have the
two specified directories from the "old" path appended and the diff once
again attempted;
4) If this still doesn't work, the current error could be printed along
with a suggestion to try a fully specified URL.
5) If both "old" and "new" contained path's that do not exist in the
current WC, then they both have to contain enough information to locate
the actual path in the repository, as offset from the current WC location.
As long as either old or new parameter contained enough context to
specify the common path in the repository, then the WC's repos_root term
would always be sufficient to determine the fully qualified path at any
point.
Does that make any sense, or do I need to create some ASCII art and
pseudo-code?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots
Posted by Julian Foad <ju...@btopenworld.com>.
Alan Barrett wrote:
> On Thu, 03 Nov 2005, Greg Hudson wrote:
>
>>In http://svn.haxx.se/dev/archive-2005-05/1367.shtml I outlined a more
>>complicated proposal which saves significantly more typing. I'm not
>>sure it's a good idea, but I do think we should be aiming higher than
>>just repository root substitution.
>
> I agree that we should aim higher, and your proposed syntax looks
> promising.
Yes. Sorry that proposal didn't get much attention (from me at least) before.
>> I'll throw out a sketch of a straw-man proposal within the above
>> solution space: (1) we introduce [...]
>> a named transformation rule; in the example, the rule name
>> is "T" and the rule substitutes the FS path prefix /trunk with /tags and
>> adds in the tag name as a path component; (2) we introduce a revision
>> specifier syntax "rule#path[@rev]" which transforms the URL [...]
>
> Would there be a search procedure? For example, search upwards in
> parent and ancestor directories for the appropriate property
Let's not worry about where and how the transform rules are stored yet, but
concentrate on deciding whether the functionality that this provides is what we
want.
> I think there needs to be some sort of wildcard and parameter
> substitution mechanism. [...]
>
> # rule n args source path target path
> TRUNK 0 tags/* trunk
> BRANCH 1 trunk branches/$1
> BRANCH 1 tags/* branches/$1
Yes.
So, how would Daniel's GCC folks (for example) best use this scheme? How would
we Subversion developers best use it? What are the disadvantages compared with
any other suggestions?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
> On Fri, 2005-11-04 at 00:58 +0100, Branko Čibej wrote:
>
>> I'm a bit dense these days... how would you define the mappings if you
>> have more than one branch directory in a repository?
>>
>
> In my straw-man proposal, the mapping is a directory property, so you
> could have different mappings for different projects.
>
Ah, yes. Thanks for confirming that I _am_ dense today. :)
> That'd be a little clunky without inherited properties, but we already
> have things which are clunky without inherited properties.
>
Sure. Worrying about inherited props is orthogonal to this discussion.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2005-11-04 at 00:58 +0100, Branko Čibej wrote:
> I'm a bit dense these days... how would you define the mappings if you
> have more than one branch directory in a repository?
In my straw-man proposal, the mapping is a directory property, so you
could have different mappings for different projects.
That'd be a little clunky without inherited properties, but we already
have things which are clunky without inherited properties.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots
Posted by Branko Čibej <br...@xbc.nu>.
Alan Barrett wrote:
> On Thu, 03 Nov 2005, Greg Hudson wrote:
>
>> In http://svn.haxx.se/dev/archive-2005-05/1367.shtml I outlined a more
>> complicated proposal which saves significantly more typing. I'm not
>> sure it's a good idea, but I do think we should be aiming higher than
>> just repository root substitution.
>>
>
> I agree that we should aim higher, and your proposed syntax looks
> promising.
>
> In http://svn.haxx.se/dev/archive-2005-05/1367.shtml Greg Hudson wrote:
>
>> I'll throw out a sketch of a straw-man proposal within the above
>> solution space: (1) we introduce a directory property "svn:transforms"
>> whose value is a series of lines which look like "T /trunk /tags". Each
>> line defines a named transformation rule; in the example, the rule name
>> is "T" and the rule substitutes the FS path prefix /trunk with /tags and
>> adds in the tag name as a path component; (2) we introduce a revision
>> specifier syntax "rule#path[@rev]" which transforms the URL according to
>> the svn:transforms value in the current directory, and uses either the
>> specified revision or the head revision. So you would do "svn diff -r
>> T#mytag foo.c" to diff a file against a tag, with the example transform
>> rule.
>>
>
> Would there be a search procedure? For example, search upwards in
> parent and ancestor directories for the appropriate property until it's
> found? If the property is found but the transform rule is not found, do
> we keep searching, so that child directories can inherit transform rules
> from their parents?
>
> I think there needs to be some sort of wildcard and parameter
> substitution mechanism. The transform rules that take you to the trunk
> do not need a parameter, but the transform rules that take you to a
> branch or tag do need a parameter. The transform rules that take you
> away from a branch or tag similarly need to have a wildcard in the
> source path, which is not necessary in the transform rules that take you
> away from the trunk.
>
> # rule n args source path target path
> TRUNK 0 trunk trunk
> TRUNK 0 branches/* trunk
> TRUNK 0 tags/* trunk
> BRANCH 1 trunk branches/$1
> BRANCH 1 branches/* branches/$1
> BRANCH 1 tags/* branches/$1
> TAG 1 trunk tags/$1
> TAG 1 branches/* tags/$1
> TAG 1 tags/* tags/$1
>
> (The above table clearly needs a better syntax with less duplication.
> Notice that, at least in this example, the target path depends only on
> the rule, not the source path, and that all rules cater for the same set
> of source paths.)
>
[...]
I'm a bit dense these days... how would you define the mappings if you
have more than one branch directory in a repository?
Take for example the standard multi-project layour:
project1/
trunk/
branches/
tags/
project2/
trunk/
branches/
tags/
Or a more complex structure that I often use at work for a project with
global, unbranched stuff and stuff that is branched, with (at least) two
branching levels:
docs/ (common, not branched)
web/ (common, not branched)
rel/ (release tags)
stream1/ (one development stream -- release development)
integ/ (integration branches)
dev/ (development branches)
tags/ (tags)
stream2/
integ/
dev/
tags/
Note that in the case above, there's no special "trunk" -- all
development branches are equal. Stuff on development branches is
promoted to the local integration branch, tags for local integ and dev
branches are created in the local tags.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots
Posted by Alan Barrett <ap...@cequrux.com>.
On Thu, 03 Nov 2005, Greg Hudson wrote:
> In http://svn.haxx.se/dev/archive-2005-05/1367.shtml I outlined a more
> complicated proposal which saves significantly more typing. I'm not
> sure it's a good idea, but I do think we should be aiming higher than
> just repository root substitution.
I agree that we should aim higher, and your proposed syntax looks
promising.
In http://svn.haxx.se/dev/archive-2005-05/1367.shtml Greg Hudson wrote:
> I'll throw out a sketch of a straw-man proposal within the above
> solution space: (1) we introduce a directory property "svn:transforms"
> whose value is a series of lines which look like "T /trunk /tags". Each
> line defines a named transformation rule; in the example, the rule name
> is "T" and the rule substitutes the FS path prefix /trunk with /tags and
> adds in the tag name as a path component; (2) we introduce a revision
> specifier syntax "rule#path[@rev]" which transforms the URL according to
> the svn:transforms value in the current directory, and uses either the
> specified revision or the head revision. So you would do "svn diff -r
> T#mytag foo.c" to diff a file against a tag, with the example transform
> rule.
Would there be a search procedure? For example, search upwards in
parent and ancestor directories for the appropriate property until it's
found? If the property is found but the transform rule is not found, do
we keep searching, so that child directories can inherit transform rules
from their parents?
I think there needs to be some sort of wildcard and parameter
substitution mechanism. The transform rules that take you to the trunk
do not need a parameter, but the transform rules that take you to a
branch or tag do need a parameter. The transform rules that take you
away from a branch or tag similarly need to have a wildcard in the
source path, which is not necessary in the transform rules that take you
away from the trunk.
# rule n args source path target path
TRUNK 0 trunk trunk
TRUNK 0 branches/* trunk
TRUNK 0 tags/* trunk
BRANCH 1 trunk branches/$1
BRANCH 1 branches/* branches/$1
BRANCH 1 tags/* branches/$1
TAG 1 trunk tags/$1
TAG 1 branches/* tags/$1
TAG 1 tags/* tags/$1
(The above table clearly needs a better syntax with less duplication.
Notice that, at least in this example, the target path depends only on
the rule, not the source path, and that all rules cater for the same set
of source paths.)
Use case: I have a checked out copy of
scheme://host/repository/project/branches/foobranch/dir/subdir. I
type "svn diff -r TAG#tagname filename". The "#" is recognised as
part of the magic syntax. The property search process finds that the
scheme://host/repository/project directory has the appropriate property.
Within that property, the variant of the "TAG" rule that says how to
go from "branches/*" is matched, and the "$1" in the target path is
replaced with "tagname". The result is as if I had typed "svn diff
-r scheme://host/repository/project/tags/tagname/dir/subdir/filename
filename".
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch woprking copy against mainline?)
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-11-03 01:22:31 -0500, Greg Hudson wrote:
> I worry that adding an auto-subst of repository roots will not be enough
> to justify the cost. We'll still suck compared to CVS in this area
> (still much more typing for a diff against a branch) and we'll have
> added another little exception to the command-line syntax so that you
> have to do something special when you want to refer to a file which
> starts with a '+' or whatever.
This would be no more exception than filenames starting with '-'.
You already need to type something like "svn info ./-h".
Otherwise just use prefixes ending with a ':' as AFAIK, the ':' is
already reserved for URL schemes.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch
woprking copy against mainline?)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-11-02 at 23:29 -0500, Daniel Berlin wrote:
> I didn't actually count, but because i use > 80 character columns in my
> shell, i realized this might be a wrong, and it is. The command is 95
> characters.
I worry that adding an auto-subst of repository roots will not be enough
to justify the cost. We'll still suck compared to CVS in this area
(still much more typing for a diff against a branch) and we'll have
added another little exception to the command-line syntax so that you
have to do something special when you want to refer to a file which
starts with a '+' or whatever.
In http://svn.haxx.se/dev/archive-2005-05/1367.shtml I outlined a more
complicated proposal which saves significantly more typing. I'm not
sure it's a good idea, but I do think we should be aiming higher than
just repository root substitution.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch
woprking copy against mainline?)
Posted by Daniel Berlin <db...@dberlin.org>.
> You can make it roughly as long as it was in cvs if you remove the
> "svn+ssh://gcc.gnu.org/svn/gcc" part
>
> Heck, it even fits on one line then
> svn diff
> --old=+/branches/gcc-4_0-branch/gcc/file.c
> --new=+/branches/gcc-3_4-branch/gcc/file.c
Just so i don't get called a liar:
I didn't actually count, but because i use > 80 character columns in my
shell, i realized this might be a wrong, and it is. The command is 95
characters.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch woprking copy against mainline?)
Posted by Alan Barrett <ap...@cequrux.com>.
On Wed, 02 Nov 2005, Daniel Berlin wrote:
> Uh, right now, to diff the gcc 4.0 branch against a working copy file,
> one has to type
> svn diff
> --old=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
> --new file.c
And in cvs, one would just do: cvs diff -r GCC_4_0_BRANCH file.c
> To diff 3.4 against 4.0
> svn diff
> --old=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
> --new=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch/gcc/file.c
In cvs: cvs diff -r GCC_4_0_BRANCH -r GCC_3_4_BRANCH file.c
Now consider how this scales as the last part (after the branch name)
changes from the relatively simple "gcc/file.c" to something more
complex like "gnu/dist/gcc/gcc/fixinc/tests/base/arch/i960/archI960.h"
(a real example from the NetBSD CVS repository). Even the proposed "+"
syntax doesn't buy you much.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auto-subst of repository roots (was Re: svn diff branch
woprking copy against mainline?)
Posted by Daniel Berlin <db...@dberlin.org>.
On Thu, 2005-11-03 at 03:59 +0000, Julian Foad wrote:
> Daniel Berlin wrote:
> > A bunch of my gcc users are complianing that they are continually typing
> > the repository root to do certain diffs.
> > They are, of course right.
> > Usually, we just say "you can script with the shell", but as Richard
> > points out below, a substitution works everywhere, shell only works if
> > you are working in the same root everywhere.
> >
> > Ignoring the question of what character would substitute repository
> > root, would anyone be opposed to having such a substitution.
>
> Not sure. May I ask to see a couple of realistic use cases?
>
Uh, right now, to diff the gcc 4.0 branch against a working copy file,
one has to type
svn diff
--old=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
--new file.c
To diff 3.4 against 4.0
svn diff
--old=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
--new=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch/gcc/file.c
You can make it roughly as long as it was in cvs if you remove the
"svn+ssh://gcc.gnu.org/svn/gcc" part
Heck, it even fits on one line then
svn diff
--old=+/branches/gcc-4_0-branch/gcc/file.c
--new=+/branches/gcc-3_4-branch/gcc/file.c
That is all my users want. To not have to type twice or three times as
much text as they did in cvs just to do diffs
> Are my examples above the sort of thing you mean?
> If so, and a user is
> commonly diffing between +/trunk/gcc and +/branches/1.0.x/gcc, then wouldn't
> he/she prefer to substitute those with an environment variable or other method
> of further abbreviation, thus obviating the need for abbreviation of just the
> repository root?
No.
Why?
People are used to the repository root being abbreviated if they used
cvs. That's what they really seem to want as a starting point. We claim
to be better than cvs, and yet require users to continually remember and
type command lines that are 2x or 3x longer. It's a noticeable amount
of typing. Telling them "oh, make your shell do that", and they'll just
say "so remind me again why i moved to something that is harder to
use?". And they would be right.
Some of these people have 20 branches of gcc checked out (most people
have 4 or 5), remote repos. We still support the 3.4 line and the 4.0
line. So realistically, you want to find diffs against 3.3 onwards.
That's 16 environment variables right now.
4.1 is trunk
3 releases of 4.0
5 releases of 3.4
7 releases of 3.3
Theoretically, we could make up such a file for every shell, and have
every developer rsync it (since it will change every 3 months), just so
they don't have to type 160 character command lines.
The simpler and better solution seems to be to introduce a repository
root substitution.
The above situation gets even worse when they have readonly mirrors
locally that they checkout from in addition to the regular repository
they check in to.
Then you have to multiply the env vars by however many repos they are
checking out from.
> For example,
>
> svn diff --old=$GCC_TRUNK/foo.c --new=$GCC_1_0/foo.c
Can you please tell me why the user should have to teach his shell
something svn now already knows, and cvs did trivially without needing
to teach your shell to do?
What are we gaining by this, other than user frustration?
It's not like this is a hard feature to implement, or particularly
burdensome on maintenance or syntax.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org