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.
WRT to Susan's inquiry about Subversion, but taking it
a bit further in hopes of piggy-backing on the
discussion, here's my current company's story:
We currently use CVS for all version control (code and
docs). Our docs platform is currently structured
Frame + WebWorks Pro (and some custom stuff in
between). We have a team of six writers, four or five
of whom are sometimes deployed on the same Big
Project.
The problem with CVS is that we cannot check out to
local sandboxes and retain Frame's file locking
feature, nor can we effectively use Frame's WebDAV
support. The latest version (sorry!) of Subversion
does support file locking. Here's what the sysadmin
for docs has to say about how to use Subversion to
solve these problems (which may or may not be part of
what you're dealing with, Susan):
<from sysadmin>
For CVS reasons, we want each user to have their own
sandbox, however to gain file-locking for frame we
need a shared webdav workspace.
These needs seem to be at odds, however I think we can
get around it pretty easily with careful deployment
architecture. Here's my current idea:
1. have users get a fresh checkout in their own
private webdav space, and maintain a server-owned [can
be from a read-only account] checkout as well.
2. setup a cron job to update the server's sandbox
very often, and have it rsynced to the shared webdav
workspace without the CVS metadata -- this needs to
play nice with webdav file locking however!
3. setup cron jobs for each user, to have the shared
workspace's files (which are effectively an
often-updating CVS export, without the CVS metadata)
rsynced over each user's sandbox.
4. users then connect frame to the shared webdav copy,
where should be able to experience the file-locking
benefits of SVN 1.2+ in frame -- users only change
files here!
5. when users want to commit their work, they commit
*from* their own sandbox, not the shared webdav space.
Their own sandbox can also be webdav, but should not
be shared (to avoid sandbox corruption).
IMPORTANT: users should not *write* any files to
their own sandbox under this plan, which can be
assured by making it read-only I think.
IMPORTANT: the limitation I see here is that users
could still commit to CVS work done by other users!
This sounds bad, although it might be workable by
responsible and well-trained CVS usage.
</from sysadmin>
Any comments, thoughts, cautions, further inquiries?
HTH&TIA,
Jennifer
Senior Manager, Documentation
a company that wants to keep its name away from Google
searches
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help 2005 converts RoboHelp files with one click. Author with Word or any HTML editor. Visit our site to see a conversion demo movie and learn more. http://www.componentone.com/TECHWRL/DocToHelp2005
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
