[logback-dev] Git as a version control system?
rob at lidalia.org.uk
Fri Aug 7 21:36:12 CEST 2009
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
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
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:
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework
> for Java.
> logback-dev mailing list
> logback-dev at qos.ch
More information about the logback-dev