TBrowder wrote:
> I appreciate all the comments, and have no defense except I read the
> developer section of the book as well as HACKING and obviously didn't read
> them thoroughly enough. I will make the corrections suggested and
resubmit.
> (And Julian, thanks for your kind words.)
>
> However, before I resubmit the patch, I'll discuss my proposal in more
detail.
>
> Sometime last year (on the users list) I asked about three features we use
> heavily with CVS:
It is good idea to keep email threads to a single concept. It makes the
discussion far easier to follow.
Accordingly, I'm replying to your mail:
"Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision
Aliases)"
in three seperate replies:
1. "Re: Proposed New Feature (SVNROOT)"
2. "Re: Proposed New Feature '.svnignore'"
3. "Re: Proposed New Feature 'rtag' (Revision Aliases)"
and I encourage people to continue discussion in each subthread seperately.
This is reply 1 of 3.
> CVSROOT
>
> Allows an administrator an easy way to point to the repository.
Allows
> users a default location (svn URL) for their primary repository. I'm not
a
> touch typist and use aliases a lot. I can easily switch repositories with
a
> two- or three-character alias (under tcsh).
...
> Then, in the last few days, I put together the first of my proposals
> (SVNROOT):
>
> The idea is to use SVNROOT (where defined) as it is used in CVS as we
> commonly use it, to wit:
>
> 'cvs co module' (equates to 'svn co URL_to_repos/module')
>
> 'cvs import module [...and other args] (equates to 'svn import
> URL_to_repos/module' without a local directory)
>
> To the best of my knowledge, svn and cvs default behaviors for other
commands
> are similar and don't need a reference to SVNROOT because they both know
the
> default repository location when the user is in a directory with a working
> copy (WC).
>
> My idea for the implementation of SVNROOT in svn is to intercept the
command
> line targets at the point just before they are checked for errors and
> execution (in the files './subversion/clients/cmdline/checkout-cmd.c' and
> './subversion/clients/cmdline/import-cmd.c' ), check to see if SVNROOT is
> defined, and make the appropriate substitutions in targets (if they are
not
> already in URL format), and pass the arguments on as usual.
>
> I believe the mod is innocuous, helpful to those who want such a feature,
and
> can be ignored by those who don't.
>
> So ends my proposal for SVNROOT.
It's true that feature could simply be ignored by those people who didn't
want to use it.
My disagreement with a SVNROOT env-var is that if you do work on more than
one repository, you end up having to remember what the env-var is currently
set to, and most of the time end up overriding it on the command line
anyway.
Also, checkout and import are rarely used operations (for me - do you use
them regularly in your pattern of work?), and adding complexity to slightly
shorten these commands seems like unnecessary code.
Any discussion of command line simplification methods should include "svn
switch" and "svn merge" - both of which could benefit in usability from a
way to implicitly refer to the root of the repository of the working copy
they are running in.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 17 15:09:02 2004