TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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 http://www.ehelp.com/techwr-l
---
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 http://www.raycomm.com/techwhirl/ for more resources and info.
