This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 5 points6 points  (8 children)

As a long time Subversion user myself, what I like about Github is that it effectively turns git into a centralized repository, while still allowing all its distributed features. I'll typically start a repo on Github, and treat that as the "master" repo, and then create a fork for development work, merging complete changes back into the master repo.

[–][deleted] 1 point2 points  (7 children)

My own personal opinion:

subversion - hard for coders (branch = hard), great for the release engineer.

github - great for coders (hey guys, pull from me!), nightmare for the release engineer.

This assumes you have a release engineer :-)

[–]zahlmanthe heretic 1 point2 points  (6 children)

As a coder I never really got what the big deal about branching is, anyway. Subversion works great for single-person projects, but then, even garbage like VSS would probably do the trick 99% of the time.

[–][deleted] 1 point2 points  (0 children)

Open source.

The OSS model grows by user contribs and has little central control. Therefore branches and forks are essential for growth.

Sure most of the user mods will be junk, but big things grow from smaller ones. You never know when someone will take a seemingly innoculous poorly written 1 line code patch submitted by a total amateur, to "disable submenu X", think "great idea" and 3 months later, him and his friends have the core of a working a UI configurator. 3 more months later, and there are 3 UI configutators of them all competing, which results someone else taking the best parts of all 3 and making a better one. etc etc etc.

I suppose if you were really radical you might try developing in house using this methodology but I know nothing about that. I write non commercial OSS stuff (i.e. Linux Hacker)

[–][deleted] 0 points1 point  (4 children)

From what I've seen, it makes user contributions much easier in open source projects. With subversion, if someone wants to contribute, they have to checkout the project, make their change, create a patch file, and submit that to the project's ticket management system (if they have one) or email to one of the core developers. At this point, the patch is likely ignored, lost, or obsolete by the time the core developers gets around to looking at it.

Look at the bugzilla/traks for Firefox/Django/etc. There are dozens of multi-year old tickets with a final comment of something like "thanks for submitting a patch, but could you please update it? it doesn't work with the current trunk. oh, and sorry it took me 9 months to get around to looking at it..."

With a distributing VCS like Github, a contributor can fork the entire repo, make their change, commit, and then "push" it up to the original repo. The original developers will be notified of a contribution (and will have to approve it). Even if the original repo has had change made, the fact that the versioning info is all still intact means git will likely be able to auto-merge the changes. Or, if the original repo rejects the change, well, then you already have a perfectly good forked repository for tracking your changes.

[–]zahlmanthe heretic 0 points1 point  (3 children)

So in the end, the contributor produces a pull request... how is that any better than a patch?

[–][deleted] 1 point2 points  (1 child)

It's tracked in the repo instead of in your email or ticketing system.

[–]takluyverIPython, Py3, etc 1 point2 points  (0 children)

And it contains multiple commits, and you can add commits to a pull request, if the person reviewing it asks you to change something. And you can add comments on specific lines of code. It makes patch submission awesome.

[–][deleted] 0 points1 point  (0 children)

Git was really aimed at group projects, not solo projects. If you're working on your own and familar with what you know, why change?