Open MPI logo

Docs Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Docs mailing list

Subject: Re: [OMPI docs] Defining an Authoring Environment
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2007-12-18 16:45:51


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.

Check out:

   http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.advanced.locking

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
> content?
>
> 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.
> <R>
> <rchrd.vcf>_______________________________________________
> docs mailing list
> docs_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/docs

-- 
Jeff Squyres
Cisco Systems