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

Re: Fwd: 1.2 features: svn ls

From: Molle Bestefich <molle.bestefich_at_gmail.com>
Date: 2005-03-09 23:02:29 CET

Brian W. Fitzpatrick wrote:
>> Hm.. You don't think that an entire web frontend on top of your
>> Subversion setup is a different beast than fixing the command line
>> utility so that it doesn't error out whenever you point it at a
>> Subversion server or a URL you only vaguely remember or don't entirely
>> know about?
>
> Garbage in, garbage out. If you point your web browser at a bogus URL,
> what do you expect your browser to do?

Hand down an error message.
Say I point it at http://svn01/devel/.net and it tells me the
repository does not exist. It's actually called
http://svn01/devel/dotnet.

The first thing most intelligent human beings would do in this
situation is point your client to http://svn01/devel and see what's
there, figure out "oh, it's called something different", and get on
with business.

>> But I can't quite see how the existence of ViewCVS is a good argument
>> against improving the Subversion client past the point where it barfs
>> when you toss an imprecise URL at it?
>
> Not imprecise, incorrect. If a user can't remember a URL, or find it
> via documentation or a web interface, then no amount of technology is
> going to fix the problem--it's a problem with communication.

Leaving management, other developers, web servers and added frontends
out of the loop was the general idea.
Communication should preferably not be necessary for people to remedy
the situation.

Not that I'm against communication.

>> If you're merely worried about the coding and testing effort involved,
>> I'd be happy to throw energy into it. I'd like to get consensus first
>> on what would be a good solution and what I can expect to be
>> considered for inclusion into Subversion first, though.
>
> Now that Subversion is past 1.0, I'm inclined to be *hyper* conservative
> about adding any new features to the command line client, again,
> *especially* if you've got a way around it.

I can agree very much to that.
Of course any such feature would have to be tested extensively.
Less extensively if #1 since that would probably be implemented as a new
command.
I imagine one important thing to test (with #2) would be how different
clients react if it were to be allowed to do a 'ls' on a parent directory
to a parent directory to a repository. Existing clients would probably
allow the user to attempt repository actions on the parent directory of
the repository, which would then fail, which is a situation that
currently doesn't occur.

I wouldn't mind doing all the testing.
I think the feature is worthwhile, that the testing is very overcome-able,
and that few if any clients would be hurt by this. I'm pretty sure
any that are possible hurt by it would be easy to fix.

Again, I'd be happy to do any documentation and testing required.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 9 23:05:44 2005

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.