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
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
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 <firstname.lastname@example.org>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Mon Oct 1 18:08:19 2007