[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

Eric

-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Wednesday, July 24, 2013 5:24 PM
To: Braun, Eric
Cc: users_at_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
Received on 2013-07-25 16:03:17 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.