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

Re: [Issue 4154] New - svn add foo foo complains

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 29 Mar 2012 17:08:53 +0200

Would having an explicit

    Skipped duplicated target 'foo'

notification address your concern?

Julian Foad wrote on Thu, Mar 29, 2012 at 15:47:34 +0100:
> Hi Daniel.
>
> In the issue, you give the example "$svn add f* *o", and then claim svn should eliminate duplicate args for you.  But why should it?
>
> That could be seen as trying to be "too clever" and help users to do what they didn't mean to do.  For example, I can recall severall times over the years when I've tried to issue a command such as
>
>   <cmd> <argument1> <argument2>
>
> but due to finger error when copy-and-pasting the arguments, accidentally issued
>
>   <cmd> <argument1> <argument1>
>
> It doesn't seem obvious to me that quietly eliding duplicate arguments is a good thing.
>
> The only precedent I can think of is that "svn commit" has always (or for a very long time) eliminated duplicates -- not only duplicate cmd-line args, but duplicate targets found by recursion.
>
> In simple cases such as your example, with only one file involved and a very short name, it's clearly a minor convenience to have it un-duplicated for you.  But if I'm pasting unversioned file-paths into an "add" command from the output of "svn status | grep -F '^?'", and there are a dozen of them and their paths are more than 80 columns wide, then I'm unlikely to notice if I accidentally paste two copies of the same path instead of two different paths.
>
>
> In short, -0.5.
>
> - Julian
>
>
>
> ----- Original Message -----
> > From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
> > To: Philip Martin <philip_at_codematters.co.uk>
> > Cc: dev_at_subversion.apache.org
> > Sent: Thursday, 29 March 2012, 12:30
> > Subject: Re: [Issue 4154] New - svn add foo foo complains
> >
> > Philip Martin wrote on Thu, Mar 29, 2012 at 10:32:42 +0100:
> >> danielsh_at_tigris.org writes:
> >>
> >> > http://subversion.tigris.org/issues/show_bug.cgi?id=4154
> >>
> >> > % ls
> >> > A  foo  iota
> >> > % $svn add f* *o
> >> > A        foo
> >> > svn: warning: W150002: '/tmp/svn/wc1/trunk/foo' is already
> > under version control
> >> > subversion/svn/add-cmd.c:108: (apr_err=200009)
> >> > subversion/svn/add-cmd.c:103: (apr_err=200009)
> >> > svn: E200009: Could not add all targets because some targets are
> > already versioned
> >> > subversion/svn/add-cmd.c:94: (apr_err=200009)
> >> > svn: E200009: Illegal target for the requested operation
> >> > zsh: exit 1    $SVN add f* *o
> >> > %
> >> >
> >> > svn should be smart enough to uniq() the targets, rather than error
> > out on me
> >> > because I tried to add it twice.
> >>
> >> This issue is "svn add foo foo" complaining that foo is already
> >> versioned.  Is add the only command that is wrong?
> >
> > As you point out, 'add' and 'mkdir' are similar. 
> > 'revert' even today
> > doesn't error out in the idempotency scenario ('svn $subc foo &&
> > svn
> > $subc foo'; the second invocation errors out for $subc =~ /add|mkdir/.)
> >
> >> Should we eliminate duplicates in all commands?
> >
> > I think we shouldn't eliminate duplicates in, for example, 'cat'.
> >
> >> Silently?
> >>
> >> $ svn add foo foo            # foo unversioned
> >> "already versioned" error
> >>
> >> $ svn mkdir X X              # no X
> >> "file exists" error
> >>
> >> $ svn rm foo foo              # foo versioned
> >> no error
> >>
> >> $ svn rm --force foo foo      # foo added
> >> "does not exist" error
> >>
> >> $ svn rm foo foo              # foo versioned and deleted
> >> no error
> >>
> >> $ svn revert foo foo          # foo versioned
> >> no error
> >>
> >> $ svn revert foo foo          # foo added
> >> "Skipped foo" notification
> >>
> >> --
> >> Philip
> >
Received on 2012-03-29 17:09:36 CEST

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.