Karl Fogel wrote:
> Bruce Korb <bkorb@sco.COM> writes:
> > Last night, I ran through some emacs macros that converted
> > *all* of the CVS command line options into autoopts option
> > definitions. Another hour or so and I'll have a command line
> > "hello, world!" program that accepts all the CVS options from
> > the command line, environment variables and RC files. From
> > that we can prune the dinkleberries and add in new feature
> > coverage. My guess: you'll see it Thursday. (I have more
> > plumbing to do when I get home today.)
>
> Well, I'm speaking about something which I haven't seen yet, so at the
> risk of sounding needlessly paranoid:
>
> This is not just a matter of going through the CVS options and
> substituting "svn" for "cvs". Subversion is different in significant
> ways. Obviously, you'll want to study the CVS options, but I think
> after that the most fruitful technique will be to start writing the
> Subversion options from scratch, with the CVS list close at hand for
> reference (essentially what I started in subversion/client/README).
>
> I'm not sure what the use of having a command-line "hello, world"
> program that accepts all the CVS options would be. We already have
> such a program -- it's called CVS... :-)
>
> Obviously how you spend your time is up to you, I'm just offering an
> opinion that designing the svn command line interface as a "diff"
> against CVS's interface is not going to get us where we need to be.
I agree, and I also support Jonathan Shapiro's idea that a
cvs-compatibility wrapper could be written in Perl and would simply
map the CVS options to the Subversion options (and maybe echo the
proper 'svn' options back so that it'd serve as a learning tool as
well.)
That way, Subversion can have its own options (-r instead of -R)
and not have to worry about the CVS cruft like '-d' meaning one
thing as a global option and another thing as a command option.
Received on Sat Oct 21 14:36:11 2006