File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes IDEs, Version Control and other tools and the fly likes cvs best practices? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "cvs best practices?" Watch "cvs best practices?" New topic
Author

cvs best practices?

nobu taku
Greenhorn

Joined: Aug 06, 2003
Posts: 17
My group would like to start using CVS for version control and I am wondering what are some best practices in it usage.

Currently, each developer has a development server, there is a single test/staging server, and a production server.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60752
    
  65

Moving to the IDEs and Other Tools forum.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Since you're just starting out, consider using Subversion instead of CVS. Subversion is intended as a modern replacement for CVS, and in a word, it rocks.

Pick one machine to be the version control server. Doesn't really matter which one, but should be up nearly 24/7. It needs lots of disk and must be backed up at least daily.

The worst problem in using any version control system is merging changes -- getting the changes developer A made to work with the changes developer B makes. If A and B work for a long time without checking their changes in, this can be really hard.

The best "best practice" I know of is to do Continuous Integration. Don't keep any changes checked out for very long. As soon as something is tested and works, check it in. If you want to be really extreme about this: some teams have a rule that you throw away any un-checked-in changes at the end of each day -- i.e., never go home when you've got uncommitted changes. It sounds bad, but it's great, really: it pretty much eliminates the problem of difficult merges.


[Jess in Action][AskingGoodQuestions]
nobu taku
Greenhorn

Joined: Aug 06, 2003
Posts: 17
thanks for the response Ernest. I guess i should have been clearer in my inital post. we are using cvs but we don't have a 'well oil machine'. in other words, a set of rules and practices for using cvs in our company. for intance, how is code moved from development to staging. is it:
-manually copied to staging, tested, and after it works checked into cvs
or
-once working in development, checked in, pulled onto staging, tested.

how is code moved from staging to production. cvs or tar files?

cvs is a tool. most books i've seen treat it like that. none seem to cover a process of using cvs. i am looking for this process/set of best practices.


BTW, i have your book 'jess in action'. very interesting and clearly written. it was nice to read something other than the usual 'monkey code to a database'. it got me excited about rule based systems and reminded me why i majored in computer science.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Originally posted by nobu taku:

-manually copied to staging, tested, and after it works checked into cvs
or
-once working in development, checked in, pulled onto staging, tested.


I suppose the answer to this is tied up with general development methodology questions, but for agile development, the answer is much closer to the second one. What we do (and everyone's process is a bit different, I'm sure)
  • Write tests
  • Write code to make tests pass
  • Check in code and tests
  • Automated build process tags CVS with a build number,

  • checks out code and tests on integration machine using that tag,
    builds an installation package (tarball, InstallShield installer, etc)
  • Build process then installs this package and runs all tests
  • Integration test reports come back in email
  • Fix failures (if any), check back in, wait for automated build



  • how is code moved from staging to production. cvs or tar files?


    If all tests pass on integration machine, then you know that building an install package from a specific tag in CVS produces a releaseable application; you use the same build script to produce the installable software and you send it off to production.

    A book that actually describes a process very much like this in a usable, hands-on way, is Mike Clark's PRagmatic Project Automation. It got some excellent reviews here at the Ranch.



    BTW, i have your book 'jess in action'. very interesting and clearly written. it was nice to read something other than the usual 'monkey code to a database'. it got me excited about rule based systems and reminded me why i majored in computer science.


    Thanks! Glad you enjoyed it!
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Another interesting book is Software Configuration Management Patterns.


    The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: cvs best practices?
     
    Similar Threads
    where to ask questions about Eclipse, CVS?
    Using Version Control
    How to create CVS
    CVS & Eclipse
    CVS Configuration in Eclipse