Version control is superior than other "sync" solutions when the data is:
- Modified mainly by humans, at human speeds
- Mistakes can be made and need reverted atomically
- Data integrity and chains of changes need to be preserved
I agree with the article that PG is a great example of where version control could work with great effect.
The downside is that teaching non-techies how to make it work is difficult, and the first time a merge is required they're frequently in too deep. This is more of a human problem - Word's revision tracking is somewhat inscrutable as well...
I'm the author of TFA and I must completely agree with you on this point. Is there a human-friendly VCS out there? I don't care how featured or not it is, as Git can be configured to pull from it (a la git-svn). Just anything that non-tech-related persons (or even just non-coders!) can use without wanting to pull their hair out and feeling very stupid?
For example, one of my software products has translations powered by the community. The entire translation files (XMLs) are hosted on GitHub, yet invariably all the volunteers would much prefer to email me their translations and I commit them on my end with silly commit messages like "Commit by John Doe jdoe@example.com with fixes for bla bla bla"
---
I suppose a web interface to git could be written, but it would be very limited and would have to be strict about what can/cannot be uploaded. But multiple drop downs with a simple "pick the file you have an update for," "pick the version your changes are based on," "browse for the new version of the file," and "what changes did you make?" inputs would probably be enough for the vast majority of non-techies..
Depends on what features you need. I've seen wikis used as "human-friendly" VCSes. There is no branching, forking and automated merging in most implementations... But that might be good things, based on who your target group is.
Mercurial (Hg) with TortoiseHg might be a good option. You could even create a pre-configured PG version, to make it even easier for novices. Along with a guide on the basics, I think that could end up working quite well.
Hg also has the benefit, compared to Git, of being strictly cross-platform.
I think Mercurial (and Git) is ridiculously complex for a non-technical user (say, my mother, who has helped with translation projects online, using Word + email). TortoiseHg is great as a GUI version, but it doesn't effectively reduce the complexity - you still need to understand the basic concepts of a DVCS to use it.
In graph, they'd be like:
|--|------------------------------|-------------------------------|
git hg wiki actually usable
by non-techies
Completely agree, but with this limited use case it should be easy to provide a tool to abstract away the complexity and give them easy access to the very few features they need.
Something like Github's "forking with the edit button"[1] functionality would be perfect for this. If you want to make a correction, press a button to see the content you were looking at in a web-based editor. Make your changes, and add your email address to a notification field. Changes go into an approval queue, and you get an email if/when your change goes live. No need to expose the casual user to the perils of DVCS, though of course a "proper" git-based infrastructure would exist in parallel for people who want more control.
Indeed, I've been working on this type of tool (without the distributed component) for blog authors who want user-submitted corrections: http://edithuddle.com
When you want a central, de-facto version, it makes sense to have a way of aggregating "similar" corrections (both in type and content) from changes.
Oh it's nowhere near halfway there. I think the idea of using git is a fine one, but some software engineering is very much required. Ideally the project would work for all phases including pushing updated copies to consumers. Once you think in those terms you start approaching a product that's going to work for non technical editors and writers.
A customized book reading application that allow critical readers to make marginal notes and corrections, and see and rate other people's marginal notes and corrections would be the ticket.
The downside is that teaching non-techies how to make it work is difficult, and the first time a merge is required they're frequently in too deep. This is more of a human problem - Word's revision tracking is somewhat inscrutable as well...