On Fri, 2004-04-09 at 10:43, Markus Wolff wrote:
> It's not the point that I want it to overwrite unversioned files, it
> just shouldn't complain when there are unversioned files in the same
> directory as the working copy. The files wouldn't be overwritten by
> any file under version control because they don't exist in the repository.
'svn up' doesn't care when your working copy has unversioned files. It
only cares when an unversioned file is obstructing the update (i.e. in
the way of versioned things it's trying to add or change.)
Which means there is something deeply messed up about your working
copy. I'm trying to figure out what you did...
> Okay, here's a transcript, using the commandline this time:
>
> [mwolff@BigBlueThingy lastresort]$ svn update module
> svn: Working copy 'module/crm/schnelleintrag' not locked
>
> The directory "schnelleintrag", in this case, has been in the main
> repository before, but has then been deleted from there and moven out
> to a spezialized repository, so it's now regarded unversioned by
> Subversion when appearing in this working copy.
Are you *sure* about this? What does "deleted and moved out" mean? Did
you just use Unix 'rm' to delete the thing, rather than actually 'svn
rm' the directory and commit?
Because to me, it looks like the directory "schnelleintrag" is still in
the repository, and therefore 'svn up' is trying to re-add it. And an
unversioned directory by the same name is sitting in the way.
Run 'svn ls' on the parent directory's URL (whatever the URL to
module/crm is). Do you see "schnelleintrag" in the repository still?
What does 'svn status' say about the module/crm/ directory?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 9 18:05:33 2004