I too am curious about this. I think there must be some tricks of the trade
here. Certainly documentation is not as error-prone as code is (the typical
use of Subversion), so if merging works for code, I fail to see whey it
wouldn't work for documents. The red-bean Subversion book mentions levels
of risk-averseness in how Subversion is used (see
http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-4-sect-4.4.2) and I
think the strict level -- including all requiring all patches to be done in
feature branches, then reviewed, approved and merged by central command only
(which is how Linux does it I think) -- would be a good idea for you and
might soothe your editors.
"Keith Wellman" <keith@Bladelogic.com> wrote in message
I'm looking for information about using svn for documentation versioning.
I'm wondering if there is a recommended way of using svn to handle this sort
of situation (outlined below)?
We have a tech writing staff that works mostly in framemaker, which uses
binary files for storing their various booksets and are used to generate
pdf's and other rich (and binary) document formats.
Their classic mode of operation in other source control systems is to make
use of the exclusive locking mechanisms to prevent concurrent work on the
same files. My understanding is that svn is not looking to support any
locking mechanism until the 1.2.0 timeframe (or later).
I'm not aware of any good tools that would handle merging of these sorts of
files, and I've met strong resistance from the writing staff about how well
merging could be done even if the right tools could be found.
* is there a svn "best-practice" for this sort of work? I suppose "no" is a
perfectly reasonable answer.. :D
* if there is one... what is it?
We certainly have the option of keeping documentation in a separate
versioning tool, but I'd like to avoid that if it isn't too much of a burden
on out tech writers to use subversion. But they do seem to have valid
concerns about concurrent changes to framemaker files being difficult or
impossible to deal with.
Thanks for any help this list can provide.
-- Keith Wellman
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Feb 2 23:53:40 2005