[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ next ]
Check /usr/share/doc/cvs/html-cvsclient,
/usr/share/doc/cvs/html-info, /usr/share/doc/cvsbook
with lynx or run info cvs and man cvs
for detailed information.
The following setup will allow commits to the CVS repository only by a member of the "src" group, and administration of CVS only by a member of the "staff" group, thus reducing the chance of shooting oneself.
# cd /var/lib; umask 002; mkdir cvs # [Woody] FSH
# apt-get install cvs cvs-doc cvsbook
# export CVSROOT=/var/lib/cvs
# cd $CVSROOT
# chown root:src . # "staff" to restrict more for starting project.
# chmod 3775 . # If above uses "staff", use 2775
# cvs -d /var/lib/cvs init # safer to specify -d here explicitly!
# cd CVSROOT
# chown -R root:staff .
# chmod 2775 .
# touch val-tags
# chmod 664 history val-tags
# chown root:src history val-tags
The following will set up shell environments for CVS repository access.
Read-only remote access:
$ export CVSROOT=:pserver:anonymous@cvs.sf.net:/cvsroot/qref
$ cvs login
$ cvs -z3 co qref
Local access from a shell on the same machine:
$ export CVSROOT=/var/lib/cvs
Remote access without SSH (use RSH protocol capability in cvs):
$ export CVSROOT=:pserver:account@cvs.foobar.com:/var/lib/cvs
$ cvs login
This is prone to eavesdropping attack.
sshRemote access with SSH:
$ export CVSROOT=:ext:account@cvs.foobar.com:/var/lib/cvs
or for SourceForge:
$ export CVSROOT=:ext:account@cvs.sf.net:/cvsroot/qref
You can also use RSA authentication (Connecting with fewer passwords – RSA, Section 9.5.3), which eliminates the password prompt.
For,
ITEM VALUE MEANING
source tree: ~/project-x All source codes
Project name: project-x Name for this project
Vendor Tag: Main-branch Tag for the entire branch
Release Tag: Release-initial Tag for a specific release
Then,
$ cd ~/project-x # dive into source directory
... create a source tree ...
$ cvs import -m "Start project-x" project-x Main-branch Release-initial
$ cd ..; rm -R ~/project-x
To work with project-x using the local CVS repository:
$ cd # move to the work area
$ cvs co project-x # get sources from CVS to local
$ cd project-x
... make changes to the content ...
$ cvs diff -u # similar to diff -u repository/ local/
$ cvs up -C modified_file # undo changes to a file
$ cvs ci -m "Describe change" # save local sources to CVS
$ vi newfile_added
$ cvs add newfile_added
$ cvs ci -m "Added newfile_added"
$ cvs up # merge latest version from CVS
... to create all newly created subdirectories from CVS, use
... "cvs up -d -P" instead
... watch out for lines starting with "C filename"
... unmodified code is moved to `.#filename.version'
... search for "<<<<<<<" and ">>>>>>>" in filename
$ cvs tag Release-1 # add release tag
... edit further ...
$ cvs tag -d Release-1 # remove release tag
$ cvs ci -m "more comments"
$ cvs tag Release-1 # re-add release tag
$ cd # move back to the work area
$ cvs co -r Release-initial -d old project-x
... get original version to old directory
$ cd old
$ cvs tag -b Release-initial-bugfixes # create branch (-b) tag
... now you can work on the old version (Tag=sticky)
$ cvs update -d -P # don't create empty directories
... source tree now has sticky tag "Release-initial-bugfixes"
... work on this branch
$ cvs up -d -P # sync with files modified by others on this branch
$ cvs ci -m "check into this branch"
$ cvs update -kk -A -d -P
... remove sticky tag and forget contents
... update from main trunk without keyword expansion
$ cvs update -kk -d -P -j Release-initial-bugfixes
... Merge from Release-initial-bugfixes branch into the main
... trunk without keyword expansion. Fix conflicts with editor.
$ cvs ci -m "merge Release-initial-bugfixes"
$ cd
$ tar -cvzf old-project-x.tar.gz old # make archive, -j for bz2
$ cvs release -d old # remove local source (optional)
Nice options to remember (use as first argument(s) to cvs):
-n dry run, no effect
-t display messages showing steps of cvs activity
To get the latest version from CVS, use "tomorrow":
$ cvs ex -D tomorrow module_name
Add alias to a project (local server):
$ su - admin # a member of staff
$ export CVSROOT=/var/lib/cvs
$ cvs co CVSROOT/modules
$ cd CVSROOT
$ echo "px -a project-x" >>modules
$ cvs ci -m "Now px is an alias for project-x"
$ cvs release -d .
$ exit # or Ctrl-D to get back from su
$ cvs co -d project px
... check out project-x (alias:px) from CVS to directory project
$ cd project
... make changes to the content ...
CVS will not overwrite the current repository file but replaces it with another one. Thus, write permission to the repository directory is critical. For every new repository creation, run the following to ensure this condition if needed.
# cd /var/lib/cvs
# chown -R root:src repository
# chmod -R ug+rwX repository
# chmod 2775 repository # if needed, this and subdirectory
A file's execution bit is retained when checked out. Whenever you see execution permission problems in checked-out files, change permissions of the file in the CVS repository with the following command.
# chmod ugo-x filename
Here are CVS commands with their shortcuts.
{add|ad|new} [-k kflag] [-m 'message'] files...
{admin|adm|rcs} [rcs-options] files...
{annotate|ann} [options] [files...]
{checkout|co|get} [options] modules...
{commit|ci|com} [-lnR] [-m 'log_message' | -f file] \
[-r revision] [files...]
{diff|di|dif} [-kl] [rcsdiff_options] [[-r rev1 | -D date1] \
[-r rev2 | -D date2]] [files...]
{export|ex|exp} [-flNn] -r rev|-D date [-d dir] [-k kflag] module...
{history|hi|his} [-report] [-flags] [-options args] [files...]
{import|im|imp} [-options] repository vendortag releasetag...
{login|logon|lgn}
{log|lo|rlog} [-l] rlog-options [files...]
{rdiff|patch|pa} [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules...
{release|re|rel} [-d] directories...
{remove|rm|delete} [-lR] [files...]
{rtag|rt|rfreeze} [-falnR] [-b] [-d] [-r tag | -D date] \
symbolic_tag modules...
{status|st|stat} [-lR] [-v] [files...]
{tag|ta|freeze} [-lR] [-F] [-b] [-d] [-r tag | -D date] [-f] \
symbolic_tag [files...]
{update|up|upd} [-AdflPpR] [-d] [-r tag|-D date] files...
Subversion is a next-generation version control system that is intended to replace CVS. The developers currently consider it to be in the "alpha" stage, but it is probably stable enough for most uses. At the time of this writing, Subversion is only available in Debian unstable.
The subversion meta-package depends on the packages needed
(libapache2-svn and subversion-tools) to set up a
server.
Currently, the subversion package does not set up a repository, so
one must be set up manually. One possible location for a repository is in
/var/local/repos.
Create the directory:
# mkdir -p /var/local/repos
Create the repository database:
# svnadmin create /var/local/repos
Make the repository writable by the WWW server:
# chown -R www-data:www-data /var/local/repos
To allow access to the repository via user authentication, add (or uncomment)
the following in /etc/apache2/mods-available/dav_svn.conf:
<Location /repos>
DAV svn
SVNPath /var/local/repos
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /etc/subversion/passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
Then, create a user authentication file with the command:
htpasswd2 -c /etc/subversion/passwd some-username
Restart Apache2, and your new Subversion repository will be accessible with the URL http://hostname/repos.
The following sections teach you how to use different commands in Subversion.
To create a new Subversion archive, type the following:
$ cd ~/your-project # go to your source directory
$ svn import http://localhost/repos your-project \
project-name -m "initial project import"
This creates a directory named project-name in your Subversion repository which contains your project files. Look at http://localhost/repos/ to see if it's there.
Working with project-y using Subversion:
$ cd # move to the work area
$ svn co http://localhost/repos/project-y # Check out sources
$ cd project-y
... do some work ...
$ svn diff # similar to diff -u repository/ local/
$ svn revert modified_file # undo changes to a file
$ svn ci -m "Describe changes" # check in your changes to the repository
$ vi newfile_added
$ svn add newfile_added
$ svn add new_dir # recursively add all files in new_dir
$ svn add -N new_dir2 # nonrecursively add the directory
$ svn ci -m "Added newfile_added, new_dir, new_dir2"
$ svn up # merge in latest version from repository
$ svn log # shows all changes committed
$ svn copy http://localhost/repos/project-y \
http://localhost/repos/project-y-branch \
-m "creating my branch of project-y" # branching project-y
$ svn copy http://localhost/repos/project-y \
http://localhost/repos/proj-y_release1.0 \
-m "project-y 1.0 release" # added release tag
... note that branching and tagging are the same. The only difference
... is that branches get committed whereas tags do not.
... make changes to branch ...
$ # merge branched copy back to main copy
$ svn merge http://localhost/repos/project-y \
http://localhost/repos/project-y-branch
$ svn co -r 4 http://localhost/repos/project-y # get revision 4
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ next ]
Debian Reference
CVS, Mon Jun 16 21:20:26 UTC 2008osamu#at#debian.org