Subversion for collaborative document editing?

[Wolfgang Keller <wo...@gmx.de>]

Hello,

in our office (technical consulting company) we work a lot on quite large, 
structured documents (project reports), usually multiple users at once one 
the same document. Currently we are using youknowwhat for these documents and 
it's the usual mess, not just for merging all the modifications by all the 
editors. Now that I've found out about a quite affordable (much less $$$ than 
e.g. Framemaker) and "clickdroid"-proof "native" XML authoring application, I 
would love to replace this mess with a more efficient toolchain.

The basic idea is to use a sourcecode-management software to store the 
"source code" of the documents, which would be "native" XML (probably 
docbook). After looking at a few available SCM systems, I would prefer 
subversion for certain reasons such as the availability of "clickdroid"-proof 
installers and GUIs for non-*x systems as well as documentation.

What is still unclear to me however is 

- which sourcecode-management software is the best for our needs and
- what I need between the sourcecode-management software and the XML 
authoring application so that for the end-user it looks essentially as if 
(s)he was working with "just an ordinary filesystem".

So far it seems to me that the answer to the second question is essentially 
"a WWW server that supports WebDAV" (e.g. Apache with Mod_DAV) on the server 
with the SVN repository. The WebDAV server can then be mounted on the clients 
and the files can be retrieved and stored "as usual", the end-users just 
don't see any difference between the currently used file server and the 
WebDAV server. Diffing and merging of the modifications would have to be done 
on the server, more or less manually. Correct?

The answer to the first question apparently depends a lot on our requirement 
to support offline work with documents. We have a lot of free-lancers who 
work from home and we also work a lot abroad ourselves (using notebooks with 
fairly limited hardware resources). Does this mean that Subversion would not 
be an adequate choice for us? Do I have to look into one of the "distributed" 
sourcecode-management systems instead?

TIA for any help (and if available references to any documentation on this 
kind of application for sourcecode-management tools)

Sincerely,

Wolfgang Keller 


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

Re: Subversion for collaborative document editing?

[Wolfgang Keller <wo...@gmx.de>]

Hello,

and thanks for your reply.

On Wed, 21 Jun 2006 19:38:41 +0200, Ryan Schmidt wrote
(in article <02...@ryandesign.com>):

> AFAIK, your requirement of simultaneous editing of documents makes  
> auto-versioning over WebDAV non-optimal, because I believe it leads  
> to the following pattern:
> 
> - User A opens a document
> - User B opens the same document
> - User A makes changes and saves the document
> - User B makes changes and saves the document, thereby overwriting  
> User A's changes
> - Neither User A nor User B are aware that this has happened

Exactly.

My understanding of the setup was the following:

WebDAV is in fact simply used as a "network filesystem" used to access the 
Subversion repository.

The fact that "behind" the WebDAV connection there is a Subversion repository 
should allow to keep all modifications, each "save" by a user just creates a 
new version of the same file containing the "diff" to the last version. 
Afterwards, someone just takes the latest versions of each user and merges 
them on the server, using the corresponding subversion commands.

What's wrong with this understanding? I'm totally ignorant of version control 
systems in general, as well as Subversion and WebDAV in particular.

> If you teach your users revision control techniques, including having  
> their own working copies of things on their own machines, writing log  
> messages describing what they do, and how to merge and resolve  
> conflicts, then you empower users to avoid this situation.

The point is to avoid having to teach each and every "clickdroid" >:-> in the 
company such revision control techniques - and "enforce" their correct and 
consistent use afterwards!

> I don't know how well you will be able to merge or resolve conflicts  
> in your XML formats. 

This mostly depends on whether Subversion allows to use the right diff tool 
and how well this diff tool can handle specifics of XML files (such as 
whitespace insignificance etc.). But that's a topic that I will have to solve 
independently.

>> The answer to the first question apparently depends a lot on our  
>> requirement to support offline work with documents. We have a lot of 
>> free- lancers who work from home and we also work a lot abroad ourselves 
>> (using  notebooks with fairly limited hardware resources). Does this mean 
>> that Subversion  would not be an adequate choice for us? Do I have to 
>> look into one of the  "distributed" sourcecode-management systems instead? 
> 
> Subversion is said to have been designed for low-bandwidth  
> connections. The philosophy is that disk is plentiful and cheap, and  
> network access is limited. So if everyone has their own working copy  
> on their local drive and updates and commits as necessary,  
> distributed work shouldn't be a problem.

My point was to avoid that each and every contributor to a document would 
have to use Subversion commands - this should be equired _only_ for the one 
who merges the contributions of the different users.

Plus, XML document authoring software usually does not offer integration with 
version control systems, so somehow
 
> WebDAV access would, of course, be a problem in that setup, because  
> you'd need a constant WebDAV connection to the server. (Another  
> reason to avoid WebDAV in your situation.)

I would _love_ to get rid of the requirement to run a WebDAV server as well.

The functionality I need in fact is something that

- can be routed over TCP/IP
- looks like an ordinary filesystem to the client application
- does NOT overwrite the existing file on each "save"
- but instead store just the "diff" to the last saved version in a new 
version of the same file.

TIA,

Sincerely,

Wolfgang Keller

-- 
My email-address is correct.
Do NOT remove ".nospam" to reply.


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

Re: Subversion for collaborative document editing?

[Ryan Schmidt <su...@ryandesign.com>]

On Jun 19, 2006, at 20:15, Wolfgang Keller wrote:

> What is still unclear to me however is
>
> - which sourcecode-management software is the best for our needs and
> - what I need between the sourcecode-management software and the XML
> authoring application so that for the end-user it looks essentially  
> as if
> (s)he was working with "just an ordinary filesystem".
>
> So far it seems to me that the answer to the second question is  
> essentially
> "a WWW server that supports WebDAV" (e.g. Apache with Mod_DAV) on  
> the server
> with the SVN repository. The WebDAV server can then be mounted on  
> the clients
> and the files can be retrieved and stored "as usual", the end-users  
> just
> don't see any difference between the currently used file server and  
> the
> WebDAV server. Diffing and merging of the modifications would have  
> to be done
> on the server, more or less manually. Correct?

AFAIK, your requirement of simultaneous editing of documents makes  
auto-versioning over WebDAV non-optimal, because I believe it leads  
to the following pattern:

- User A opens a document
- User B opens the same document
- User A makes changes and saves the document
- User B makes changes and saves the document, thereby overwriting  
User A's changes
- Neither User A nor User B are aware that this has happened

You should construct a test scenario to see if this actually occurs,  
but I'm led to believe it does.

If you teach your users revision control techniques, including having  
their own working copies of things on their own machines, writing log  
messages describing what they do, and how to merge and resolve  
conflicts, then you empower users to avoid this situation.

I don't know how well you will be able to merge or resolve conflicts  
in your XML formats. It depends on the specific XML format. I'm not  
familiar with the internals of docbook. I've just heard stories on  
the list about certain IDEs using XML files that are very non- 
mergeable because they include system-generated unique sequential ID  
numbers which then become non-unique during conflict resolution,  
causing problems. You may just have to try it out -- construct a few  
conflict situations and see how easy it is to resolve.


> The answer to the first question apparently depends a lot on our  
> requirement
> to support offline work with documents. We have a lot of free- 
> lancers who
> work from home and we also work a lot abroad ourselves (using  
> notebooks with
> fairly limited hardware resources). Does this mean that Subversion  
> would not
> be an adequate choice for us? Do I have to look into one of the  
> "distributed"
> sourcecode-management systems instead?

Subversion is said to have been designed for low-bandwidth  
connections. The philosophy is that disk is plentiful and cheap, and  
network access is limited. So if everyone has their own working copy  
on their local drive and updates and commits as necessary,  
distributed work shouldn't be a problem.

WebDAV access would, of course, be a problem in that setup, because  
you'd need a constant WebDAV connection to the server. (Another  
reason to avoid WebDAV in your situation.)



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