Creating a module
First things first, you need to create a module directory in which to store all your files. To do this, create a temporary directory (make sure it is empty) such as tmp as follows:

  [/]$ mkdir tmp
  [/]$ cd tmp
  [tmp]$ cvs import myproject myname start
[download]

Checking Out Module
Next, find somewhere to check your module directory out to.

  [tmp]$ cd ..
  [/]$ cvs co myproject
[download]

  [/]$ cd myproject
  [myproject]$
[download]

Adding Files To Module
Copy your files into your myproject directory.

  [myproject]$ cp ../myperlcode.pl .
  [myproject]$
[download]

  [myproject]$ cvs add myperlcode.pl
[download]

  [myproject]$ cvs commit -m "Initial import" myperlcode.pl
[download]

Checking In A Change
Now edit your file myperlcode.pl where it is in the myproject directory. When you now run

  [myproject]$ cvs status myperlcode.pl
[download]

  [myproject]$ cvs diff myperlcode.pl
[download]

  [myproject]$ cvs commit -m "Minor change" myperlcode.pl
[download]

  [myproject]$ cvs status myperlcode.pl
[download]

Show The History
You can view who has edited the file by running

  cvs log myperlcode.pl
[download]

There's much more you can do.. this was just a very very brief overview, look at the documentation available on the web for better tutorials.

Firstly you need to create a CVS repository somewhere for yourself. The mechanics of this are not straightforward so this is one I'll leave you to google for yourself.

This is just a complementary to your wonderful response to OP. Can be considered as a prequel to it.
What you need to do is first to create a main database (CVS repository).

[/]$ mkdir cvsroot
[download]

Then set the variable, by putting this into your .bash_profile

CVSROOT=~/cvsroot;
export CVSROOT
[download]

Don't forget to source your .bash_profile.

$ source .bash_profile
[download]

After this follow the instruction provided by monarch above.

Regards,
Edward

Short example of how to start out with subversion (honestly, if you're just starting out I don't see merit in beginning with one of the older version control systems, they're no easier to learn and make your daily life harder).

Let's say your current code is in /home/neversaint/code and you'd like to keep the subversion repository (the backend storage, i.e. database if you will) in /home/neversaint/subversion.

svnadmin create /home/neversaint/subversion
[download]

cd /home/neversaint/code
svn import . file:////home/neversaint/subversion
[download]

mkdir /home/neversaint/workspace
cd /home/neversaint/workspace
svn co file:///home/neversaint/subversion
[download]

svn -m "Commit message" ci
[download]

This will update the repository to the state of the workspace.

For further instructions, see the book pointed out by duff and the subversion documentation, execute

svn help
[download]

svn help <command>
[download]

While there is nothing incorrect with your example, I've followed the suggestion of using trunk, tags, and branches, and have found it to be very helpful. (Use branches for parallel development... like migrating code to a new platform while development continues on the current one. Use tags for "point in time" snapshots.) I use this structure even for repositories for which I'm *sure* I'll never need them. (If, for no better reason, than to always know I need to check out the trunk on any given repo.)

You set this up before the initial import. Create a directory (let's assume /home/rhose/svn). In this directory, create three more directories -- trunk, tags, and branches. Place all your directories/code in the trunk directory.

cd /home/rhose
mkdir svn
cd svn
mkdir trunk
mkdir tags
mkdir branches
cd trunk
cp /home/rhose/work/project123/* .
[download]

You are now ready to import. (Please note, I'm using the Subversion daemon in this example.)

svn import /home/rhose/svn svn://myserver/myrepo -m "Initial import"

You are now free to nuke your import structure, checkout the trunk, and start working. Also, I like to make a temporary copy of the original files until I verify the repo import worked correctly and everything is in there... I've never had a problem, but I tend to play it extra safe. (Please note... once you check out a repo, do NOT mess with the .svn directories -- like Bruce Banner, you'll not like them when they're angry.)

cd /home/rhose/svn
rm -rf *
cd /home/rhose/work
mv project123 project123.save
mkdir project123
cd project123
svn checkout svn://myserver/myrepo/trunk/ .
vi mycode.pl
svn commit -m "Made change XXX for project YYYY"
cd ..
rm -rf project123.save
[download]

If you are in a Windows environment, I'd like to second tphyahoo's advice -- TortoiseSVN is wonderful.

Dear Rhose,


[snip] svn://myserver/myrepo [snip]

Where and how do you set/define this server repository? Say if I am only working locally for myself.


---
neversaint and everlastingly indebted.......

Dear tirwhan,
Let me make myself clear again. Please bear with me. Suppose I have the following directory which contain a file (myperlcode.pl) which I want to store them with SVN.

  ~/MyPerl
     |
     |__Project1
           |
           |__ myperlcode.pl


Note: ~/ = home/neversaint
[download]

Following your advice what I tried to do is following steps.

Step 1: Creating a subversion main repository and repository related to Project1

home/neversaint $ mkdir subversion
home/neversaint $ cd subversion
home/neversaint/subversion $ svnadmin create Project1
[download]

Listing them:

home/neversaint/subversion $ cd Project1
home/neversaint/subversion/Project1 $ ls
README.txt  conf  dav  db  format  hooks  locks
[download]

Step 2: Attempting to create empty repository

home/neversaint/subversion $ cd ~/MyPerl/Project1
home/neversaint/MyPerl/Project1 $ svn import . file:///~/subversion/Pr
+oject1
                                                 ^
                                                 |
Note: did I get this right? ---------------------|
[download]

Now, at this point I encounter problem with this message:

svn: Could not use external editor to fetch log message; consider<br> 
setting the $SVN_EDITOR environment variable or using the 
--message (-m) or --file (-F) options
svn: None of the environment variables SVN_EDITOR, VISUAL or 
EDITOR is set, and no 'editor-cmd' run-time configuration option was 
found
[download]

Is there anything wrong with my steps above? Did I misunderstood your advice above? Hope to hear from you again.


---
neversaint and everlastingly indebted.......

Import (like commit) needs a log message. I'd use the -m switch on the import. (Although you can define the editor and enter the log message using it.)

svn import . file:///~/subversion -m "Initial import"

I have to mention darcs. It is simple to use and easy to set up, and trés cool, as it is written in Haskell. We all know all the cool things we can make with Haskell, don't we?

I have switched from Subversion to darcs in my personal projects, as i don't have to worry about creating and maintaining separate repositories. Darcs is a distributed revision control system, so all source trees can also work as repositories. In day to day work for one person this doesn't make any difference, but if you routinely code on intercontinental flights (for example?), the ability to commit changes locally and synchronize when you get back to a network connection is invaluable.

From the intro:

Creating your repository

Creating your repository in the first place just involves telling darcs to create the special directory (called _darcs) in your project tree, which will hold the revision information. This is done by simply calling from the root directory of your project:

% cd my_project/
% darcs initialize
[download]

This creates the _darcs directory and populates it with whatever files and directories are needed to describe an empty project. You now need to tell darcs what files and directories in your project should be under revision control. You do this using the command darcs add3.1:

% darcs add *.c Makefile.am configure.ac
[download]

When you have added all your files (or at least, think you have), you will want to record your changes. ``Recording'' always includes adding a note as to why the change was made, or what it does. In this case, we'll just note that this is the initial version.

% darc record --all
What is the patch name? Initial revision.
[download]

Note that since we didn't specify a patch name on the command line we were prompted for one. If the environment variable `EMAIL' isn't set, you will also be prompted for your email address. Each patch that is recorded is given a unique identifier consisting of the patch name, its creator's email address, and the date when it was created.

Try darcs. You have nothing to lose :)

You might want to use subversion instead of CVS if you're just starting out. There's also a nice book that will tell you everything you need to know.

Hrm... without mentioning names, I have heard good things about svk.

Indeed. svk is fairly cool. It (like anything) takes a bit getting used to though. But given that the OP is new to tools like cvs/svn it's probably best if he learns how to use svn first.

Also, I find that just as when I switched from cvs to svn and had a hard time typing "svn" because my fingers wanted to type "cvs", so too it's a bit difficult getting the fingers trained to type "svk" rather than "svn". Only it's worse for svk/svn as they are so similar.

duff

The usual mantra.

Did you use Super Search? Have you seen our Tutorials?

If you had, you may have noticed that there is

• Using CVS for revision control
• [OT] Advanced CVS usage
• Perl code, RCS/CVS, and distribution
• CVS and perl

The first one is a tutorial with plenty of reference links. The other posts give you some additional info.

Next, if you're on windows, first thing to do is download tortoisesvn gui shell for it. To heck with the command line, the gui makes everything sooo much easier. Also, if you download tortoise, that takes care of everything, you don't need to download subversion client or server or anything, it's all bundled in tortoise. Not sure if tortoisesvn is ok for unix, but if it's not, I would suggest hunting around for some gui shell that is.

Make a test repository, and dink around with it for a while, following the "easy start for beginners" type stuff in the manual. Use the tortoisesvn manual, not the subversion book: the tortoisesvn manual is a lot easier and will get you productive sooner. You can always read the subversion book later for the nitty gritty.

For the more fancy stuff (both subversion and cvs), pay a visit to cvsdude's forum, or the svn or tortoisesvn mailing lists. Personally I like cvsdude's better, but maybe that's just cause I find web forums easier to navigate than mailing lists.

Finally, USE it. It will save you time, and the time saving will probably kick in pretty fast. Don't just use it for code. Use it for letters, notes to yourself, excel spreadsheets, whatever. Version control is a very Good Thing. Good for you for deciding to learn about it and integrate it into your set of tools.

I think the biggest selling point of any SCCS is what you might do with it in the future. Considering I have an account on SourceForge, and that they use CVS, using CVS for my personal perl projects makes sense as I'll be able to leverage all my experience using cvs with SourceForge with what I'm doing outside of SourceForge; I'll be able to create a project on SourceForge and move my repository over; and if/when I do so, I won't need to change anything that I'm doing in order to use it.

I know there are a number of open-source SCCS repositories found on the 'net now. But I would suggest that using what they use (whichever one of "they" that you choose) will make life easier should you ever want to put your project up there to collaborate with others.

Update: This isn't an argument against Subversion. Just a warning to educate yourself on what you may want to do in the future before committing to something now ;-) (It isn't even meant to be an advertisement for sourceforge ;-})

Just to note, one of the design goals of Subversion was that the command interface be backwards-compatible with CVS. So if you switch over, you won't need to relearn how to use your SCM, just remember to type 'svn' instead of 'cvs' (or alias cvs=svn in a shell startup file). The only thing you need to get used to is that you are now able to rename and move directories, as well as do a bunch of other stuff :-).


Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

There's buzz that sourceforge is eventually going to offer subversion support. I sure hope so.

First of all, learn subversion first: it's the future.

Whenever I hear someone say "Use XXX, it's the future", I think "there's a quack selling vaporware as snake oil".

Usually, when I look at using a piece of software, I have a problem I need to solve now - I don't need something that will solve my problems at some unspecific time in the future.

If you want to pitch subversion, sell it on its merits. "It's the future" is meaningless.

Perl --((8:>*

All right, all right. <grumbles>

"So what's wrong with CVS? Because it uses the RCS storage system under the hood, CVS can only track file contents, not tree structures. As a result, the user has no way to copy, move or rename items without losing history. Tree rearrangements are always ugly server-side tweaks......

......

In 1995, Karl Fogel and Jim Blandy founded Cyclic Software, a company for commercially supporting and improving CVS. Cyclic made the first public release of a network-enabled CVS (contributed by Cygnus software). In 1999, Karl Fogel published a book about CVS and the open-source development model it enables (cvsbook.red-bean.com). Karl and Jim had long talked about writing a replacement for CVS; Jim even had drafted a new, theoretical repository design. Finally, in February 2000, Brian Behlendorf of Collabnet (www.collab.net) offered Karl a full-time job to write a CVS replacement. Karl gathered a team and work began in May.

The team settled on a few simple goals: it was decided that Subversion would be designed as a functional replacement for CVS. It would do everything that CVS does, preserving the same development model while fixing the flaws in CVS's (lack of) design. Existing CVS users would be the target audience; any CVS user should be able to start using Subversion with little effort."

As always, your milage may vary. But that's what I meant about "future."

For an introduction, tutorial, and references to CVS visit cvsbook .

Since most of the example are for compiled language like C/C++ where it required linking etc.

One of the points of design in subversion is that it uses a binary differencing algorithm. It does so so that it can store binary files efficiently. CVS, as far as I can tell, has to store the whole file each time you change a binary file. Not so with subversion.

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

I've had some good luck with Perforce. It's free and has some good documentation to help you get started. Like you, I am a complete novice with SCCS's, but was able to get going after a few false starts. My suggestion: RTFM, because if you don't, you'll make a few false starts...

It should perhaps be pointed out that Perforce is only free as in beer, not speech, and that the Perforce Server (which is needed if you want to share the repo with more than one other person) is not free (unless you're an open-source project in which case you can get a special license).

Without wanting to turn this into an off-topic flamefest, I don't know any feature which Perforce (or any other closed-source SCM) offers that is not available from an open source one, and the Linux kernel Bitkeeper mess shows the importance of keeping one's codebase in an open format which can be readily accessed with open tools.


Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

Well, as I mentioned previously, I am a complete newbie with SCCS software. I tried CVS, Subversion, and Perforce. The only system I could get up and running, that had documentation I could understand, was Perforce. Those other systems may very well be better, but since I can't figure out how to make them go, they aren't useful to me. As for Perforce not being "free as in speech", I didn't consider that an issue. Since nothing I produce would depend on Perforce, it would not affect any licensing. I agree that if you're trying to keep your machine completely "free as in speech", Perforce would not be an appropriate choice. I'm not acquainted with the "Linux kernel Bitkeeper mess". That mess (if I knew about it) might have caused me to change my mind about using a closed-source product. The Perforce Server is free (as in beer), but sharply limited (2 users, 5 client workspaces).

As it turns out, however, I finally just wrote my own script to take care of the problem of version control, and it works well enough for me that I don't have to worry about any of these programs. It just tucks my files away into time-stamped directories, so that I can find them if needed. It's not pretty, but it does the job.

I started with the O'Reilly cvs book, then I could use cvs easily (although I kept peeking at the cvs documentation).

This makes your life so much better in ways people just don't realize till they try it (i explain why below).

I use two systems in my day to day life:

• darcs
• svk

For my own projects I use darcs, which is a joy to work with.

I suggest you start with darcs, then also learn to use svn. After that replace svn with the more complex svk (darcs will help you understand svk's ideas, svn will let you understand svk's interface, and experience will help you understand why svk exists). In my opinion don't bother with cvs - the world is phasing it out, and it's limited, and frustrating to learn.

I think that darcs is by far the best system to start with because it's so simple and "pure" that technical distractions are kept to an absolute minimum. This lets you really see what's going on without blowing your mental stack. However, this does not mean that darcs is an incapable tool.

The power of distributed version control is philosophical more than anything - it teaches you on the value (and the price) of branching. The cheaper it is to branch, the more valuable branches are.

Constructing branches for temporary digressions, versions, big features, release engineering, and so on and so forth, and then throwing away whatever's unneeded is, IMHO a crucial part of using version control systems effectively.

Distributed version control systems are designed from the start to support these features well.

A notable mention is bazaar (and bazaar-ng), which is bassed on arch (another distributed version control system) but whose interface is supposed to be more friendly. I haven't used bazaar but I found arch (well, tla to be specific) traumatic at best.

package Class::Cache;
use strict;

BEGIN {
    use Exporter ();
    use vars qw($VERSION @ISA @EXPORT @EXPORT_OK %EXPORT_TAGS);
    $VERSION     = ('$Revision: 1.1.1.1 $' =~ m/([\.\d]+)/) ;
    @ISA         = qw(Exporter);
    #Give a hoot don't pollute, do not export more than needed by defa
+ult
    @EXPORT      = qw();
    @EXPORT_OK   = qw();
    %EXPORT_TAGS = ();
}
[download]