> >> First option should be to tell the external tool not to touch files
> > (in
> >> particular the write-protected content of .svn) it doesn't
> know about.
> >> However, it might also be the other way 'round that
> Subversion should
> > not
> >> try
> >> to version the contents of that directory. It depends.
> >> Unconditionally removing write-protected content is a bug in that
> >> external application though.
> >
> > Yeah well if wishes were fishes... My hands are more or
> less tied for
> > the time being.
>
> Aside from the issue of the external tool deciding to
> overwrite the original data, the main problem is that
> Subversion stores its metadata within the revisioned source
> tree. This would be a non-issue if we didn't have the .svn
> directories. The big question in this situation is whether
> there is a better workaround.
>
I'm not sure you can blame the app for deleting directories - read-only
is often not the same as delete-protected. Whichever way you want to cut
it, the problem is still that svn needs to interfere in directories that
don't really belong to it.
So far, I've seen a fix where the .svn dirs would mirror the current
directory structure but in an alternative part of the filesystem. This
sounds like it's a simple and effective fix; as would a command that
restores the .svn directories without fetching the latest files. (a
checkout without getting data)
The trouble with the former is that, if you delete a directory there's
no easy way of detecting that its gone in order to delete the
corresponding .svn directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 26 18:42:45 2007