Hacker News Reader

Comment by iSnow | Hacker News Reader

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.

View on HN

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.

>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.

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 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.

With SVN a commit is a push. You can't forget to push after you've committed.

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.

Right. The last time i used subversion was about 7 years ago, so i forgot it. But it makes sense for centralized vc

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.

Latex essentially has the same properties as source code in a VCS's eyes. .docx files would not work as well.

I wonder how true that is if the xml wasn't compressed.

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-hea...

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.

Reply on news.ycombinator.com