Difference between revisions of "WorkingWithCVS"

From Inkscape Wiki
Jump to navigation Jump to search
(Obsolete)
m
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.

Revision as of 19:36, 17 April 2007

This page is obsolete please see WorkingWithSVN for current version control procedure

CVS Basics

This node discusses the basics of using CVS. Also see Checking out CVS modules on sourceforge.net

For complete on information CVS, including the basics, see:

For information on more advanced usage, see:

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

Retrieved from "https://wiki.inkscape.org/wiki/index.php?title=WorkingWithCVS&oldid=14223"