All the Perl that's Practical to Extract and Report

CVS for non-programmers

Ovid on 2003-02-04T17:38:06

How do you explain source control to a non-programmer? Our creative department head was chatting with me yesterday and said that he has no idea why we use CVS. It makes no sense to him. Despite the fact that he's been using CVS for months now, it wasn't until today that I faced the mess that his confusion has caused (and that's certainly curious timing).

I needed to update a few query strings in some HTML docs, only to find that he's been editing files directly on a server without bothering to check changes into CVS. He'll toss new files out there just to "test things out" and we don't know what goes with what. A simple change that should only have taken a few minutes is now a few hours of wading through this mess. The creative department head and I get along very well, so if I can find a way to explain it to him that he understands, he'll be receptive, but so far he's found no value in tracking older versions of what he does. Sigh.

Benefits that he should understand:

  • Track history
  • Ease of collaboration
  • Backup of work done

Update: Our CTO had a chat with him this morning. Apparently, as a result of that chat, the creative director went through and got everything straightened out in CVS. He wiped out all of my work from yesterday, too.

Benefits that he should understand

wickline on 2003-02-04T19:02:54

Examples often work well.

PHB seven layers up the chain of command wants something to work the way it worked seven months ago when he last used it. Suppose you don't use CVS. You go to the sys admin folks and ask for a restore from backup to some handy location so you can do a diff. They tell you that the tapes from that period are no longer available on site.

Two weeks later you have the backup from the tape.

You diff the files and realize that the feature the PHB wanted wasn't implemented then. It was an enhancement idea that you were just toying with and may have had in there for a couple of hours before reverting to the normal version. Or maybe you left it in there, but someone else had that file open before you and their save stomped over your change. You don't really remember because at the time you didn't care: the feature was just an experiment.

You ask the sysadmin folks if they can get that version you had during that few hour window on the afternoon of that day (when apparently the PHB must have used the application). They tell you that 'nope' they only generate these changes each evening, so anything that exists only in between nightly backups won't get saved to tape.

Hmmm. Looks like the code is irrevocably gone and you'll have to redo it from scratch and hope you do it right because this PHB is seven layers up the chain of command.

The above is also a an example of why you should have separate development and production systems, but the same reasoning can apply when you're talking about your own code in your own development environment. If you want some code you created some time ago, how easy is it for you to get it?

It also sounds like your current snafu situation would make a good example.

-matt

CVS for nonprogrammers

da on 2003-02-04T19:40:06

Sometimes I think O'Reilly really should have published an entire CVS book, not just a pocket reference, which does the neophyte user little good for understanding the concepts. Unfortunately I haven't seen a book or FAQ that would really help in this situation. I'd love to know of one.

I was working on a project for a graphic design firm that wanted a revision control system, but they and their clients did not want to change their current behaviors.

What we settled on was a WebDAV (Distributed Authoring and Versioning) folder their Windows machines could connect to. DAV would transparently handle concurrency/locking. My code transparently made backups of everything they saved. The clients didn't really care about version comments or merging files together.

Behind the scenes the WebDAV stuff worked on an Apache server with custom mod_perl handlers to talk to an Oracle database to store revision info. The backup files were simply numbered .gz copies in a mirrored directory structure on the DAV folder. It met the clients' needs and it worked pretty nicely, too. If you'd like more info about this, I'd be happy to provide it.

Perhaps you should stage a few disaster situations for your graphic guy to recover from- such as editing a file while he's editing it and overwriting his changes. Nothing teaches like real-world experience. Or, since you like the guy, just demonstrate how smoothly and efficiently things can work with CVS in place- version logs, etc... :-)

Re:CVS for nonprogrammers

rooneg on 2003-02-05T00:44:37

if you want autoversion'd WebDAV without having to write a custom backend, Subversion can do that, although you have to use a bleeding edge version of apache, and the support is still a bit flakey (as our WebDAV/DeltaV support is currently limited to pretty much 'what we need to make svn work'). some people have reported success with it though. see here for some details.