

Collaborating on GitHub with Subversion  - arunagarwal
https://github.com/blog/1178-collaborating-on-github-with-subversion

======
apendleton
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
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
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
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
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
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
> _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
And here I thought <http://svnhub.com> was an April Fools joke.

~~~
technoweenie
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>

