Re: SVN release methodology : svn copy

2004-12-13 Thread Geoffrey Young 

 svn copy https://svn.apache.org/.../trunk \
 https://svn.apache.org/.../tags/1.17

 (optionally with an -r to peg at specific revision, I guess)
 
 
 Yes, that's probably what we will have to end up doing in the future.

if you can find the time, can you please make sure the RELEASE file is up to
date so that the next person to release Apache-Test has no trouble doing the
right thing?  thanks :)

--Geoff

SVN release methodology : svn copy

2004-12-11 Thread Philippe M. Chiasson 
[EMAIL PROTECTED] wrote:
Author: stas
Date: Sat Dec 11 11:15:27 2004
New Revision: 111615
URL: http://svn.apache.org/viewcvs?view=revrev=111615
Log:
tag 1.17
Added:
   httpd/test/tags/APACHE_TEST_1_17/
  - copied from r111612, httpd/test/trunk/perl-framework/Apache-Test/
   httpd/test/tags/APACHE_TEST_1_17/Changes
  - copied unchanged from r111614, 
httpd/test/trunk/perl-framework/Apache-Test/Changes
   httpd/test/tags/APACHE_TEST_1_17/Makefile.PL
  - copied unchanged from r111613, 
httpd/test/trunk/perl-framework/Apache-Test/Makefile.PL
   httpd/test/tags/APACHE_TEST_1_17/RELEASE
  - copied unchanged from r111613, 
httpd/test/trunk/perl-framework/Apache-Test/RELEASE
Anybody care to shed some light to what exactly this means?
Our normal release process is something like this:
$ make dist
[... test ...]
$ vi lib/Apache/Test.pm [bump version]
$ svn ci -m'Bump version' lib/Apache/Test.pm
$ svn copy . https://svn.apache.org/[...]/tags/1.17
And I thought this was the appropriate way to go about it. From what I can 
gather by reading this message,
the copy operation wasn't 100% clean, am I right ?
At this point, I am just a bit worried that there is something going on that I 
am
not fully aware, so if anybody can shed some light, it would be much 
appreciated.

Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5


signature.asc
Description: OpenPGP digital signature

Re: SVN release methodology : svn copy

2004-12-11 Thread Joe Orton 
On Sat, Dec 11, 2004 at 11:43:56AM -0800, Philippe M. Chiasson wrote:
 [EMAIL PROTECTED] wrote:
 Author: stas
 Date: Sat Dec 11 11:15:27 2004
 New Revision: 111615
 
 URL: http://svn.apache.org/viewcvs?view=revrev=111615
 Log:
 tag 1.17
 
 Added:
httpd/test/tags/APACHE_TEST_1_17/
   - copied from r111612, httpd/test/trunk/perl-framework/Apache-Test/
httpd/test/tags/APACHE_TEST_1_17/Changes
   - copied unchanged from r111614, 
   httpd/test/trunk/perl-framework/Apache-Test/Changes
httpd/test/tags/APACHE_TEST_1_17/Makefile.PL
   - copied unchanged from r111613, 
   httpd/test/trunk/perl-framework/Apache-Test/Makefile.PL
httpd/test/tags/APACHE_TEST_1_17/RELEASE
   - copied unchanged from r111613, 
   httpd/test/trunk/perl-framework/Apache-Test/RELEASE
 
 Anybody care to shed some light to what exactly this means?
 
 Our normal release process is something like this:
 
 $ make dist
 [... test ...]
 $ vi lib/Apache/Test.pm [bump version]
 $ svn ci -m'Bump version' lib/Apache/Test.pm
 $ svn copy . https://svn.apache.org/[...]/tags/1.17
 
 And I thought this was the appropriate way to go about it. From what I
 can gather by reading this message, the copy operation wasn't 100%
 clean, am I right ?

I think it's OK, but since you had a mixed revision working copy it 
looks a little strange: you had:

  . = last svn update at r111612
  Makefile.PL, RELEASE = committed changes in r111613
  Changes = committed changes in r111614

and so when you copied the WC to the tag, that's exactly what SVN
copied.  If you had run svn update first, it would all have been
copied from the same revision, r111614 (or whatever).

But the normal procedure for tagging is to copy from URL to URL, which
avoids this and is faster:

svn copy https://svn.apache.org/.../trunk \ 
https://svn.apache.org/.../tags/1.17

(optionally with an -r to peg at specific revision, I guess)

joe

 
 At this point, I am just a bit worried that there is something going
 on that I am not fully aware, so if anybody can shed some light, it
 would be much appreciated.
 
 
 Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 
 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 
 A107 88C3A5A5