9 ms·
Don't be a git, use subversion
- k3n 13y agoNo need for an inflammatory (link-bait) title IMHO.
- gte910h 13y agoIf you must keep with subversion, explicitly authorize the use of git-svn for developers who are using git. Git use causes smaller incremental commits, which can be squashed into bigger ones for re-merging, but makes for better, more ambitious changes, and easier rollbacks to working code. You get 85% of the benefit by allowing those who can handle it to use git as a subversion client.
- wting 13y agoUmm... fuck no. There is no reason that you can't use git as a master repository system--that's how most people treat GitHub anyway. OTOH if you want to do anything besides the basic commit or update with Subversion, it's ridiculously difficult. Subversion is a SCM tool where people actually prefer to merge manually rather than deal with its conflict handler.
- marcuskaz 13y agoI agree most people do use Git as a master repository system, so why deal with the extra complexity and just use Subversion. It will save you a command on every commit, no need to commit and then push.
- MetaCosm 13y agoBecause git is significantly faster, better at merging, allows cheap private branching and private changes (don't have to do everything in public just to have version control), allows staging of changes, allows offline work, allows "out of band" collaboration between developers, is up to 30x smaller repos (mozilla), more redundant (everyone has full history)... (more)
- hamburglar 13y ago"save you a command on every commit"? If the number of commands you type is your inverse measure of productivity, then ok, more power to you.
- MetaCosm 13y agoSVN Merging: Don't.
- develop7 13y agoWell, git sucks a lot, but switch to CVCS instead? No way.
- marcuskaz 13y agoI never said git sucks, its actually quite powerful; but with the power comes added complexity that for most is not worth it
- caoimhin 13y agoThere are more and more devs who have only worked with git. For them, they will find svn complex. They'll be used to using branches and svn will get in their way. Git is complex for you. The mistake you're making is in not realising that's not universally true.
- marcuskaz 13y agoA very good point, and something I've considered. You might just be right and I'm just getting old and crotchety :) I still see git requiring more commands for simple tasks and the model of what is happening has more moving parts (more complex). This gives git the ability to do a lot more, but my thought is for the majority you don't need the more.
- syncerr 13y agoI actually like git, a lot. Far more than SVN. If git sucks, are you saying all VCS are broken? Or do you have an alternative?
- russelluresti 13y ago"Don't be a git, use subversion" - no one ever
- cmsj 13y agoDVCS is so so much better than CVCS that developers generally love it hence the popularity it is seeing. You are trying to hold back the tide here :)
- marcuskaz 13y agoThere are complexities with DVCS that people gloss over focusing only on the positive. My view is that the complexity is rarely worth it for most company settings. This article explains the complexity well: http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ http://steveko.wordpress.com/2012/02/24/10-things-i-hate-abo...
- gte910h 13y agoThat article is a huge strawman. His example is easily 3x more complex than it needs to be.
- joshka 13y agoDon't be a tool, learn to use your tools.
- dysinger 13y agoAAH.... HAHAHHAHAHAHAHAHAHA
- hamburglar 13y agoI am curious to hear stats from your experiment in creating a fake HN controversy. Please report back.
- marcuskaz 13y agoI don't think I created any controversy. The real controversy is whether you should use rebase or not. My thought was just simplify and subversion might be the right tool for many jobs. Everyone thinks I'm a fool. As far as stats, if you really are curious. I received about 1,600 views on the article. Oddly no referrer data from HN, around 300 from Twitter, 150 from Google Reader and 100 from hckrnews.com.
- dguaraglia 13y agoI think what the author is trying to say is that by saving a command for 'every action' that you take on git, you can offset the hours and hours of conflicts and manual work you get every time you try to merge a branch into trunk on SVN. Or maybe not.