WorkingWithCVS - Revision history

Valavanisalex: update git link

2017-06-22T15:56:04Z

update git link

← Older revision		Revision as of 15:56, 22 June 2017
Line 1:		Line 1:
	'''This page is obsolete; please see [[Working with ~~Bazaar~~]] for current version control procedure.'''		'''This page is obsolete; please see [[Working with Git]] for current version control procedure.'''

	== CVS Basics ==		== CVS Basics ==

Frigory: Category:Wiki Attic

2016-07-10T04:25:52Z

Category:Wiki Attic

← Older revision		Revision as of 04:25, 10 July 2016
Line 1:		Line 1:
	='''This page is obsolete please see [[~~WorkingWithSVN~~]] for current version control procedure'''=		'''This page is obsolete; please see [[Working with Bazaar]] for current version control procedure.'''

	== CVS Basics ==		== CVS Basics ==
Line 193:		Line 193:

	The actual removal will not take effect until you commit.		The actual removal will not take effect until you commit.

			[[Category:Wiki Attic]]

Colin Marquardt: Reverted edits by QqqAje (Talk); changed back to last version by GigaClon

2007-04-20T15:39:34Z

Reverted edits by QqqAje (Talk); changed back to last version by GigaClon

← Older revision		Revision as of 15:39, 20 April 2007
Line 56:		Line 56:
	Developers who have been given write access (access to the master repository) will need to have ssh installed, and set their [[CVS_RSH]] environment variable to '''ssh'''.		Developers who have been given write access (access to the master repository) will need to have ssh installed, and set their [[CVS_RSH]] environment variable to '''ssh'''.

	To avoid being prompted for your Sourceforge password every time you run a CVS command on the master repository, you will probably want [http://sourceforge.net/docman/display_doc.php?docid=761		To avoid being prompted for your Sourceforge password every time you run a CVS command on the master repository, you will probably want [http://sourceforge.net/docman/display_doc.php?docid=761&group_id=1 to upload an SSH key].

			If you've been doing work in a codebase checked out as anonymous, you can convert it to your developer account with a little work. Essentially, you need to recursively convert all of the CVS[[/Root]] files in the tree from the anonymous user to your username. Alternatively, you can just create a diff and then patch it over.

			==== How Do I Check Out a Working Copy? ====

			To check out a copy of Inkscape from the developer CVS, you may use the following command:

			cvs -z3 -d''repository'' checkout inkscape

			Here are what the options mean:

			-z3 is a general CVS option, and requests that communication with the server be compressed to save bandwidth. Recommended especially if you are on dialup.

			-d specifies the repository to check out from.

			"checkout" ("co" means the same thing) specifies the action to take (check out a working copy).

			"inkscape" is the name of the ''module'' (group of files and directories) that make up our project.

			==== Which Repository Do I Use? ====

			Most users will use the anonymous repository (''':pserver:anonymous@cvs.sourceforge.net:/cvsroot/inkscape'''), as shown above.

			If you are a developer who has been given CVS write access, the repository will be ''':ext:''username''@cvs.sourceforge.net:/cvsroot/inkscape''', where ''username'' is your sourceforge username.

			==== Now What? ====

			You should have a complete working copy in the '''inkscape''' directory. You can cd to it and try compiling.

			:Note: If it is a fresh checkout, you will need to run the ./autogen.sh shell script at the top level to create files needed to compile

			You should not need to specify the repository with -d in any CVS commands for this working copy. CVS remembers which repository a working copy came from.

			Note that a CVS command only applies to the current directory and (possibly) any subdirectories. Normally (particularly for updates, diffs, and checkins), you will want to run the command from the top level of the project.

			=== Bringing Your Working Copy Up-To-Date ===

			Your working copy will not automatically include changes others have made to the repository since you checked it out.

			To ''update'' your working copy, use this command:

			cvs -z3 update -Pd

			-P specifies to remove any directories that become empty as a result of the update

			-d creates any new directories introduced by the update

			=== Dealing with Conflicts ===

			If you've made changes to your working copy, what happens if you update after someone has commited changes to the same files?

			Normally, CVS can work this out on its own. Sometimes you have to help it along, though. If CVS says there were conflicts, look for which files have a ''C'' next to them in its progress output. Some of those may have unresolved conflicts. You can also search for '=======' in the files themselves to find any unresolved conflicts.

			<<<<<<< ''filename''
			The changes in your version will be here
			=======
			The changes the other person will be here
			>>>>>>> ''some version here''

			Sometimes you will keep one set of changes and discard the other, and sometimes you will combine the two. It will require a judgement call on your part either way. Talk to the person who made the other set of changes or ask on the mailing list if it's unclear what's going on. Remember that CVS is no substitute for communication.

			Also, always make sure to build and test after an update to make sure that the combined changes work as intended.

			=== Generating a Diff ===

			('''Always''' update before generating a diff!)

			From the top-level directory, run the command:

			cvs -z3 diff -u3 > filename

			-u3 specifies which format to use (a unified diff with three lines of context). This is the recommended diff format.

			This will create a file describing the changes you have made, though if you have created new files as part of your changes, you will need to include those separately too when emailing them to the list or another developer for inclusion.

			=== Automatic Commit Diff ===

			To always generate a diff when you commit to CVS, set the environment variable "CVSEDITOR" to the following script:

			#!/bin/bash
			# get rid of redhat 9 locale ugliness
			unset [[LC_CTYPE]]
			# Turn on ro access (to stop multiple locks) for local roots
			grep @ CVS[[/Root]] >/dev/null 2>&1 \|\| export CVSREADONLYFS=1
			# Tell the user what's going on
			echo Building diff...
			cvs diff -up 2>/dev/null \| perl -ne 'print "CVS: $_" unless /^\?/' >> "$1"
			exec ${EDITOR:-vi} "$1"

			If the above script is named "~/bin/cvsdiffvi", then assuming you run the bash shell, you can add the following your .bashrc file:

			export CVSEDITOR=~/bin/cvsdiffvi

			Now, every time you commit, the entire diff will be visible to you as you write your commit comments.

			=== Patching a Diff ===

			A diff file can be applied to the codebase using the 'patch' command.

			If the diff was made as <code>inkscape/src/thingy.cpp</code> and you're in the "inkscape" directory, you'll want to use the command:

			patch -p1 < thingy.diff

			Depending on how many path elements are part of the diff, you'll need to strip them with -p1, -p2, etc.

			=== Committing your Changes ===

			('''Always''' update before committing!)

			If you have write access to the repository, you can commit your changes like this:

			Before you commit, please make sure that you describe the changes you have made in the [[ChangeLog]] file at the top-level directory.

			cvs -z3 commit -m "Your description of your changes goes here"

			Tip: even if you are committing directly, you still might want to generate a diff. It's a good reference to look at when you're filling out the [[ChangeLog]], since it will remind you of all the changes you've made.

			=== Adding Files to the Repository ===

			To add new files as part of your commit, you will need to run:

			cvs -z3 add ''files and directories to add go here''

			Before you commit. This also goes for new directories.

			Except for directories, the actual addition or removal will not take effect until you commit.

			=== Removing Files from the Repository ===

			To remove files from the repository (they aren't actually removed, just marked as inactive), you will need to run:

			cvs -z3 remove ''files that were removed go here''

			The files will have to have been deleted from your working copy before CVS will let you do this.

			The actual removal will not take effect until you commit.

QqqAje at 19:36, 17 April 2007

2007-04-17T19:36:43Z

← Older revision		Revision as of 19:36, 17 April 2007
Line 56:		Line 56:
	Developers who have been given write access (access to the master repository) will need to have ssh installed, and set their [[CVS_RSH]] environment variable to '''ssh'''.		Developers who have been given write access (access to the master repository) will need to have ssh installed, and set their [[CVS_RSH]] environment variable to '''ssh'''.

	To avoid being prompted for your Sourceforge password every time you run a CVS command on the master repository, you will probably want [http://sourceforge.net/docman/display_doc.php?docid=761~~&group_id=1 to upload an SSH key].~~		To avoid being prompted for your Sourceforge password every time you run a CVS command on the master repository, you will probably want [http://sourceforge.net/docman/display_doc.php?docid=761

	If you've been doing work in a codebase checked out as anonymous, you can convert it to your developer account with a little work. Essentially, you need to recursively convert all of the CVS[[/Root]] files in the tree from the anonymous user to your username. Alternatively, you can just create a diff and then patch it over.

	~~==== How Do I Check Out a Working Copy? ====~~

	~~To check out a copy of Inkscape from the developer CVS, you may use the following command:~~

	~~cvs -z3 -d''repository'' checkout inkscape~~

	~~Here are what the options mean:~~

	~~-z3 is a general CVS option, and requests that communication with the server be compressed to save bandwidth. Recommended especially if you are on dialup.~~

	~~-d specifies the repository to check out from.~~

	~~"checkout" ("co" means the same thing) specifies the action to take (check out a working copy).~~

	~~"inkscape" is the name of the ''module'' (group of files and directories) that make up our project.~~

	~~==== Which Repository Do I Use? ====~~

	~~Most users will use the anonymous repository (''':pserver:anonymous@cvs.sourceforge.net:/cvsroot/inkscape'''), as shown above.~~

	~~If you are a developer who has been given CVS write access, the repository will be ''':ext:''username''@cvs.sourceforge.net:/cvsroot/inkscape''', where ''username'' is your sourceforge username.~~

	~~==== Now What? ====~~

	~~You should have a complete working copy in the '''inkscape''' directory. You can cd to it and try compiling.~~

	~~:Note: If it is a fresh checkout, you will need to run the ./autogen.sh shell script at the top level to create files needed to compile~~

	~~You should not need to specify the repository with -d in any CVS commands for this working copy. CVS remembers which repository a working copy came from.~~

	Note that a CVS command only applies to the current directory and (possibly) any subdirectories. Normally (particularly for updates, diffs, and checkins), you will want to run the command from the top level of the project.

	~~=== Bringing Your Working Copy Up-To-Date ===~~

	~~Your working copy will not automatically include changes others have made to the repository since you checked it out.~~

	~~To ''update'' your working copy, use this command:~~

	~~cvs -z3 update -Pd~~

	~~-P specifies to remove any directories that become empty as a result of the update~~

	~~-d creates any new directories introduced by the update~~

	~~=== Dealing with Conflicts ===~~

	~~If you've made changes to your working copy, what happens if you update after someone has commited changes to the same files?~~

	Normally, CVS can work this out on its own. Sometimes you have to help it along, though. If CVS says there were conflicts, look for which files have a ''C'' next to them in its progress output. Some of those may have unresolved conflicts. You can also search for '=======' in the files themselves to find any unresolved conflicts.

	~~<<<<<<< ''filename''~~
	~~The changes in your version will be here~~
	~~=======~~
	~~The changes the other person will be here~~
	~~>>>>>>> ''some version here''~~

	Sometimes you will keep one set of changes and discard the other, and sometimes you will combine the two. It will require a judgement call on your part either way. Talk to the person who made the other set of changes or ask on the mailing list if it's unclear what's going on. Remember that CVS is no substitute for communication.

	~~Also, always make sure to build and test after an update to make sure that the combined changes work as intended.~~

	~~=== Generating a Diff ===~~

	~~('''Always''' update before generating a diff!)~~

	~~From the top-level directory, run the command:~~

	~~cvs -z3 diff -u3 > filename~~

	~~-u3 specifies which format to use (a unified diff with three lines of context). This is the recommended diff format.~~

	This will create a file describing the changes you have made, though if you have created new files as part of your changes, you will need to include those separately too when emailing them to the list or another developer for inclusion.

	~~=== Automatic Commit Diff ===~~

	~~To always generate a diff when you commit to CVS, set the environment variable "CVSEDITOR" to the following script:~~

	~~#!/bin/bash~~
	~~# get rid of redhat 9 locale ugliness~~
	~~unset [[LC_CTYPE]]~~
	~~# Turn on ro access (to stop multiple locks) for local roots~~
	~~grep @ CVS[[/Root]] >/dev/null 2>&1 \|\| export CVSREADONLYFS=1~~
	~~# Tell the user what's going on~~
	~~echo Building diff...~~
	~~cvs diff -up 2>/dev/null \| perl -ne 'print "CVS: $_" unless /^\?/' >> "$1"~~
	~~exec ${EDITOR:-vi} "$1"~~

	~~If the above script is named "~/bin/cvsdiffvi", then assuming you run the bash shell, you can add the following your .bashrc file:~~

	~~export CVSEDITOR=~/bin/cvsdiffvi~~

	~~Now, every time you commit, the entire diff will be visible to you as you write your commit comments.~~

	~~=== Patching a Diff ===~~

	~~A diff file can be applied to the codebase using the 'patch' command.~~

	~~If the diff was made as <code>inkscape/src/thingy.cpp</code> and you're in the "inkscape" directory, you'll want to use the command:~~

	~~patch -p1 < thingy.diff~~

	~~Depending on how many path elements are part of the diff, you'll need to strip them with -p1, -p2, etc.~~

	~~=== Committing your Changes ===~~

	~~('''Always''' update before committing!)~~

	~~If you have write access to the repository, you can commit your changes like this:~~

	~~Before you commit, please make sure that you describe the changes you have made in the [[ChangeLog]] file at the top-level directory.~~

	~~cvs -z3 commit -m "Your description of your changes goes here"~~

	Tip: even if you are committing directly, you still might want to generate a diff. It's a good reference to look at when you're filling out the [[ChangeLog]], since it will remind you of all the changes you've made.

	~~=== Adding Files to the Repository ===~~

	~~To add new files as part of your commit, you will need to run:~~

	~~cvs -z3 add ''files and directories to add go here''~~

	~~Before you commit. This also goes for new directories.~~

	~~Except for directories, the actual addition or removal will not take effect until you commit.~~

	~~=== Removing Files from the Repository ===~~

	~~To remove files from the repository (they aren't actually removed, just marked as inactive), you will need to run:~~

	~~cvs -z3 remove ''files that were removed go here''~~

	~~The files will have to have been deleted from your working copy before CVS will let you do this.~~

	~~The actual removal will not take effect until you commit.~~

GigaClon: Obsolete

2006-06-19T03:55:46Z

Obsolete

← Older revision		Revision as of 03:55, 19 June 2006
Line 1:		Line 1:
			='''This page is obsolete please see [[WorkingWithSVN]] for current version control procedure'''=

	== CVS Basics ==		== CVS Basics ==

Conversion script: link fix

2006-01-22T02:33:51Z

link fix

New page

== CVS Basics ==

This node discusses the basics of using CVS. Also see [http://sourceforge.net/cvs/?group_id=93438 Checking out CVS modules on sourceforge.net]

For complete on information CVS, including the basics, see:
* The [http://cvsbook.red-bean.com/ Red Bean Book]
* [http://www.astro.umd.edu/~teuben/miriad/cvs.html CVS for BIMA]

For information on more advanced usage, see:
* [[WorkingWithCVSBranches]] - making branches and merging between them

=== Concepts ===

==== The Repository ====

CVS stores source code in a shared '''repository''' (in our case on Sourceforge's server). The repository contains all past and present versions of the code, and is shared by everyone.

==== Your Working Copy ====

To work with the source code, CVS requires you to '''check out''' a ''working copy''. This copy is private, so you can make and test any changes you like without disturbing anyone else.

If you have '''write access''' to the repository, when you are finished making your changes, you may '''commit''' your changes to the shared repository, making them available to everyone.

Alternately, you may generate a file containing the changes you made (a ''diff''), and send it to a developer with write access to be incorporated.

You can check out as many working copies as you want; they take up only your own disk space, and they are completely independent of each other.

If you no longer need a working copy, you may simply delete it.

=== Getting Started ===

==== Setting Up ====

===== Default Settings =====
Create a .cvsrc file in your home directory with the following contents:

cvs -z3 -q
diff -uNp
update -Pd
remove -f

===== Anonymous Access =====

Most developers will initially only have access to a read-only copy of the repository. You will need to run the following command once:

'''cvs -z3 -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/inkscape login'''

And then simply press enter when asked for a password (the password is blank).

Note that this read-only copy is normally ~24 hours behind the newest changes.

===== Write Access =====

Developers who have been given write access (access to the master repository) will need to have ssh installed, and set their [[CVS_RSH]] environment variable to '''ssh'''.

To avoid being prompted for your Sourceforge password every time you run a CVS command on the master repository, you will probably want [http://sourceforge.net/docman/display_doc.php?docid=761&group_id=1 to upload an SSH key].

If you've been doing work in a codebase checked out as anonymous, you can convert it to your developer account with a little work. Essentially, you need to recursively convert all of the CVS[[/Root]] files in the tree from the anonymous user to your username. Alternatively, you can just create a diff and then patch it over.

==== How Do I Check Out a Working Copy? ====

To check out a copy of Inkscape from the developer CVS, you may use the following command:

cvs -z3 -d''repository'' checkout inkscape

Here are what the options mean:

-z3 is a general CVS option, and requests that communication with the server be compressed to save bandwidth. Recommended especially if you are on dialup.

-d specifies the repository to check out from.

"checkout" ("co" means the same thing) specifies the action to take (check out a working copy).

"inkscape" is the name of the ''module'' (group of files and directories) that make up our project.

==== Which Repository Do I Use? ====

Most users will use the anonymous repository (''':pserver:anonymous@cvs.sourceforge.net:/cvsroot/inkscape'''), as shown above.

If you are a developer who has been given CVS write access, the repository will be ''':ext:''username''@cvs.sourceforge.net:/cvsroot/inkscape''', where ''username'' is your sourceforge username.

==== Now What? ====

You should have a complete working copy in the '''inkscape''' directory. You can cd to it and try compiling.

:Note: If it is a fresh checkout, you will need to run the ./autogen.sh shell script at the top level to create files needed to compile

You should not need to specify the repository with -d in any CVS commands for this working copy. CVS remembers which repository a working copy came from.

Note that a CVS command only applies to the current directory and (possibly) any subdirectories. Normally (particularly for updates, diffs, and checkins), you will want to run the command from the top level of the project.

=== Bringing Your Working Copy Up-To-Date ===

Your working copy will not automatically include changes others have made to the repository since you checked it out.

To ''update'' your working copy, use this command:

cvs -z3 update -Pd

-P specifies to remove any directories that become empty as a result of the update

-d creates any new directories introduced by the update

=== Dealing with Conflicts ===

If you've made changes to your working copy, what happens if you update after someone has commited changes to the same files?

Normally, CVS can work this out on its own. Sometimes you have to help it along, though. If CVS says there were conflicts, look for which files have a ''C'' next to them in its progress output. Some of those may have unresolved conflicts. You can also search for '=======' in the files themselves to find any unresolved conflicts.

<<<<<<< ''filename''
The changes in your version will be here
=======
The changes the other person will be here
>>>>>>> ''some version here''

Sometimes you will keep one set of changes and discard the other, and sometimes you will combine the two. It will require a judgement call on your part either way. Talk to the person who made the other set of changes or ask on the mailing list if it's unclear what's going on. Remember that CVS is no substitute for communication.

Also, always make sure to build and test after an update to make sure that the combined changes work as intended.

=== Generating a Diff ===

('''Always''' update before generating a diff!)

From the top-level directory, run the command:

cvs -z3 diff -u3 > filename

-u3 specifies which format to use (a unified diff with three lines of context). This is the recommended diff format.

This will create a file describing the changes you have made, though if you have created new files as part of your changes, you will need to include those separately too when emailing them to the list or another developer for inclusion.

=== Automatic Commit Diff ===

To always generate a diff when you commit to CVS, set the environment variable "CVSEDITOR" to the following script:

#!/bin/bash
# get rid of redhat 9 locale ugliness
unset [[LC_CTYPE]]
# Turn on ro access (to stop multiple locks) for local roots
grep @ CVS[[/Root]] >/dev/null 2>&1 || export CVSREADONLYFS=1
# Tell the user what's going on
echo Building diff...
cvs diff -up 2>/dev/null | perl -ne 'print "CVS: $_" unless /^\?/' >> "$1"
exec ${EDITOR:-vi} "$1"

If the above script is named "~/bin/cvsdiffvi", then assuming you run the bash shell, you can add the following your .bashrc file:

export CVSEDITOR=~/bin/cvsdiffvi

Now, every time you commit, the entire diff will be visible to you as you write your commit comments.

=== Patching a Diff ===

A diff file can be applied to the codebase using the 'patch' command.

If the diff was made as <code>inkscape/src/thingy.cpp</code> and you're in the "inkscape" directory, you'll want to use the command:

patch -p1 < thingy.diff

Depending on how many path elements are part of the diff, you'll need to strip them with -p1, -p2, etc.

=== Committing your Changes ===

('''Always''' update before committing!)

If you have write access to the repository, you can commit your changes like this:

Before you commit, please make sure that you describe the changes you have made in the [[ChangeLog]] file at the top-level directory.

cvs -z3 commit -m "Your description of your changes goes here"

Tip: even if you are committing directly, you still might want to generate a diff. It's a good reference to look at when you're filling out the [[ChangeLog]], since it will remind you of all the changes you've made.

=== Adding Files to the Repository ===

To add new files as part of your commit, you will need to run:

cvs -z3 add ''files and directories to add go here''

Before you commit. This also goes for new directories.

Except for directories, the actual addition or removal will not take effect until you commit.

=== Removing Files from the Repository ===

To remove files from the repository (they aren't actually removed, just marked as inactive), you will need to run:

cvs -z3 remove ''files that were removed go here''

The files will have to have been deleted from your working copy before CVS will let you do this.

The actual removal will not take effect until you commit.

VonHalenbach: *

2005-10-26T16:20:13Z

New page

== CVS Basics ==

This node discusses the basics of using CVS. Also see [http://sourceforge.net/cvs/?group_id=93438 Checking out CVS modules on sourceforge.net]

For information on more advanced usage, see:
* WorkingWithCVSBranches - making branches and merging between them

=== Concepts ===

==== The Repository ====

CVS stores source code in a shared '''repository''' (in our case on Sourceforge's server). The repository contains all past and present versions of the code, and is shared by everyone.

==== Your Working Copy ====

To work with the source code, CVS requires you to '''check out''' a ''working copy''. This copy is private, so you can make and test any changes you like without disturbing anyone else.

If you have '''write access''' to the repository, when you are finished making your changes, you may '''commit''' your changes to the shared repository, making them available to everyone.

Alternately, you may generate a file containing the changes you made (a ''diff''), and send it to a developer with write access to be incorporated.

You can check out as many working copies as you want; they take up only your own disk space, and they are completely independent of each other.

If you no longer need a working copy, you may simply delete it.

=== Getting Started ===

==== Setting Up ====

===== Default Settings =====
Create a .cvsrc file in your home directory with the following contents:

cvs -z3 -q
diff -uNp
update -Pd
remove -f

===== Anonymous Access =====

Most developers will initially only have access to a read-only copy of the repository. You will need to run the following command once:

'''cvs -z3 -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/inkscape login'''

And then simply press enter when asked for a password (the password is blank).

Note that this read-only copy is normally ~24 hours behind the newest changes.

===== Write Access =====

Developers who have been given write access (access to the master repository) will need to have ssh installed, and set their CVS_RSH environment variable to '''ssh'''.

To avoid being prompted for your Sourceforge password every time you run a CVS command on the master repository, you will probably want [http://sourceforge.net/docman/display_doc.php?docid=761&group_id=1 to upload an SSH key].

If you've been doing work in a codebase checked out as anonymous, you can convert it to your developer account with a little work. Essentially, you need to recursively convert all of the CVS/Root files in the tree from the anonymous user to your username. Alternatively, you can just create a diff and then patch it over.

==== How Do I Check Out a Working Copy? ====

To check out a copy of Inkscape from the developer CVS, you may use the following command:

cvs -z3 -d''repository'' checkout inkscape

Here are what the options mean:

-z3 is a general CVS option, and requests that communication with the server be compressed to save bandwidth. Recommended especially if you are on dialup.

-d specifies the repository to check out from.

"checkout" ("co" means the same thing) specifies the action to take (check out a working copy).

"inkscape" is the name of the ''module'' (group of files and directories) that make up our project.

==== Which Repository Do I Use? ====

Most users will use the anonymous repository (''':pserver:anonymous@cvs.sourceforge.net:/cvsroot/inkscape'''), as shown above.

If you are a developer who has been given CVS write access, the repository will be ''':ext:''username''@cvs.sourceforge.net:/cvsroot/inkscape''', where ''username'' is your sourceforge username.

==== Now What? ====

You should have a complete working copy in the '''inkscape''' directory. You can cd to it and try compiling.

:Note: If it is a fresh checkout, you will need to run the ./autogen.sh shell script at the top level to create files needed to compile

You should not need to specify the repository with -d in any CVS commands for this working copy. CVS remembers which repository a working copy came from.

Note that a CVS command only applies to the current directory and (possibly) any subdirectories. Normally (particularly for updates, diffs, and checkins), you will want to run the command from the top level of the project.

=== Bringing Your Working Copy Up-To-Date ===

Your working copy will not automatically include changes others have made to the repository since you checked it out.

To ''update'' your working copy, use this command:

cvs -z3 update -Pd

-P specifies to remove any directories that become empty as a result of the update

-d creates any new directories introduced by the update

=== Dealing with Conflicts ===

If you've made changes to your working copy, what happens if you update after someone has commited changes to the same files?

Normally, CVS can work this out on its own. Sometimes you have to help it along, though. If CVS says there were conflicts, look for which files have a ''C'' next to them in its progress output. Some of those may have unresolved conflicts. You can also search for '=======' in the files themselves to find any unresolved conflicts.

<<<<<<< ''filename''
The changes in your version will be here
=======
The changes the other person will be here
>>>>>>> ''some version here''

Sometimes you will keep one set of changes and discard the other, and sometimes you will combine the two. It will require a judgement call on your part either way. Talk to the person who made the other set of changes or ask on the mailing list if it's unclear what's going on. Remember that CVS is no substitute for communication.

Also, always make sure to build and test after an update to make sure that the combined changes work as intended.

=== Generating a Diff ===

('''Always''' update before generating a diff!)

From the top-level directory, run the command:

cvs -z3 diff -u3 > filename

-u3 specifies which format to use (a unified diff with three lines of context). This is the recommended diff format.

This will create a file describing the changes you have made, though if you have created new files as part of your changes, you will need to include those separately too when emailing them to the list or another developer for inclusion.

=== Automatic Commit Diff ===

To always generate a diff when you commit to CVS, set the environment variable "CVSEDITOR" to the following script:

#!/bin/bash
# get rid of redhat 9 locale ugliness
unset LC_CTYPE
# Turn on ro access (to stop multiple locks) for local roots
grep @ CVS/Root >/dev/null 2>&1 || export CVSREADONLYFS=1
# Tell the user what's going on
echo Building diff...
cvs diff -up 2>/dev/null | perl -ne 'print "CVS: $_" unless /^\?/' >> "$1"
exec ${EDITOR:-vi} "$1"

If the above script is named "~/bin/cvsdiffvi", then assuming you run the bash shell, you can add the following your .bashrc file:

export CVSEDITOR=~/bin/cvsdiffvi

Now, every time you commit, the entire diff will be visible to you as you write your commit comments.

=== Patching a Diff ===

A diff file can be applied to the codebase using the 'patch' command.

If the diff was made as <code>inkscape/src/thingy.cpp</code> and you're in the "inkscape" directory, you'll want to use the command:

patch -p1 < thingy.diff

Depending on how many path elements are part of the diff, you'll need to strip them with -p1, -p2, etc.

=== Committing your Changes ===

('''Always''' update before committing!)

If you have write access to the repository, you can commit your changes like this:

Before you commit, please make sure that you describe the changes you have made in the ChangeLog file at the top-level directory.

cvs -z3 commit -m "Your description of your changes goes here"

Tip: even if you are committing directly, you still might want to generate a diff. It's a good reference to look at when you're filling out the ChangeLog, since it will remind you of all the changes you've made.

=== Adding Files to the Repository ===

To add new files as part of your commit, you will need to run:

cvs -z3 add ''files and directories to add go here''

Before you commit. This also goes for new directories.

Except for directories, the actual addition or removal will not take effect until you commit.

=== Removing Files from the Repository ===

To remove files from the repository (they aren't actually removed, just marked as inactive), you will need to run:

cvs -z3 remove ''files that were removed go here''

The files will have to have been deleted from your working copy before CVS will let you do this.

The actual removal will not take effect until you commit.

195.177.212.225: Removed spam

2004-09-24T07:58:51Z

Removed spam

New page

== CVS Basics ==

This node discusses the basics of using CVS. Also see [http://sourceforge.net/cvs/?group_id=93438 Checking out CVS modules on sourceforge.net]

For information on more advanced usage, see:
* WorkingWithCVSBranches - making branches and merging between them

=== Concepts ===

==== The Repository ====

CVS stores source code in a shared ''repository'' (in our case on Sourceforge's server). The repository contains all past and present versions of the code, and is shared by everyone.

==== Your Working Copy ====

To work with the source code, CVS requires you to ''check out'' a ''working copy''. This copy is private, so you can make and test any changes you like without disturbing anyone else.

If you have write access to the repository, when you are finished making your changes, you may ''commit'' your changes to the shared repository, making them available to everyone.

Alternately, you may generate a file containing the changes you made (a ''diff''), and send it to a developer with write access to be incorporated.

You can check out as many working copies as you want; they take up only your own disk space, and they are completely independent of each other.

If you no longer need a working copy, you may simply delete it.

=== Getting Started ===

==== Setting Up ====

===== Anonymous Access =====

Most developers will initially only have access to a read-only copy of the repository. You will need to run the following command once:

cvs -z3 -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/inkscape login

And then simply press enter when asked for a password (the password is blank).

Note that this read-only copy is normally ~24 hours behind the newest changes.

===== Write Access =====

Developers who have been given write access (access to the master repository) will need to have ssh installed, and set their CVS_RSH environment variable to '''ssh'''.

To avoid being prompted for your Sourceforge password every time you run a CVS command on the master repository, you will probably want [http://sourceforge.net/docman/display_doc.php?docid=761&group_id=1 to upload an SSH key].

If you've been doing work in a codebase checked out as anonymous, you can convert it to your developer account with a little work. Essentially, you need to recursively convert all of the CVS/Root files in the tree from the anonymous user to your username. Alternatively, you can just create a diff and then patch it over.

==== How Do I Check Out a Working Copy? ====

To check out a copy of Inkscape from the developer CVS, you may use the following command:

cvs -z3 -d''repository'' checkout inkscape

Here are what the options mean:

-z3 is a general CVS option, and requests that communication with the server be compressed to save bandwidth. Recommended especially if you are on dialup.

-d specifies the repository to check out from.

"checkout" ("co" means the same thing) specifies the action to take (check out a working copy).

"inkscape" is the name of the ''module'' (group of files and directories) that make up our project.

==== Which Repository Do I Use? ====

Most users will use the anonymous repository (''':pserver:anonymous@cvs.sourceforge.net:/cvsroot/inkscape'''), as shown above.

If you are a developer who has been given CVS write access, the repository will be ''':ext:''username''@cvs.sourceforge.net:/cvsroot/inkscape''', where ''username'' is your sourceforge username.

==== Now What? ====

You should have a complete working copy in the '''inkscape''' directory. You can cd to it and try compiling.

:Note: If it is a fresh checkout, you will need to run the ./autogen.sh shell script at the top level to create files needed to compile

You should not need to specify the repository with -d in any CVS commands for this working copy. CVS remembers which repository a working copy came from.

Note that a CVS command only applies to the current directory and (possibly) any subdirectories. Normally (particularly for updates, diffs, and checkins), you will want to run the command from the top level of the project.

=== Bringing Your Working Copy Up-To-Date ===

Your working copy will not automatically include changes others have made to the repository since you checked it out.

To ''update'' your working copy, use this command:

cvs -z3 update -Pd

-P specifies to remove any directories that become empty as a result of the update

-d creates any new directories introduced by the update

=== Dealing with Conflicts ===

If you've made changes to your working copy, what happens if you update after someone has commited changes to the same files?

Normally, CVS can work this out on its own. Sometimes you have to help it along, though. If CVS says there were conflicts, look for which files have a ''C'' next to them in its progress output. Some of those may have unresolved conflicts. You can also search for '=======' in the files themselves to find any unresolved conflicts.

<<<<<<< ''filename''
The changes in your version will be here
=======
The changes the other person will be here
>>>>>>> ''some version here''

Sometimes you will keep one set of changes and discard the other, and sometimes you will combine the two. It will require a judgement call on your part either way. Talk to the person who made the other set of changes or ask on the mailing list if it's unclear what's going on. Remember that CVS is no substitute for communication.

Also, always make sure to build and test after an update to make sure that the combined changes work as intended.

=== Generating a Diff ===

('''Always''' update before generating a diff!)

From the top-level directory, run the command:

cvs -z3 diff -u3 > filename

-u3 specifies which format to use (a unified diff with three lines of context). This is the recommended diff format.

This will create a file describing the changes you have made, though if you have created new files as part of your changes, you will need to include those separately too when emailing them to the list or another developer for inclusion.

=== Patching a Diff ===

A diff file can be applied to the codebase using the 'patch' command.

If the diff was made as <code>inkscape/src/thingy.cpp</code> and you're in the "inkscape" directory, you'll want to use the command:

patch -p1 < thingy.diff

Depending on how many path elements are part of the diff, you'll need to strip them with -p1, -p2, etc.

=== Committing your Changes ===

('''Always''' update before committing!)

If you have write access to the repository, you can commit your changes like this:

Before you commit, please make sure that you describe the changes you have made in the ChangeLog file at the top-level directory.

cvs -z3 commit -m "Your description of your changes goes here"

Tip: even if you are committing directly, you still might want to generate a diff. It's a good reference to look at when you're filling out the ChangeLog, since it will remind you of all the changes you've made.

=== Adding Files to the Repository ===

To add new files as part of your commit, you will need to run:

cvs -z3 add ''files and directories to add go here''

Before you commit. This also goes for new directories.

Except for directories, the actual addition or removal will not take effect until you commit.

=== Removing Files from the Repository ===

To remove files from the repository (they aren't actually removed, just marked as inactive), you will need to run:

cvs -z3 remove ''files that were removed go here''

The files will have to have been deleted from your working copy before CVS will let you do this.

The actual removal will not take effect until you commit.