4 ms·

Collaborating on GitHub with Subversion

40 points by arunagarwal 14y ago

apendleton 14y ago
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.
- sophacles 14y ago
  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.
  - flatline3 14y ago
    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.
    - voidr 14y ago
      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.
      - flatline3 14y ago
        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.
        voidr 14y ago
        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. :)
        flatline3 14y ago
        > 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.
woodrow 14y ago
And here I thought http://svnhub.com http://svnhub.com was an April Fools joke.
- arunagarwal 14y ago
  ha ha ha... but this is true!
- technoweenie 14y ago
  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 https://github.com/blog/31

40 points by arunagarwal 14y ago

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.

sophacles 14y ago
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.
- flatline3 14y ago
  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.
  - voidr 14y ago
    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.
    - flatline3 14y ago
      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.
      - voidr 14y ago
        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. :)
        flatline3 14y ago
        > 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.

woodrow 14y ago

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

arunagarwal 14y ago
ha ha ha... but this is true!
technoweenie 14y ago
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 https://github.com/blog/31