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

Re: Uh-oh. 'svn add --force top-level-wc-dir' broken?

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-10-01 18:08:10 CEST

C. Michael Pilato wrote:
> Did somebody broke 'svn add --force'?
> $ svn st wc
> A wc/trunk
> ? wc/trunk/some-file.txt
> A wc/branches
> $ svn add --force wc
> subversion/libsvn_wc/lock.c:601: (apr_err=155007)
> svn: '.' is not a working copy
> subversion/libsvn_subr/io.c:2626: (apr_err=2)
> svn: Can't open file '.svn/entries': No such file or directory
> $
> This should have succeeded, adding 'wc/trunk/some-file.txt' to version
> control.

Well, call me confused.

I was seeing this work under svn 1.4.5, but I think that was because in my
test case, "wc" was sitting inside a directory that happened to be versioned
elsewhere (my home directory). So, given 'svn add wc --force', Subversion
checks to see if the parent directory is versioned (yep), then proceeds to
perform the add action on the child. Of course, it never bothers to notice
that the child is *a disjoint working copy of another repository
altogether*. Sheesh.

Is there any good reason to treat 'svn add TARGET --force' differently than
'cd TARGET; svn add . --force' when TARGET is already under version control?

C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Mon Oct 1 18:08:19 2007

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.