Re: Revisioning systems and the lackof
by imp (Priest) on Oct 06, 2006 at 04:34 UTC
|
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. | [reply] [Watch: Dir/Any] [d/l] |
Re: Revisioning systems and the lackof
by perrin (Chancellor) on Oct 06, 2006 at 04:28 UTC
|
Anyone who is not sure what the value of a source control system is should consider this scenario: you have software in production which you now need to both support with emergency bug fixes and also create a major new version of for release in three months time. How will you get any fixes on the maintenance branch merged into the new development branch? With a system like Subversion, this is pretty easy. Without it, you have a lot of manual diff and merge operations ahead of you. | [reply] [Watch: Dir/Any] |
Re: Revisioning systems and the lackof
by GrandFather (Saint) on Oct 06, 2006 at 02:45 UTC
|
If you want an analogy in a single user environment then try: using an editor without undo/redo compared to using and editor that provides full undo/redo.
If you want an analogy in a multiuser environment try: chaotic anarchy compared to almost any other political system (depends how your revision control system works).
DWIM is Perl's answer to Gödel
| [reply] [Watch: Dir/Any] |
|
Hey! Speaking as the token woolly anarchist, I don't think that's a particularly good analogy.
The fact that I can't think of a better one is probably best ignored
| [reply] [Watch: Dir/Any] |
Re: Revisioning systems and the lackof
by ciderpunx (Vicar) on Oct 06, 2006 at 11:46 UTC
|
Have to agree that once you have version control you never want to go back. Its saved my life about n amount of times where n is a bloody big number.
I use subversion for source code. I'm actually thinking of putting major config files under source control - at the moment I have only the current config backed up.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
Re: Revisioning systems and the lackof
by planetscape (Chancellor) on Oct 06, 2006 at 02:15 UTC
|
| [reply] [Watch: Dir/Any] |
Re: Revisioning systems and the lackof
by radiantmatrix (Parson) on Oct 06, 2006 at 14:48 UTC
|
IMHO, anyone who isn't using some kind of revision control is just asking for trouble. I used to be like EvanCarroll, and eschew it. My moment of epiphany came when I had a "well, it worked yesterday, why the hell doesn't it work today" moment for about the nth time, and realized how much work CVS saved me:
- Find yesterdays tarball
- Unpack it somewhere safe
- Look at timestamps to see which files I changed
- Use diff on those files to find out what I changed
- Figure out which change breaks what
vs.
- Use CVS to do a diff between last CO and current files
- Figure out which change breaks what
After that, I started using CVS for everything I worked on. The more I used it, the more valuable it became. Some of the advantages:
- Multi-branch development. You can easily manage "stable" and "unstable" branches, adding patches to the "stable" branch while working on new features in "unstable". Merging the patches from stable into unstable later is straightforward.
- Multiple work sites. So I work at home and at the office, often on the same project. Sometimes I forget to save my home changes to the repository before coming in the next day (i.e. make changes at home, make changes at work, commit changes at work, make changes at home, commit changes at home). No big deal with CVS (or SVN, etc.): the merges are done automatically.
- Collaboration with other developers. This is a big one: two devs can work on two files at the same time, and neither will lose their work -- the control system takes care of the merge. Not only that, but I can easily find out who made the change without having to rely on them remembering to add their name in a comment.
Much like test-driven development, CVS or SVN can seem like a waste of time at first, but after a little while one realizes that it actually saves time in the long run.
| [reply] [Watch: Dir/Any] |
Re: Revisioning systems and the lackof
by tinita (Parson) on Oct 06, 2006 at 09:23 UTC
|
i was always to lazy to set up a CVS (or svn) repository on my own computer,
also because then i don't have it elsewhere.
now i started to use google project hosting for projects which are not worth maybe to create a sourceforge project, for example.
this is great. if you know you have all your past code in the revision history you can make changes without being worried how to roll them back if they don't work. an rcs is even recommendable if you only have one script. | [reply] [Watch: Dir/Any] |
Re: Revisioning systems and the lackof
by tilly (Archbishop) on Oct 06, 2006 at 05:09 UTC
|
| [reply] [Watch: Dir/Any] |
|
I've taken jobs where they didn't have source control. A week later they did though.
If no one shows them how to do it and how useful it is, why should they change? Spread the word by pollinating other places with your experience and skills.
| [reply] [Watch: Dir/Any] |
|
Agreed. Sometimes the most rewarding roles are ones where you have to start from nothing (or worse) and recreate a sensible working environment.
What's worse than nothing? How about legacy systems that are impossible to support and maintain? If you have reasonable management, who realise there's something wrong (they usually won't know exactly what it is), and are prepared to put their trust in you as a domain expert, you can often work wonders for them in this situation.
| [reply] [Watch: Dir/Any] |
|
|
Same here. I came onboard a recent project, and the code was splattered everywhere. Each person had their own way of making a backup, and that's when they took the time to do so. I saw files with .bak, .bak.bak, and every perversion of a date format used to create filenames such as my\ foo.bar.baz(qux).051006.bak.~~#123#.
I asked around. I figured maybe there was some kind of revision control system there. There was. RCS itself, the reverse-delta cousin of SCCS from the before time. However, it was out of date, and we really needed concurrant access and update to the files. After much searching for a formal procedure regarding it, I decided to implement SVN myself.
SVN is easy to use, and easy to host out of my own private account. A few extra scripts and a couple of cron jobs, and I had automated backups of the repository being archived away in a safe place. I even set up project member notification upon committing changes to the repository. It worked like a charm. No more guessing. No more difficult merges via copy/paste, or hacked diffs. And since it's not raw RCS, there were no locking issues preventing us from working on the source code.
When it came to deploying the new software, I simply checked it out of the repository as the production user, and poof! Easy updates. And even easier rollbacks, if needed. Deployment became simple and efficient.
The only advice I can give you is to always use a revision control system, regardless of the system. I have directly observed an improvement in the development process, project maintainability, and deployment consistency.
You will, too.
Contemplative, -v.
"Perl. There is no substitute."
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
|
It depends on what you enjoy. I personally don't enjoy trying to fight inertia and incompetent co-workers. If you do, then my hat is off to you. But I've been through enough pain in the past to shy away from that.
| [reply] [Watch: Dir/Any] |
|
If I was interviewing for a job, and It came up in the middle of the interview that they didn't use a centrally maintained source control system, I would walk out.
I wouldn't even be tactful about it, I would just say "I'm sorry, I refuse to work for incompetent people" and leave.
| [reply] [Watch: Dir/Any] |
Re: Revisioning systems and the lackof
by Anonymous Monk on Oct 06, 2006 at 10:40 UTC
|
I missed the boat when CVS was becoming the hip thing to do, and wrote it off the first ten thousands times as buzz ...
Huh??? If I had to guess, I would say that CVS is older than you are, and no doubt it has been "the buzz" since you were in grade school.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
Re: Revisioning systems and the lackof
by rvosa (Curate) on Aug 22, 2007 at 17:21 UTC
|
I know this is a late reply, but for what it's worth: I contribute/track about half a dozen large open source projects, all of which use revision control systems (cvs and svn). I have them all checked out into my eclipse workspace. I can't imagine having to do this with tarballs. Some people I know use revisioning not only for source code, but also for flat data files (I dabble in bioinformatics) and article manuscripts (latex). It's genius. Can a tarball tell you who did what, when, and why? The metadata you can get out of svn, from command line - but better yet if integrated in an IDE, is a godsend in collaborative projects. It keeps the managers happy also, what with all the neat graphs you can get out of it using fisheye or ohloh or something. Arguing against it is a losing battle, in my opinion. | [reply] [Watch: Dir/Any] |