Stable CVS Version 1.11.23 Released, What’s new in Perforce CVS 2011.1, let’s find?

stable-cvs-version-1.11.23

Stable CVS 1.11.23 has been released. Stable releases contain only bug fixes from previous versions of CVS. This version includes an efficiency fix that reduces checkouts of very old revisions from an O(n^2) operation to an O(n) one, as well as yet another Windows file time stamp handling fix (bug #22781), and some other minor fixes and efficiency improvements. We recommend this upgrade for all CVS clients and servers!

Please take a look at the NEWS file from the CVS source distribution and the CVS 1.11.23 manual for more information about the changes contained in this release.

CVS can be downloaded from the GNU download server within four hours of this announcement or one of the mirrors after 24 hours or so (make sure to check the ”’non-gnu”’ directory on the mirrors). (This release may be obtained from Savannah download server prior to appearing on the GNU download server, but please don’t use the already heavily loaded Savannah download server unless you have to.) For other ways to obtain CVS, please read How to get GNU Software.

URL: http://savannah.nongnu.org/projects/cvs

Tagged : / / / / / / / / / / / / / / / / / / / /

How to configure and use SSH authentication system server CVS

ssh-with-cvs

How to configure and use SSH authentication system server CVS

cvs (Concurrent Version System) is a very popular version control tool. Although its function as Perforce, Subversion and other powerful, but because of its easy configuration, simple to use and the introduction of longer, so in all a kind of software project widely used.

first is to install FreeBSD, and application security patches. This step is very simple, download a FreeBSD (the upcoming 5.2-RELEASE is a good choice, in this article was published, this version may have been able to download a) of the mini iso burning CD-ROM, then you can install the (choose “Minimum” installation). Note that, in order to be able to use ssh authentication, be sure to install the crypto. Configure the network for this machine, so after the restart just fine.

then install the necessary package. FreeBSD 4.x built-in perl, but in 5.x in, perl be deleted from the basic system. In order to better use, including ACL, commit mail, and a number feature, you must install perl.

I personally recommend using the ports in the 5.8.x version of perl. Before installing, first of all convinced that the system does not perl 5.6.x installed, the new system, they can safely execute the following command:

This will remove the existing any package. In general, the majority of FreeBSD users use cvsup to update the system, but the release of the CD, cvsup-without-gui is not included, while the ordinary cvsup package requires a series of X11 libraries. To avoid trouble, consider the following two different ways to complete the first code update:

1, using the FreeBSD’s cvs to synchronize code:

cvs-d: pserver: anoncvs@anoncvs.jp.FreeBSD.org: / home / ncvs login

enter “anoncvs”, Enter

cd / usr

cvs-R-d: pserver: anoncvs@anoncvs.jp.FreeBSD.org: / home / ncvs export-r RELENG_5_2 src ports

Note: If you are not using 5.2-RELEASE, please make appropriate amendments to RELENG_5_2 (for example ,4-STABLE is RELENG_4, – CURRENT is the HEAD, etc.)

2, install cvsup-without-gui:

pkg_add-r cvsup-without-gui

then use cvsup to synchronize code, space is limited, I will not repeat them

I recommend the first method, of course, the second method should be faster, and does not require manually compiling cvsup. Subsequently, the installation of Perl 5.8.x:

cd / usr / ports / lang / perl5.8 & & make all install clean & & rehash

Then we will face a very serious problem: ports inside use.perl script does not know the system had not installed perl, so the time to be wrong in the implementation – this time, just make a symbolic link to perl on it. Well, the implementation:

use.perl port

This script will help you complete use.perl modify configuration files (such as / etc / make.conf) and a series of work. Here is not the table, a little profile about OpenSSH (sshd) configuration, in general, add the following two lines:

Protocol 2

PasswordAuthentication no

the benefits of doing so: ( 1) only allow ssh2 protocol log, which can provide better security (2) does not allow password login, which no doubt will increase security.

1, create a cvs repository

Well, pre-configuration is basically over. Do not forget to create a user for the cvs group, for example, ncvs, as well as a cvs repository for the management of users, such as the repoman (which of course is ncvs that group), and then create a directory to save the cvs repository, in this case , we put it into / home / ncvs in:

rm-rf / home / ncvs

mkdir-p / home / ncvs

chown-R repoman: ncvs / home / ncvs

chmod-R 775 / home / ncvs

next step is to initialize the repository, and simple to implement:

su-l repoman

cvs-d / home / ncvs init

on it.

present, all the FreeBSD version of cvs are included in the safety of the existence of a small vulnerability, although this flaw only in local use, but we recommend that you put it back on is to find / usr / src / contrib / cvs / src / expand_path.c in

return current_parsed_root-> original;

line, turning it into a

return current_parsed_root-> directory;

Of course, the next step is to re-make world kernel of. Need to note is that if you are using a 5-CURRENT, also need to modify some code for it to reach 5.2-RELEASE as performance (-CURRENT in a large number of debugging options turned on), specific methods will not go into here.

2, the configuration commitmail and ACL

then configure cvs commitmail and ACL. I personally think that commitmail the team software development a very important thing to cvs, it is especially important because cvs is not atomic submit function, but commitmail just enough to make up for this.

FreeBSD development team used a very good perl script to complete commitmail function, while the hook they use cvs to achieve a simple access control function (ACL). I use the cvs repository based on FreeBSD’s CVSROOT, and made a few changes.

use the CVSROOT cover your CVSROOT, and you also need to freebsd directory mailsend.c which compiled the results into the / usr / local / bin (the script assumes that the CVSROOT in this matter). In addition, the CVSROOT need some modifications before it is put into use (for example, machine name, etc.). These settings can be found in the cfg_local.pm inside:

$ MAILADDRS = ‘cvs- all@example.org ‘;

commitmail this is the place to be sent to.

$ MAIL_BRANCH_HDR = “X-Phantasm-CVS-Branch”;

this is to be added to the commitmail head of information, if you use the mailing list, then it can help mailing list automatically sorted.

$ MAILBANNER = “The Phantasm Studio repository”;

this soon in commitmail said that they commit to which a repository.

if ($ hostname = ~ / ^ cvs \. Example \. Org $ / i)

commit to this is to determine the host name

$ CVSWEB_URL = “http://cvsweb.example.org/cgi-bin/cvsweb.cgi”;

This is cvsweb services at

a brief CVSROOT in the other documents

avail: the file used to control access to user group.

access: This file is used to control who can perform cvs operations.

exclude: This file is used to control those files do not need to check the cvs tag

options: this file used to control the commencement of cvs tag, for example, can define $ Phantasm $, etc.

3, configuration of users and restrict ssh permissions

ssh authentication using a more vexing question is, ssh means that users have a system account, and that they be able to log in.. If configured properly, they can get a shell, it is natural to be a potential security risk.

must therefore be very careful in handling the ssh cvs authentication issue. The underlying principle is: any action against the user, unless we allow them to do so.

create a user in accordance with the following rules:

user’s” primary “group is ncvs (This will not only restrict the user’s permission, so we can more easily control the other users in the cvs repository which can not be free to commit)

users do not use password authentication, which will ease because they do not properly set up ftp and other safety hazards caused by

still give the user a shell, the “shell” can be a perl script, it only allow the implementation of the beginning of the command cvs

then allow users to use openssh’s ssh-keygen to generate your own key pair. OpenSSH in most * BSD and Linux distributions can be found in, if the user uses the Windows Desktop, you need to install cygwin (in particular, the installation of net in OpenSSH), of course, the implementation of the command is the same:

ssh-keygen-t dsa-b 2048

for the paranoid security enthusiasts, can consider later in 2048 will be replaced by-b 4096. Of course, under the barrel theory, if you are a paranoid, then obviously you should be forced to use all the partners are also at least as long as your key:)

, the administrator should be user (committer) the key into the server, the user corresponding to the authorized_keys file in the folder inside. For example, one of my public key as follows:

ssh-dss AAAAB3NzaC1kc3MAAAEBAL +1 jinOw +86 RcTEaSM5/Hz4Lr9tIS0IQsX8ebo

TwLzWnqpOHRh2KBCGn/e0xGCIAai7PGz7c + SZCvrLiRvG9mCsMMMue8ZIL + QF4OAmMd

Cz8Qoyg0cc4YXImOd + UEpdOX29PC4aMAz28v/GO2yf58/Qa49Clfq1kHa/8q3IAgs9o

W95 / ArG + IWFOsN1Tv9nh4XJb5AQjpa5uMlB5SEmvKGTXQ2oYiRVIxL8vzHL6MtO/8×1

j8 + RioSH6FCpEXS7UJbYxE7vF3m5Fa5o6g2dIZewphsleOeHkvYJ442Hqvsly3p4 +4 N

dvim4bY2HMDha5r5zeTV8tTlOz4wQVgKyWoEAAAAVAINGzX7uU0vR8l63qhBhUeWGZt

C9AAABADWiO +9 bvV7DApsn08LR1eoEnMjJFQgEfGlbV + EvZHkO0bkHZAdRIKtVmgNUw

G6uufykkt2Tb + q5SbVNZkzeaFVv4ZMtnjSvEPIZrEXcQFFguGk1it5v5EYcmq4G8 + j1

BFTVHef4b1wMTSt11WtEz0LUYncuZ6LA48/WGTuZiSm8JkchgVm8HhR9NqjdeFJH8sO

RUhUBoxyWjo/hv7zFg7HqoJGzeNfrEhFg36psR2RDaRvSP0vN1W2q4j5OZy3gB6ZyVt

nsEPl1HELhlaCFifmdz1LVxDx + FyPy6wMsPQLTmB1g6N1J6PWy3qCTJ0NyQgarSt3 / A

TQ0InF1BOdJn8QAAAEAPb1OgswuMHdEsHk2ETZVmOKOkI9Rjf72vjZ3xG45iEbCH/7p

aTP8OQmJMW9FD4MHjdmtktPVYXDIa9Hj/IM44zhfMHEdKs9LlFUK5dBgNUps + yPj2Ns

Mr2rl771ODR0mB52FwrXm1FCmNTM7WQpFOEy/QhtZRpHK +7 / YZp7PBggt17Fw7rbjP2

zhWnZluoSKLgvfkhxhJuOMm/ElNJx2c + XHdxPqI3eR5UxzLNjDUNh59I8 + h + E69bFB3

b2uhKqziziHOQcqoH5r0Kud / DBBE79lU3mRUF8FQNygCRh/V3yFzed40rc0nF0PQpNZ

6zodDTJByrm6vX5wr2lI4RgA9w == bitripper@grimreaper.delphij.net

Description: public key is not allowed off-line, here is convenient for typesetting. We have just opened to the user shell, which is still potential pitfalls, so we tighten security in this regard, the public key by adding the following text before the project:

command = “/ usr / bin / cvs – allow-root = / home / ncvs server”

So, the whole line should look like this:

command =” / usr / bin / cvs – allow-root = / home / ncvs server “ssh-dss AAAAB

…… …………………..

X5wr2lI4RgA9w == bitripper@grimreaper.delphij.net

ssh this command means that up on the implementation of / usr / bin / cvs – allow-root = / home / ncvs server this command, and can only perform this command. Thus, unless there are loopholes in the cvs itself, otherwise, can not really cut out through ssh shell. – Allow-root limits the ability to use the repository, so users can not easily specify the other repository, thus trying to undermine the security will become more difficult. If you need multiple repository, you can specify the number of allow-root parameter.

be noted is that if users have multiple public key, you need to specify each public key before the command.

4, configuration cvsweb

configuration cvsweb is quite simple. First install the apache (I tried 1.3.x and 2.0.x), configure the ready, from the port which install cvsweb on it:

cd / usr / ports / devel / cvsweb & & make all installl clean

and then to modify it configuration file:

cd / usr / local / etc / cvsweb

vi cvsweb.conf

find

;

@ CVSrepositories = (

line, follow the example of an increase in following their own repository, For example:

‘ncvs’ => [‘ New CVS Repository ‘,’ / home / ncvs’],

write the number of how many, of course, @ CVSrepositories the first to directly access cvsweb.cgi when the repository.

in FreeBSD 5.1-CURRENT development process carried out by some of the changes caused by the ports in the cvsweb not normally call the cvs and rcs tools, which will cause it to not work properly. To solve this problem, can be found from the following web site the latest version of cvsweb:

http://www.freebsd.org/projects/cvsweb.html

the author of this writing, the latest cvsweb version is 2.9.1 beta. Before the installation, need to install the other two port:

cd / usr/ports/devel/p5-IPC-Run & & make all install clean

cd / usr/ports/net/p5-URI & & make all install clean

then downloaded tbz file unpack, copy to the appropriate location (cgi-bin and related images directory) can be used.

Tagged : / / / / / / / / / / / / / / /

Power Point PPT: Software Configuration Management And CVS

software-configuration-management-and-cvs

Power Point PPT: Software Configuration Management And CVS

Tagged : / / / / / / / / / / / / /

Power Point PPT: Version Control With CVS – Complete Guide

version-control-with-cvs

Power Point PPT: Version Control With CVS

 

Tagged : / / / / / / / / / / / / / /

CVS Configuration Procedure – Install CVS – CVS Setup Guide

cvs-configuration-install

CVS Configuration – Install CVS

  • Procedure #1:-

Use rpm or up2date or yum command to install cvs:

for Redhat Use:-

rpm -ivh cvs
OR#    up2date cvs
for fedora use:-

yum install cvs
For Debian Users:-

apt-get install cvs

Create a CVS user#
useradd cvs
#     passwd cvs

Above command will create a user cvs and group cvs with /home/cvs home directory.
Configure CVS

Open /etc/profile and append following line:# vi /etc/profile
Append following line:
 export CVSROOT=/home/cvs
Save the file and exit to shell promot.

Make sure your /etc/xinetd.d/cvs looks as follows:

# less /etc/xinetd.d/cvsOutput:

service cvspserver
{
disable            = no
socket_type    = stream
wait                = no
user                = cvs
group              = cvs
log_type          = FILE /var/log/cvspserver
protocol          = tcp
env                 = ‘$HOME=/home/cvsroot’
bind                = 192.168.1.100
log_on_failure  += USERID
port                = 2401
server             = /usr/bin/cvs
server_args     = -f –allow-root=/home/cvsroot pserver
}

Note: Replace 192.168.1.100 with your actual server IP address.

Restart xinetd:# service xinetd restartAdd users to this group (see this howto for more info)
# adduser username -g cvs

# passwd usernameClient configuration

Finally user can connect to this CVS server using following syntax:
$ export CVSROOT=:pserver:@:/home/cvs
$ cvs loginWhere,

* Login – username
* 192.168.1.100 – CVS server IP
——————————————

  • Procedure #2:-

——-
1st Set CVS in /etc/profile as
CVSROOT=$HOME
then
export CVSROOT in .bashrc file

2nd:-
Creat a cvs directory
mkdir -p /home/cvs
cs /home/cvs/
touch Entries
touch Root
touch Repository
touch Templet

then
vi Entries
(should be empty)
then save and close.
vi Repository
edit as “./”
then save and close
vi Root
it shoud contain your path name…
eg:- pwd >> Root
save and quit
Vi Templet
edit BugID:
save and close
3rd:-
On Shell prompt
cvs init
cvs checkout ./
cvs add
cvs commit or ci

and have a look bellow links too..

http://www.taursys.com/howto/cvs/
http://www.cyberciti.biz/faq/linux-setup-a-concurrent-versioning-system-cvs-howto/
http://www.cs.brandeis.edu/~guru/cvs.html
http://defindit.com/readme_files/cvs.html
http://www.taursys.com/howto/cvs/

if you are facing any problem then let me know..

Thanks,
-Amaresh

Tagged : / / / / / / / / / / / / /

How CVS will help to Realtime Developers ?

CVS Tips & Tricks

The CVS commands here assume that you are using the command line version of CVS. Tips and tricks for a specific CVS GUI are specific to each GUI and do not really belong here.

Viewing the commit log of a file.

$ cvs log filename

Show current status of a file.

The status command will show you the latest version, the version in your working directory and if your local copy has been modified.

$ cvs status filename

Performing a CVS diff

After developers have checked in updates to the code it may be beneficial to see what has changed, either to help solve bugs or to track changes. There are several option to do this.

  1. Perform a diff between complete branches:
$ cvs -q diff -u -r BRANCH1 -r BRANCH2
  1. Perform a diff between a single file in two branches:
$ cvs -q diff -u -r BRANCH1 -r BRANCH2 filename
  1. Perform a diff between different versions of a file:
$ cvs -q diff -u -r version1 -r version2 filename
  1. Perform a diff between working version and most up to date file in database:
$ cvs -q diff -u filename
  1. Perform a diff between working version and a specific database version:
$ cvs -q diff -u -r version filename

Retrieving CVS Information on Files

To retrieve the current version and other relevant information about a file run:

$ cvs status filename

To retrieve the entire change log pertaining to a file run:

$ cvs log filename

Retrieving CVS Files Based Upon Revision

To retrieve a file from CVS based upon a revision number perform the following:

$ cvs -q up -Pd -r revision filename
  • To get the revision number use the log command above

Tag file in CVS as a Release

To tag files in CVS as a release perform the following:

$ cvs tag
  • Run the command from within the release source dir.

Creating a Branch

I like to do the following before creating a branch:

See what tags are available and pick one.

$ cvs -q log filename

Revert to a tagged version of HEAD.

$ cvs -q up -r TAG_Version

To create a branch in CVS perform the following:

$ cvs tag -b

Run the command from within the release source dir. This should be done in the top level directory of the project. The chosen_branch is something like BRANCH_36_BUG_.

cvs -q up -r
$ cvs -q status <– confirm that the branch has specified as the tag
$ cvs tag _mm_day_year <– eg: BRANCH_12_BUG_12345_07_17_2009

Reverting to a Branch

To revert to a branch in CVS perform the following:

$ cvs -q up –r
  • Run the command from within the release source dir. This should be done in the top level directory of the project. The chosen_branch is something like BRANCH_BUG_.

Verifying you are in a branch

To verify you are in a branch

$ cvs -q status

You will see that the branch is a sticky tag.

Merge Current Branch with HEAD

Ensure that you are in the branch by reverting to the branch and Verifying that you are in the branch.

$ cvs update -j

This will ensure that you are your branch is getting merged properly with HEAD so the only differences you see between your branch and the are changes that you made. You can verify this from your branch with:

$ cvs -q diff -u -r | less

You will eventually have to commit your changes you should always do a tag on the branch after your commit.

$ cvs tag

Merge HEAD into Current Branch Multiple Times (with tags) and without -kk option

$ cvs update -j -j

This command will unfortunenately result in a lot of your ID tags getting changed at the top. Using the –kk option will avoid this problem. But then you won’t see which files have changed and You won’t know who last modified a file easily. After you run this command I recommend:

$ vim `cvs up -d | grep '^C' | sed -e 's/^C //'`

You may find the following page interesting as well: http://kb.wisc.edu/middleware/page.php?id=4087

This will grab all of the conflicting files. You can save them with :w. And step through them with :bn. You can easily close them all with :wq!.

Merge HEAD into Current Branch Multiple Times (with tags)

To merge current HEAD into a branch that has already had HEAD merged into it once, the differences between that last merge and current HEAD need to be gathered and applied to the branch. This is done by finding out when the last time HEAD was merged with the branch. Hopefully you tagged your branch. Repeat steps 1 and 2 from the previous section to create a tag for HEAD and to create a tag for your branch so you can have a backup/reference point. Then, perform the following if you have tagged the branch when merging the last time:

$ cvs update -kk -j -j
  • Run the command from within the branched version. is the old tag in HEAD from the last time you merged (the tag that you created in Step one from the previous section). If you in this case, the format will likely be the following:
$ cvs update -kk -j UPDATE_HEAD_36_BUG__06_16_2008 -j UPDATE_HEAD_36_BUG__07_23_2008

The first tag is the one created the last time HEAD was merged into the branch. The second tag is one that should have been just created. This will take all the differences between the two tags, and bring them into the branch. The next time a merge from HEAD into the branch occurs, this latest tag will be the “old” tag, and the new tag will be created at the time of the merge.

The reason for tagging the branch before a join/merge like this is to create a reference point to revert to if the need ever arises. The -kk option removes rcsid tags so that the cvs tag at the top doesn’t get flagged as a conflict on every merge/join.

Merge HEAD into Current Branch Multiple Times (without tags)

If no tags have been created for the branch when HEAD was merged into a branch at a previous time, an alternative is to use the daily build tag. Find the commit message of the last time HEAD was merged into the branch and was committed and select the daily build tag the day BEFORE that one (but only if the commit was before the daily build that day, i.e. before lunch time for GMT -06:00). An example is provided below on how to merge without tagging:

$ cvs update -kk -j Tag_Branch -j HEAD>

Run the command from within the branched version.

———————————-
To Avoide network confusion :-

use :- alias cvs=`cvs -z9`

causes cvs to use compression level 6.

Good links for it:-

Tagged : / / / / / / / / /

List of 5 Common Problems in CVS – Troubleshooting Guide

cvs-common-problems

List of 5 Common Problems in CVS – Troubleshooting Guide

  • Problem 1:- How will we modify our conflict occurred files ?

While updating if you will get message like bellow, then check,

This will list:

* “A filename” for files that you added
* “M filename” for files that you modified
* “C filename” for files that have conflicts

Conflicts are files that you modified and that were modified on the head revision as well.

@ If u ll get C or conflict then go to that file and remove that lines and duplicate line then it will recover, it because, if more than two developer working on same file and comming on same time then conflict occures,

Files with conflicts will have conflict markers in them. Conflict markers look like:

<<<<<<< filename
your lines
=======
other person’s lines
>>>>>>> current version

  • Problem 2:-

If you are using your colleague’s checked out code for some changes, after that If you made any changes in code and then if you will try to check-in the code in CVS from your machine,after that if  it will ask your colleague’s password for checking-in. So How will we resolve this one ?


Soln:-
Please fine the CVS dir on your present code directory, then go to CVS dirctory, there, you will find Entries, Root, Repository like files , So now open that Rot file and change that username then your problem will solve, else let me know.
Steps:
cd CVS
vim Root
edit present urername to your username
@cvs:
:wq   // save and quit
cd ..  // come to parent directory
then do your work ..
it will fine

  • Problem 3:-
    Is there any way to identify the information of deleted lines in a file through CVS annotate or any other means?

Soln:-

         You deleted from CVS or local server ? if u deleted from both server then i have to see, else if u deleted from      either local server or CVS server  then do “cvs -q up -Pd  “

else do cvs -q up -Pd -r  ” .

  •  Problem4:-

           When I view the “cvs log”, the log report is fetching the file but says

            “date: 2008/12/31 06:00:51;  author: amareshcd;  state: Exp;  lines: +0 -0”
But I have added with 130 lines. Why the log is not showing “+130 -0” in its report.   ?

Soln:-

Use ,“cvs log -d date1 logfile.log”

  •  Problem5:-

        I have files that went into the Attic.  How do I restore them back? Viewing  the files  revealed that they’re in DEAD State. Someone has ‘cvs remove’d the files. Just restore them with ‘cvs add’. How ?

Soln:-

Step1:-
cvs log
Step2:-
Find til newest non-dead version
step 3:-
cvs update -r
step4:-
mv foo
step 5:-
cvs update -A
step 6:-
mv foo
step 7:-
cvs add
step 8:-
cvs commit -m “bring out your dead”

Tagged : / / / / / / / / / / / / / / / / / / / / / / /

How CVS will help to Realtime Developers ?

how-cvs-will-help-to-realtime-developers

CVS Tips & Tricks

The CVS commands here assume that you are using the command line version of CVS. Tips and tricks for a specific CVS GUI are specific to each GUI and do not really belong here.

Viewing the commit log of a file.

$ cvs log filename

Show current status of a file.

The status command will show you the latest version, the version in your working directory and if your local copy has been modified.

$ cvs status filename

Performing a CVS diff

After developers have checked in updates to the code it may be beneficial to see what has changed, either to help solve bugs or to track changes. There are several option to do this.

  1. Perform a diff between complete branches:
$ cvs -q diff -u -r BRANCH1 -r BRANCH2
  1. Perform a diff between a single file in two branches:
$ cvs -q diff -u -r BRANCH1 -r BRANCH2 filename
  1. Perform a diff between different versions of a file:
$ cvs -q diff -u -r version1 -r version2 filename
  1. Perform a diff between working version and most up to date file in database:
$ cvs -q diff -u filename
  1. Perform a diff between working version and a specific database version:
$ cvs -q diff -u -r version filename

Retrieving CVS Information on Files

To retrieve the current version and other relevant information about a file run:

$ cvs status filename

To retrieve the entire change log pertaining to a file run:

$ cvs log filename

Retrieving CVS Files Based Upon Revision

To retrieve a file from CVS based upon a revision number perform the following:

$ cvs -q up -Pd -r revision filename
  • To get the revision number use the log command above

Tag file in CVS as a Release

To tag files in CVS as a release perform the following:

$ cvs tag
  • Run the command from within the release source dir.

Creating a Branch

I like to do the following before creating a branch:

See what tags are available and pick one.

$ cvs -q log filename

Revert to a tagged version of HEAD.

$ cvs -q up -r TAG_Version

To create a branch in CVS perform the following:

$ cvs tag -b

Run the command from within the release source dir. This should be done in the top level directory of the project. The chosen_branch is something like BRANCH_36_BUG_.

cvs -q up -r
$ cvs -q status <– confirm that the branch has specified as the tag
$ cvs tag _mm_day_year <– eg: BRANCH_12_BUG_12345_07_17_2009

Reverting to a Branch

To revert to a branch in CVS perform the following:

$ cvs -q up –r
  • Run the command from within the release source dir. This should be done in the top level directory of the project. The chosen_branch is something like BRANCH_BUG_.

Verifying you are in a branch

To verify you are in a branch

$ cvs -q status

You will see that the branch is a sticky tag.

Merge Current Branch with HEAD

Ensure that you are in the branch by reverting to the branch and Verifying that you are in the branch.

$ cvs update -j

This will ensure that you are your branch is getting merged properly with HEAD so the only differences you see between your branch and the are changes that you made. You can verify this from your branch with:

$ cvs -q diff -u -r | less

You will eventually have to commit your changes you should always do a tag on the branch after your commit.

$ cvs tag

Merge HEAD into Current Branch Multiple Times (with tags) and without -kk option

$ cvs update -j -j

This command will unfortunenately result in a lot of your ID tags getting changed at the top. Using the –kk option will avoid this problem. But then you won’t see which files have changed and You won’t know who last modified a file easily. After you run this command I recommend:

$ vim `cvs up -d | grep '^C' | sed -e 's/^C //'`

You may find the following page interesting as well: http://kb.wisc.edu/middleware/page.php?id=4087

This will grab all of the conflicting files. You can save them with :w. And step through them with :bn. You can easily close them all with :wq!.

Merge HEAD into Current Branch Multiple Times (with tags)

To merge current HEAD into a branch that has already had HEAD merged into it once, the differences between that last merge and current HEAD need to be gathered and applied to the branch. This is done by finding out when the last time HEAD was merged with the branch. Hopefully you tagged your branch. Repeat steps 1 and 2 from the previous section to create a tag for HEAD and to create a tag for your branch so you can have a backup/reference point. Then, perform the following if you have tagged the branch when merging the last time:

$ cvs update -kk -j -j
  • Run the command from within the branched version. is the old tag in HEAD from the last time you merged (the tag that you created in Step one from the previous section). If you in this case, the format will likely be the following:
$ cvs update -kk -j UPDATE_HEAD_36_BUG__06_16_2008 -j UPDATE_HEAD_36_BUG__07_23_2008

The first tag is the one created the last time HEAD was merged into the branch. The second tag is one that should have been just created. This will take all the differences between the two tags, and bring them into the branch. The next time a merge from HEAD into the branch occurs, this latest tag will be the “old” tag, and the new tag will be created at the time of the merge.

The reason for tagging the branch before a join/merge like this is to create a reference point to revert to if the need ever arises. The -kk option removes rcsid tags so that the cvs tag at the top doesn’t get flagged as a conflict on every merge/join.

Merge HEAD into Current Branch Multiple Times (without tags)

If no tags have been created for the branch when HEAD was merged into a branch at a previous time, an alternative is to use the daily build tag. Find the commit message of the last time HEAD was merged into the branch and was committed and select the daily build tag the day BEFORE that one (but only if the commit was before the daily build that day, i.e. before lunch time for GMT -06:00). An example is provided below on how to merge without tagging:

$ cvs update -kk -j Tag_Branch -j HEAD>

Run the command from within the branched version.

———————————-
To Avoide network confusion :-

use :- alias cvs=`cvs -z9`

causes cvs to use compression level 6.

Good links for it:-

  • http://datagrams.blogspot.com/2009/01/how-to-deploy-cvs-concurrent-versions.html
  • http://kb.wisc.edu/middleware/page.php?id=4087
  • http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_10.html#SEC85
  • http://ximbiot.com/cvs/wiki/Special/Index
  • More Help!!

Refer for more on This:-

          Click Me!!

Thanks,

-Amaresh Das

Tagged : / / / / / / / / / / / /

What are the Best Practices of CVS?

cvs-best-practices

CVS Best Practices

 

These are list of CVS Best Practices:

* Don’t share workspaces

Sharing workspaces compromises CVS’s ability to track activity by user or task.

* Don’t work outside of managed workspaces

CVS can only track work in progress when it takes place within managed workspaces. Never copy files from others sandboxes or even from outside your sandbox since you may overwrite somebody else’s code.

* Don’t use jello views

A file in your workspace should not change unless you explicitly cause the change. A “jello view” is a workspace where file changes are caused by external events beyond your control e.g. workspace built upon a tree of symbolic links to files in another workspace.

* Stay in sync with the codeline

The quality of your work depends largely on how well it meshes with others work. In other words, as changes are checked into the codeline, you should update your workspace and integrate those changes with yours. Update your code at least once in the morning daily.

* Checkin code daily

Integrating your development work with other peoples’ work also requires you to check in your changes regularly. Don’t keep your new code lying in your workspace for many days at a time. This may lead to many conflicts at a later stage when you try to merge.

* Never check in without compiling and testing your code

* Always update your modules/ files and resolve any conflicts before committing

* After committing changes, diff with previous version to make sure you did not accidentally overwrite anybody else’s code

* If you overwrite somebody else’s code, rollback

* Always communicate any changes you commit, to all those concerned with the module/ file that was changed

* Always add comments when committing changes

Good and meaningful comments make it easy for others to know exactly what was changed. For e.g. if it’s a bug fix it should have a Bug Number.

* Add whitespaces with discretion

Changes to whitespaces cause unnecessary updates to happen and may show conflicts during merges

Tagged : / / / / / / / / / / / / / / /

Introduction to CVS | Know ABout CVS | Quick Start Guide

cvs-introduction

Introduction to CVS

CVS is a version control system, an important component of Source Configuration Management (SCM). Using it, you can record the history of sources files, and documents. It fills a similar role to the free software RCS, PRCS, and Aegis packages.
CVS is a production quality system in wide use around the world, including many free software projects.
While CVS stores individual file history in the same format as RCS, it offers the following significant advantages over RCS:

  • It can run scripts which you can supply to log CVS operations or enforce site-specific polices.
  • Client/server CVS enables developers scattered by geography or slow modems to function as a single team. The version history is stored on a single central server and the client machines have a copy of all the files that the developers are working on. Therefore, the network between the client and the server must be up to perform CVS operations (such as checkins or updates) but need not be up to edit or manipulate the current versions of the files. Clients can perform all the same operations which are available locally.
  • In cases where several developers or teams want to each maintain their own version of the files, because of geography and/or policy, CVS’s vendor branches can import a version from another team (even if they don’t use CVS), and then CVS can merge the changes from the vendor branch with the latest files if that is what is desired.
  • Unreserved checkouts, allowing more than one developer to work on the same files at the same time.
  • CVS provides a flexible modules database that provides a symbolic mapping of names to components of a larger software distribution. It applies names to collections of directories and files. A single command can manipulate the entire collection.
  • CVS servers run on most unix variants, and clients for Windows NT/95, OS/2 and VMS are also available. CVS will also operate in what is sometimes called server mode against local repositories on Windows 95/NT.
Tagged : / / / / / / / / / / / / /