[logback-dev] Git as a version control system?
Thorbjoern Ravn Andersen
ravn at runjva.com
Fri Aug 7 13:53:43 CEST 2009
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
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
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.  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 :)
 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!"
More information about the logback-dev