<p>I notice that no one is giving the "small" tutorial for <a href="http://git-scm.com/">GIT</a>, so I'll try to cover it.  GIT is faster and superior to SVN, but maybe it is easier for you to get an SVN account on a server at your university, since SVN is well established.  Also may of your collaborators would know how to use it.</p>

<p>Even if you collaborate using SVN you may want to use GIT for your own local versioning (I do!).</p>

<p><strong>First bit of warning</strong>: GIT is very powerful and for basic usage is only slightly harder to use than SVN (e.g., one option to be added in the command line; two steps commit for central repository).</p>

<p><strong>Second bit of warning</strong>: GIT has the philosophy of considering a set of changes to be atomic (a $\Delta$ as they call it) even if the set spans several files.  Also in GIT you have the notion of <strong>local</strong> repository and <strong>central</strong> repository.
<strong>GOOD</strong>: You can work offline.
<strong>BAD</strong>: You need two steps commit to a <strong>central</strong> server.</p>

<p>Basic commands assuming you already have a repository</p>

<ul>
<li>Clone a repository: <code>git clone &lt;url&gt;</code></li>
<li>Update your local repository: <code>git pull &lt;repo&gt;</code> or just <code>git pull</code> if you cloned as above.</li>
<li>The pull command really does both <code>git fetch</code> and <code>git merge</code>.  The former "fetch" stuff from the central server, and the second apply a merge of your files and the ones of the server. </li>
</ul>

<p>The merge is automatic as long there are no simultaneous edits on the same parts of some files. If the merge fails you working directory remains in a "merge state", which means that you have to fix the conflicts and then you have to commit the merged copy. If you still have unmanaged conflicts in you files then the commit would fail again, no garbage committed. </p>

<ul>
<li>Add a new file to be committed: <code>git add &lt;file name&gt;</code>.</li>
<li>Commit changes to you <strong>local</strong> repository: <code>git commit -am "&lt;textmessages&gt;"</code> or <code>git commit -a</code> if you want to edit the commit messages.</li>
<li>Push the changes in your <strong>local</strong> repository to the <strong>central</strong> repository.</li>
</ul>

<p>Notice that for pushing changes to your central repository you first have to commit to your <strong>local</strong> repository and the you have to push all the commits (even more than one) to your <strong>central</strong> repository. </p>

<p>Create a user-local repository</p>

<ul>
<li>Creation of a repository <code>git init</code> in any folder you like.</li>
<li>Done!</li>
</ul>

<p>Create a public-shared repo (also private if you pay cash) with a nice GUI.</p>

<ul>
<li>Use <a href="https://github.com/">GitHub</a></li>
</ul>

<p>Crate as many private/public repository with different groups of users but no GUI.</p>

<ul>
<li>Ask for an SSH account with no password on an accessible machine.</li>
<li>Don't worry since authentication is done by SSH keys.</li>
<li>Install Gitosis according to <a href="http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way">this tutorial</a>.</li>
<li>Now you can administrate  you own git server by editing a single file and committing it to the repository!</li>
</ul>

<p><strong>Git does not need a central server</strong>: any folder in your computer can be used as repository, so you can play with git and make your tests offline.  You can initialize one repository and simulate three collaborators in three other folders without sending one bit on the net.  This is because any cloned copy of the repository is a full featured repository to which you can commit.  This is good if you want to work in a flight between USA, China or Europe.   </p>

CC BY-SA 3.0
2014-02-26T06:58:20.940Z
Since I wrote my answer above, I have come to prefer Git, too. If you like Github but are hesitant to give your intellectual property to a company (and/or pay for that privilege), check out [Gitlab](http://gitlab.org/).
Raphael
CC BY-SA 3.0
2011-08-28T09:41:56.617Z
2011-08-28T13:15:04.337Z
2011-08-28T13:15:04.337Z
MassimoLauria
<p>Google Documents ( <a href="https://docs.google.com">https://docs.google.com</a> ) provides great tools for authoring documents together (including real time editing). It stores everything online for you and integrates well with your Gmail account. By default Google Docs does not have LaTeX compatibility, but you can enable it by going here:</p>

<p><a href="http://docs.latexlab.org/">http://docs.latexlab.org/</a></p>

<p>I am not sure how well it works for rollback, but I am sure there is a feature for it. I have heard of some people using Google Wave's LaTeX plug-in to work out preliminary sketches for papers.</p>

CC BY-SA 2.5
2011-01-30T23:28:45.560Z
Sorry, but that's probably like building the prototype of your new invention in your competitor's lab. I know that Google's tools are popular, presumable because of there ease of use and availability, but I doubt they are very often the best choice. Setting up a decent working environment is not too hard once you have put in a little inital effort. I feel that that should not be too much of a demotivator for people who spend about ten years after school in order to qualify for their job.
Raphael
CC BY-SA 2.5
2011-01-30T23:38:34.503Z
I don't compete with Google... so for me it just seems like using the easiest tool available, which seems to be one of the requirements OP asked for. Just because it doesn't run in your command line doesn't necessarily make it a bad tool. If it lacking some functionality you need, then it is an open source project, and you can use your experience to add to it. Further, if you use the development version you can even use your local LaTeX compiler instead of the one on their servers.
Artem Kaznatcheev
CC BY-SA 2.5
2011-01-31T10:11:02.697Z
Don't get me wrong, I am no CLI-only guy. I greatly enjoy graphical editors, for example (although I dislike WYSIWYG). Fact is, there are alternatives that are not provided by the biggest data miner on earth. I used the term "competitor" since, afaik, Google *does* some research in computer science, especially machine learning flavors.
Raphael
CC BY-SA 2.5
2011-01-30T23:20:52.130Z
2011-01-30T23:20:52.130Z
Artem Kaznatcheev
<p>I make my coauthors learn Mercurial, and I used to make them learn Subversion. If you are a Subversion fan, <a href="http://hginit.com/00.html">just read this</a>, it is all true.</p>

<p>No matter what system you use, by far the hardest thing is to get the other person to install the software and start using it. Skype is the perfect solution. Recent versions of Skype allow "desktop sharing" which really helps when you want to lead your coauthor through the installation procedure. And I have used straight desktop sharing combined with Skype to write a paper with my coauthor. It works pretty well.</p>

<p>What is really needed is a "Github for scientists". Something that gives a repository, has version control, collaborative editing, etc. Guess what, there is <a href="http://www.scribtex.com/">http://www.scribtex.com/</a>.</p>

CC BY-SA 3.0
2011-08-27T23:17:59.593Z
I'm using Github right now to write a survey with a collaborator. It's convenient enough and I don't feel the need for online collaborative editing since we're usually working in different sections.
Suresh Venkat
CC BY-SA 3.0
2013-09-27T14:41:05.783Z
bitbucket would give you the advantages of github with some privacy. I am testing it.
J.y B.y
CC BY-SA 3.0
2011-08-27T20:35:31.590Z
2011-08-27T20:35:31.590Z
Andrej Bauer
<p>here is a new collaborative online Latex editor called <a href="https://www.writelatex.com/" rel="nofollow noreferrer">WriteLatex</a> that looks promising, as a near one-stop shop for many scientific writing needs/requirements.</p>

<ul>
<li>works on mobile</li>
<li>has realtime preview</li>
<li>easy/private sharing</li>
<li>finds latex errors</li>
<li>allows add on latex libraries/styles</li>
<li>cloud storage</li>
</ul>

<p>the coauthor 
John Hammersley posted an announcement in tcs se meta <a href="https://cstheory.meta.stackexchange.com/a/2645/7884">here</a> and he's responsive to feedback (5 more votes on the ad &amp; it will appear on the main site). it looks like it could evolve into a valuable tool for the tcs community over time and maybe the authors will be able to implement some popular features specifically on request.</p>

CC BY-SA 3.0
2013-02-14T23:38:02.340Z
2013-02-14T23:38:02.340Z
2017-03-16T15:45:13.547Z
vzn
<p>What about simple systems, solutions:</p>

<ul>
<li>Google Docs, <a href="http://writer.zoho.com" rel="nofollow">Zoho writer</a>... and other collaborative tools.</li>
<li>Dropbox handles situations when two people try to commit changes on same file. Second committing person gets his/her file renamed (X.txt -> X.txt_blabla...) , and original file (X.txt) up-to-date with newest version. More info on : <a href="http://www.dropbox.com/help/36" rel="nofollow">Dropbox Help: "What happens if two people change the same file?"</a></li>
</ul>

<p>It's out of question, but sometimes there are situations where part of group is capable of simple solutions like SVN, while other part of group is capable of distributed version control like GIT. In such situations cooperation is possible:</p>

<ul>
<li><a href="http://www.kernel.org/pub/software/scm/git/docs/git-svn.html" rel="nofollow">git-svn</a> - Bidirectional operation between a Subversion repository and git </li>
<li><a href="http://git.or.cz/course/svn.html" rel="nofollow">Git - SVN Crash Course</a></li>
<li><a href="http://www.viget.com/extend/effectively-using-git-with-subversion/" rel="nofollow">Effectively Using Git With Subversion</a></li>
</ul>

CC BY-SA 3.0
2011-08-27T13:03:04.167Z
2011-08-27T13:03:04.167Z
Grzegorz Wierzowiecki
<p>I recently discovered <a href="http://www.sharelatex.com" rel="nofollow">sharelatex.com</a> and used it with my collaborator to coauthor a paper. I liked it so much my current plan is to use it for all my projects. Some notable features:</p>

<ul>
<li><p>Real-time in-browser TeXing (like Google Docs, but made for TeX, syntax-highlighting and all). </p></li>
<li><p>In-browser compiling and PDF viewing</p></li>
<li><p>Supports projects with multiple files</p></li>
<li><p>Has a history feature</p></li>
<li><p>Syncs with Dropbox (soon to be released publicly, from its current beta status). This way you can offload the saving of backups etc. to Dropbox. Depending on how it's done, this should also let you use sharelatex even if your coauthors don't want to, as long as they are willing to use Dropbox to share files.</p></li>
<li><p>You can download/upload your project at any time, so you're not stuck using sharelatex if something goes wrong or you change your mind or whatever.</p></li>
</ul>

<p>The only downside (but I think it's worth it): although using sharelatex is free, some of its features are not. Notably, to use Dropbox sync (when they release it), or if you want more than 6 coauthors to work on the same sharelatex project, you have to pay \$8/mo. or \$80/year [as of April 2013]. Once they release Dropbox sync though, it seems like a very fair price to me.</p>

<p>[Disclaimer: I have no relationship with sharelatex or its employees other than that I use their product.]</p>

CC BY-SA 3.0
2014-02-26T06:55:46.993Z
[It's open source now!](https://www.sharelatex.com/blog/2014/02/21/sharelatex-is-now-open-source.html) (And, fwiw, there's also [writelatex](https://www.writelatex.com/) which is similar but can be used for quick fun without registration.) That said, I would not put my intellectual property in a commercial cloud (until it's published).
Raphael
CC BY-SA 3.0
2013-04-05T21:37:48.163Z
2013-04-05T21:37:48.163Z
Joshua Grochow
<p>SVN is the tool developed for this purpose.  I would put in the effort to learn it.   It is not more complicated than learning to use say the algorithm2e Latex package or one of the pdf slide creator Latex packages.</p>

<p>Having said that, I use CVS instead of SVN.  There is better support from the CS admins at our institution (the SVN server is more user managed).  Plus, I appreciate that the underlying version files are still there and editable if something goes very-very wrong.</p>

<p>There are 2 drawbacks when compared to SVN.  File renames are not as nice, but I can live with that (pick a good name first time).  The second problem is that one needs a local CS account to access the repository.  Therefore from another institution access is only possible if an account is created first.  Of course I do not expect this to be a real problem anywhere; a local department member can probably sponsor that account.</p>

<p>The local access restriction is due to the fact that the admins do not want to support a pserver.  (Harder to secure etc.)</p>

CC BY-SA 3.0
2012-12-30T18:33:20.313Z
Downvoted because this doesn't really address the question's request for step-by-step help and because most of the advantages and disadvantages listed seem to be localized to the home institution of the answerer.
David Eppstein
CC BY-SA 3.0
2011-06-03T22:59:59.213Z
2011-06-03T22:59:59.213Z
Matyas
<p>First off: If your are interested in real-time collaborative editing, try something like <a href="http://gobby.0x539.de/trac/">gobby</a>. It lets you literally edit a document at the same time.</p>

<p>As for revision systems, I am only familiar with SVN. This is what you do, after installing subversion, of course:</p>

<ol>
<li>Get someone to set you up a repository and give you URL, username and password</li>
<li>Go to where you want to have your lokal copy</li>
<li>In a shell (command line?), type: <code>svn co url://to.your/repository</code> (check-out). Now a new folder with the repository's contents appears.</li>
</ol>

<p>That's all. Now the most basic commands:</p>

<ul>
<li>Whenever you <em>add</em> a new file <code>foo</code>, enter: <code>svn add foo</code></li>
<li>Whenever you want to remove a file, enter: <code>svn rm foo</code></li>
<li>Whenever you have made changes, enter: <code>svn ci</code> (check-in)</li>
<li>Whenever you want to get the newest stuff, enter: <code>svn up</code> (update)</li>
</ul>

<p>There are also commands for moving, copying, branching, resolving conflicts,  ... but as long as you do not try funny stuff, you are fine with the above. If anything breaks or seems to, backup your edits, delete the whole folder and checkout the whole thing anew. That's for svn like rebooting for Windows.</p>

<p>Addendum: I see you seem to be concerned about "smart merges". I assume that you refer to have to different versions of a file merged, with the assumption that two people added things in disjoint parts of the paper. As far as I know, svn would treat that as a conflict, and probably rightly so. I don't think that there is a general procedure that ensures you get what you want after two people manipulated the same source. There are graphical svn clients that visualise such conflicts and help you resolving them; they are pretty much diff-viewers were you can choose which version to keep for every conflicting line). It will require work, though.</p>

CC BY-SA 2.5
2011-01-30T23:39:16.603Z
I'll second Raphael's answer. svn is complicated, but for the vast majority of situations I never need anything except the 5 commands listed above. svn does smart merging except when there's a direct conflict: you use one phrase and someone else uses a different one in the exact same location in the text. Line breaks and all don't throw it off at all.
Suresh Venkat
CC BY-SA 2.5
2011-01-30T23:41:47.287Z
Also, you should use ToriseSVN to handle all interaction with SVN graphically; it makes everything a breeze.
Noon Silk
CC BY-SA 2.5
2011-01-31T00:00:02.793Z
I'll add to this that rather than setting up your own SVN server, I recommend using a free hosted service like http://unfuddle.com.  It's fairly painless and private.
Anand Kulkarni
CC BY-SA 2.5
2011-01-31T01:23:46.073Z
thanks, and thanks to Anand for the suggestion of unfuddle, this was exactly the 1-minute tutorial that I was looking for. I tried setting up a repository on unfuddle, making two local copies on different computers, making inconsitent edits, and checking in, and it does perform the smart merge as Suresh says. (If two users make inconsistent changes, the second one to check in  does get an error message; but if the second one updates, and then checks in, the update makes the smart merge locally, and the check-in puts the smart merge in the central repository.)
Luca Trevisan
CC BY-SA 2.5
2011-01-31T03:51:40.560Z
@Luca: SVN is pretty good like that. Occasionally you will get conflicts, and SVN will give you all the conflicting revisions and you will need to merge manually, but even this is not as scary as it may seem. You just take one of the revisions, make it the main one (by renaming it), and make the changes, and commit. PS, consider taking a look at: http://www.mirios.com.au:8081/index.php?title=Strategy_for_Scientific_Collaboration_with_LaTeX_and_SVN wherein I've described a basic setup within SVN that should allow nice collaboration. Maybe it's useful, maybe not. Good luck :)
Noon Silk
CC BY-SA 2.5
2011-01-31T04:15:52.560Z
about Raphael's off: http://etherpad.org/ - another really real-time editing tool. very promising...
Alessandro Cosentino
CC BY-SA 2.5
2011-01-31T10:06:56.870Z
@ Suresh: Cool, I did not know svn could do this. @Noon Silk: I have had bad experiences with graphical clients, in particular when different contributers used different clients. Maybe we were too stupid, but once we all used CLI svn, the problems vanished. Therefore, I am hesitant to recommend UI clients, especially since the CLI interface is (in most cases) pretty easy.
Raphael
CC BY-SA 2.5
2011-01-31T10:07:34.527Z
@Anand: If you can live with giving your data away, do this. I would expect that every university/group has managed servers were you can easily get a repository. @Alessandro: Jup, etherpad is nice too, and open and free, afaik. That means you can probably install your own copy somewhere (that has become a requirement for me).
Raphael
CC BY-SA 2.5
2011-01-31T10:12:24.473Z
I should say that many people prefer git over svn, but I have no experience with it myself.
Raphael
CC BY-SA 2.5
2011-01-31T23:28:25.333Z
@Raphael: Fair enough, I've not used differing clients (only SVN), but you are right, you need to be careful how it is set up, (ignore patterns, etc), and how you use it. Glad the CLI works for you.
Noon Silk
CC BY-SA 3.0
2011-08-28T14:51:04.953Z
@noon-silk I guess you mean TortoiseSVN, in which case you failed to mention that it's for the Windows platform only.
Janoma
CC BY-SA 3.0
2013-02-15T05:23:01.273Z
Subversion is a poor solution compared to Git with GitHub. See the answer below for reasons to use Git with GitHub (or Gitorious or GitLab or a similar hosted repository website).
argentpepper
CC BY-SA 3.0
2013-02-15T06:46:51.893Z
@argentpepper We have been using Git in our group for some time now, and I like it. However, it is more involved to use than SVN, so I'd recommend SVN to less tech-savy folks. Aside from that, a public hoster may or may not suited to your needs. For example, our exam questions better stay private.
Raphael
CC BY-SA 2.5
2011-01-30T23:18:35.733Z
2011-01-30T23:25:08.203Z
2011-01-30T23:25:08.203Z
Raphael
<p>Suppose that coauthors from two or more different institutions are writing a paper in latex, and would like to do better than repeatedly emailing drafts back and forth.</p>

<p>They realize they can open for free a dropbox account, share the password, and synch the version of the paper on their computer with the one on dropbox. If two people are simultaneously editing the same section, however, they'll overwrite each other changes.</p>

<p>They have also heard that version-control systems like SVN and Git have tools to merge concurrent changes, which work reasonably well. The documentation of these products, however, is rather hard to read, and it is more focused on how to undo changes and how to manage different "branches" rather than on the basic needs of coauthors writing a paper.</p>

<p>Is there a simple step-by-step exposition on how to use a version-control system in this setup:</p>

<ul>
<li> central repository
<li> local copies
<li> "smart" merge
<li> no branches
</ul>

<p>?</p>

<p>Of the standard version-control systems, which one is the easiest to use? (We are talking theoretical computer science professors here.) </p>

<p>Are there even simpler tools that  only do synch with smart merge, without version control?</p>

<p>Conversely, do people who use version-control systems to even write a single-authored paper really feel that the unlimited-undo capability is worth the extra complexity?</p>

CC BY-SA 2.5
2011-01-30T21:20:10.910Z
Very interesting question.
Oleksandr Bondarenko
CC BY-SA 2.5
2011-01-30T22:12:11.677Z
Indeed. I haven't found anything better than SVN so far, but it's sometimes a bit tedious to get the newcomer to use it properly. I look forward to answers providing user-friendlier solutions.
Anthony Labarre
CC BY-SA 2.5
2011-01-30T23:07:41.320Z
I like this question too! @Luca: You may also be interested in [Version control for collaboration (with word-level diffs)?](http://cstheory.stackexchange.com/q/2934/873).
Sadeq Dousti
CC BY-SA 2.5
2011-01-30T23:17:40.780Z
In some branches of CS, it's common to write papers (and slides) as literate source. Tools such as lhs2tex (http://people.cs.uu.nl/andres/lhs2tex/) are useful in this regard. The upshot is that source code examples in the paper are compilable and checked, and results may even be automatically generated. In such cases, a genuine dvcs seems like the only sane thing to do :-)
sclv
CC BY-SA 3.0
2011-06-04T01:19:42.670Z
btw dropbox has rudimentary version control: you can roll back to a previous version of any file. but merging will have to be manual, which can be a bummer. still, even with svn, i imagine it's still a good idea to pass virtual tokens around? what i've done is split the latex file into a different file for every section and just use dropbox.
Sasho Nikolov
<soft-question><research-practice><software><writing>
Collaborative tools for dummies/professors
Luca Trevisan
# Collaborative tools for dummies/professors

(Asked by: username_0 on 2011-01-30)

Suppose that coauthors from two or more different institutions are writing a paper in latex, and would like to do better than repeatedly emailing drafts back and forth.

They realize they can open for free a dropbox account, share the password, and synch the version of the paper on their computer with the one on dropbox. If two people are simultaneously editing the same section, however, they'll overwrite each other changes.

They have also heard that version-control systems like SVN and Git have tools to merge concurrent changes, which work reasonably well. The documentation of these products, however, is rather hard to read, and it is more focused on how to undo changes and how to manage different "branches" rather than on the basic needs of coauthors writing a paper.

Is there a simple step-by-step exposition on how to use a version-control system in this setup:

* central repository* local copies* "smart" merge* no branches

?

Of the standard version-control systems, which one is the easiest to use? (We are talking theoretical computer science professors here.)

Are there even simpler tools that only do synch with smart merge, without version control?

Conversely, do people who use version-control systems to even write a single-authored paper really feel that the unlimited-undo capability is worth the extra complexity?

**Tags:** soft-question, research-practice, software, writing

> **Comments:**
> **username_1**: Very interesting question.  
> **username_2**: Indeed. I haven't found anything better than SVN so far, but it's sometimes a bit tedious to get the newcomer to use it properly. I look forward to answers providing user-friendlier solutions.  
> **username_3**: I like this question too! @Luca: You may also be interested in [Version control for collaboration (with word-level diffs)?](http://cstheory.stackexchange.com/q/2934/873).  
> **username_4**: In some branches of CS, it's common to write papers (and slides) as literate source. Tools such as lhs2tex (http://people.cs.uu.nl/andres/lhs2tex/) are useful in this regard. The upshot is that source code examples in the paper are compilable and checked, and results may even be automatically generated. In such cases, a genuine dvcs seems like the only sane thing to do :-)  
> **username_5**: btw dropbox has rudimentary version control: you can roll back to a previous version of any file. but merging will have to be manual, which can be a bummer. still, even with svn, i imagine it's still a good idea to pass virtual tokens around? what i've done is split the latex file into a different file for every section and just use dropbox.  

---

## 8 answers

### Answer by username_7 on 2011-01-30. Score: 12 | Accepted answer

First off: If your are interested in real-time collaborative editing, try something like [gobby](http://gobby.0x539.de/trac/). It lets you literally edit a document at the same time.

As for revision systems, I am only familiar with SVN. This is what you do, after installing subversion, of course:

1. Get someone to set you up a repository and give you URL, username and password
2. Go to where you want to have your lokal copy
3. In a shell (command line?), type: `svn co url://to.your/repository` (check-out). Now a new folder with the repository's contents appears.

That's all. Now the most basic commands:

* Whenever you *add* a new file `foo`, enter: `svn add foo`
* Whenever you want to remove a file, enter: `svn rm foo`
* Whenever you have made changes, enter: `svn ci` (check-in)
* Whenever you want to get the newest stuff, enter: `svn up` (update)

There are also commands for moving, copying, branching, resolving conflicts, ... but as long as you do not try funny stuff, you are fine with the above. If anything breaks or seems to, backup your edits, delete the whole folder and checkout the whole thing anew. That's for svn like rebooting for Windows.

Addendum: I see you seem to be concerned about "smart merges". I assume that you refer to have to different versions of a file merged, with the assumption that two people added things in disjoint parts of the paper. As far as I know, svn would treat that as a conflict, and probably rightly so. I don't think that there is a general procedure that ensures you get what you want after two people manipulated the same source. There are graphical svn clients that visualise such conflicts and help you resolving them; they are pretty much diff-viewers were you can choose which version to keep for every conflicting line). It will require work, though.

> **Comments:**
> **username_10**: I'll second username_7's answer. svn is complicated, but for the vast majority of situations I never need anything except the 5 commands listed above. svn does smart merging except when there's a direct conflict: you use one phrase and someone else uses a different one in the exact same location in the text. Line breaks and all don't throw it off at all.  
> **username_17**: Also, you should use ToriseSVN to handle all interaction with SVN graphically; it makes everything a breeze.  
> **username_18**: I'll add to this that rather than setting up your own SVN server, I recommend using a free hosted service like http://unfuddle.com.  It's fairly painless and private.  
> **username_0**: thanks, and thanks to Anand for the suggestion of unfuddle, this was exactly the 1-minute tutorial that I was looking for. I tried setting up a repository on unfuddle, making two local copies on different computers, making inconsitent edits, and checking in, and it does perform the smart merge as Suresh says. (If two users make inconsistent changes, the second one to check in  does get an error message; but if the second one updates, and then checks in, the update makes the smart merge locally, and the check-in puts the smart merge in the central repository.)  
> **username_17**: @Luca: SVN is pretty good like that. Occasionally you will get conflicts, and SVN will give you all the conflicting revisions and you will need to merge manually, but even this is not as scary as it may seem. You just take one of the revisions, make it the main one (by renaming it), and make the changes, and commit. PS, consider taking a look at: http://www.mirios.com.au:8081/index.php?title=Strategy_for_Scientific_Collaboration_with_LaTeX_and_SVN wherein I've described a basic setup within SVN that should allow nice collaboration. Maybe it's useful, maybe not. Good luck :)  
> **username_19**: about username_7's off: http://etherpad.org/ - another really real-time editing tool. very promising...  
> **username_7**: @ Suresh: Cool, I did not know svn could do this. @username_17: I have had bad experiences with graphical clients, in particular when different contributers used different clients. Maybe we were too stupid, but once we all used CLI svn, the problems vanished. Therefore, I am hesitant to recommend UI clients, especially since the CLI interface is (in most cases) pretty easy.  
> **username_7**: @Anand: If you can live with giving your data away, do this. I would expect that every university/group has managed servers were you can easily get a repository. @Alessandro: Jup, etherpad is nice too, and open and free, afaik. That means you can probably install your own copy somewhere (that has become a requirement for me).  
> **username_7**: I should say that many people prefer git over svn, but I have no experience with it myself.  
> **username_17**: @username_7: Fair enough, I've not used differing clients (only SVN), but you are right, you need to be careful how it is set up, (ignore patterns, etc), and how you use it. Glad the CLI works for you.  
> **username_20**: @noon-silk I guess you mean TortoiseSVN, in which case you failed to mention that it's for the Windows platform only.  
> **username_21**: Subversion is a poor solution compared to Git with GitHub. See the answer below for reasons to use Git with GitHub (or Gitorious or GitLab or a similar hosted repository website).  
> **username_7**: @username_21 We have been using Git in our group for some time now, and I like it. However, it is more involved to use than SVN, so I'd recommend SVN to less tech-savy folks. Aside from that, a public hoster may or may not suited to your needs. For example, our exam questions better stay private.  

---

### Answer by username_6 on 2011-08-28. Score: 12

I notice that no one is giving the "small" tutorial for [GIT](http://git-scm.com/), so I'll try to cover it. GIT is faster and superior to SVN, but maybe it is easier for you to get an SVN account on a server at your university, since SVN is well established. Also may of your collaborators would know how to use it.

Even if you collaborate using SVN you may want to use GIT for your own local versioning (I do!).

**First bit of warning**: GIT is very powerful and for basic usage is only slightly harder to use than SVN (e.g., one option to be added in the command line; two steps commit for central repository).

**Second bit of warning**: GIT has the philosophy of considering a set of changes to be atomic (a $\Delta$ as they call it) even if the set spans several files. Also in GIT you have the notion of **local** repository and **central** repository.
**GOOD**: You can work offline.
**BAD**: You need two steps commit to a **central** server.

Basic commands assuming you already have a repository

* Clone a repository: `git clone`
* Update your local repository: `git pull`  or just `git pull` if you cloned as above.
* The pull command really does both `git fetch` and `git merge`. The former "fetch" stuff from the central server, and the second apply a merge of your files and the ones of the server.

The merge is automatic as long there are no simultaneous edits on the same parts of some files. If the merge fails you working directory remains in a "merge state", which means that you have to fix the conflicts and then you have to commit the merged copy. If you still have unmanaged conflicts in you files then the commit would fail again, no garbage committed.

* Add a new file to be committed: `git add` .
* Commit changes to you **local** repository: `git commit -am ""` or `git commit -a` if you want to edit the commit messages.
* Push the changes in your **local** repository to the **central** repository.

Notice that for pushing changes to your central repository you first have to commit to your **local** repository and the you have to push all the commits (even more than one) to your **central** repository.

Create a user-local repository

* Creation of a repository `git init` in any folder you like.
* Done!

Create a public-shared repo (also private if you pay cash) with a nice GUI.

* Use [GitHub](https://github.com/)

Crate as many private/public repository with different groups of users but no GUI.

* Ask for an SSH account with no password on an accessible machine.
* Don't worry since authentication is done by SSH keys.
* Install Gitosis according to [this tutorial](http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way).
* Now you can administrate you own git server by editing a single file and committing it to the repository!

**Git does not need a central server**: any folder in your computer can be used as repository, so you can play with git and make your tests offline. You can initialize one repository and simulate three collaborators in three other folders without sending one bit on the net. This is because any cloned copy of the repository is a full featured repository to which you can commit. This is good if you want to work in a flight between USA, China or Europe.

> **Comments:**
> **username_7**: Since I wrote my answer above, I have come to prefer Git, too. If you like Github but are hesitant to give your intellectual property to a company (and/or pay for that privilege), check out [Gitlab](http://gitlab.org/).  

---

### Answer by username_8 on 2011-01-30. Score: 8

Google Documents ( <https://docs.google.com> ) provides great tools for authoring documents together (including real time editing). It stores everything online for you and integrates well with your Gmail account. By default Google Docs does not have LaTeX compatibility, but you can enable it by going here:

<http://docs.latexlab.org/>

I am not sure how well it works for rollback, but I am sure there is a feature for it. I have heard of some people using Google Wave's LaTeX plug-in to work out preliminary sketches for papers.

> **Comments:**
> **username_7**: Sorry, but that's probably like building the prototype of your new invention in your competitor's lab. I know that Google's tools are popular, presumable because of there ease of use and availability, but I doubt they are very often the best choice. Setting up a decent working environment is not too hard once you have put in a little inital effort. I feel that that should not be too much of a demotivator for people who spend about ten years after school in order to qualify for their job.  
> **username_8**: I don't compete with Google... so for me it just seems like using the easiest tool available, which seems to be one of the requirements OP asked for. Just because it doesn't run in your command line doesn't necessarily make it a bad tool. If it lacking some functionality you need, then it is an open source project, and you can use your experience to add to it. Further, if you use the development version you can even use your local LaTeX compiler instead of the one on their servers.  
> **username_7**: Don't get me wrong, I am no CLI-only guy. I greatly enjoy graphical editors, for example (although I dislike WYSIWYG). Fact is, there are alternatives that are not provided by the biggest data miner on earth. I used the term "competitor" since, afaik, Google *does* some research in computer science, especially machine learning flavors.  

---

### Answer by username_9 on 2011-08-27. Score: 7

I make my coauthors learn Mercurial, and I used to make them learn Subversion. If you are a Subversion fan, [just read this](http://hginit.com/00.html), it is all true.

No matter what system you use, by far the hardest thing is to get the other person to install the software and start using it. Skype is the perfect solution. Recent versions of Skype allow "desktop sharing" which really helps when you want to lead your coauthor through the installation procedure. And I have used straight desktop sharing combined with Skype to write a paper with my coauthor. It works pretty well.

What is really needed is a "Github for scientists". Something that gives a repository, has version control, collaborative editing, etc. Guess what, there is <http://www.scribtex.com/>.

> **Comments:**
> **username_10**: I'm using Github right now to write a survey with a collaborator. It's convenient enough and I don't feel the need for online collaborative editing since we're usually working in different sections.  
> **username_11**: bitbucket would give you the advantages of github with some privacy. I am testing it.  

---

### Answer by username_12 on 2013-02-14. Score: 5

here is a new collaborative online Latex editor called [WriteLatex](https://www.writelatex.com/) that looks promising, as a near one-stop shop for many scientific writing needs/requirements.

* works on mobile
* has realtime preview
* easy/private sharing
* finds latex errors
* allows add on latex libraries/styles
* cloud storage

the coauthor
John Hammersley posted an announcement in tcs se meta [here](https://cstheory.meta.stackexchange.com/a/2645/7884) and he's responsive to feedback (5 more votes on the ad & it will appear on the main site). it looks like it could evolve into a valuable tool for the tcs community over time and maybe the authors will be able to implement some popular features specifically on request.


---

### Answer by username_13 on 2011-08-27. Score: 2

What about simple systems, solutions:

* Google Docs, [Zoho writer](http://writer.zoho.com)... and other collaborative tools.
* Dropbox handles situations when two people try to commit changes on same file. Second committing person gets his/her file renamed (X.txt -> X.txt\_blabla...) , and original file (X.txt) up-to-date with newest version. More info on : [Dropbox Help: "What happens if two people change the same file?"](http://www.dropbox.com/help/36)

It's out of question, but sometimes there are situations where part of group is capable of simple solutions like SVN, while other part of group is capable of distributed version control like GIT. In such situations cooperation is possible:

* [git-svn](http://www.kernel.org/pub/software/scm/git/docs/git-svn.html) - Bidirectional operation between a Subversion repository and git
* [Git - SVN Crash Course](http://git.or.cz/course/svn.html)
* [Effectively Using Git With Subversion](http://www.viget.com/extend/effectively-using-git-with-subversion/)


---

### Answer by username_14 on 2013-04-05. Score: 2

I recently discovered [sharelatex.com](http://www.sharelatex.com) and used it with my collaborator to coauthor a paper. I liked it so much my current plan is to use it for all my projects. Some notable features:

* Real-time in-browser TeXing (like Google Docs, but made for TeX, syntax-highlighting and all).
* In-browser compiling and PDF viewing
* Supports projects with multiple files
* Has a history feature
* Syncs with Dropbox (soon to be released publicly, from its current beta status). This way you can offload the saving of backups etc. to Dropbox. Depending on how it's done, this should also let you use sharelatex even if your coauthors don't want to, as long as they are willing to use Dropbox to share files.
* You can download/upload your project at any time, so you're not stuck using sharelatex if something goes wrong or you change your mind or whatever.

The only downside (but I think it's worth it): although using sharelatex is free, some of its features are not. Notably, to use Dropbox sync (when they release it), or if you want more than 6 coauthors to work on the same sharelatex project, you have to pay \$8/mo. or \$80/year [as of April 2013]. Once they release Dropbox sync though, it seems like a very fair price to me.

[Disclaimer: I have no relationship with sharelatex or its employees other than that I use their product.]

> **Comments:**
> **username_7**: [It's open source now!](https://www.sharelatex.com/blog/2014/02/21/sharelatex-is-now-open-source.html) (And, fwiw, there's also [writelatex](https://www.writelatex.com/) which is similar but can be used for quick fun without registration.) That said, I would not put my intellectual property in a commercial cloud (until it's published).  

---

### Answer by username_15 on 2011-06-03. Score: -5

SVN is the tool developed for this purpose. I would put in the effort to learn it. It is not more complicated than learning to use say the algorithm2e Latex package or one of the pdf slide creator Latex packages.

Having said that, I use CVS instead of SVN. There is better support from the CS admins at our institution (the SVN server is more user managed). Plus, I appreciate that the underlying version files are still there and editable if something goes very-very wrong.

There are 2 drawbacks when compared to SVN. File renames are not as nice, but I can live with that (pick a good name first time). The second problem is that one needs a local CS account to access the repository. Therefore from another institution access is only possible if an account is created first. Of course I do not expect this to be a real problem anywhere; a local department member can probably sponsor that account.

The local access restriction is due to the fact that the admins do not want to support a pserver. (Harder to secure etc.)

> **Comments:**
> **username_16**: Downvoted because this doesn't really address the question's request for step-by-step help and because most of the advantages and disadvantages listed seem to be localized to the home institution of the answerer.  

---

