Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The (side?) benefit of a DVCS is that you commit locally. So I can do all my fun experiments on my team's codebase on my laptop - it doesn't pollute the number of branches on the server, etc.

Indeed, even when forced to use SVN, I would simply check out the SVN trunk, create a Mercurial repository in that "working" directory, and then clone from their whenever I did any development (one clone per feature). I would then push back to the main Mercurial repository, and push that to the SVN server.

Other than that - true. No real DVCS benefit compared to SVN. I would imagine most of the nicer Git features that people use have, or could have, analogs in SVN.



> Indeed, even when forced to use SVN, I would simply check out the SVN trunk, create a Mercurial repository in that "working" directory, and then clone from their whenever I did any development (one clone per feature). I would then push back to the main Mercurial repository, and push that to the SVN server.

Once did something similar with Git, the one time I was at a place that used SVN. I didn't trust any of the git-to-SVN tools so I just did all my work in a local git repo, then copied my working directory to an SVN-controlled directory and committed maybe once or twice a day, when I had something worth preserving.

The ~week before I switched to this workflow was nerve-wracking. Not being able to make all the branches I want for any purpose at all without it showing up for anyone else, or to make shitty commit messages for my own local junk-commits before it was ready for consumption by anyone else, was awful. Having to worry that every little vcs operation might mess up someone else's stuff was the worst.

Luckily I was working on an isolated part of a larger system on my own, so this worked OK. No incoming code to worry about, so SVN was write-only from my perspective.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: