I suppose I don't really see the version control system as the major problem in the situation where you have some personal requirement that you could solve by forking an open source project. If I wanted to fork say logback and use my fork in a production system I would see the major problems as: 1) Having somewhere reliable to make the binary available in the long term, when I'm no longer on the project - does the organisation have a stable and long lasting Maven repository that's in everyone's settings.xml? Or am I going to have to force everyone to build it themselves and install it into their local Maven repository? Because obviously the Maven central repository can't possibly be polluted with forks of every library by every man and his dog. I would be worried that one day someone would be trying to build the project and swearing because the pom requires logback-classic-my-custom-version-1.0.0.jar and it's nowhere to be found. 2) Ease of upgrade - will I be making it a nightmare if they ever want to upgrade to a later version of logback? After all, some critical security risk or unusual but to them disastrous bug might make it absolutely vital for them to do so, and then they have to worry about merging the changes somehow in a way that keeps everything working properly... ouch. 3) Developer knowledge - am I going to be making all the web based reference material if not actually useless, at least so suspect that future developers on the project no longer trust anything they read about it on the web and waste considerable time verifying it? Am I going to confuse the hell out of the guy who thought he "knew" logback but now finds I've made several subtle but important changes? By forking you change the position of the any project that uses the fork of the library from one of client (albeit community supported) of the software to that of developer/maintainer of the software, which is a big and potentially very expensive decision. Those are the reasons I wouldn't fork even when there are areas I might like to - using an "official" version just makes life so much easier in the long term. Having said all of which, it's just occurred to me that the one major benefit of the Git approach as outlined in that link is that it fulfils the requirement of many non-GPL open source licenses immediately - the changes are available to the whole world, and at no maintenance cost to the forker - the fork is available via the repository maintained by the primary development team. That's certainly a big win. Anyway, if the plan was to maintain subversion alongside it until Git had comparable tool support that would remove my main concern immediately. Rob On 7 Aug 2009, at 18:17, Ceki Gulcu wrote:
Ralph Goers wrote:
Supposedly this forking and merging is supposed to be the main advantage of git, yet I've never gotten anyone to sufficiently explain it so that my feeble mind can actually grasp what the work flow looks like.
Here is an attempt at explaining the workflow: http://blog.discursive.com/2009/08/couchdb4j-is-case-in-point-for-git-and.ht...
Ralph
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev