> Your average college professor isn't going to learn how to use a version control system to suggest changes to his student's thesis-in-progress.
Word has version control though, and it's appreciated by many in academia. Version control for humans is a Big Startup Idea, I wouldn't be surprised if Dropbox and Github were trying to tackle it (from 2 different angles: Dropbox from the "how do we get average the user to get features for nerds", and Github from the "how do we get the average non-nerd to use us")
Word's review functions appear as pretty colored bubbles and a bunch of icons on the Ribbon. It's easy enough even for Humanities professors to use on a daily basis, despite the fact that as a VCS, it's strictly inferior to something like git. Actually, I think it's popular precisely because it ain't git. Most professors who are fluent in Word's review functions would be hopelessly lost when faced with a Dropbox conflict, let alone merging git repos.
Totally agree that word's review functions are really simple. Which is why even all legal/contract documents are exchanged back and forth between companies in Word today. The hassle is that its done over email - sending versions of attachments back and forth. Nice naming convention helps, but there are definitely better solutions to do the same online today.
Actually, most big law firms do not use the built in track changes function in Word, they use more specialized (and in my experience, better performing) software that take a "before" and "after" Word file and then generate a nice "redlined" version showing insertions, deletions, moves, etc. in different colors. Examples include Workshare DeltaView and Litera Change Pro.
I think you're absurdly underestimating people. A diff is a bunch of lines removed, and lines added. That's a pretty damn natural representation.
As for git's complexity, it's all in its completely opaque display of its internal state. A chain of deltas - diffs - isn't complicated. It's all git's (perverse) desire to follow the exact-same command-line interface as cat and awk, when neither contain persistent state.
It's not the concept of a diff that baffles ordinary people. It's (a) the lack of an intuitive interface, and (b) poor integration with natural languages, that make most VCS's difficult to use in the context of a word processor.
Word shows pretty bubbles next to sections that have been edited. The bubbles are color-coded so it's easy to tell who did what. The edits can be accepted, rejected, or further modified with a couple of clicks. There is no list of commands or keyboard shortcuts to memorize. Just a bunch of icons, menus, and clicking around.
Word doesn't require your content to be made up of neat lines of verse, either. Natural languages don't organize themselves into 78-char lines. It should be OK to edit a few words in a long paragraph of prose. Even Wikipedia's messy "Revision History" is probably better than git in this regard.
'a bunch of lines removed/added' is a great representation for stuff that consist of semi-atomic lines, like code.
It is a horrible representation for stuff where edits may consist of both typo fixes, and separate wording changes in a single sentence - where you might want to accept change to one word and reject change to another word, despite that they came from a single "commit" to a single line.
For collaborative text editing both word's track changes and google docs features are far superior to git.
FWIW, I don't often encounter diff output in my day-to-day computer usage, but when I do, I do not find them very intuitive to understand. A bit of UI magic would help here, it's not the concept that is hard (for me) to grasp, just all those lines with +'s and -'s and figuring out the contexts in which they apply. It's always a bit of a puzzle, especially if, for some reason, it's not highlighted with colours.
Our startup takes a third approach: automatically detect when one document is a new version of another, so that software can take care of the version control, while the humans can go on being human.
We're bringing version control to people who collaborate by email, starting with Gmail. All people have to do is exchange drafts by email (like normal!), and we infer the history, as if they've been using git.
This looks quite interesting and quite topical to a discussion I had just yesterday during an interview. I almost clicked the installer but hesitated. A link that discusses the impact and especially any issues if/when your product was uninstalled would be reassuring.
with the answer to your question (and more), but I'll answer here too:
We don't modify the data in your Gmail account, so if you try Draftable, then uninstall it, your Gmail account won't be altered. Furthermore, if you disable Draftable before uninstalling it, we'll delete our index and revoke our access to your account.
Version control in physics research: a pile of printed documents
Collaboration in physics research: hand-written notes on margins of said pile
The issue with git etc is that everyone involved has to understand how it works and accept and appreciate the benefits over the system outlined above (which works quite well for papers with few authors). If even one author doesn't care, you cannot implement the system. And good luck getting professors to care about things that aren't research or funding.
Version control in Word (and pretty much any WYSIWYG editor) is fundamentally broken. I can't recall how many days of work I lost just because 1 out of 15 co-authors was not able to use it and fucked up everyone's text. And normally there's just 1 out of 15 that IS able to use it. If you're authoring papers on your own, heh, you could just be using pen and paper.
And if some of them can't use it, teach them. And revert to the previously non-fucked up version (it's on someone's email by the name of Article_1_fixed_2_corrections_10_10.docx)
I had to deal with that situation before but I was actually the middle of three parties. (I was B of A-B-C where. A and C was not talking to each other for political and linguistic reasons.) It was nothing but a mess, my inbox would be piled with revised document that often lost tracking, one party sending revised document based on outdated version. (And not sure which version was it.)
Something I like about version control is that it at least ensures continuity of the version.
Yours sincerely, a graduate student whose thesis is written in LaTeX and then converted to RTF and then hand edited so his supervisor(s) can give him comments.
I sent them a link to my github repository, but they never took me up on my offer :(
You're much better off converting your latex--provided you don't have a bunch of kinky formatting--to docx via Pandoc.
I've found that collaboration on documents via Markdown is not too crazy bad. Otherwise, I ask for comments on the PDF or on hard copy. Going back to latex from RTF is an exercise in madness.
If you don't already do it, set up separate branches for each advisor/supervisor so you can add their comments there, then merge it back with your own work. i.e., just pretend that they're using git too, but do it for them.
And I second the pandoc recommendation if you can get it to work
I actually do make bit of things in LaTeX through Org-mode at the office, and sending things in PDF actually makes it clear what kind of handling I'm looking for. If I'm actually expecting someone to revise my writing, then I'll just send them plaintext.
Now considering even Adobe Reader allows commenting, I don't think there are many of issues any more...
Couldn't agree with you more. My SO is a PhD candidate and she doesn't know what she's missing when it comes to collaborative version control. They spend a lot of time sending around modified office docs.
Well, some people claim that tar balls and patches are a much superior source control management system than CVS. So you could say that unless you want every Joe User to master git, sending around modified office docs might not be the worst of solutions.
No offense, but using git for collaborative writing? That's like using nukes to get rid of mosquitoes. SVN would be a poor but better choice, but you'd rather use stypi, google docs or something like that.
Wow, do I disagree. I use version control (hg) for solo writing, and I'd love to use it for collaboration if I didn't think it would be an uphill slog to convince my coauthors to learn it too.
I'm guessing that you too have opened a recent-but-not-current doc, made changes, added polish etc, only to realise a few hours down the track that you opened a legacy version. Having multiple backups with numbered version names etc is all very well, but when you do it manually and you are working late at night, tired, it's way too easy to screw up up. Better document version control sounds excellent.
I can not think of any scenario where svn would be preferable over a distributed vcs such as git or mercurial. They can both be used exactly the same way as svn if you feel for it but come with tons of other benefits. I even think there's less friction to start with for non techincal people because you are always working in "everything always checked out"-mode and there is no need for a common server. Just let them edit in peace and when you want to merge then pull from their local repo.
I don't know the state of visual tools for git but tortoisehg for mercurial is quite easy to get started with.
What? The result would be exactly the same, right? You don't have your unpushed commit if your laptop is broken, neither with svn nor with git. The only difference is that you still can use your local git repository if your server burns down, but you can't do that with svn.
>The only difference is that you still can use your local git repository if your server burns down, but you can't do that with svn.
Even then I can `svn relocate`.
Look, I am not defending SVN for software development, I am a happy git camper. But git for technical writing is simply the wrong tool for the wrong job.
The biggest advantage of svn over git for non-technical users is that you can never end up with commit that then conflicts with another submit (as submits all happen on the server).
I have had various beginner git users get very confused when dealing with conflicts -- I have got myself quite confused on occasion too.
I have always used source control for papers I write in groups - it's just assumed we're going to use source control. The only discussion is which one. I've used cvs, svn, git and mercurial when writing papers. Our papers are written in Latex. We often commit raw data and benchmark source code to the repository too.
that's a dumb thing to say. It's reasonably frequent that the best tool for a job is one that scales from the smallest possible use case (individual) to the largest, smoothly and without hassle. Git fits this criterion. SVN is a real pain by comparison.
Well, I believe in YAGNI. Throwing the biggest possible solution onto a small problem because it might get a large problem is speculative thinking. Which is bad.
That's different. YAGNI (e.g. starting with oracle where sqlite is probably all you need) is different to using tools designed to (reasonably transparrently) scale from the smallest use case to the largest.
Yeah, our creative writing tool (backspacr.com) uses versioning at the scene/subchapter level, and it's definitely nontrivial to present diff and merge tools to end users. We're working through customer stories right now to try and do discovery on just this issue.
Word has version control though, and it's appreciated by many in academia. Version control for humans is a Big Startup Idea, I wouldn't be surprised if Dropbox and Github were trying to tackle it (from 2 different angles: Dropbox from the "how do we get average the user to get features for nerds", and Github from the "how do we get the average non-nerd to use us")