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
Received on 2013-06-06 22:38:11 CEST