Dealing with forks in a DVCS
ozmm.org
ozmm.org
The network graph things look like cool technology, but I am not convinced - perhaps you're looking at things from too much of a github centric view? That's easy when you live and breathe something. "The Google" is where most of us still start looking.
> It may seem strange, and perhaps even like a lot of work.
It does seem like an awful lot of work!
> In the old model, actionwebservice wouldn’t have made it past 1.2.6. Welcome to distributed version control.
That's not necessarily true. DHH or whoever could add the datanoise people as committers on the RubyForge project, where they could happily continue to work on the 'canonical' version. There are plenty of projects where that has happened, with the torch being passed, and the code moving forward.
I concede to that, and we're interested in attacking that problem, too. It's easier for us to start with GitHub though.
> That's not necessarily true. DHH or whoever could add the datanoise people as committers on the RubyForge project, where they could happily continue to work on the 'canonical' version. There are plenty of projects where that has happened, with the torch being passed, and the code moving forward.
But he didn't, and that's the point.
Everyone could also maintain their projects indefinitely, reviewing and merging in all the good patches. But they don't. DVCS answers the "but they could have..." hypothetical situations in the classic model with real solutions. datanoise could have continued development without DHH's permission, and he did. Someone can, in the future, do the same to him.