[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: Binary documentation in SVN?

From: Keith Wellman <keith_at_Bladelogic.com>
Date: 2005-02-03 15:13:39 CET

Sorry for the top post, but my mail client sucks.

Yes, it's clear that binary merge is too context dependent to
generalize, and it appears that subversion wisely punts on the issue and
simply provides the files that any merge program would want (e.g.,
merge-left merge-right working). Leave it to some 3rd party to support
merging.

I'm new to subversion, but in practice I expect when dealing with binary
items such as images or 3rd party binary libraries - there is no
sensical interpretation of a merge. You want one or the other and it's
easy to grab the right one and slam it into place. Svn deals with this
situation in fine fashion.

The problem arises when you have 'binaries' such as Framemaker binary
files that can very reasonably be logically merged, but the nature of
the binary markup makes it difficult to do (or too niche to bother
doing). So unless Adobe provides a whiz-bang cool merge tool for
Framemaker documents (which I don't believe they do) AND my tech writers
feel comfortable using it (which they wouldn't) - they are left in fear
of parallel changes to any document. This leads to their reliance on a
locking / serial model for version control.

So unless I'm missing something key to this issue, it looks like
subversion really isn't the place for them until it can support an
exclusive locking model.

From what I can gather on the mail lists - this is in development now.
Time for me to check the roadmap.

If anyone has any further thoughts on the issue, I'd love to hear them.

Thanks
 -- Keith

-----Original Message-----
From: Glenn McAllister [mailto:gmcallister@sapient.com]
Sent: Wednesday, February 02, 2005 7:13 PM
To: Nick Seigal; users@subversion.tigris.org
Subject: RE: Re: Binary documentation in SVN?

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 3 15:27:25 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.