Differences between revisions 10 and 11
Revision 10 as of 2005-01-31 01:47:39
Size: 2589
Editor: 222-153-64-191
Comment: Add info about using a web browser to view repository structure
Revision 11 as of 2005-02-03 17:43:21
Size: 4926
Editor: dD5E05A90
Comment: record info from mailing list
Deletions are marked like this. Additions are marked like this.
Line 34: Line 34:
= 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).

Misc info

Whatever you do, don't checkout /jakarta/commons as you will be checking out a copy of every tag, trunk, and branch and it will take forever and a day. *Instead*, check out individual components, or (more likely) check out "trunks-proper" or "trunks-sandbox".

Checkout all components

svn co https://svn.apache.org/repos/asf/jakarta/commons/trunks-proper/ jakarta/commons/trunks-proper
svn co https://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbox/ jakarta/commons/trunks-sandbox

Checkout individual components (Don't forget to checkout commons-build!)

svn co https://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk jakarta/commons/trunks-proper/commons-build
svn co https://svn.apache.org/repos/asf/jakarta/commons/proper/dbcp/trunk jakarta/commons/trunks-proper/dbcp

svn co https://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk jakarta/commons/trunks-sandbox/commons-build
svn co https://svn.apache.org/repos/asf/jakarta/commons/sandbox/cache/trunk jakarta/commons/trunks-sandbox/cache

Getting directory listings

If you don't know the exact path to the component you wish to access, use 'svn ls' to get a directory listing, eg:

svn ls http://svn.apache.org/repos/asf/jakarta/commons

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

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:

[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

maven.changelog.factory=org.apache.maven.svnlib.SvnChangeLogFactory

project.xml

  <repository>
   <connection>scm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk</connection>
    <url>http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk</url>
  </repository>

Commons repo

Software

Documentation

UsingSVN (last edited 2012-02-09 17:41:22 by sebbapache)