The issue is around merging binary documents. There are algorithms that
can do a (mostly) logical merge of multiple versions of a text file that
produces something legible. Try that with a binary file (a graphic is
the de-facto example) and usually the result is completely useless.
You can't use an arbitrary merge algorithm with a Word document and have
it make sense. You'd need to understand the details of how the Word
binary format works to be able to logically merge changes
(addition/deletion of text), which is why no one does it. Everyone
understands "text," be it plain-old ASCII or UTF8 in more modern
environments, which is why everyone supports it.
If you want to do merging with documentation, you need to use a
text-only format. Docbook and its siblings can be appropriate depending
on your author's comfort level. I don't know how well the XML format
that Word 2003 can produce would merge; from what I recall seeing it was
pretty icky XML.
Glenn McAllister
Sapient Canada, Inc.
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Nick Seigal
Sent: Wednesday, February 02, 2005 5:09 PM
To: users@subversion.tigris.org
Subject: Re: Binary documentation in SVN?
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" <keith@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 3 01:15:31 2005