Re: CVSBookmarks and upstream submission

[Kaz Kylheku]

Christian Reis <kiko@async.com.br> wrote in message 
news:<mailman.1294.1044073772.21513.bug-cvs@gnu.org>...
> (Apologizing for lack of context, mailer situation a bit complicated
> ATM)
> 
> I do agree that the shell provides command substitution, and that it
> does in a way emulate the functionality the patch provides.

It does? Which came first? Which is way more flexible?

   REPO=:ext:user@foo.bar/usr/local/cvs
   cvs -d $REPO/a-project ...   # substitute part of the name only
   cvs -d $REPO/b-project ...

   REPO='-d ...'   # fold away the -d option itself!
   cvs $REPO ...

   alias here-cvs='cvs -d here...'    # aliases
   alias there-cvs='cvs -d there...'

   function cvs-wrapper ()
   {
      # do what you want
   }

Come on.

> I just think
> it's a nice feature to have in CVS, improving usability and offering
> convenience at very little added complexity. Some rationale:
> 
>     a. The patch should work cross-platform, so it does not depend on

There are cross-platform implementations of the POSIX shell. If you
want that syntax on Windows, install Cygwin, which even has a CVS
package.

If I'm using a Windows GUI, I'd rather have the repository list in a
GUI element such as a list control, and not have to edit some config
file. The GUI should remember the repositories I have visited.

>        what type of shell you are using. It should even work on the
>        native command interpreters of the windows world.

Why should it not depend on what type of shell you are using? Maybe
people like using whatever shell they are using?

You are trying to rationalize the folding of shell features into the
CVS codebase.

This is not rationalizable.

There is a reason why these features are split off, rather than
reimplemented in each one of the the hundreds of command line tools.

What's next? Having a ~/.greprc where you give names to common search
patterns?
 
>     b. It avoids adding to the environment namespace a variable that
>        doesn't indicate *anything* beyond a cvs repository. The

Clue: shell variables are not environment variables unless you export
them! Child processes won't see your variable unless you want them to.

>        environment is commonly used to set session-wide parameters,
>        though we do have application-specific vars in spots.

A metavariable that is not lexically distinct is even worse. Suppose
that the bookmarks scheme is extended to other elements of the CVS
command line, not just repositories.

What is the meaning of

  cvs -d aaa -r bbb module

? Quite likely, aaa is a bookmark, because it doesn't have the form of
a typical repository path. But bbb a CVS tag, or a bookmark?

The shell does this right; expansion is signaled by the $ prefix. If
you want a literal $, there is a way to get that too.

>        I personally dislike using environment variables for this sort of

I professionally dislike polluting stable software with useless,
redundant features.

>        issue as the risk of the names clashing with something more
>        `standard' [1] increases (think $GNOME, $MOZILLA, $ZOPE, for
>        instance). 

Use a suffix: $GNOME_CVS. Tab completion helps you here if you really
mind typing four extra characters.

Lastly, note that the CVSBookmarks functionality can be written as a
script which reads the alias definitions from a file, and then calls
CVS. The CVS source code does not need to be hacked.

I wrote a whole new version control system with directory structure
versioning without touching a single line of CVS code, so don't tell
me you that this stupid ``featurelet'' needs to be hacked into the CVS
source code!

>     c. While I agree it's not a very strong point, having a separate
>        bookmarks file does simplify maintenence from the user's
>        standpoint (no worrying about what shell he might use, or if it's
>        a login shell or not, or if he's clobbering a bashrc when moving
>        it to another box). It offers a platform-neutral, shell-neutral
>        way of specifying aliases for long pserver strings.

It's not platform-neutral at all; it just becomes a feature of the CVS
platform, rather than the shell platform. Of course, now you are going
to need SubversionBookmarks, ArchBookmarks, BitkeeperBookmarks... Get
it?

>     d. While not a decisive point per se, having it included would suggest
>        to people a documented, standard mechanism for accessing multiple
>        repositories.

What?
 
> The patch is a client-side change only, and quite simple at that.  It
> should be quite easy to audit it for problems and provide constructive
> review.

If it's so easy, why are security bugs still being found in the 10+
year old CVS code base? Do you think that client side software can't
have security problems?

Buffer overflow perpetrated by malicious data in ~/.cvsbookmarks; I
can just see the headlines.
 
> So, the question is, are these arguments reasonable enough to warrant
> further discussion of the feature, or is it a YAGNI? I know I've wanted
> it a number of times, and so have other CVS users I've observed.

How many of them were aware that they could use the shell, and yet
explicitly rejected that alternative? You and a couple of like-minded
friends hardly constitute a statistically valid poll.