>> 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?
