I think if the documentation for --parents says it will do a non-recursive commit of any intermediate directories and if any of these are marked as replaced or copied it will error out then this is sufficient documentation for the user. Yes, the scenarios you listed are correct but with the right info I think it's acceptable.
The GUI I was referring to was WanDisco's smartSVN. It handles both scenarios properly by not showing the intermediate directory in the commit list thus causing an error for not having all targets defined if the user proceeds to commit the lower level change. TortoiseSVN appears to be the same way. Both however automatically add the intermediate directories to the commit list if they newly added. What I am trying to enable is the ability to add and commit files deep in hierarchies w/o having to specify intermediate directories. We were using simple examples but often we will have many level structures that are previously committed and create new structures beneath it along with modifying the existing. We want to add/commit just the new directories/files specified and not the other areas. This achievable with a GUI but very hard to filter out just what you want. Eric -----Original Message----- From: Stefan Sperling [mailto:s...@elego.de] Sent: Thursday, July 25, 2013 10:21 AM To: Braun, Eric Cc: users@subversion.apache.org; Moe, Mark Subject: Re: Mixing recursive and non-recursive commits On Thu, Jul 25, 2013 at 02:01:23PM +0000, Braun, Eric wrote: > I don't know why this is > should be complicated to do from the command line when GUI clients are > already doing this today. My concern is not about whether this would be complicated to implement. It wouldn't be. My concern is that your proposal is creating a command line option that will cause a commit to succeed or fail based on the order of operations the user carried out in a working copy. svn mkdir A svn mkdir A/B svn commit --parents A/B commit succeeds svn rm A svn mkdir A svn mkdir A/B svn commit --parents A/B commit fails svn mkdir A svn mkdir A/B svn commit A/B commit succeeds svn rm A svn mkdir A svn mkdir A/B svn commit A/B commit succeeds I don't think this is intuitive behaviour. It is sensible from the point of view of your use case, no doubt. However, I'm concerned about creating an option that has inconsistent behaviour depending on working copy state. You're saying some GUI clients had this feature already. I'd like to know how they deal with the replacement and copy cases I've pointed out. I believe it's quite likely that they perform recursive commits in those cases, which defeats the point of the proposed option. [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records. To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com
