Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision Aliases)

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:

  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).

  .cvsignore

      I've tried the method described in the book and (1) it didn't work and (2) I don't agree with it.

  rtag (and the command 'cvs history -T')

     Allows a quick glance at milestones of a project without cluttering up the repository tree with changeable tags. Not changeable by the user. Output of 'cvs history -T' is guaranteed to be in reverse chronological order.

Most replies from responders (mostly developers) said words to the effect that no one used such commands because svn has another way to do it and besides, they didn't agree with them. In addition, the primary effort was to get version one out the door before much thought was given to new features. My reply was that my users (myself included) basically use CVS in a linear manner and tag major stages in the history of a project, and these three features (non of which svn has in a straight-forward manner) will be highly desirable in a CVS replacement. And I offered to make the features available. Since then I have seen other responders on the users list mention some of theses features as desirable (SVNROOT and .svnignore).

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.

In the future I shall propose implementation of the other two features I would like. Here are my initial thoughts on those:

  .svnignore

Similar to CVS except better (allow .svnignore to apply to directories): When the default 'svn status' command is given, for each directory first check for the presence of the file '.svnignore' and use the limited regular expressions inside to check files and dirs that are unknown to svn (for "recursive" behavior, require an absolute or relative path to the file expression). Do not include those files in the resulting list.

  rtag

The best idea I can come up with is to add the capability for an alias for a revision (but, better than CVS, with a larger allowable character set) and it would appear (if defined) in the log listing. A new alias may also be added at a later date. I think it should not be changeable (except for additions) by anyone except the administrator. The alias should be able to be used in any svn command that uses a revision number or date. The log listing command should have a switch to avoid showing entries without a revision alias.

I see where one of the desirable featues of svn is to enable easy use of scripts to add locally desired policies, etc., but I think the features I've proposed (which are well-established in CVS) should be part of the svn core.

In summary, svn is a great product and I want to use it to replace cvs for our use. We have grown accustomed to certain features of cvs that are not directly offered in the current version of svn, and I want to help add those features.

Tom Browder
Received on Wed Mar 17 12:53:57 2004