[Jakarta Commons Wiki] Updated: UsingSVN

[co...@jakarta.apache.org]

   Date: 2005-02-03T09:43:23
   Editor: DirkVerbeeck
   Wiki: Jakarta Commons Wiki
   Page: UsingSVN
   URL: http://wiki.apache.org/jakarta-commons/UsingSVN

   record info from mailing list

Change Log:

------------------------------------------------------------------------------
@@ -31,6 +31,55 @@
 A web browser can also be used to view the repository structure, just by entering the URL that you would use for subversion operations.
 Note that this shows only the latest version of everything (directories and files).
 
+= Differences between CVS and SVN =
+
+Normally CVS "tags" are simply used to mark a set of files so that you
+can retrieve that same set later. In this case, the equivalent in
+subversion is just to use
+  svn cp {from} {to}
+eg
+  svn cp https://..../trunk  https://.../tags/beta1
+to save the current state of the trunk as a directory "beta1". The copy
+command makes a "light-weight copy", essentially a sort of hard link
+with copy-on-write so updates don't affect the original source.
+
+If the trunk versions move on, and you later want beta1 to include one
+of the updated files, then update what "beta1" refers to by relinking
+from the beta1 directory to the version you really want:
+  * removing the file (link) you no longer need from the "tag" dir
+     eg  svn rm https://....../tags/..../foo.txt [1]
+  * copying back in (ie link to) the version you want
+     eg svn cp 
+          -r 100 https://..../trunk/.../foo.txt  [2]
+          https://..../tags/.../foo.txt   [3]
+
+[1] or if you have a working copy of the tag dir, you can 
+    do svn rm and svn commit
+[2] if you want the latest version, just omit the -r 100.
+[3] or if you have a working copy of the tag, copy to your working
+    copy then svn commit it.
+
+Performing the copy again (ie linking to the *updated* file [together
+with its history] from the tag) is what Brett means by "copy with
+history again". Using "svn merge" doesn't do the same thing, because it
+is effectively generating a patch file then applying it to your version;
+the differences get merged in, but not the history.
+
+Alternatively, if the "updated" tag is meant to look mostly or
+completely like the new trunk, then just use "svn update" to ensure your
+trunk working copy looks like the stuff you want to tag, then delete the
+old "beta1" directory, and recreate it. Copies are cheap!
+
+There isn't any difference between a directory created with the intent
+of just using it as a "tag" and a directory created with the intent of
+using it as a branch. The convention of putting the scn copy into
+subdirs "{project}/branches" and "{project}/tags" are traditionally used
+to *indicate the intent* of the copy, but they are functionally
+identical.
+
+For some other traditional uses of CVS tags, it might be better to use
+subversion "properties" (see svn set-prop).
+
 = Maven config =
 
 '''project.properties'''

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