Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

cvs best practices?

 
nobu taku
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 64833
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Moving to the IDEs and Other Tools forum.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
nobu taku
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Posts: 14112
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Another interesting book is Software Configuration Management Patterns.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic