commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From skitch...@apache.org
Subject svn commit: r190386 - /jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml
Date Mon, 13 Jun 2005 11:30:01 GMT
Author: skitching
Date: Mon Jun 13 04:30:01 2005
New Revision: 190386

URL: http://svn.apache.org/viewcvs?rev=190386&view=rev
Log:
Added useful notes on "svn update" and "svn log --stop-on-copy"

Modified:
    jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml

Modified: jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml
URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml?rev=190386&r1=190385&r2=190386&view=diff
==============================================================================
--- jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml (original)
+++ jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml Mon Jun 13 04:30:01
2005
@@ -69,9 +69,16 @@
       If a release branch is to be made early, then the following should be done:
       <pre>
         cd to the project's base directory in your subversion working copy.
+        svn update trunk
         svn cp trunk branches/foo-1.2-work
-        svn commit
+        svn commit branches/foo-1.2-work
       </pre>
+      Note that the "svn update" step is necessary in order to ensure that the directory
being
+      copied does not have a mix of files at various revisions; even if the files haven't
changed
+      since the last svn update this can cause "svn log -v" on the new directory to report
files as
+      having been (R)eplaced. Alternatively, use "svn cp URL1 URL2" which will copy files
+      internally within the repository without using the local working copy; this always
ensures
+      a clean copy is made.
       </p>
       <p>
       The description below assumes a release is being prepared on the trunk. The process
is nearly
@@ -134,13 +141,14 @@
         had been created:
         <pre>
           cd {project-base}/tags
-          svn log . | more
-          # look for the commit message that indicates the creation of dir foo-1.1 and
-          # note the revision number NNNN that created the tag (or the date DDDD on which
-	  # the commit occurred).
+
+          svn log --stop-on-copy foo-1.1
+          # The last revision NNNN reported in the log output is the revision that was
+          # copied to create the tag. If this is a true tag directory, then of course
+          # there will only be one revision listed by the log command..
+
           cd ..
           svn log -v -rNNNN:HEAD trunk > commits-since-last-release.txt
-          # or svn log -v -r{DDDD}:HEAD trunk > commits-since-last-release.txt
         </pre>
 	</p>
 	<p>
@@ -252,8 +260,18 @@
         <p>
         Now create a tag: 
 	<pre>
+	  svn update trunk
 	  svn cp trunk tags/foo-1.2-rc1
+	  svn commit tags/foo-1.2-rc1
 	</pre>
+	</p>
+	<p>
+        Note that the "svn update" step is necessary in order to ensure that the directory
being
+        copied does not have a mix of files at various revisions; even if the files haven't
changed
+        since the last svn update this can cause "svn log -v" on the new directory to report
files as
+        having been (R)eplaced. Alternatively, use "svn cp URL1 URL2" which will copy files
+        internally within the repository without using the local working copy; this always
ensures
+        a clean copy is made.
 	</p>
 	<p>
 	Build distributions from that tag (as <a href='release.html'>per full release</a>).




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message