Binary documentation in SVN?

[Keith Wellman <ke...@Bladelogic.com>]

Hi.
 
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)?
 
Scenario:
 
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.
 
so:
 
* 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
BladeLogic, Inc.
keith@bladelogic.com

Re: Binary documentation in SVN?

[Nick Seigal <ni...@nickseigal.com>]

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.

Nick Seigal

"Keith Wellman" <ke...@Bladelogic.com> wrote in message 
news:497C0B4A0C2D4B44ADDE1D8772BE98DD020CC40E@MI8NYCMAIL01.Mi8.com...
Hi.

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)?

Scenario:

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.

so:

* 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
BladeLogic, Inc.
keith@bladelogic.com 




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org