RE: Mixing recursive and non-recursive commits

I'm not following why you think this would be inconsistent behavior. The scenarios you listed are all "modified" parents not newly added parents. I'm not requesting an option to always automatically add parents just to add new parents if needed. I don't know of any one requesting "automatic parents" add although I guess you could extend it in the future to that. Would it help to call the option --include-new-parents instead of just --parents?

The fact of the matter is there is no option to do this now and to build a list of parents on the command line to checkin a new file down in a large subdir tree is time consuming because you have to specify each potentially new parent tree (even after added locally). Doing a commit at the higher level is obviously not desirable if there are other subdirs there that are added w/ new or modified dirs/files I don't wish to commit now.

I understand you are looking for more consensus from others before moving forward with an official request on this. I'm hoping others jump on this thread over time I guess and push for this. All I can point to is others asking/complaining about the lack of support for the same thing:

http://stackoverflow.com/questions/8932165/add-and-commit-files-in-a-tree-to-svn
http://subversion.1072662.n5.nabble.com/feature-request-svn-ci-parents-option-td69929.html

I'll wait awhile to see if others think this is valid but if not I'm fine continue on manually adding parents to the command line checkin.

Eric

-----Original Message-----
From: Philip Martin [mailto:philip.martin_at_wandisco.com]
Sent: Tuesday, August 20, 2013 9:40 AM
To: Braun, Eric
Cc: Stefan Sperling; users_at_subversion.apache.org; Moe, Mark
Subject: Re: Mixing recursive and non-recursive commits

"Braun, Eric" <eric.braun_at_medtronic.com> writes:

> If do a google search for "svn commit parents" you'll see I'm not the
> first to unofficially request this and come across this issue. I
> suspect most others just kludged around this and found a subtree to
> checkin with additional work involved. I see the need for this quite
> often when I'm running scripts that interactive with multiple
> directory trees. Quite often the scripts create new dirs with new
> files that I want to checkin. So I add these with --parents. When
> completed though I may want to selectively checkin certain files w/ a
> given comment (not the whole subtree).
>
> Regarding your corner cases if we stick to the explanation that only
> newly added parent directories (and their properties set) will get
> added to the commit list then this handles these scenarios. In the
> first scenario the property updates in A would NOT be committed
> because A is not a newly added parent directory. In the second corner
> case items in the changelist plus any newly added parent directories
> is what would be committed.

The problem I have is that the simple behaviour leads to inconsistencies such as modified parents with properties. You suggest resolving that inconsistency in a particular way but as far as I can see other behaviours are just as reasonable. You describe the feature as "added parents" but somebody else could describe it as "automatic parents" and want the other behaviour. If we implement one behaviour now how do we extend it in the future?

I don't see many requests for this behaviour and in this thread the discussion is mostly you and me. To make progress we need consensus on the desired behaviour and that is hard when there are so few voices.

--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
[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