RE: Strange behavior on directory delete/commit

>> I think SVN is behaving correctly. When you do svn commit foo you're
>telling Subversion to commit changes made in foo. There are no changes in
>foo because it's been deleted. The changes, instead, are in its parent
>directory, the one from where you issued your commands. That's why svn
>commi works, it assumes . as the path.

I disagree. Providing a PATH argument should tell svn that one wants to
commit the changes to "foo". In this case it would be that "foo" was
deleted. Since I want only the changes to "foo" to be versioned, it would
not make sense to include all other changes within the parent directory.
 
>I think "svn commit foo" would work fine, provided you do not "rmdir foo"
>first; that was your error.
>
>I also have a feeling Subversion 1.7's new working copy arrangement will
>fix or at least change this behavior.

So there's still a light at the far end of the tunnel! :o) From what I've
read just now 1.7.X's WC arrangement will become alike hg's way. I
understand well that the current svn infrastructure is not suited for this
usecase.

Would patching svn 1.6.X to fix the behaviour be feasible?
Received on 2011-08-03 10:05:39 CEST