On Fri, May 2, 2008 at 10:31 AM, Martijn Dashorst < [EMAIL PROTECTED]> wrote:
> There is just one thing that bugs me. By moving main development off > of svn into git-svn, you limit the visibility of development for > non-git users, effectively forcing everyone that wants to join the > project to us git-svn. How else will they be able to work on a branch, > or see your code? The only "development" that is visible are the > commits done on trunk. > Mmmh I'm not sure I'm following you here. So git-svn is a client, locally it helps you use git to handle your working copy. So you enjoy all the git features that we like. But git-svn is still backed by svn, when you do 'svn-git dcommit' it goes to the SVN central repository like any other commit. On Apache ODE for example, I personnally also git-svn nowadays, it makes it much easier to have temporary local branches. I can develop a bigger-sized feature that I can't commit for 3-4 days (because it breaks everything) and parrallely do small bug fixes or changes that I commit in SVN after just 20mn. I used to have several svn checkouts to do the same before and that's how most people usually handle this but that's a PITA to maintain. Some could argue I could have created a SVN branch for my 3-4 days development and use that instead. But sometimes it's just 2 days. Or 1 day. SVN branching is painful enough that in practice nobody creates small to mid-size branches. Now other committers on ODE use SVN and I'm sure they don't even know I've switched to git-svn (unless I tell them). I commit the same stuff, just as often. Only with better commit logs ;) So I'm missing the visibility part of your argument. Unless you have visibility on my svn local working copies without me knowing :) Cheers, Matthieu > > Effectively you have forked your community into git users versus non-git > users. > > Martijn > > On 5/2/08, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > On Fri, May 2, 2008 at 9:25 AM, Alex Boisvert <[EMAIL PROTECTED]> > wrote: > > > > > For what it's worth, my takeaways from this thread are, > > > > > > 1) Buildr developers want to lower the barrier to contribution and > > > participation -- many think using Git can help and therefore are > ready to > > > support it use. > > > > > > 2) Many people are concerned that using distributed SCM tools may > lead to > > > lesser community participation because it makes caving/forking easier > -- or > > > more generally it could lead to a more fragmented community > > > > > > Both of these arguments have merit and I don't believe there's a > definitive > > > indication as to which outcome is most likely. This being said, > > > > > > 3) Buildr developers believe using Git is compatible with the Apache > Way, > > > and acknowledge the concerns and risks of fragmentation; we believe > the > > > risks can be mitigated by clearly articulating that the focus of the > > > project > > > lies within Apache and that dSCM is a convenience, not a substitute > for > > > community participation. With great power comes increased > responsibility. > > > > > > 4) Buildr developers want the freedom to experiment with dSCM and > would > > > prefer to do so with the concent of the incubator PMC. We believe > the > > > incubator is a good place to run such experiment and we're willing to > > > accept > > > the guidance and mentoring of the IPMC to reach both objectives: > increased > > > participation and stronger community. We assume the risk that it > might > > > affect the time and outcome for graduation, should the experiment > fail, but > > > we're convinced that we can make it happen. > > > > > > > > Agree, but I want to clarify a couple of points: > > > > Git is presently a choice, and we wont' be running off SVN, until > Apache > > infrastructure switches to Git. It's an option available to anyone, > and > > they can choose to use it any way they want. > > > > We can warn people of the potential for misuse, but we can't stop them > from > > using Git. Alternatively, we can warn people of the potential for > misuse, > > and provide a way to use it responsibly, turning it into a benefit. > And I > > articulated some of the ways in which Git could work better than SVN. > > > > So it's about the way we make it easier on everyone to use Git > responsibly, > > so that -- not misuse -- becomes the default path and the one everybody > can > > follow by example. > > > > > > Assaf > > > > > > > > > > > > > > > I hope I'm not misrepresenting anything or anybody here; please > correct me > > > if you feel your opinion has not been represented here. > > > > > > alex > > > > > > On Thu, May 1, 2008 at 7:42 PM, Assaf Arkin <[EMAIL PROTECTED]> > wrote: > > > > > > > On Thu, May 1, 2008 at 2:30 PM, Gilles Scokart <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > > > I don't want to reactivate this thread. I just want to make sure > you > > > > > understood one point by repharasing it. > > > > > > > > > > > > I think we should keep this thread open as long as we need to. > We're > > > > talking about community ownership here, and we have to make sure we > keep > > > > doing the right thing. > > > > > > > > Assaf > > > > > > > > > > > > > > > > > > > > > > > If we 'fear' creating block commits, it is simply because we know > what > > > > > it give. When a commit is too big it is impossible to review and > it > > > > > becomes more difficult to have a community 'ownership' of the > code. > > > > > > > > > > (Now, I didn't say that you are making too big changes... I just > say > > > > > that it could happen...) > > > > > > > > > > I will now follow Martijn and lurking again also. > > > > > > > > > > -- > > > > > Gilles Scokart > > > > > > > > > > > > > > > > > > > > > > -- > > CTO, Intalio > > http://www.intalio.com > > > > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.3 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 >
