Resolving Conflicts
I forgot to mention it earlier. When you commit changes and there are conflicts, the conflicting files will now contain both sets of changes, and it is up to you to go in and edit to fix this problem.
branching
I'll give a set of commands and explain them:
cd .. //get out of current working directory
cvs -q checkout -d new_folder -r Release_Name Project_Name // gets a working copy at the specified Release in the folder specified
cd new_folder
cvs -q tag -b Branch_Name // create a branch at the state in the working directory with the given branch name
two ways to get a check out files in new branch:
cvs co -d desired folder -r branch_name project_name // of course you don't have to use the -d option on check out
--or--
cvs update -r Branch_Name // this will try to merge changes in current working directory, so if you have changes you don't want added it is best to use the checkout method
if the working copy you have is on a branch, you can commit normally, and it will go into the branch
you can get back to the current version as always with:
cvs -q update -A
merging changes from branch to trunk:
(from trunk working copy)
cvs -q diff -c -r branch_name //this shows differences in branch and current versions
cvs -q update -j branch_name // -j means join
Resolve any conflicts as you normally would by editing the files with conflicts in them.
Trying to re-merge after new changes will cause conflicts because it looks at differences between the root and tip of the branch and tries to merge all of those changes. some of them have already been merged, hence the conflict.
To avoid re-merge conflicts
cvs -q update -j "branch_name:date -j branch_name // the first -j gives join a start point, and keeps it from using the root of the branch.
If you tagged the point at which you merged last time, you could do the following:
cvs -q update -j last_merge_tag -j branch_name
for this reason it is good to tag at every merge with a descriptive name (including the branch name in the tag is a good idea)
branching without first checking out a working copy of the release to branch
cvs rtag -b -r Release_to_be_branched_at desired_branch_name project_name
For permanent command options
edit .cvsrc file in home directory
e.g.:
diff -c
update -P
cvs -q
the cvs -q part is a global option
getting snapshots
By Date
cvs -q update -D "2003-09-22"
this means the first moment of September 22nd, 2003, to get stuff up tp 1:00 that afternoon:
cvs -q update -D "2003-09-22 13:00:00 GMT"
don't forget the GMT!
updating with -D will give you a sticky date that your working directory will remember until you run with -A or a different -D
You cannot check in changes with a sticky date, but you can diff them:
cvs -q diff -c -r 1.5 index.php
Adding a tag
tag marks a certain point in time in the development process
cvs -q tag "Test_Release-2003_09_22"
tag must start with letter and consist of letters, digits, hyphens, and undescores ([a-z][A-Z][0-9]-_)
Checking out a separate working copy at a tag
move to a new directory (not in existing working copy or parent directory)
cvs -d (CVS_ROOT information) checkout -r release_name project_name
Comparing current state to tagged state:
cvs diff -c -r Release_Name file name
Revert temporarily to tag:
cvs update -r Release_Name [filename]
(cannot check in changes to a release unless it is a branch [branches discussed next time])
as before update with -A option or a different revision or date to lose or change sticky option
an example of what I did to make this happen:
first make sure that you know which revision you want, check it out temporarily and have a look at it. I wanted revision 1.20 of the file en/2004/exhibitors/f-inf_promotion.html
so first I ran cvs update with the -p parameter to write it to standard output
cvs up -p -r 1.20 en/2004/exhibitors/f-inf_promotion.html
This was how I wanted it the first time, because I have my .cvsrc file set up to always add the -q tag to my cvs commands. If you don't have this then you will see some cruft before the contents of your file. This is exactly why we ran the file this way first. (In actuality the extra cruft that not using -q produces is harmless and wouldn't actually go into your file, but I always feel safer making sure it isn't there)
(you would run it like this to fix it):
cvs -q up -p -r 1.20 en/2004/exhibitors/f-inf_promotion.html
after you have verified that what is being printed to your screen is exactly what you want as the contents of your file you will direct this output into the file itself:
cvs up -p -r 1.20 en/2004/exhibitors/f-inf_promotion.html > en/2004/exhibitors/f-inf_promotion.html
Now just check in, and you are back to the desired version of the file.
setting up connection type:
CVS_RSH=ssh; export CVS_RSH
setting up repository location: CVSROOT=:ext:user@hostname:/usr/local/cvsrep; export CVSROOT
One doesn't need to set up the CVSROOT except for use in import and checkout, so one can just as easily use the cvs -d option
This uses the following form:
cvs -d :ext:user@hostname:/usr/local/cvsrep command
to import a project:
change to project directory
cvs import -m "log msg" projname vendortag releasetag
vendor tag and release tag usually don't matter, use username and start
checking out a working copy:
cvs checkout projname
If you want to check it out into a directory different than the project name:
cvs co -d directory project
Contents of CVS directory:
Root = location of cvs repository
Repository = location of project repository
Entries = details of individual files in directory (filename/revision number/datestamp//)
other stuff (no time to be specific):
cvs -q update [filename] = get latest versions
cvs -Q diff -c [filename] = find the differences between versions
cvs commit -m "log message" [filename] OR cvs ci etc = commit changes to repository
cvs status [filename] = get the status of the local file in relation to repository
cvs log [filename] = get log of cvs activity
to undo change:
(slow unwieldy method)
cvs -Q update -p -r {version number to revert to} {filename} > filename
cvs update
cvs -Q diff -c
check for accuracy of change
cvs ci -m "revert message"
adding files to project:
cvs add filename
cvs ci -m "log msg" filename
adding directory to project:
mkdir dirname
cvs add dirname
removing files from project:
rm filename
cvs remove filename
cvs ci -m "removal message" filename
removing directory from project:
remove all files from directory
cvs remove removed files
cvs ci -m "remove massage" filename(s)
cd ..
cvs update -P (P prunes empty directories)
(plain update doesn't bring in new directories occasionally should run update -d
Renaming Files and Directories
File
mv oldname newname
cvs remove oldname
cvs add newname
cvs ci -m "rename msg" olfname newname
Directory
mkdir newdir
cvs add newdir
mv olddir/* newdir
mv: newdir/CVS: cannot overwrite directory
cd olddir
cvs rm filenames
cd ../newdir
cvs add filenames
cd ..
cvs commit -m "move message"
cvs update -P