6 ms·

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 u

by iSnow 13y ago

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.

deleted 13y ago
[deleted]
Steuard 13y ago
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.
- lostlogin 13y ago
  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.
Too 13y ago
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.
- iSnow 13y ago
  >I can not think of any scenario where svn would be preferable over a distributed vcs such as git or mercurial. After forgetting to push after commit and then dropping your laptop, you'll know.
  - phaer 13y ago
    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.
    - regularfry 13y ago
      With SVN a commit is a push. You can't forget to push after you've committed.
      - jeltz 13y ago
        No but when I used svn I committed way less frequently so it ended up to be the same thing. With git I forget to push with svn I forgot to commit.
      - phaer 13y ago
        Right. The last time i used subversion was about 7 years ago, so i forgot it. But it makes sense for centralized vc
    - iSnow 13y ago
      >The result would be exactly the same, right? Nope, like regularfry rightly pointed out. >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.
- CJefferson 13y ago
  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.
singingfish 13y ago
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.
- iSnow 13y ago
  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.
  - singingfish 13y ago
    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.
scott_s 13y ago
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.
- xshoppyx 13y ago
  Latex essentially has the same properties as source code in a VCS's eyes. .docx files would not work as well.
  - reycharles 13y ago
    I wonder how true that is if the xml wasn't compressed.
k3n 13y ago
Did you miss the story earlier in the year about the Princeton math students who did just that? 1. http://www.wired.com/wiredenterprise/2013/06/cades-witty-headline-here/ http://www.wired.com/wiredenterprise/2013/06/cades-witty-hea...

by iSnow 13y ago

deleted 13y ago

[deleted]

Steuard 13y ago

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.

lostlogin 13y ago
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.

Too 13y ago

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.

iSnow 13y ago
>I can not think of any scenario where svn would be preferable over a distributed vcs such as git or mercurial. After forgetting to push after commit and then dropping your laptop, you'll know.
- phaer 13y ago
  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.
  - regularfry 13y ago
    With SVN a commit is a push. You can't forget to push after you've committed.
    - jeltz 13y ago
      No but when I used svn I committed way less frequently so it ended up to be the same thing. With git I forget to push with svn I forgot to commit.
    - phaer 13y ago
      Right. The last time i used subversion was about 7 years ago, so i forgot it. But it makes sense for centralized vc
  - iSnow 13y ago
    >The result would be exactly the same, right? Nope, like regularfry rightly pointed out. >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.
CJefferson 13y ago
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.

singingfish 13y ago

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.

iSnow 13y ago
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.
- singingfish 13y ago
  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.

scott_s 13y ago

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.

xshoppyx 13y ago
Latex essentially has the same properties as source code in a VCS's eyes. .docx files would not work as well.
- reycharles 13y ago
  I wonder how true that is if the xml wasn't compressed.

k3n 13y ago

Did you miss the story earlier in the year about the Princeton math students who did just that? 1. http://www.wired.com/wiredenterprise/2013/06/cades-witty-headline-here/ http://www.wired.com/wiredenterprise/2013/06/cades-witty-hea...