RE: Mixing recursive and non-recursive commits
From: Braun, Eric <eric.braun_at_medtronic.com>
Date: Thu, 25 Jul 2013 14:01:23 +0000
I understand the copy and delete scenarios. They would have to be identified up front (with perhaps a behind the scenes svn status -u --depth=empty on all the parent directories w/ respect to the command line objects) and if they are replaced or added via copy then it would error out and make the user handle these because they need to be recursive operations.
The problem with just passing a list of targets is just that... coming up with the entire list of targets below the original target recursively and then above (parents). This could be a long list to have add/figure out when it would seem the tool could just do this when a --parents option was added. So what's needed in other words is when --parents is added it recursively looks below the targets given and gathers the usual targets that need to be committed. It then looks up through the parents and adds each parent directory depending on whether each is a simple add or not. It then does the commit with a --depth=empty on all targets and proceeds. I don't know why this is should be complicated to do from the command line when GUI clients are already doing this today. I would use a GUI client to do this work in most cases but GUI's don't work as well when defining wildcards/filtering (*/*/file for example for a commit target).
On Wed, Jul 24, 2013 at 07:32:20PM +0000, Braun, Eric wrote:
What would svn commit --parents do if the newly added parents are replacing a deleted item in the working copy? It seems svn would then have to commit a replacement instead of an addition. In which case this option cannot claim to be scoped to just additions, because a deletion needs to be committed as part of the replacement.
The same questions applies to added items which are inside copies.
If the --parents option did nothing for copied and replaced items, it would probably have to error out if those occur.
For example, the following would commit A and A/B:
svn mkdir A
svn rm A
And this would also error out or commit any children of C along with the child B, effectively committing C recursively, which defeats the idea of the --parents option:
svn cp A C
So, due to the recursive nature of copies, the above would be equivalent to:
svn cp A C
I'm not sure how this behaviour can be defined in a consistent way.
What about passing the right list of commit targets instead of adding a new --parents option? Note that the list can be passed via a file using the --targets option. Perhaps you could generate a file that includes the proper list of targets, and then run the commit?
[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.
This is an archived mail posted to the Subversion Users mailing list.