subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <>
Subject Re: preventing accidental commit
Date Thu, 06 Jun 2013 20:37:30 GMT

On 6/6/2013 3:12 PM, Stefan Sperling wrote:
> On Thu, Jun 06, 2013 at 02:46:16PM -0400, Marshall Schor wrote:
>>   a) checkout the part of the update site from the ...dist/release... spot;
>>   b) update that, changing some files, adding others
>>   c) put it somewhere for a vote, and after the vote passes,
>>   d) commit the changes to the ...dist/release... spot
> When you say "accidental commit", do you mean the release manager
> is running 'svn commit' on a working copy from dist.a.o instead
> of an unrelated working copy the commit was intended to be made
> from, not realising the mistake until the commit has been made? 
> Or do you mean the release manager intentionally publishing the
> release, not realising that votes are outstanding? In which case
> I don't think there is a good technical solution to the problem.
> Perhaps the release manager needs a break :)
> In the first case:
> Why don't you commit to and vote in dev/release, and when all votes
> have passed, move the files to dist/release using svnmucc?
> This is what we do in Subversion itself. See this script:
> This approach makes it very unlikely that release artifacts
> end up in the dist/release directory by accident.
One issue we thought about when considering using .../dev/... was "wasting
space" in SVN with (potentially multiple) release candidates (which were binary
artifacts, like compressed Jar files).  Because of this, we were trying to avoid
using .../dev/... for this.

But, if that is an unnecessary worry, and we go with using .../dev/..., it would
seem that the first step in this would be to do an svn copy in
from /release/... to /dev/... and then check out from /dev/.   The reason for
the svn-copy from .../release/... to .../dev/... is because we need to
"guarantee" that we're incrementally building against the previous "release"
version; who knows what may have happened inside /dev/ since the last release.

The release manager could then commit the "candidate" to /dev/, and when it is
finally voted out, copy dev -> release for that part.

One thing I don't understand about SVN is how the svn copy works when copying
from one repository location to another, when files already may exist at the
target spot.  The svn book I think is silent on this issue (unless I missed it)
- the use cases talked about (like for branching and tagging) all seem to assume
that the target spot "path" exists except for the last name segment (with an
optional flag "--parents" to add multiple new path segments at the end).  

Is it a requirement that the target spot (including the last name in the path)
for svn -> svn copying not already exist?  If so, I guess the thing to do would
be an svn delete of the target spot, followed by an svn copy.   Does this sound

Thanks. -Marshall

View raw message