Collaborating on GitHub with Subversion | Hacker News Reader

Collaborating on GitHub with Subversion

github.com

40 pointsarunagarwal13 comments

I like that GitHub offers SVN interoperability, but this tutorial doesn't seem tailored to its ideal use-case. I would imagine that the biggest benefits of using SVN to access github would be for use with higher-level tools (IDEs, continuous integration systems, etc.) that already have SVN backends. If you're just going to be interacting with your repo from the command line like they do here, though, you could spend the same amount of time it takes to read this tutorial to learn the four or five git commands you would need to complete the steps it covers.

Nah, a major benefit is teams that have the one guy who won't learn git. He'll claim he is, but really he's still mentally using subversion, and it shows when it does awful things to your repo. We have this guy on our team, just for an example of what happens:

* every day claims "subversion doesn't have merge conflicts"

* every day decides that "branches should be taken out of git, they are too confusing"

* refuses to accept that master is not special other than by convention

* regularly requires someone else on the team to take 30 minutes cleaning up his stuff

* since he doesn't get git, he will have his code changes scattered around 5 different clones of repos and do hand merging because it is safer. (he did this with svn too :/)

* wishes that TFS would just hurry up and have a git bridge because git isn't enterprise enough, and therefore not production ready.

There are more...

Anyway, he's a good coder and useful in what he does well, so it's not a case of "bad develper", he just has blind spot when it comes to version control. I presume he's not the only one.

He's probably not unusual. I know git, but I refuse to use it until forced to. It's overly complicated and wastes my time.

My SVN workflow works fine. My non-branch workflow:

* Step 1: Do my work. Commit very often -- every time I implement a small granular piece. I keep the unit tests running. Other people see my commits immediately. This is simple, communication flows easily, and I'm not thinking about version control.

My branch-based workflow.

* Step 1: Create branch. svn cp ^/trunk ^/branches/feature-whatever && svn switch ^/branches/feature-whatever

* Step 2: Do my work. Commit often. Other people see my commits immediately. This is simple.

* Step 3: Run svn merge ^/trunk. Fix the occasional merge error caused by two people working on the exact same code at the same time. This is simple as long as I communicate with the team. It's easy to communicate with the team, because they all see my regular commits, and I see theirs, and so I know if we're stepping on any toes.

* Step 4: Merge my work to trunk (possibly after review). svn switch ^/trunk && svn merge ^/branches/feature-whatever

I hate the constant badgering from git proponents. They all want me to use a more complicated tool that doesn't offer any advantages to what I see as a simple, seamless workflow. I want my SCM to stay out of my way entirely. If I could avoid even thinking about it, I would.

My job is to write code, not to spend a bunch of time juggling local/remote commits in a complex SCM tool.

I've worked through the industry transitions from RCS to CVS, CVS to SVN, and introduction of SVK, Mercurial, darcs, and now git. Despite being a part of all those industry transitions, I've never seen such religious proselytizing and scorn from any SCM "proponents" as I've seen from git advocates.

With git, you can basically do the same thing and a lot more. You could probably even alias your favorit SVN commands for easier learning. One of the main problems with SVN is that it works with files and not commits, you work on 3 files, commit your work, and SVN will let me only update 1 or 2 files, I think this is horrible and people do it... a lot.

You are not forced to have local branches and commits that you didn't push to the main repository, but having them as options is a step forward. Also I can't imagine SVN working as good as git in the open source realm.

I'm aware that you can do the same things, just with a lot more user complexity. I prefer simpler tools if the complexity does not strike me as advantageous towards completing my primary task -- writing software.

As for OSS, I'm much happier with the results of the PostgreSQL or FreeBSD development communication models than I am with the results of git/Linux style of development coordination. I think it's fair to judge by results.

I don't feel any complexity, only more control. I admit though, that I started with git, which probably helped a lot.

If I want to I can alias git commit && git push, so that I don't have to type two commands to achieve something that can be done with one in SVN, I really don't see that as a big deal.

The thing that bugs me about a lot of SVN users is that they are afraid for branching. A lot of them thing that updating specific files instead of the whole tree is a good thing.

Sure there are some projects where SVN is good enough, but sometimes you just feel the need for the features of git.

I think Linux is doing a lot better than FreeBSD. :)

> I don't feel any complexity, only more control. I admit though, that I started with git, which probably helped a lot.

Control, complexity. Same thing. I don't need control, I need the SCM to make my commits available to everyone immediately and get out of my way. Any time I spend twiddling the SCM system for asthetic reasons, or because I don't want to share my work until I'm ready for other people to see it, is wasted time that serves no code or communication advantage. We're software developers, not SCM operators.

Git appeals to certain aspects of human nature that make the tool appealing, but are fundamentally negatively impacting on communication and the development process.

> I think Linux is doing a lot better than FreeBSD. :)

Not in terms of code quality, it's not. MySQL is also more popular than PostgreSQL, but there's no technical comparison.

For the branch workflow:

* Step 1: git checkout -b feature-whatever

* Step 2: git commit -a (for all changes) OR or git add file1 file2; git commit (for specific files) OR git add -p; git commit (for staging specific changes within files)

* Step 3: git fetch origin master:master; git merge master OR git pull origin master (while your feature is checked out) OR git fetch origin master:master; git rebase master (to replay your changes on top of master, which is cleaner and avoids a merge in history)

* Step 4: git checkout master; git merge feature-whatever; git push origin master

Is that really so much harder? Plus if you use the rebase option for Step 3 you don't get an ugly pointless merge.

Yes, that is more complex, especially when you start dealing with local vs local+remote branches. The SVN simple case is practically mindlessly simple, the branch case only slightly more involved. There are far, far, far fewer moving parts to worry about.

Fair enough you don't like it, and you probably don't need it. But if the team decides to use a tool, it is still kind of stupid, and just a little stubbornly unprofessional to cause them extra effort just to put up with your dislike of it - which is the case I'm describing.

I mean I really dislike Visual studio and C#, but for reasons out of my control, we have to use it for a couple of projects. I could complain the whole time how it's not what I want, but instead I'm just doing it, because that's the job right now. I don't make the guy who doesn't like git (but is good at VS) come fix my environment or undo my mistakes every 3 days.

My point was, the github svn support at least mitigates that scenario, whether or not it should happen.

And here I thought http://svnhub.com was an April Fools joke.

ha ha ha... but this is true!

It was an April Fools joke in 2008. The feature became a reality in 2010, and has seen some major updates since then.'

https://github.com/blog/31

Reply on news.ycombinator.com