RE: Large help projects and version control software

Subject: RE: Large help projects and version control software
From: Jon Konrath <Jon -at- datasynapse -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Mon, 19 Aug 2002 14:06:21 -0400

> The check-out procedure serves several purposes. Yes,
> it puts a copy of the doc on the local machine. But
> it also locks the file so that only the person that
> checked out a file can check it in. That safeguard
> is there to protect your team from itself. It alerts
> the rest of the team that someone is working on that
> file so that they won't. What you're protecting against
> is two people making changes to the same file and losing
> one person's changes when the two new versions are saved
> one atop the other.

This isn't true with CVS; it doesn't support a lock system. Multiple people
can check out the same files and modules, and then attempt to check them
back in. When you're doing something in ASCII, like HTML or C code, this is
a Good Thing, because it will calculate your differences from the last
version and apply them. Depending on your version and platform, it can
sometimes do a pretty good job of figuring this out. If not, it will barf
when you commit your files, and you're forced to reconcile the differences
by hand.

If your files are binary (MS Word, Frame), CVS won't be able to diff changes
at all, and you'll be in trouble when two people check in their changes from
the same original version. The second person's changes will go right on top
of the first person's changes.

RCS and SourceSafe do locking (and I think Perforce, but it's been a while.)
Otherwise, you need to have a good procedure for making sure people aren't
working on the same files. Everyone will still have *copies* of the files
on their personal machines, and they will be editable. Everyone can be
making changes, compiling help, and all of that. The problem will come when
they need to check their stuff back in.

> IMO, the larger the team, the more important to follow
> an appropriate process.

...which is very true.

Dumb trick: When there were two of us working on a help sysem (among a few
other projects), we had this toy from a McDonald's happy meal that
represented our virtual "lock" on the CVS files. If it was on your desk,
you could check in. If you weren't working on the files, you put the toy on
the other person's desk. If you wanted to check in files and the toy wasn't
on your desk, you went looking for it. Dumb, but it worked.


Jon Konrath, Technical Writer
DataSynapse, Inc.
jon -at- datasynapse -dot- com
View the DataSynapse email disclaimer here:

Check out the new release of RoboDemo, our easy-to-use tutorial software.
Plus, buy RoboHelp Office in August and save $100 with our mail-in rebate.
Get details and download free trial versions at

TECHWR-L is supported by ads and sponsorships...and donations.
You can help maintain the TECHWR-L community with donations

You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit for more resources and info.


Previous by Author: RE: MS Word--Page Breaks
Next by Author: RE: Word Macros, Toolbars and Screentips
Previous by Thread: Re: Large help projects and version control software
Next by Thread: Re: Large help projects and version control software

What this post helpful? Share it with friends and colleagues:

Sponsored Ads