You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2004/07/24 19:10:28 UTC

Re: Locking and version control of structured documents (was: Commercial Users of Subversion: LET ME KNOW)

On Sat, 2004-07-24 at 13:34, Kenneth Porter wrote:
> --On Saturday, July 24, 2004 8:21 AM -0500 Ron Bieber <ro...@bieberlabs.com> 
> wrote:
> 
> > 3.  File Locking - We have one documentation CVS repository containing
> > Word documents and diagrams that we have not converted because of the
> > lack of locking support.
> 
> What would be required to eliminate the need for locking? I'm guessing the 
> issue is mostly the undocumented file format that makes sub-file merging 
> impossible? How does svn handle Open Office documents, which IIRC are zip 
> files containing XML files?

Subversion and CVS clients are only capable of merging line-based
textual formats, that's it.  Today, if Subversion sees an
'svn:mime-type' property on a file that indicates the file isn't
contextually mergable, then it automatically produces a 'conflict' and
leaves 3 fulltext files behind for the user to resolve with an external
tool.  (Someday we hope that the svn client will be able to launch
3rd-party merging tools for various binary formats, based on the value
of the svn:mime-type property.)

<philosophy>
Even with that feature though, nothing will completely eliminate the
need for locking.  Just because a tool exists to allow users to merge
OpenOffice or MSOffice documents, doesn't mean every team should be
*forced* to use these tools.  Many teams are happier locking these sorts
of files... sometimes users would rather not start working on a file at
all when they learn that somebody else is already editing it;  it's just
easier to wait and take turns, rather than use a merging tool.  

In other words, a locking feature (which will hopefully be coming in svn
1.2) is mainly a communication/coordination tool, not a "shortcoming" or
failure to address a larger problem.
</philosophy>



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