Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Learning How to Use CVS for Personal Perl Coding Practices

by neversaint (Deacon)
on Nov 03, 2005 at 05:53 UTC ( [id://505232]=perlquestion: print w/replies, xml ) Need Help??

neversaint has asked for the wisdom of the Perl Monks concerning the following question:

Programmers make mistakes, and occasionally those mistakes will be catastrophic.
- D. Conway on using "revision control system" (PBP).
Dear Masters,

Can anybody give a simple example (tutorial)? How can I use CVS - or others - for my own personal Perl coding practices? Since most of the example are for compiled language like C/C++ where it required linking etc.
Currently what I do is just simply saving my code under different name, this is painful! etc.
I've never use CVS or RCS or Subversion before, and would really like to know how you guys use it, in your Perl coding experience. Please be patient with me.

neversaint and everlastingly indebted.......

Replies are listed 'Best First'.
Re: Learning How to Use CVS for Personal Perl Coding Practices
by monarch (Priest) on Nov 03, 2005 at 06:51 UTC
    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.

    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
    You'll be asked to provide a comment, and you can type something like Created module directory.

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

    [tmp]$ cd .. [/]$ cvs co myproject
    This will create a directory called myproject and we will move into this directory now:
    [/]$ cd myproject [myproject]$

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

    [myproject]$ cp ../ . [myproject]$
    Now we can add each file into the repository:
    [myproject]$ cvs add
    ..and then commit the file..
    [myproject]$ cvs commit -m "Initial import"
    Bingo, your file is now in the repository.

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

    [myproject]$ cvs status'll see that CVS has detected you've changed the code. What differences are there between your edited version and the version stored?
    [myproject]$ cvs diff
    Checking in a change is simple, run
    [myproject]$ cvs commit -m "Minor change"
    Once you've done this, check the status again:
    [myproject]$ cvs status
    ..and you'll see the file is up-to-date. And version 1.2 now too..

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

    cvs log

    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
      Then set the variable, by putting this into your .bash_profile
      CVSROOT=~/cvsroot; export CVSROOT
      Don't forget to source your .bash_profile.
      $ source .bash_profile
      After this follow the instruction provided by monarch above.

Re: Learning How to Use CVS for Personal Perl Coding Practices
by tirwhan (Abbot) on Nov 03, 2005 at 07:06 UTC

    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
    This will create an empty repository for you.
    cd /home/neversaint/code svn import . file:////home/neversaint/subversion
    This will import your codebase into the repository.
    mkdir /home/neversaint/workspace cd /home/neversaint/workspace svn co file:///home/neversaint/subversion
    This will create a new copy of your current codebase in /home/neversaint/workspace. From then on, make all changes to these files. Whenever you want to save your files to the repository, do a
    svn -m "Commit message" ci

    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
    svn help <command>
    for details on certain commands.
    Update:Changed to using real-world paths, after msg's asking for clarification, also fixed a syntax error in the create.

    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
      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/* .

      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 mkdir project123 cd project123 svn checkout svn://myserver/myrepo/trunk/ . vi svn commit -m "Made change XXX for project YYYY" cd .. rm -rf

      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 ( which I want to store them with SVN.
      ~/MyPerl | |__Project1 | |__ Note: ~/ = home/neversaint
      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
      Listing them:
      home/neversaint/subversion $ cd Project1 home/neversaint/subversion/Project1 $ ls README.txt conf dav db format hooks locks
      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? ---------------------|
      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
      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"

Re: Learning How to Use CVS for Personal Perl Coding Practices
by pernod (Chaplain) on Nov 03, 2005 at 08:35 UTC

    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
    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
    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.
    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 :)

    Mischief. Mayhem. Soap.

Re: Learning How to Use CVS for Personal Perl Coding Practices
by duff (Parson) on Nov 03, 2005 at 06:01 UTC

    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.

Re: Learning How to Use CVS for Personal Perl Coding Practices
by rnahi (Curate) on Nov 03, 2005 at 10:49 UTC
Re: Learning How to Use CVS for Personal Perl Coding Practices
by tphyahoo (Vicar) on Nov 03, 2005 at 09:50 UTC
    First of all, learn subversion first: it's the future. Cvs is pretty similar and you can always learn it later.

    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 ( 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 ( 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."

Re: Learning How to Use CVS for Personal Perl Coding Practices
by ioannis (Abbot) on Nov 03, 2005 at 06:25 UTC
    Before you dive into svn or cvs, for the bare basics you should consider RCS. RCS comes pre-installed in most Unix systems for the last 15-20 years. Start with the manpages of rcs(1), rcsintro(1), ci(1), and co(1) .

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

Re: Learning How to Use CVS for Personal Perl Coding Practices
by polettix (Vicar) on Nov 03, 2005 at 10:08 UTC
    Revision Control Systems are usually more effective at keeping textual data instead of binary. Not that they cannot - but the possibility to make useful diffs, that help the programmer understand what changed and things like that, are obviously tailored around a textual world. And here we come to what impressed me in your post:
    Since most of the example are for compiled language like C/C++ where it required linking etc.
    You usually don't track compiled objects with revision systems, for the reasons above and, most of all, because the objects are likely to be different in different machines. OTOH, the source code is the same - and it' (usually!) text much like any Perl script (even if it may resemble line noise ;). IIRC, all examples in the CVS manual relate to the sources, except of course the chapter about binary objects :)

    perl -ple'$_=reverse' <<<ti.xittelop@oivalf

    Don't fool yourself.
      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.


      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

Re: Learning How to Use CVS for Personal Perl Coding Practices
by spiritway (Vicar) on Nov 03, 2005 at 06:40 UTC

    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.

Re: Learning How to Use CVS for Personal Perl Coding Practices
by pajout (Curate) on Nov 03, 2005 at 10:19 UTC
    Still one opinion...
    I use CVS in my work, storing relatively big mod_perl/Perl/SQLengine/XML oriented projects. It works fine, specially, when good branching/merging policy is established. Pure development on maintrunk, stable releases on own branches.
    So, for some reasons we are gradually changing CVS to SVN, because better (simpler?) data model.
Re: Learning How to Use CVS for Personal Perl Coding Practices
by ambrus (Abbot) on Nov 03, 2005 at 08:36 UTC

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

Re: Learning How to Use CVS for Personal Perl Coding Practices
by LanceDeeply (Chaplain) on Nov 03, 2005 at 18:07 UTC
    for my home dev environment i use Eclipse with the EPIC plugin. Eclipse integrates very well with cvs and I use cvsnt as my home cvs server. All this stuff is free and works well together. I dont have to remember any cvs commands, i just right click and commit/update whatever...
Re: Learning How to Use CVS for Personal Perl Coding Practices
by artist (Parson) on Nov 03, 2005 at 15:50 UTC
    If you use Emacs, it is easy. Default system is RCS.
    Just do C-x v v and rest will be taken care. Explore further by reading docs.
Re: Learning How to Use CVS for Personal Perl Coding Practices
by monkfan (Curate) on Nov 03, 2005 at 20:52 UTC
    Check out CVS plugin for VIM here.

Re: Learning How to Use CVS for Personal Perl Coding Practices
by nothingmuch (Priest) on Nov 06, 2005 at 11:19 UTC
    I'd like to really stress out the importance of using a distributed version control system.

    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:

    I use svk to interoperate with svn driven repositories. I don't like it as much as darcs because it's not as simple or easy to use, and it's not as easy to publish repositories on http as it is with darcs. Aside from that it's an excellent system, which can really boost productivity.

    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.

    zz zZ Z Z #!perl
Re: Learning How to Use CVS for Personal Perl Coding Practices
by metaperl (Curate) on Nov 04, 2005 at 22:35 UTC
    I like to version my files automatically by the CVS revision number. Here's how to handle that in Perl:
    package Class::Cache; use strict; BEGIN { use Exporter (); use vars qw($VERSION @ISA @EXPORT @EXPORT_OK %EXPORT_TAGS); $VERSION = ('$Revision: $' =~ 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 = (); }

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://505232]
Approved by planetscape
Front-paged by wfsp
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (6)
As of 2024-04-22 15:47 GMT
Find Nodes?
    Voting Booth?

    No recent polls found