Ceki Gulcu skrev:
Since you are the project leader, and the primary committer, I believe you should do whatever you think allows you to be more efficient while still allowing others to provide patches.
Although I find git's disconnected mode of operation valuable, I'm also risk-averse and afraid of new things. So I am looking for reasons to tip the balance in favor of git so as to overcome my fears. Facilitated collaboration would be an important justification in my mind. It appears that git encourages (by making very easy) project forks and to publicize the forked results. I can somehow imagine why this would encourage contributions but would also like to hear from others.
I think you should set your goals straight. A low threshold is important for others to switch from users of distribution jars to tweaking source and build the resulting jars themselves, so the amount of pain needed to go through should be minimal. A good example is Glassfish 2 which is close to impossible to get to build as the supported build environment is arcane and hard to set up. If you want to have another source repository system, so be it, and just do it, since you appear to basically have convinced yourself :D If you want to encourage more collaboration and contributions, I believe this is not primarily a technical issue, but more a question of community building. This has proven to be very hard. Linus and Apache have done so. Sun have failed for most of their open source products. For logback it appears that there are around 10 active individuals on the developer list.
The mere fact that people still talk about git speaks volumes about the quality of git because Linus is an awful advocate for git. The git presentation he gave at Google is embarrassingly inappropriate. See http://www.youtube.com/watch?v=4XpnKHJAok8
I will give it a look sometime later - for now I accept your word for it.
In my experience changing source repository platform is similar to changing operating system. Not something you do everyday.
Once a decade maybe. :-) Yes. No need to hurry the issue. Personally I would not change unless there was a killer feature which made a LOT of difference.
At work our primary problem with CVS is the inability to rename files and keep the history. The rest is minor things. That alone is not enough to warrant switching, but we have considered more than once to switch to Subversion.
(and we still use CVS at work, since the benefits of good tools strongly overshadow the deficiencies of CVS ... for us!).
Interesting point. I guess a similar reasoning applies to migrating from log4j to logback.
No. Those things are very different. The logging platform is "just" a component of applications, which happen to throw stuff to disk - most people stay with the default appenders etc. [1] The source repository is the "operating system" of the source code, and changing that influences the work of all developers. We have not fully switched from log4j to logback, but we switched to slf4j to solve the usual log4j + commons logging problem while keeping log4j. After figuring out that log4j is essentially in maintainance mode after the logback fork, and that jdk14 logging is basically frozen (plus hard to configure externally), we decided that for now we use logback as the logging platform. So, the abstraction quality of slf4j is the primary reason why switching logging platforms is a lesser pain than switching source repositories :) [1] Our situation is not quite typical. Our production platform does not allow for debuggers or profilers, and most issues are frequently not reproducable in test. Hence I am investigating using logging as a forensic tool and less a "all is well" tool. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"