Sven Brueggemann wrote:
>> - "Degrade to normal folder":
> That's nothing TSVN can savely do - it would require support for
> operations like this in the subversion library.
Don't hesitate to tell me I shouldn't be asking on this list, or point
me to any previous discussion I failed to find. I wonder what support
would be required. I can image something for my contrived suggestions,
yes, but not for the simple "degrade" operation = remove all SVN data.
1. I assume it can easily see if you are on a working copy and not on a
subdirectory, like the SVN Delete operation. Or not?
2. As far as I know, if there is any writing operation in progress, the
working copy is locked. Surely an SVN client can already check that and
back off? So the "degrade" operation has the working copy all for itself.
3. The (not entirely explicit) contract of SVN says it stores its data
only in folders called .svn (or whatever SVN_WC_ADM_DIR_NAME and
SVN_ASP_DOT_NET_HACK dictate), and that users don't. So removing the
.svn directories is a sound process. Is the issue you can't actually
tell what the exact name for .svn is ?
4. As soon as the operation removes the first SVN file, the entire
directory tree is no longer a valid working copy. Any new SVN operation
on a subdirectory between that point and the end can lead to anything.
But that's what the user asked: stop being a working copy. Is your
concern that this transition is not immediate?
I don't want to imply this is easy to do, let alone worth while. I just
wonder why there's opposition.
> On Subversion's users list there are sometimes similar requests, but
> before the developers can thin of implementing these operations, svn
> has to be able to deal with incomplete working copies.
I don't understand why anyone wants incomplete working copies to begin
with, but it doesn't change anything in my view. The operation is then
"stop being an incomplete working copy and remove the incomplete SVN
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Aug 23 17:48:36 2006