On Mon, 01 Oct 2007, C. Michael Pilato wrote:
> 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?
Do they have a different effect on TARGET's entry in the parent
directory's .svn/entries file?
- application/pgp-signature attachment: stored
Received on Mon Oct 1 23:04:07 2007