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

Re: preventing accidental commit

From: Marshall Schor <msa_at_schor.com>
Date: Thu, 06 Jun 2013 16:37:30 -0400

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:
> https://svn.apache.org/repos/asf/subversion/trunk/tools/dist/release.py
> 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 dist.apache.org
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
Received on 2013-06-06 22:38:11 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.