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).

Eric

-----Original Message-----
From: Stefan Sperling [mailto:s...@elego.de]
Sent: Wednesday, July 24, 2013 5:24 PM
To: Braun, Eric
Cc: users@subversion.apache.org; Moe, Mark
Subject: Re: Mixing recursive and non-recursive commits

On Wed, Jul 24, 2013 at 07:32:20PM +0000, Braun, Eric wrote:
> The enhancement would be to include only parents marked for addition.  
> Nothing special for prop changes as you don't want to commit these later if 
> the directory was already committed (unless explicitly stated).
>
> So, I think's a rather simple request.  If commit --parents is loaded then 
> any parent directories for the given command line targets that are in an add 
> state should be included in the targets passed on.
>
> Eric

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.
Copies can only be committed recursively due to the way cheap copies are 
implemented in the repository. That would mean that not only parents of the 
explicit commit target would be committed, but also any other children of those 
parents.

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 mkdir A/B
  svn commit --parents A/B

But the following would have to error out or commit the deletion of the 
original A, not just an addition:

  svn rm A
  svn mkdir A
  svn mkdir A/B
  svn commit --parents A/B

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
  svn mkdir C/B
  svn commit --parents C/B

So, due to the recursive nature of copies, the above would be equivalent to:

  svn cp A C
  svn mkdir C/B
  svn commit 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.

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

Reply via email to