subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Braun, Eric" <eric.br...@medtronic.com>
Subject RE: Mixing recursive and non-recursive commits
Date Thu, 25 Jul 2013 17:33:19 GMT
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:stsp@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


Mime
View raw message