• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

cvs best practices?

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Moving to the IDEs and Other Tools forum.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
     
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Another interesting book is Software Configuration Management Patterns.
     
    Don't get me started about those stupid light bulbs.
    reply
      Bookmark Topic Watch Topic
    • New Topic