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

Re: Question on release process - making release public by svn move

From: sebb <sebbaz_at_gmail.com>
Date: Sat, 3 Mar 2012 13:03:47 +0000

On 3 March 2012 12:48, Daniel Shahaf <danielsh_at_apache.org> wrote:
> sebb wrote on Sat, Mar 03, 2012 at 12:30:53 +0000:
>> On 3 March 2012 09:29, Daniel Shahaf <danielsh_at_apache.org> wrote:
>> > Greg Stein wrote on Sat, Mar 03, 2012 at 04:20:33 -0500:
>> >> On Sat, Mar 3, 2012 at 04:02, Daniel Shahaf <danielsh_at_apache.org> wrote:
>> >> >> >>> The release tarballs and signatures can be svn mv'ed from the
>> >> >> >>> https://dist.apache.org/repos/dist/dev/httpd/ repository across to the
>> >> >> >>> https://dist.apache.org/repos/dist/release/httpd/ repository.
>> >> >> >>> <<
>> >> >> >>>
>> >> >> >>> I've tried using svn mv directly on a test repo (i.e. not using a
>> >> >> >>> workspace), and it does not seem to be possible to move multiple files
>> >> >> >>> at once.
>> >> >> >>>
>> >> >> >>> Can I ask for a bit more detail on how you actually do the move?
>> >> >
>> >> > 1)
>> >> > svnmucc -m logmsg -U https://dist.apache.org/repos/dist/   \
>> >> >        mv dev/subversion/subversion-1.7.4.tar.bz2         \
>> >> >           release/subversion/subversion-1.7.4.tar.bz2     \
>> >> >        mv dev/subversion/subversion-1.7.4.tar.bz2.asc     \
>> >> >           release/subversion/subversion-1.7.4.tar.bz2.asc
>> >> >
>> >> > 2)
>> >> > svn mv https://dist.apache.org/repos/dist/dev/subversion/subversion-1.7.4.tar.bz2 \
>> >> >       https://dist.apache.org/repos/dist/dev/subversion/subversion-1.7.4.tar.bz2.asc \
>> >> >       https://dist.apache.org/repos/dist/release/subversion/
>> >> >
>> >> > 3)
>> >> > svn mv https://dist.apache.org/repos/dist/dev/subversion/1.7.4/ \
>> >> >       https://dist.apache.org/repos/dist/release/subversion/
>> >> >
>> >> > 4)
>> >> > svn mv https://dist.apache.org/repos/dist/dev/subversion/1.7.4/ \
>> >> >       https://dist.apache.org/repos/dist/release/subversion/1.7.4/
>> >> >
>
> There is also
>
> 5)
> svn co --depth empty https://dist.apache.org/repos/dist/
> cd dist
> svn up --parents --set-depth infinity dev/subversion release/subversion/
> svn mv dev/subversion/* release/subversion/

Won't that download every single prior release and all release
candidates for subversion?
That is exactly what I was trying to avoid.

>> And when might one use the different options?
>> For example, how does 4) differ from 3)?
>> Won't 4) end up creating subversion/1.7.4/1.7.4/ ?
>
> The semantics are the same as unix mv: if the 2nd argument already
> exists, then the first argument is moved to a child within the 2nd
> argument named like the basename of the first argument; otherwise,
> the parent of the 2nd argument must exist.

Probably safer not to recommend 4 then; as its behaviour changes
depending on the repo state.

>>
>> Also 1 & 2 seem to relate to different directory layouts compared with 3 & 4.
>> As far as I can tell, 3&4 assume each release has a different
>> subdirectory, which is not the case with httpd at present.
>> Using a separate sub-directory per release makes it trivial, but is
>> not going to suit all projects.
>
> Who said per release?  You can use
>
> /release/$tlp/foo/
>
> with directory moves, where "foo" is some constant string.

Well of course, but that's not the point.

If foo contains multiple versions, renaming foo will rename all the
files contained therein, which is not what is required.

I also asked:

How was the following commit acheived?

svn log -r397 -v https://dist.apache.org/repos/dist/

Whatever was used to generate that commit is good because it shows
clearly that the release files were derived from the dev files, for
example:

  R /release/httpd/CHANGES_2.2 (from /dev/httpd/CHANGES_2.2:396)
  A /release/httpd/CHANGES_2.2.21 (from /dev/httpd/CHANGES_2.2.21:396)
Received on 2012-03-03 14:04:22 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.