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 right? Thanks. -Marshall
