Thanks Edwin -- that confirms what I suspected, that a workflow for allowing
staff to collaboratively update metadata records needn't necessarily be
restricted just to Fedora, but could incorporate SVN or somesuch too.

Optimistic locking (and subsequent failure if someone else has got their
update in before yours) is workable if you're dealing with relatively quick
edit operations, but we're thinking of working with relatively complex
metadata objects (TEI XML), which we could easily expect someone to be
spending an hour or more editing before they have completed their work -- if
we simply rely on optimistic locking (with no ability to merge changes, a la
SVN), then it will be problematic trying to work out how to manually merge
changes.

Jason


On Tue, Jun 14, 2011 at 6:36 PM, Edwin Shin <ed...@fedora-commons.org>wrote:

> The closest thing available in Fedora was implemented in 3.4's REST API:
> https://jira.duraspace.org/browse/FCREPO-689
>
> See
> https://github.com/mediashelf/fedora-client/blob/master/src/test/java/com/yourmediashelf/fedora/client/request/ModifyDatastreamIT.java#L121for
>  how you might use fedora-client.
>
>
> On 13 Jun 2011, at 5:58 PM, Jason Darwin wrote:
>
> > I'm wondering if anyone can answer a question for me -- in the paast
> (i.e. pre-Fedora) we've worked with XML files on disk, being kept under
> version control by SVN.
> > The beauty of this system was that two users could simultaneously be
> editing the same XML file (i.e. from their local working copy), and not
> stomp on each other's changes. If the second person tried to commit their
> changes after the first person had already committed theirs, SVN would
> inform the second person that the file had been updated in the interim, and
> give them the option to merge these changes made by the first person in to
> their own copy of the file, before allowing them to commit the merged
> results.
> >
> > My question is: is there any way of working that allows a similar
> workflow with Fedora? From what I've seen so far, only one user at a time
> can be editing an object and hope to have their changes saved back to Fedora
> -- i.e if two users try to simultaneously try to update the same object, one
> of them (i.e. the second) will win (their changes get saved over the changes
> of the first user).
> >
> > Thinking about this has led me to wonder if I shouldn't be looking at
> keeping using SVN (to preserve the ability for two users to work
> simultaneously), and introducing a post-commit hook to update Fedora
> whenever a changed document is committed to SVN.
> >
> > Jason
> >
> >
> ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> >
> http://p.sf.net/sfu/ephox-dev2dev_______________________________________________
> > Fedora-commons-users mailing list
> > Fedora-commons-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Fedora-commons-users mailing list
> Fedora-commons-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Fedora-commons-users mailing list
Fedora-commons-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users

Reply via email to