[logback-dev] Git as a version control system?

[Robert Elliot]

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.html
>
>
>>> 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 at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev