[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Auto-subst of repository roots (was Re: svn diff branch woprking copy against mainline?)

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2005-11-03 05:24:27 CET

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
Received on Thu Nov 3 05:25:12 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.