Yes, you can lock files. We don't use this model in the OMPI
community, but given the fact that you'll be working with binary
files, it's probably a good idea.
In particular, check out the part at the end of the section about the
"svn:needs-lock" attribute -- it looks like that would help quite a bit.
On Dec 18, 2007, at 4:35 PM, Richard.Friedman_at_[hidden] wrote:
> Jeff Squyres wrote:
>> Sorry; I missed this post.
>> SVN can handle any type of file. It works best with text-based
>> files (to capture diffs between revisions), but it'll work just
>> fine with binary files, too. You'll need to be careful between
>> revisions -- SVN won't be able to integrate changes from two
>> different sources. E.g.:
>> - foo.odt is in the repository at r1
>> - Bob makes a change to foo.odt and commits the change at r2
>> - Alice makes a change to foo.odt *r1* and tries to commit
>> Alice's change will not be able to be merged back in because
>> foo.odt is a binary format and SVN doesn't know how to merge it
>> in. SVN in this case will detect the discrepancy and tell Alice
>> that she can't check in -- there's been a conflict that a human
>> needs to resolve. So Alice will need to get the new foo.odt at r2
>> and manually integrate her changes in. Then she'll be able to
>> commit it back to the repository.
> So I assume the workflow for Alice must be something like:
> 1. grab the latest revision (the one that includes Bob's changes)
> 2. edit that revision
> 3. commit it.
> Is there no way to lock a revision while you're working on it (like
> SCCS) so no one can commit while you are actively editing that
> What I think we'll have to implement is a verbal agreement that only
> one person work on a chapter at a time to avoid such clashes.
> Since the team is pretty small, I don't see that as a problem.
> docs mailing list