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

Re: [PATCH] Fix for "svn log URL"

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-02-11 17:41:33 CET

Zack Weinberg <zack@codesourcery.com> writes:

> On Mon, Feb 11, 2002 at 08:45:39AM -0600, cmpilato@collab.net wrote:
> > Philip Martin <philip@codematters.co.uk> writes:
> >
> > > > Now it does working copies, and URLS. However, it doesn't do a FILE
> > > > PATH to a Subversion repository. Should it do that also?
> > >
> > > If you mean 'svn log /some/path/repo/db', then probably not. In
> > > general, svn commands act on URLs or working copy paths, there is no
> > > reason for log to be different.
> >
> > Exactly. We, of course, know that the user *meant* to type:
> >
> > svn log file:///some/path/repo
> If the computer can know unambiguously what the user meant to type,
> then it should do what the user meant to do. In this case, I think it
> can. There's never going to be a situation where a local filesystem
> path to a repo directory is ambiguous with a path to a working copy.
> Therefore, when we get /some/path/repo, we ought to just stick
> "file://" in front of it and proceed - for all svn commands.

I assume you want this for all commands, not just log. Consistency is
important. Consider

   svn cp wc_path1 wc_path2

where I make mistake with wc_path2. If the erroneous path happens to
match the repository, then the error will cause a commit. The same
happens with

   svn rm wc_path

Instead of making a change to my working copy I get a delete in the

In both these cases the command I intended would have made a temporary
change, which would only become permanent when/if I committed it. By
promoting the path into an URL these commands make permanent changes

Now the $EDITOR functionality should probably be extended to all
commands that alter the repository, at least then I would get a chance
to abort the command. Even if this were done, it's a roundabout way of
catching an error.

On the whole, I prefer being required to specify an URL explicitly.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:06 2006

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.