Was this page helpful?

CVS

     

    Resources

    CVS features

    CVS is a source code control system that we use for many projects.  Although there is a little overhead, CVS greatly simplifies the problems that occur when groups of programmers work together on a single code, and is very useful for single programmer projects as well.  Some features of CVS:

    • Saves complete history of code
    • Shows differences between specific versions of code
    • Allows code as of a certain date to be restored (as in, oops, I broke it)
    • Ensures that simultaneous changes by multiple programmers get properly resolved
    • Allows for branching of multiple versions (separate development streams)
    • Allows progammers to set watches on code
    • Compatible with Eclipse and EPIC/Perl
    • Allows for locking of code during critical changes (we don't use this)

    CVS with Eclipse

    almost always use CVS via Eclipse.  To use CVS with eclipse

    1. Open CVS Repository Exploring Perspective
    2. In the CVS Repositories pane, right click and select "new repository location"
      • host: pro.genomics.purdue.edu (or any server with the cbio directory available)
      • repository path: /cbio/cvs
      • connection type: extssh
      • authentication: your username and password on genomics unix systems (must be in gribskov group)
    3. Select and right click a bransh to check out and it will appear in your navigator pane
    4. Use team->commit to commit your changes

    Telling CVS to ignore files

    CVS normally expects to be managing all the files in a directory (with some standard assumptions -- it will ignore files ending in ~, files starting with #, files ending in .o or .a, files named core, and a variety of other standard exclusions intended to avoid temporary or generated files; see info cvs for a full list). Often that isn't what you want, though. The standard practice is only to put source files under CVS control; any file that can be programmatically and automatically generated from the other files probably shouldn't be under revision control itself. (For programming projects, this generally means any file that can be build automatically from the Makefile.)

    To tell CVS to completely ignore a file, put the name of the file in a file named .cvsignore in that directory. CVS will completely ignore any files listed in that file, treating them as if they didn't exist. You can also put wildcards into .cvsignore, using standard wildcard shell syntax; for example, a line of *.elc will tell CVS to ignore all files ending in .elc.

    Similarly, CVS will normally expect to be managing all subdirectories of a directory, but if a directory name matches a filename or wildcard expression in .cvsignore CVS will ignore it.

    Another use of .cvsignore is to tell CVS it does need to manage files it normally wouldn't. For example, CVS normally ignores files ending in .a because they're generally libraries built as the result of compiling sources, and therefore are generated files. If you have a file ending in .a that you want CVS to track, put:

       !
    

    in .cvsignore in that directory. That single exclamation point will clear the default list of ignored files. (You may have to, after the !, list some of the standard patterns like *~ or #* again if you want CVS to ignore them still, since ! clears out all patterns of files to ignore.)

    Branching

    Branching is covered in chapter 5 of the CVS manual.

    branch is a series of revisions that for some reason should not be committed onto the main development path (usually called the trunk). For example, if you want to try some experiment that may not work or make a customized version that changes the code so it would probably not work for its original applications, you wouldn't want to check it into the trunk. You could work on in your own directory, never checking any files into the repository - but then you'd lose all the advantages of using CVS. The alternative is to create and work on a branch, which allows the advantages of CVS without disturbing anyone else.

    The original set of versions, before the branch was created, is called the trunk, main line, main branch. It's what you get when you checkout code with cvs co my_prog. After a branch is created the main line is still the default version. Unless you specifically merge changes from a branch back into the main line or vice-versa, the changes that you make on a branch will never appear in the main line, and vice-versa.

    Creating a branch

    to create a branch called myversion_0

    • checkout or update to the current version of the code
    • cvs tag -b myversion_0 (splits off a branch  "myversion_0" from the current revision code)
    • cvs checkout -r myversion_0 or cvs update -r myversion_0
      checks out the new branch code (the code in your directory is from the trunk). This is very important, if you do not checkout the branch code you are modifying and possibly destroying the main version.

    if you do cvs status before creating the branch you should see something like

    File: GenomeRNA.pm      Status: Up-to-date
    
       Working revision:    1.14    Wed May 12 14:29:17 2010
       Repository revision: 1.14    /cbio/cvs/RNA/src/perl_src/evo/GenomeRNA.pm,v
       Sticky Tag:          (none)
       Sticky Date:         (none)
       Sticky Options:      (none)

    after creating the branch and updating you will see something like

    File: GenomeRNA.pm      Status: Up-to-date
    
       Working revision:    1.14    Wed May 12 14:29:17 2010
       Repository revision: 1.14    /cbio/cvs/RNA/src/perl_src/evo/GenomeRNA.pm,v
       Sticky Tag:          siox_0 (branch: 1.14.2)
       Sticky Date:         (none)
       Sticky Options:      (none)

    Note the "Sticky Tag" that has been added

    Was this page helpful?
    Tag page (Edit tags)
    • No tags

    Files 1

    FileSizeDateAttached by 
     1108_cvs_demo.pdf
    intro to CVS slides from 2011-08-03 group meeting
    740.13 kB12:31, 4 Aug 2011gribskovActions
    You must login to post a comment.