You are viewing a plain text version of this content. The canonical link for it is here.
Posted to release-discuss@apache.org by Greg Stein <gs...@gmail.com> on 2012/03/02 20:22:15 UTC
Re: Question on release process - making release public by svn move
Moving this thread over to dev@subversion. We're using the dist area
for our upcoming 1.7.4 release (early next week).
Also copying the mailing list for release managers (release-discuss@)
Cheers,
-g
On Fri, Mar 2, 2012 at 13:58, sebb <se...@gmail.com> wrote:
> On 14 February 2012 11:26, sebb <se...@gmail.com> wrote:
>> On 10 February 2012 01:25, sebb <se...@gmail.com> wrote:
>>> I'm looking into updating the JMeter release instructions to use the
>>> https://dist.apache.org/repos/dist/ repo.
>>
>> Potentially also add the information to the releases FAQ [2] for
>> everyone to use.
>>
>> Ping: can no-one offer help here?
>
> I also asked on users@subversion, and did not get any further there.
>
> The only suggestion I got was to use svnmucc to allow multiple file
> renames within a single commit.
>
> Is that what httpd is using?
>
> If so, do you have a script to create the command line?
>
>> AFAICT the project has been using svnpubsub for releases for some
>> while now, and judging by the SVN logs have got a process that works
>> well.
>
> Are there no RMs here who can provide details on how the httpd process works?
>
>> Hopefully JMeter and other projects can benefit from the httpd experience.
>>
>> [2] http://www.apache.org/dev/release.html#upload-ci
>>
>>> AIUI you use dev/httpd/ for vote staging, and then rename the files to
>>> release/httpd/
>>>
>>> The documentation [1] says:
>>>
>>>>>
>>> *How do we make it public?*
>>> ...
>>> 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?
>>>
>>> I want to ensure that we preserve the history to show that the
>>> release/ files are derived from the dev/ files; this ties them back to
>>> the vote thread.
>>>
>>> Thanks!
>>>
>>> [1] http://httpd.apache.org/dev/release.html
Re: Question on release process - making release public by svn move
Posted by Daniel Shahaf <da...@apache.org>.
Daniel Shahaf wrote on Fri, Mar 09, 2012 at 21:10:27 +0200:
> sebb wrote on Fri, Mar 09, 2012 at 18:47:46 +0000:
> > No, still waiting for details on how the httpd commits were achieved.
>
> Just ask Sam to implement this in Whimsy.
Specifically:
* GET /postarelease/${pmc}
- Runs `svn ls -R #{DIST_ROOT}/repos/${pmc}`.
- Displays a multiselect widget (or a set of checkboxes), allowing
to choose any subset of the files/dirs there.
- Provide a textbox and a [Submit] button.
* POST /postarelease/${pmc}
- Preprocessing: if both X and all of X's immediate children are
selected, then unselect all those children. Repeat (recursing
upwards).
- Preprocessing: if any selected path is a child of any other
selected path, error out.
- Run svnmucc to move the selected paths from dev/ to release/, with
the user's credentials. Use textbox contents for the log message.
Optional features:
- A hidden form field with the "last modified revision" of dev/${tlp},
and at POST time use that as the base revision passed to the commit
editor (via svnmucc's argv).
Re: Question on release process - making release public by svn move
Posted by Daniel Shahaf <da...@apache.org>.
Daniel Shahaf wrote on Fri, Mar 09, 2012 at 21:10:27 +0200:
> sebb wrote on Fri, Mar 09, 2012 at 18:47:46 +0000:
> > No, still waiting for details on how the httpd commits were achieved.
>
> Just ask Sam to implement this in Whimsy.
Specifically:
* GET /postarelease/${pmc}
- Runs `svn ls -R #{DIST_ROOT}/repos/${pmc}`.
- Displays a multiselect widget (or a set of checkboxes), allowing
to choose any subset of the files/dirs there.
- Provide a textbox and a [Submit] button.
* POST /postarelease/${pmc}
- Preprocessing: if both X and all of X's immediate children are
selected, then unselect all those children. Repeat (recursing
upwards).
- Preprocessing: if any selected path is a child of any other
selected path, error out.
- Run svnmucc to move the selected paths from dev/ to release/, with
the user's credentials. Use textbox contents for the log message.
Optional features:
- A hidden form field with the "last modified revision" of dev/${tlp},
and at POST time use that as the base revision passed to the commit
editor (via svnmucc's argv).
Re: Question on release process - making release public by svn move
Posted by Daniel Shahaf <da...@apache.org>.
sebb wrote on Fri, Mar 09, 2012 at 18:47:46 +0000:
> No, still waiting for details on how the httpd commits were achieved.
Just ask Sam to implement this in Whimsy.
Re: Question on release process - making release public by svn move
Posted by Daniel Shahaf <da...@apache.org>.
sebb wrote on Fri, Mar 09, 2012 at 18:47:46 +0000:
> No, still waiting for details on how the httpd commits were achieved.
Just ask Sam to implement this in Whimsy.
Re: Question on release process - making release public by svn move
Posted by Philip Martin <ph...@wandisco.com>.
sebb <se...@gmail.com> writes:
>>> 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)
>>
>> I don't know what httpd folks did there.
>
> Neither do I, which is where this all started ...
You can do it with svnmucc:
$ svnmucc -U http://localhost:8888/obj/repo \
rm release/httpd/f \
cp head dev/httpd/f release/httpd/f \
cp head dev/httpd/g release/httpd/g
$ svn log -vqr4 http://localhost:8888/obj/repo
------------------------------------------------------------------------
r4 | (no author) | 2012-03-09 19:51:58 +0000 (Fri, 09 Mar 2012)
Changed paths:
R /release/httpd/f (from /dev/httpd/f:3)
A /release/httpd/g (from /dev/httpd/g:3)
------------------------------------------------------------------------
Or you could use the Subversion bindings to drive the RA layer.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Question on release process - making release public by svn move
Posted by Philip Martin <ph...@wandisco.com>.
sebb <se...@gmail.com> writes:
>>> 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)
>>
>> I don't know what httpd folks did there.
>
> Neither do I, which is where this all started ...
You can do it with svnmucc:
$ svnmucc -U http://localhost:8888/obj/repo \
rm release/httpd/f \
cp head dev/httpd/f release/httpd/f \
cp head dev/httpd/g release/httpd/g
$ svn log -vqr4 http://localhost:8888/obj/repo
------------------------------------------------------------------------
r4 | (no author) | 2012-03-09 19:51:58 +0000 (Fri, 09 Mar 2012)
Changed paths:
R /release/httpd/f (from /dev/httpd/f:3)
A /release/httpd/g (from /dev/httpd/g:3)
------------------------------------------------------------------------
Or you could use the Subversion bindings to drive the RA layer.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Question on release process - making release public by svn move
Posted by sebb <se...@gmail.com>.
On 8 March 2012 13:49, Stefan Sperling <st...@elego.de> wrote:
> On Sat, Mar 03, 2012 at 01:03:47PM +0000, sebb wrote:
>> >> >> > 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
>> >> >> >
>
>> > 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?
>
> Yes it will.
>
>> 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)
>
> I don't know what httpd folks did there.
Neither do I, which is where this all started ...
> For Subversion 1.7.4, I used danielsh's suggestion number 5 simply
> because it is easy to do and I didn't mind downloading the 1.7.3 tarballs.
That's not going to be suitable for projects with lots of archives,
e.g. Commons.
And not ideal for projects with very large archive files either.
> I plan to implement suggestion number 1 (using the svnmucc command) in
> subversion's release.py script at
> https://svn.apache.org/repos/asf/subversion/trunk/tools/dist/release.py
> so we can use it for future releases.
>
> Have you found a satisfying solution yet?
No, still waiting for details on how the httpd commits were achieved.
Re: Question on release process - making release public by svn move
Posted by sebb <se...@gmail.com>.
On 8 March 2012 13:49, Stefan Sperling <st...@elego.de> wrote:
> On Sat, Mar 03, 2012 at 01:03:47PM +0000, sebb wrote:
>> >> >> > 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
>> >> >> >
>
>> > 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?
>
> Yes it will.
>
>> 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)
>
> I don't know what httpd folks did there.
Neither do I, which is where this all started ...
> For Subversion 1.7.4, I used danielsh's suggestion number 5 simply
> because it is easy to do and I didn't mind downloading the 1.7.3 tarballs.
That's not going to be suitable for projects with lots of archives,
e.g. Commons.
And not ideal for projects with very large archive files either.
> I plan to implement suggestion number 1 (using the svnmucc command) in
> subversion's release.py script at
> https://svn.apache.org/repos/asf/subversion/trunk/tools/dist/release.py
> so we can use it for future releases.
>
> Have you found a satisfying solution yet?
No, still waiting for details on how the httpd commits were achieved.
Re: Question on release process - making release public by svn move
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Mar 03, 2012 at 01:03:47PM +0000, sebb wrote:
> >> >> > 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
> >> >> >
> > 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?
Yes it will.
> 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)
I don't know what httpd folks did there.
For Subversion 1.7.4, I used danielsh's suggestion number 5 simply
because it is easy to do and I didn't mind downloading the 1.7.3 tarballs.
I plan to implement suggestion number 1 (using the svnmucc command) in
subversion's release.py script at
https://svn.apache.org/repos/asf/subversion/trunk/tools/dist/release.py
so we can use it for future releases.
Have you found a satisfying solution yet?
Re: Question on release process - making release public by svn move
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Mar 03, 2012 at 01:03:47PM +0000, sebb wrote:
> >> >> > 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
> >> >> >
> > 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?
Yes it will.
> 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)
I don't know what httpd folks did there.
For Subversion 1.7.4, I used danielsh's suggestion number 5 simply
because it is easy to do and I didn't mind downloading the 1.7.3 tarballs.
I plan to implement suggestion number 1 (using the svnmucc command) in
subversion's release.py script at
https://svn.apache.org/repos/asf/subversion/trunk/tools/dist/release.py
so we can use it for future releases.
Have you found a satisfying solution yet?
Re: Question on release process - making release public by svn move
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sat, Mar 3, 2012 at 2:03 PM, sebb <se...@gmail.com> wrote:
> On 3 March 2012 12:48, Daniel Shahaf <da...@apache.org> wrote:
>> sebb wrote on Sat, Mar 03, 2012 at 12:30:53 +0000:
>>> On 3 March 2012 09:29, Daniel Shahaf <da...@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 <da...@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)
Just following from a distance here, but from the looks of it, I think
option 2 from Daniel's suggestions would work quite well for projects
which don't have a directory per release (and if you want the move to
be done server-side). From 'svn help move':
usage: move SRC... DST
So you can simply give multiple sources and one destination directory. As in:
svn mv ^/dev/httpd/CHANGES_2.2 ^/dev/httpd/CHANGES_2.2.21 ^/release/httpd
However, I'm not sure about your exact example. I don't think you can
do the R (replace) without a working copy.
--
Johan
Re: Question on release process - making release public by svn move
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sat, Mar 3, 2012 at 2:03 PM, sebb <se...@gmail.com> wrote:
> On 3 March 2012 12:48, Daniel Shahaf <da...@apache.org> wrote:
>> sebb wrote on Sat, Mar 03, 2012 at 12:30:53 +0000:
>>> On 3 March 2012 09:29, Daniel Shahaf <da...@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 <da...@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)
Just following from a distance here, but from the looks of it, I think
option 2 from Daniel's suggestions would work quite well for projects
which don't have a directory per release (and if you want the move to
be done server-side). From 'svn help move':
usage: move SRC... DST
So you can simply give multiple sources and one destination directory. As in:
svn mv ^/dev/httpd/CHANGES_2.2 ^/dev/httpd/CHANGES_2.2.21 ^/release/httpd
However, I'm not sure about your exact example. I don't think you can
do the R (replace) without a working copy.
--
Johan
Re: Question on release process - making release public by svn move
Posted by sebb <se...@gmail.com>.
On 3 March 2012 12:48, Daniel Shahaf <da...@apache.org> wrote:
> sebb wrote on Sat, Mar 03, 2012 at 12:30:53 +0000:
>> On 3 March 2012 09:29, Daniel Shahaf <da...@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 <da...@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)
Re: Question on release process - making release public by svn move
Posted by sebb <se...@gmail.com>.
On 3 March 2012 12:48, Daniel Shahaf <da...@apache.org> wrote:
> sebb wrote on Sat, Mar 03, 2012 at 12:30:53 +0000:
>> On 3 March 2012 09:29, Daniel Shahaf <da...@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 <da...@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)
Re: Question on release process - making release public by svn move
Posted by Daniel Shahaf <da...@apache.org>.
sebb wrote on Sat, Mar 03, 2012 at 12:30:53 +0000:
> On 3 March 2012 09:29, Daniel Shahaf <da...@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 <da...@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/
> 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.
>
> 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.
Re: Question on release process - making release public by svn move
Posted by Daniel Shahaf <da...@apache.org>.
sebb wrote on Sat, Mar 03, 2012 at 12:30:53 +0000:
> On 3 March 2012 09:29, Daniel Shahaf <da...@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 <da...@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/
> 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.
>
> 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.
Re: Question on release process - making release public by svn move
Posted by sebb <se...@gmail.com>.
On 3 March 2012 09:29, Daniel Shahaf <da...@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 <da...@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/
>> >
>> > Does that answer your question?
>>
>> I work on the same project as you, Daniel, and even for me, that was
>> certainly.... opaque.
>>
>> Looks like you are providing four different alternatives to move from
>> "development review" to "release". Did I get that right?
>>
>
> Yes, I was providing four different ways to move the tarballs+signatures
> from the dev/ tree to the release/ tree.
>
>> A bit of exposition would be nice.
>>
>
> Next time, sure.
So 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)
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/ ?
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.
Re: Question on release process - making release public by svn move
Posted by sebb <se...@gmail.com>.
On 3 March 2012 09:29, Daniel Shahaf <da...@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 <da...@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/
>> >
>> > Does that answer your question?
>>
>> I work on the same project as you, Daniel, and even for me, that was
>> certainly.... opaque.
>>
>> Looks like you are providing four different alternatives to move from
>> "development review" to "release". Did I get that right?
>>
>
> Yes, I was providing four different ways to move the tarballs+signatures
> from the dev/ tree to the release/ tree.
>
>> A bit of exposition would be nice.
>>
>
> Next time, sure.
So 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)
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/ ?
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.
Re: Question on release process - making release public by svn move
Posted by Daniel Shahaf <da...@apache.org>.
Greg Stein wrote on Sat, Mar 03, 2012 at 04:20:33 -0500:
> On Sat, Mar 3, 2012 at 04:02, Daniel Shahaf <da...@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/
> >
> > Does that answer your question?
>
> I work on the same project as you, Daniel, and even for me, that was
> certainly.... opaque.
>
> Looks like you are providing four different alternatives to move from
> "development review" to "release". Did I get that right?
>
Yes, I was providing four different ways to move the tarballs+signatures
from the dev/ tree to the release/ tree.
> A bit of exposition would be nice.
>
Next time, sure.
> Thanks,
> -g
Re: Question on release process - making release public by svn move
Posted by Daniel Shahaf <da...@apache.org>.
Greg Stein wrote on Sat, Mar 03, 2012 at 04:20:33 -0500:
> On Sat, Mar 3, 2012 at 04:02, Daniel Shahaf <da...@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/
> >
> > Does that answer your question?
>
> I work on the same project as you, Daniel, and even for me, that was
> certainly.... opaque.
>
> Looks like you are providing four different alternatives to move from
> "development review" to "release". Did I get that right?
>
Yes, I was providing four different ways to move the tarballs+signatures
from the dev/ tree to the release/ tree.
> A bit of exposition would be nice.
>
Next time, sure.
> Thanks,
> -g
Re: Question on release process - making release public by svn move
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Mar 3, 2012 at 04:02, Daniel Shahaf <da...@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/
>
> Does that answer your question?
I work on the same project as you, Daniel, and even for me, that was
certainly.... opaque.
Looks like you are providing four different alternatives to move from
"development review" to "release". Did I get that right?
A bit of exposition would be nice.
Thanks,
-g
Re: Question on release process - making release public by svn move
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Mar 3, 2012 at 04:02, Daniel Shahaf <da...@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/
>
> Does that answer your question?
I work on the same project as you, Daniel, and even for me, that was
certainly.... opaque.
Looks like you are providing four different alternatives to move from
"development review" to "release". Did I get that right?
A bit of exposition would be nice.
Thanks,
-g
Re: Question on release process - making release public by svn move
Posted by Daniel Shahaf <da...@apache.org>.
> >>> 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/
Does that answer your question?
Re: Question on release process - making release public by svn move
Posted by Daniel Shahaf <da...@apache.org>.
> >>> 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/
Does that answer your question?