Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Revisioning systems and the lackof

by EvanCarroll (Chaplain)
on Oct 06, 2006 at 02:02 UTC ( #576604=perlmeditation: print w/replies, xml ) Need Help??

I recently spent the time to learn SVN (Subversion); moreover it was my first Revision / Versioning management system. I'll start out by saying, while I was learning it I thought the whole way through, "This is a waste of time", with very few "thats neat" mixed in. I missed the boat when CVS was becoming the hip thing to do, and wrote it off the first ten thousands times as buzz or something that was just as easily accomplished with `tar cf`. Having learned it, I was wrong. I can't defend it yet, because I still had 50% of the functionality as before, which is 90% of the importance of the system, but having it; and, not being able to adequately justify the polish of it, doesn't mean I don't appreciate the system for what it is worth. If someone wanted a close analogy to working with a revision system, as compared to working without it, the closest thing I can think of is using CGI, vs utilizing a modern web framework.

While I realize that revisioning systems are often as polarized as text-editors I have to ask a more pertinent question How many monks don't use a version management system at all? And lets say we get a poll going for this!

Evan Carroll

Replies are listed 'Best First'.
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

    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.

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.
Re: Revisioning systems and the lackof
by GrandFather (Sage) 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

      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

Re: Revisioning systems and the lackof
by planetscape (Chancellor) on Oct 06, 2006 at 02:15 UTC
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.
      I'm actually thinking of putting major config files under source control
      Keeping config files under source control has saved me a lot of headaches.

      "Who changed httpd.conf, and what did you change?"
      "I dunno."
      "Not me."
      "Arrrgh... I wish I had the working version so I could diff it with this broken one..."

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:

    1. Find yesterdays tarball
    2. Unpack it somewhere safe
    3. Look at timestamps to see which files I changed
    4. Use diff on those files to find out what I changed
    5. Figure out which change breaks what
    1. Use CVS to do a diff between last CO and current files
    2. 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.

    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet
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.

Re: Revisioning systems and the lackof
by tilly (Archbishop) on Oct 06, 2006 at 05:09 UTC
    I would refuse to take a job if they did not use revision control.

    In fact I have done so in the past.

      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.

      brian d foy <>
      Subscribe to The Perl Review
        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.

        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\

        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.


        "Perl. There is no substitute."
        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.

      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.

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.

      Right; which means it was becoming hip just before he was. ;-)

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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://576604]
Approved by planetscape
Front-paged by andyford
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2018-06-20 10:21 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (116 votes). Check out past polls.