There are few links and tools available which will help to migrate from CVS to Subversion (SVN). Plz have alook on this and let me know yours issues.

www.apache.org/dev/cvs2svn.html
cvs2svn.tigris.org/
sam.zoy.org/writings/programming/svn2cvs.html
onlamp.com/pub/a/onlamp/2005/10/03/cvs-t…on-with-cvs2svn.html
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

The post Migration of CVS to Subversion appeared first on scmGalaxy.

Key Features

The post Top 5 Open Source Code Management tools appeared first on scmGalaxy.

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

The post Stable CVS Version 1.11.23 Released, What’s new in Perforce CVS 2011.1, let’s find? appeared first on scmGalaxy.

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.

The post How to configure and use SSH authentication system server CVS appeared first on scmGalaxy.

Power Point PPT: Software Configuration Management And CVS

The post Power Point PPT: Software Configuration Management And CVS appeared first on scmGalaxy.

Power Point PPT: Version Control With CVS

The post Power Point PPT: Version Control With CVS – Complete Guide appeared first on scmGalaxy.

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

The post CVS Configuration Procedure – Install CVS – CVS Setup Guide appeared first on scmGalaxy.

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.

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.

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:

1. Perform a diff between a single file in two branches:

1. Perform a diff between different versions of a file:

1. Perform a diff between working version and most up to date file in database:

1. Perform a diff between working version and a specific database version:

Retrieving CVS Information on Files

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

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

Retrieving CVS Files Based Upon Revision

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

• 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:

• 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.

Revert to a tagged version of HEAD.

To create a branch in CVS perform the following:

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_.

Reverting to a Branch

To revert to a branch in CVS perform the following:

• 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

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.

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:

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

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

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:

• 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:

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:

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

The post How CVS will help to Realtime Developers ? appeared first on scmGalaxy.

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”

The post List of 5 Common Problems in CVS – Troubleshooting Guide appeared first on scmGalaxy.

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.

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.

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:

1. Perform a diff between a single file in two branches:

1. Perform a diff between different versions of a file:

1. Perform a diff between working version and most up to date file in database:

1. Perform a diff between working version and a specific database version:

Retrieving CVS Information on Files

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

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

Retrieving CVS Files Based Upon Revision

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

• 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:

• 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.

Revert to a tagged version of HEAD.

To create a branch in CVS perform the following:

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_.

Reverting to a Branch

To revert to a branch in CVS perform the following:

• 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

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.

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:

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

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

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:

• 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:

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:

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

The post How CVS will help to Realtime Developers ? appeared first on scmGalaxy.

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

The post What are the Best Practices of CVS? appeared first on scmGalaxy.

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

The post CVS Best Practices – List of CVS Best Practices – CVS Tips appeared first on scmGalaxy.

Share common projects with two different projects in CVS If there are two or more projects in the repository, some of the files are common in these two projects and some are different.How to share the files that are same between these projects? How can archive this? How Changes in common files be reflected to both projects. Version of CVS 2.5.03  

Answer: The CVSROOT/modules2 file or the older CVSROOT/modules file can help with this sort of thing:

http://cvsnt.org/manual/html/Administrative-files.html#modulesOrhttp://cvsnt.org/manual/html/modules2.html  

Generally the best CM independent solution is to organise your project source code hierarchy within the CM tool in such a way that ‘common’code is in a project/module/directory of it’s own so it can be checked out and managed independently of other projects, ie:  

/repo/proja 

/repo/projb 

/repo/common 

Then you define a module where ‘projecta’ = ‘proja’+’common’ so when a person does ‘cvs co projecta’ they  get: 

/projecta/proja 

/projecta/common 

If your server is running on Linux then you can ‘cheat’ by simply symbolically linking the RCS file into two directories (though this may cause locking conflicts if the files are very busy).   

Thanks to:Arthur Barrett 

The post Share common projects with two different projects in CVS appeared first on scmGalaxy.

Advantages of CVSNT over CVS

The post Benefits of CVSNT, What are the advantages of CVSNT over CVS ? appeared first on scmGalaxy.

Major differences between CVS and CVSNT | CVS Vs CVSNT

CVSNT was started as a variation (or branch) of CVS in 1999 because patches contributed to CVS were not considered to be suitable for that project by those responsible for making such decisions at that time.
CVSNT has continued to add features to the original CVS that support modern version control and configuration management best practice as well as maintain feature parity with CVS.
Today CVSNT is the most widely deployed version of CVS and is distributed with TortoiseCVS and WinCVS.

Similarities between CVS and CVSNT

• From a SCM perpective, they share similarity in purpose, Commands including syntax and functionality
• Both are freeware
• Both can be accessed through clients.
• Both are supported with Unix-like, Windows, Mac OS X

Difference between CVS and CVSNT

• An alternative to CVS with advance features and support
• CVS is being maintained but new features are not being added henceforth CVSNT is being maintained and new features are under development.
• CVS is having only merge function instead of CVSNT is having merge and locking system as well.
• CVS is having limited features than CVSNT

The post Major differences between CVS and CVSNT | CVS Vs CVSNT appeared first on scmGalaxy.