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
Received on Wed Jun 21 19:41:19 2006