This misses the biggest thing that made me initially switch to git: local commits.
I can do with only a single branch if necessary, but how the f*ck are you supposed to develop anything locally and roll back changes in subversion if you are never allowed to commit because it might break someone else's stuff?
I think there are other svn-alikes that might solve this problem (svk?), but with pure subversion it is the biggest roadblock for me (and I bet, a lot of other new coders).
It's something you can do in svn already. Granted, it's not as streamlined as it is in git, and you would need to commit to the remote server, but that's not the end of the world.
In the old days, before git existed, we used to have a space in the repo for each developer. You could put whatever you wanted in there. So if you wanted to go off on a tangent you just copied the code via svn, switched to that copy, do your work, commit as you please. When you were happy you could cherrypick / merge into the main branches of the code.
Git makes this stuff easier, but it was all possible with svn. Hell, it was probably even possible with cvs if you jumped through the right hoops.
Firstly -- it's on the server, as you said, which slows things down. Also, is there an easy way to rollback, if you don't have certain privileges on the server?
True, but it's a trade off. I've run big svn repos before where we couldn't have used git because it would have taken up too much space on the client machines.
In terms of editing the history it's generally just considered something that you don't need to do.
My point was not so much that git isn't better. It was more that the desire for the new tech makes people forget what the old tech could do. It happened when svn took over from cvs. It'll happen when the next tech comes along to replace it. That's life.
You can always use your own feature branch on the server. The only difference is online/offline access to it. Otherwise - do whatever you want - there are a lot of projects doing private branches (just by namespacing them by prefix) where people experiment.
Yeah, this can be quite a game-changer. Initially, people always undervalue this and think it's only good when you want to work on a plane.
But being able to commit locally makes stuff faster, makes you able to test things out - and only share code when you actually want to.
Totally agree. And no, it didn't invent it, but its the first system that has that, and has enough traction in the world to warrant being learned.
As to the features mentioned in the article, I agree in principal, and someday I'll even learn git well enough to be feel like trying to use them isn't a huge, mental drain from the focus of my actual work :-)
Comments
This misses the biggest thing that made me initially switch to git: local commits.
I can do with only a single branch if necessary, but how the f*ck are you supposed to develop anything locally and roll back changes in subversion if you are never allowed to commit because it might break someone else's stuff?
I think there are other svn-alikes that might solve this problem (svk?), but with pure subversion it is the biggest roadblock for me (and I bet, a lot of other new coders).
It's something you can do in svn already. Granted, it's not as streamlined as it is in git, and you would need to commit to the remote server, but that's not the end of the world.
In the old days, before git existed, we used to have a space in the repo for each developer. You could put whatever you wanted in there. So if you wanted to go off on a tangent you just copied the code via svn, switched to that copy, do your work, commit as you please. When you were happy you could cherrypick / merge into the main branches of the code.
Git makes this stuff easier, but it was all possible with svn. Hell, it was probably even possible with cvs if you jumped through the right hoops.
we used to call that space "developer branch" or a "feature branch" :)
Firstly -- it's on the server, as you said, which slows things down. Also, is there an easy way to rollback, if you don't have certain privileges on the server?
True, but it's a trade off. I've run big svn repos before where we couldn't have used git because it would have taken up too much space on the client machines.
In terms of editing the history it's generally just considered something that you don't need to do.
My point was not so much that git isn't better. It was more that the desire for the new tech makes people forget what the old tech could do. It happened when svn took over from cvs. It'll happen when the next tech comes along to replace it. That's life.
Seriously, that's the elephant in the room of the biggest feature of git—local, personal branches.
You can always use your own feature branch on the server. The only difference is online/offline access to it. Otherwise - do whatever you want - there are a lot of projects doing private branches (just by namespacing them by prefix) where people experiment.
Yeah, this can be quite a game-changer. Initially, people always undervalue this and think it's only good when you want to work on a plane. But being able to commit locally makes stuff faster, makes you able to test things out - and only share code when you actually want to.
Totally agree. And no, it didn't invent it, but its the first system that has that, and has enough traction in the world to warrant being learned.
As to the features mentioned in the article, I agree in principal, and someday I'll even learn git well enough to be feel like trying to use them isn't a huge, mental drain from the focus of my actual work :-)