5 ms·

Yeah I have some problems handling git as I'm used to svn. It'd be nice if they expanded to the other version control systems that are out there. Wasn't there a

Yeah I have some problems handling git as I'm used to svn. It'd be nice if they expanded to the other version control systems that are out there. Wasn't there a rumor not long ago that they had registered svnhub.com or mercurialhub.com? My memory escapes me.

jpcx01 18y ago
I think they'd benefit much more if they used their position as the killer git app in order to help git go mainstream. Having git be universal in the Ruby/Rails world has been a huge accellerator for maintaing open source projects. No longer are we subject to core teams losing interest, anyone can fork and become the new core team.
- davidw 18y ago
  Anyone at all can and does fork, which, yeah, is great and all, but until they fiddle some more with the UI or something, makes it really difficult for other people to figure out who the heck the core team is. It's not like it wasn't possible to fork stuff in the past, it just required a little bit more effort... enough so that you didn't just get random copies of stuff all over the place. I wonder if you get a projects bugs if you fork it?
  - tvon 18y ago
    It's kind of the nature of the beast. If you make forking and merging simple, people will do it on a whim. An indicator for the original code would maybe be useful, but it would lead to confusion when, for example, the original maintainers fade away and another repo becomes the pseudo-canonical tree.
rcoder 18y ago
Supporting multiple version control systems means accepting the set intersection of their features as your baseline. Part of why GitHub has been able to just fly is their laser-like focus on only those features which facilitate collaboration atop Git. (I say this from painful experience, having spent much of the last couple of months months trying with only limited success to make users of Subversion, Mercurial, and Git happy with the same UI for source code repository browsing.) Furthermore, trying to implement fork queues, pull requests, and even proper contributor attribution atop Subversion would be a ridiculous amount of work for very little gain. Regardless, if you really want to stick with Subversion, you might at least consider setting up a cron job that fetches to a local git-svn mirror and then pushes a clone to GitHub. You won't have to learn a whole new version control system, and your users will happily run circles around you with their ability to fork, branch, and merge before you can copy your source tree into a new tag.

jpcx01 18y ago

I think they'd benefit much more if they used their position as the killer git app in order to help git go mainstream. Having git be universal in the Ruby/Rails world has been a huge accellerator for maintaing open source projects. No longer are we subject to core teams losing interest, anyone can fork and become the new core team.

davidw 18y ago
Anyone at all can and does fork, which, yeah, is great and all, but until they fiddle some more with the UI or something, makes it really difficult for other people to figure out who the heck the core team is. It's not like it wasn't possible to fork stuff in the past, it just required a little bit more effort... enough so that you didn't just get random copies of stuff all over the place. I wonder if you get a projects bugs if you fork it?
- tvon 18y ago
  It's kind of the nature of the beast. If you make forking and merging simple, people will do it on a whim. An indicator for the original code would maybe be useful, but it would lead to confusion when, for example, the original maintainers fade away and another repo becomes the pseudo-canonical tree.

rcoder 18y ago

Supporting multiple version control systems means accepting the set intersection of their features as your baseline. Part of why GitHub has been able to just fly is their laser-like focus on only those features which facilitate collaboration atop Git. (I say this from painful experience, having spent much of the last couple of months months trying with only limited success to make users of Subversion, Mercurial, and Git happy with the same UI for source code repository browsing.) Furthermore, trying to implement fork queues, pull requests, and even proper contributor attribution atop Subversion would be a ridiculous amount of work for very little gain. Regardless, if you really want to stick with Subversion, you might at least consider setting up a cron job that fetches to a local git-svn mirror and then pushes a clone to GitHub. You won't have to learn a whole new version control system, and your users will happily run circles around you with their ability to fork, branch, and merge before you can copy your source tree into a new tag.