I advocate the use of Revision Control Systems for damn near every project. The benefits you receive from a RCS that is used properly are so substantial that I consider it a harmful development practice to not take advantage of them. It's on the same level as 'use strict' and unit tests for me.
The most basic benefit is access to older versions of the source code. This is useful for rolling back changes, seeing what the code was like at a given point intime, and for comparing the code between two dates (or revision numbers).
A few other important things that rcs can provide:
A way to find who last edited a file or line, and what their intent was
Without a RCS you tend to play cube-gopher and ask your neighbors who edited a particular function, and then pray that the author still works for the company and remembers their intention from a modification done 2 years ago.
With the RCS you type:
svn blame Foo.pm
Statement of intent for a code change
Documentation comes in many forms, and each has its own reason for existing. We use POD for the API specification and for a conversational explanation of the code's purpose. Inline documentation for the details of a particular algorithm.. and revision logs to record a statement of intent for a given code change.
Multiple developers editing the same file
Most people who have worked with other developers have had work deleted because someone else was editing the same file that you are working on.. it's miserable. With a RCS you can both work on separate instances of the same file, and the RCS will deal with merging the changes.
Multiple sandboxes
Working with multiple copies of a project can be difficult when it comes time to merge the changes back in. The newest timestamp is seldom an appropriate selection criteria, so you end up doing recursive diffs and finding which file changed and which changes should be kept. With 'svn diff' and 'svn status' this becomes trivial.
Working remotely and staying in synch with your work environment
When you are working with a large codebase it is not always convenient to transfer tarballs back and forth. If only 12 files out of 3000 changed, why copy them all? Instead just do 'svn up'.
Development transparency
Being able to see a list of changes and the associated log entries for a given time period (and or file set) is enough of a benefit to justify a RCS in my opinion. This information is extremely to QA departments as well as for communicating the changes to your peers, particularly when one has been on vacation.
It's also a good way for managers to see what has been going on in the system.
Integration with other tools
Take a look at
Trac, which provides an integrated respository browser, changeset viewer (with a nice diff), log viewer, ticketing system, and wiki.
Having the repository, wiki, and tickets on the same timeline is a valuable way of tracking progress.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.