Ask HN: Is git/svn right for me?
10 comments
Yes. Try git or mercurial (AKA "hg": http://selenic.com/mercurial/) rather than svn; both are much easier to set up and try out. When it only takes a second to set them up, you'll be more likely to experiment with them and discover what they're good at. SVN really doesn't have any real advantage over them these days.
There is a function in git and hg (an extension) called "shelve" which does exactly what you want - you can temporarily set aside the new feature in progress, commit the bugfix, and then go back to working on the feature. (If you knew ahead of time you were going to need to do this, it would probably have made more sense to do the feature in a branch, of course.)
People will argue back and forth whether git or hg is better, but in my experience they do the same things* , they just have different personalities. Pick one, get the hang of using it, and then experiment with the other - you'll be better able to make an informed decision. Both are significantly better than just about every other VC system.
* The advanced features they don't have in common are probably not going to matter until you know all the base functionality, and any new features in either will probably get ported to the other by then.
There is a function in git and hg (an extension) called "shelve" which does exactly what you want - you can temporarily set aside the new feature in progress, commit the bugfix, and then go back to working on the feature. (If you knew ahead of time you were going to need to do this, it would probably have made more sense to do the feature in a branch, of course.)
People will argue back and forth whether git or hg is better, but in my experience they do the same things* , they just have different personalities. Pick one, get the hang of using it, and then experiment with the other - you'll be better able to make an informed decision. Both are significantly better than just about every other VC system.
* The advanced features they don't have in common are probably not going to matter until you know all the base functionality, and any new features in either will probably get ported to the other by then.
version control is almost always a good idea. If you're the only developer, then I would recommend svn. git is distributed version control -- its used e.g. for Linux Kernel development, when hundreds of developers are doing independent work on the same codebase.
Version control is indeed always a good idea. However, I'd strongly advise choosing Git over SVN.
SVN's branching capability is a joke compared to Git, and you'll wonder how you ever lived without easy branching once you get used to having it. This is important even if you're the only developer on the project.
SVN's branching capability is a joke compared to Git, and you'll wonder how you ever lived without easy branching once you get used to having it. This is important even if you're the only developer on the project.
Since the release of SVN 1.5, branching / merging is trivial.
I've never really used git, but it seems to be the future, so you might as well start with that, no?
The advantage of SVN is that it has been around longer, so you can (e.g.) find GUI software that leads you through it, like TortoiseSVN, or those two SVN clients for the Mac that conveniently came out just as I switched to git. :]
That's the only advantage, though. I frankly don't understand the notion that SVN is easier to learn than git. Git has its tricky points (like the index), and its documentation and teaching material have only recently emerged from obscurity, but I think it's conceptually more straightforward, particularly because you can use it without having to set up a server. And you can back up your entire repository by just dragging your working directory to some backup media, so crazy experiments feel a lot less risky.
Start at github. And I learned mainly from the git screencast at Peepcode and the Randal Schwartz Google talk on git.
That's the only advantage, though. I frankly don't understand the notion that SVN is easier to learn than git. Git has its tricky points (like the index), and its documentation and teaching material have only recently emerged from obscurity, but I think it's conceptually more straightforward, particularly because you can use it without having to set up a server. And you can back up your entire repository by just dragging your working directory to some backup media, so crazy experiments feel a lot less risky.
Start at github. And I learned mainly from the git screencast at Peepcode and the Randal Schwartz Google talk on git.
I found mercurial much easier to learn/explain than git (the hg team seems to be more interested in keeping its public interface clean), and it has TortoiseHG (http://tortoisehg.sourceforge.net/) on Windows. (There are several other graphic interfaces available: http://www.selenic.com/mercurial/wiki/index.cgi/OtherTools)
This book helps, too: http://hgbook.red-bean.com/
This book helps, too: http://hgbook.red-bean.com/
No offense, but if you really don't know, it probably doesn't help to just unquestioningly repeat buzz you've heard.
"Don't know anything" isn't accurate. It's not as if I don't follow the issues in question, read people's opinions, articles, commentary, and so on. It's just that I haven't used git myself, yet, aside from checkouts.
My point is merely that, if I were given the choice today to learn a version control system for my own use (like the poster), I would pick git because that seems to be where things are going. svn works well enough for me and I don't see any need to chase after the buzz, but sooner or later I too will probably get around to figuring out the ins and outs of git.
Either one is obviously a vast improvement over no version control.
My point is merely that, if I were given the choice today to learn a version control system for my own use (like the poster), I would pick git because that seems to be where things are going. svn works well enough for me and I don't see any need to chase after the buzz, but sooner or later I too will probably get around to figuring out the ins and outs of git.
Either one is obviously a vast improvement over no version control.
Ah. I'd say checkouts counts as using it, FWIW.
(Mercurial is really good, too.)
(Mercurial is really good, too.)
Hi HN,
I never thought I'd need to use a version tracking system, but after having a live site, I'm thinking I do. (Single developer.)
Say I have a feature I need to implement, but would take days or weeks to finish it. In the meantime, I need to fix a bug which could take just a few minutes to fix and deploy. I'm finding myself making whole copies of my site on my local machine, and using the original copy change little things and deploy.
Would git/svn make this easier for me, or am I stuck doing what I'm doing? Thanks!