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

Re: svn up -p

From: Noel Yap <yap_noel_at_yahoo.com>
Date: 2002-11-06 15:04:59 CET

--- Ben Collins-Sussman <sussman@collab.net> wrote:
> 'cat' seems to imply both a fetch and a print to
> stdout, I like that a
> lot. It goes nicely with 'svn ls'. If we went this
> route, 'svn ls'
> and 'svn cat' would be partners in crime: they both
> dump information
> to the screen, both take a revision arg, and both
> operate on either
> wc-paths or urls. There's a nice consistency there.

Hey, finally, an idea of mine that's had at least two
other positive feedbacks. I should spit out more
ideas before my morning coffee :-)

> On the other hand, I'm still not sure if it's better
> to create a whole
> new subcommand or not. I'm still thinking about
> that.

I share the same concerns. For example, why stop at
"ls" and "cat"? Why not have "find" or any other of
the myriad commands out there?

I may be rambling now, but one thing I liked about
ClearCase is that the entire repository was available
as a file system obviating the need for additional
"ls", "cat", "find" commands since one could all the
commands that were able to access the file system.

I've heard there's webdav_fs (sp?) out there for
Linux. If this were made portable, I think the need
for "svn ls" and "svn cat" should go away. Does
anyone want to take on the challenge? :-) Are there
any bad consequences to this approach I haven't
thought of?

Noel

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 6 15:05:39 2002

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.