geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: git, hg or bzr for G development?
Date Thu, 29 Jan 2009 14:33:28 GMT

On Jan 28, 2009, at 12:47 AM, Jason Dillon wrote:

> On Jan 28, 2009, at 1:47 AM, Kevan Miller wrote:
>>>> There are some usages of GIT that would not fit well into an  
>>>> Apache project. For instance, I would not want to see project  
>>>> members using GIT as a private means of sharing code updates.  
>>>> Ultimately, code needs to get into our svn repo -- that's where  
>>>> we should be sharing code.
>>> Why do you have a problem with users sharing code via their own  
>>> GIT repos?  I guess I can kinda see your concern, but I'd expect  
>>> folks with significant changes to the codebase to want to share  
>>> their GIT repos with others *before* pushing those changes back  
>>> into SVN.
>> Right. So, I wouldn't want a few people to decide to implement some  
>> new function, start sharing code (privately amongst themselves),  
>> and then dump it into svn. IIUC, GIT makes this pretty easy to do.  
>> Currently, this sort of activity would happen in an svn sandbox or  
>> via patches posted to a Jira. In either case the collaboration and  
>> work should be public. I want to make sure we maintain this.
> Jay's example of a security-related patch is a very compelling  
> example as to why sharing code directly via GIT instead of SVN can  
> be a good idea at times.

Sure. I'm not denying that GIT has potential advantages. I'll point  
out that we can share security patches, already. Certainly not as  
easily as GIT *could*, but it's not that hard, either... Also, the  
code sharing occurs publicly within the security community. So, all  
members of the security team can participate. We'd also require some  
kind of access control on any GIT-based code sharing that occurs.

>> Until *everyone* is using GIT and we have community policies  
>> governing its usage, svn and our mailing lists are where we need to  
>> be collaborating.
> Why does *everyone* need to use GIT?  IMO it is just a tool, some  
> folks might prefer BZR, HG or SVK, making use of the features/ 
> advantages that each tool provides.  I don't see why there would  
> ever need to be a point where *everyone* is on the same tool since  
> ATM the underlying authoritative and definitive location for the  
> codebase is the ASF SVN.

Let me explain what I meant by that... Until we have community policy  
that governs our usage of GIT, I think GIT should not be used to share  
code between members of our community. Until then, use it as a tool to  
improve your local development -- just like you might use SVK (I'm not  
familiar with BZR or HG). If GIT improves your productivity, that's  

However, if you and Joe start sharing GIT to privately share code  
(merging between your two GIT repos), then I'd be concerned. Just like  
I'd be concerned if you and Joe were privately sharing code patches.  
Does that make sense?

If you and Joe are sharing code in an SVN sandbox, via patches in  
JIRA, or via patches in community mailing list emails, then everyone  
in the community can participate. That sort of openness needs to be  
maintained with any usage of GIT within the community.

> * * *
> I really don't see what the harm is that you seem worried about.   
> I'm not sure that we need any "policies governing its usage" either,  
> no more than we need guidelines on how some one uses /bin/vi or  
> notepad.exe, unless you mean the content not the tool, and in that  
> case I think the general docs we have on that is sufficient.
> IMO GIT allows for a much more flexible development model, and I  
> really don't see why we'd want to take away that flexibly with tape  
> (of the red kind).

Maintaining open communication is my only concern. That's the only  
"red tape" that I'm putting on the process. I'm not saying this can't  
be fixed. Just that we'd have to work out the issues...

As always, I'd like to hear from others in the community...

It might be useful if you could let others know how you're using GIT.


View raw message