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

Re: Subversion for collaborative document editing?

From: Wolfgang Keller <wolfgang.keller.nospam_at_gmx.de>
Date: 2006-06-22 18:36:08 CEST

Hello,

and thanks for your reply.

On Wed, 21 Jun 2006 19:38:41 +0200, Ryan Schmidt wrote
(in article <023F8E6A-3145-4A27-A498-D537A05CF450@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
Received on Thu Jun 22 18:39:13 2006

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.