Re: Podling to use native git
I do agree with you. I don't really get this argument either. But in the meantime, you need to use an svn backend, and ask for a git mirror. You can then fork / merge at github the way you want, merge back into trunk and git svn dcommit from there. I think it's really worse, as branches aren't maintained anymore in the apache svn area, but that's what we need to live with until git can be properly supported at Apache. On Fri, Oct 1, 2010 at 08:49, Mark Struberg wrote: > Hmm, to be honest, I don't see this argument. Because you can also use a > centralised model with GIT. > > Also, the main benefit of GIT is not only that you can do offline commits, > but mostly that it's sooo much easier to merge! > I had a merge hell with my colleague in the company this week. He kept a > SVN feature branch for only one week and merging his feature branch into the > trunk (team with 10 developers) did cost us a whole day... > > The reason is that SVN applies an end to end diff while git aims to merge > by walking the commit tree of the branch and applying each commit > separately. > > GIT even supports signing off commits. So each committer who pushes to the > central repo 'signs' that the contribution is ASL licensed. > > LieGrue, > stru > > --- On Thu, 9/30/10, Noel J. Bergman wrote: > > > From: Noel J. Bergman > > Subject: RE: Podling to use native git > > To: general@incubator.apache.org > > Date: Thursday, September 30, 2010, 11:13 PM > > > Does any other podling use > > git-only workflow. > > > > No ASF project is permitted to use git-only. And the > > typical git workflow is part of the problem. We > > strongly believe in a single, central, repository as part of > > the process of community building. The git model is > > better suited to disparate groups partially sharing a > > codebase. > > > > Fundamentally, we WANT people working in a central, shared, > > repository. > > > > If/when the ASF allows git as a technology, you can expect > > that the workflow will be an ASF workflow. And once > > Greg gets offline commmit working with SVN, I suspect that > > it will be harder to push for git. > > > > --- Noel > > > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
RE: Podling to use native git
> -Original Message- > From: Guillaume Nodet [mailto:gno...@gmail.com] > Sent: Friday, 1 October 2010 5:11 PM > To: general@incubator.apache.org > Subject: Re: Podling to use native git > > I do agree with you. I don't really get this argument either. > > But in the meantime, you need to use an svn backend, and ask for a git > mirror. You can then fork / merge at github the way you want, merge > back > into trunk and git svn dcommit from there. > > I think it's really worse, as branches aren't maintained anymore in the > apache svn area, What's wrong with 'git tag' ?? > but that's what we need to live with until git can be > properly supported at Apache. It will be a while. Gav... > > On Fri, Oct 1, 2010 at 08:49, Mark Struberg wrote: > > > Hmm, to be honest, I don't see this argument. Because you can also > use a > > centralised model with GIT. > > > > Also, the main benefit of GIT is not only that you can do offline > commits, > > but mostly that it's sooo much easier to merge! > > I had a merge hell with my colleague in the company this week. He > kept a > > SVN feature branch for only one week and merging his feature branch > into the > > trunk (team with 10 developers) did cost us a whole day... > > > > The reason is that SVN applies an end to end diff while git aims to > merge > > by walking the commit tree of the branch and applying each commit > > separately. > > > > GIT even supports signing off commits. So each committer who pushes > to the > > central repo 'signs' that the contribution is ASL licensed. > > > > LieGrue, > > stru > > > > --- On Thu, 9/30/10, Noel J. Bergman wrote: > > > > > From: Noel J. Bergman > > > Subject: RE: Podling to use native git > > > To: general@incubator.apache.org > > > Date: Thursday, September 30, 2010, 11:13 PM > > > > Does any other podling use > > > git-only workflow. > > > > > > No ASF project is permitted to use git-only. And the > > > typical git workflow is part of the problem. We > > > strongly believe in a single, central, repository as part of > > > the process of community building. The git model is > > > better suited to disparate groups partially sharing a > > > codebase. > > > > > > Fundamentally, we WANT people working in a central, shared, > > > repository. > > > > > > If/when the ASF allows git as a technology, you can expect > > > that the workflow will be an ASF workflow. And once > > > Greg gets offline commmit working with SVN, I suspect that > > > it will be harder to push for git. > > > > > > --- Noel > > > > > > > > > > > > --- > -- > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling to use native git
On Fri, Oct 1, 2010 at 09:44, Gav... wrote: > > > > -Original Message- > > From: Guillaume Nodet [mailto:gno...@gmail.com] > > Sent: Friday, 1 October 2010 5:11 PM > > To: general@incubator.apache.org > > Subject: Re: Podling to use native git > > > > I do agree with you. I don't really get this argument either. > > > > But in the meantime, you need to use an svn backend, and ask for a git > > mirror. You can then fork / merge at github the way you want, merge > > back > > into trunk and git svn dcommit from there. > > > > I think it's really worse, as branches aren't maintained anymore in the > > apache svn area, > > What's wrong with 'git tag' ?? > What I'm saying is that having to maintain some branches at github outside of svn in git is not the best thing. But that's really the only option we have here. > > > > but that's what we need to live with until git can be > > properly supported at Apache. > > It will be a while. > > > Gav... > > > > > On Fri, Oct 1, 2010 at 08:49, Mark Struberg wrote: > > > > > Hmm, to be honest, I don't see this argument. Because you can also > > use a > > > centralised model with GIT. > > > > > > Also, the main benefit of GIT is not only that you can do offline > > commits, > > > but mostly that it's sooo much easier to merge! > > > I had a merge hell with my colleague in the company this week. He > > kept a > > > SVN feature branch for only one week and merging his feature branch > > into the > > > trunk (team with 10 developers) did cost us a whole day... > > > > > > The reason is that SVN applies an end to end diff while git aims to > > merge > > > by walking the commit tree of the branch and applying each commit > > > separately. > > > > > > GIT even supports signing off commits. So each committer who pushes > > to the > > > central repo 'signs' that the contribution is ASL licensed. > > > > > > LieGrue, > > > stru > > > > > > --- On Thu, 9/30/10, Noel J. Bergman wrote: > > > > > > > From: Noel J. Bergman > > > > Subject: RE: Podling to use native git > > > > To: general@incubator.apache.org > > > > Date: Thursday, September 30, 2010, 11:13 PM > > > > > Does any other podling use > > > > git-only workflow. > > > > > > > > No ASF project is permitted to use git-only. And the > > > > typical git workflow is part of the problem. We > > > > strongly believe in a single, central, repository as part of > > > > the process of community building. The git model is > > > > better suited to disparate groups partially sharing a > > > > codebase. > > > > > > > > Fundamentally, we WANT people working in a central, shared, > > > > repository. > > > > > > > > If/when the ASF allows git as a technology, you can expect > > > > that the workflow will be an ASF workflow. And once > > > > Greg gets offline commmit working with SVN, I suspect that > > > > it will be harder to push for git. > > > > > > > > --- Noel > > > > > > > > > > > > > > > > --- > > -- > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > -- > > Cheers, > > Guillaume Nodet > > > > Blog: http://gnodet.blogspot.com/ > > > > Open Source SOA > > http://fusesource.com > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Podling to use native git
> > I think it's really worse, as branches aren't maintained > > anymore in the apache svn area, yes, and anyone ever asked yourself _why_ this happens? The answer imo is: because its _sooo_ painful to do feature branches in SVN (and merge them back). GIT otoh has it's flaws too. There is e.g. no way to keep one big fat unique Apache SVN where you can move around directories. This would have to be done with git-submodules, which is much less handy. So I'm with Gav here: we need to evaluate this in multiple steps 1st) in theory, and later 2nd) via an incubator podling project If it turns out that we cannot live with GIT, then we could still import all the history of 'master' into our SVN. LieGrue, strub --- On Fri, 10/1/10, Guillaume Nodet wrote: > From: Guillaume Nodet > Subject: Re: Podling to use native git > To: general@incubator.apache.org > Date: Friday, October 1, 2010, 8:20 AM > On Fri, Oct 1, 2010 at 09:44, Gav... > > wrote: > > > > > > > > -Original Message- > > > From: Guillaume Nodet [mailto:gno...@gmail.com] > > > Sent: Friday, 1 October 2010 5:11 PM > > > To: general@incubator.apache.org > > > Subject: Re: Podling to use native git > > > > > > I do agree with you. I don't > really get this argument either. > > > > > > But in the meantime, you need to use an svn > backend, and ask for a git > > > mirror. You can then fork > / merge at github the way you want, merge > > > back > > > into trunk and git svn dcommit from there. > > > > > > I think it's really worse, as branches aren't > maintained anymore in the > > > apache svn area, > > > > What's wrong with 'git tag' ?? > > > > What I'm saying is that having to maintain some branches at > github outside > of svn in git is not the best thing. But > that's really the only option we > have here. > > > > > > > > > but that's what we need to live with until git > can be > > > properly supported at Apache. > > > > It will be a while. > > > > > > Gav... > > > > > > > > On Fri, Oct 1, 2010 at 08:49, Mark Struberg > > wrote: > > > > > > > Hmm, to be honest, I don't see this > argument. Because you can also > > > use a > > > > centralised model with GIT. > > > > > > > > Also, the main benefit of GIT is not only > that you can do offline > > > commits, > > > > but mostly that it's sooo much easier to > merge! > > > > I had a merge hell with my colleague in the > company this week. He > > > kept a > > > > SVN feature branch for only one week and > merging his feature branch > > > into the > > > > trunk (team with 10 developers) did cost us > a whole day... > > > > > > > > The reason is that SVN applies an end to end > diff while git aims to > > > merge > > > > by walking the commit tree of the branch and > applying each commit > > > > separately. > > > > > > > > GIT even supports signing off commits. So > each committer who pushes > > > to the > > > > central repo 'signs' that the contribution > is ASL licensed. > > > > > > > > LieGrue, > > > > stru > > > > > > > > --- On Thu, 9/30/10, Noel J. Bergman > wrote: > > > > > > > > > From: Noel J. Bergman > > > > > Subject: RE: Podling to use native git > > > > > To: general@incubator.apache.org > > > > > Date: Thursday, September 30, 2010, > 11:13 PM > > > > > > Does any other podling use > > > > > git-only workflow. > > > > > > > > > > No ASF project is permitted to use > git-only. And the > > > > > typical git workflow is part of the > problem. We > > > > > strongly believe in a single, central, > repository as part of > > > > > the process of community > building. The git model is > > > > > better suited to disparate groups > partially sharing a > > > > > codebase. > > > > > > > > > > Fundamentally, we WANT people working > in a central, shared, > > > > > repository. > > > > > > > > > > If/when the ASF allows git as a > technology, you can expect > > > > > that the workflow will be an ASF > workflow. And once > > > > > Greg gets offline commmit working with > SVN, I suspect that > > > > > it will be harder to push for git. > > > > > > > > > > --- Noel > > > > > > > > > > > > > > > > > > > > > --- > > > -- > > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > > > > > -- > > > Cheers, > > > Guillaume Nodet > > > > > > Blog: http://gnodet.blogspot.com/ > > > > > > Open Source SOA > > > http://fusesource.com > > > > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache
Re: Podling to use native git
On Fri, Oct 1, 2010 at 10:45, Mark Struberg wrote: > > > I think it's really worse, as branches aren't maintained > > > anymore in the apache svn area, > > yes, and anyone ever asked yourself _why_ this happens? > The answer imo is: because its _sooo_ painful to do feature branches in SVN > (and merge them back). > Yes, this is the real reason ... and having an offline commit in svn won't solve that problem. > > GIT otoh has it's flaws too. There is e.g. no way to keep one big fat > unique Apache SVN where you can move around directories. This would have to > be done with git-submodules, which is much less handy. > > So I'm with Gav here: we need to evaluate this in multiple steps > > 1st) in theory, and later > 2nd) via an incubator podling project > > If it turns out that we cannot live with GIT, then we could still import > all the history of 'master' into our SVN. > > LieGrue, > strub > > > --- On Fri, 10/1/10, Guillaume Nodet wrote: > > > From: Guillaume Nodet > > Subject: Re: Podling to use native git > > To: general@incubator.apache.org > > Date: Friday, October 1, 2010, 8:20 AM > > On Fri, Oct 1, 2010 at 09:44, Gav... > > > > wrote: > > > > > > > > > > > > -Original Message- > > > > From: Guillaume Nodet [mailto:gno...@gmail.com] > > > > Sent: Friday, 1 October 2010 5:11 PM > > > > To: general@incubator.apache.org > > > > Subject: Re: Podling to use native git > > > > > > > > I do agree with you. I don't > > really get this argument either. > > > > > > > > But in the meantime, you need to use an svn > > backend, and ask for a git > > > > mirror. You can then fork > > / merge at github the way you want, merge > > > > back > > > > into trunk and git svn dcommit from there. > > > > > > > > I think it's really worse, as branches aren't > > maintained anymore in the > > > > apache svn area, > > > > > > What's wrong with 'git tag' ?? > > > > > > > What I'm saying is that having to maintain some branches at > > github outside > > of svn in git is not the best thing. But > > that's really the only option we > > have here. > > > > > > > > > > > > > > but that's what we need to live with until git > > can be > > > > properly supported at Apache. > > > > > > It will be a while. > > > > > > > > > Gav... > > > > > > > > > > > On Fri, Oct 1, 2010 at 08:49, Mark Struberg > > > > wrote: > > > > > > > > > Hmm, to be honest, I don't see this > > argument. Because you can also > > > > use a > > > > > centralised model with GIT. > > > > > > > > > > Also, the main benefit of GIT is not only > > that you can do offline > > > > commits, > > > > > but mostly that it's sooo much easier to > > merge! > > > > > I had a merge hell with my colleague in the > > company this week. He > > > > kept a > > > > > SVN feature branch for only one week and > > merging his feature branch > > > > into the > > > > > trunk (team with 10 developers) did cost us > > a whole day... > > > > > > > > > > The reason is that SVN applies an end to end > > diff while git aims to > > > > merge > > > > > by walking the commit tree of the branch and > > applying each commit > > > > > separately. > > > > > > > > > > GIT even supports signing off commits. So > > each committer who pushes > > > > to the > > > > > central repo 'signs' that the contribution > > is ASL licensed. > > > > > > > > > > LieGrue, > > > > > stru > > > > > > > > > > --- On Thu, 9/30/10, Noel J. Bergman > > wrote: > > > > > > > > > > > From: Noel J. Bergman > > > > > > Subject: RE: Podling to use native git > > > > > > To: general@incubator.apache.org > > > > > > Date: Thursday, September 30, 2010, > > 11:13 PM > > > > > > > Does any other podling use > > > > > > git-only workflow. > > > > > > > > > > > > No ASF project is permitted to use > > git-only. And the > > > > > > typical git workflow is part of the > > problem. We > > > > > > strongly believe in a single, central, > > repository as part of > > > > > > the process of community > > building. The git model is > > > > > > better suited to disparate groups > > partially sharing a > > > > > > codebase. > > > > > > > > > > > > Fundamentally, we WANT people working > > in a central, shared, > > > > > > repository. > > > > > > > > > > > > If/when the ASF allows git as a > > technology, you can expect > > > > > > that the workflow will be an ASF > > workflow. And once > > > > > > Greg gets offline commmit working with > > SVN, I suspect that > > > > > > it will be harder to push for git. > > > > > > > > > > > > --- Noel > > > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > -- > > > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > > > For additional commands, e-mail: > general-h...@incubator.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: general-unsubscr..
Re: Podling to use native git
Wow, I haven't intended to start another flame war : ) >From a technical standpoint, I do believe that git will be the default choice of developers more and more in the upcoming years, and Apache will start to support read-write git one day. I was just curious if we can volunteer to be the first podling (I think there is a discussion about using git-only for some Apache labs projects). Anyway, it seems that the discussions about git usage at the infra dev has been settled down to this: "switching to git is the most difficult thing in current infra". So we should not expect a first class git repo anytime soon I guess. But in the mean time, I was asking about whether any of the podlings use a git only workflow, I mean using git as the main tool and svn for commits only. And if so, do you svn-copy branches and releases, or use git for that. Thanks, Enis On Fri, Oct 1, 2010 at 11:58 AM, Guillaume Nodet wrote: > On Fri, Oct 1, 2010 at 10:45, Mark Struberg wrote: > > > > > I think it's really worse, as branches aren't maintained > > > > anymore in the apache svn area, > > > > yes, and anyone ever asked yourself _why_ this happens? > > The answer imo is: because its _sooo_ painful to do feature branches in > SVN > > (and merge them back). > > > > Yes, this is the real reason ... and having an offline commit in svn won't > solve that problem. > > > > > > GIT otoh has it's flaws too. There is e.g. no way to keep one big fat > > unique Apache SVN where you can move around directories. This would have > to > > be done with git-submodules, which is much less handy. > > > > So I'm with Gav here: we need to evaluate this in multiple steps > > > > 1st) in theory, and later > > 2nd) via an incubator podling project > > > > If it turns out that we cannot live with GIT, then we could still import > > all the history of 'master' into our SVN. > > > > LieGrue, > > strub > > > > > > --- On Fri, 10/1/10, Guillaume Nodet wrote: > > > > > From: Guillaume Nodet > > > Subject: Re: Podling to use native git > > > To: general@incubator.apache.org > > > Date: Friday, October 1, 2010, 8:20 AM > > > On Fri, Oct 1, 2010 at 09:44, Gav... > > > > > > wrote: > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Guillaume Nodet [mailto:gno...@gmail.com] > > > > > Sent: Friday, 1 October 2010 5:11 PM > > > > > To: general@incubator.apache.org > > > > > Subject: Re: Podling to use native git > > > > > > > > > > I do agree with you. I don't > > > really get this argument either. > > > > > > > > > > But in the meantime, you need to use an svn > > > backend, and ask for a git > > > > > mirror. You can then fork > > > / merge at github the way you want, merge > > > > > back > > > > > into trunk and git svn dcommit from there. > > > > > > > > > > I think it's really worse, as branches aren't > > > maintained anymore in the > > > > > apache svn area, > > > > > > > > What's wrong with 'git tag' ?? > > > > > > > > > > What I'm saying is that having to maintain some branches at > > > github outside > > > of svn in git is not the best thing. But > > > that's really the only option we > > > have here. > > > > > > > > > > > > > > > > > > > but that's what we need to live with until git > > > can be > > > > > properly supported at Apache. > > > > > > > > It will be a while. > > > > > > > > > > > > Gav... > > > > > > > > > > > > > > On Fri, Oct 1, 2010 at 08:49, Mark Struberg > > > > > > wrote: > > > > > > > > > > > Hmm, to be honest, I don't see this > > > argument. Because you can also > > > > > use a > > > > > > centralised model with GIT. > > > > > > > > > > > > Also, the main benefit of GIT is not only > > > that you can do offline > > > > > commits, > > > > > > but mostly that it's sooo much easier to > > > merge! > > > > > > I had a merge hell with my colleague in the > > > company this week. He > > > > > kept a > > > > > > SVN feature branch for only one week and > > > merging his feature branch > > > > > into the > > > > > > trunk (team with 10 developers) did cost us > > > a whole day... > > > > > > > > > > > > The reason is that SVN applies an end to end > > > diff while git aims to > > > > > merge > > > > > > by walking the commit tree of the branch and > > > applying each commit > > > > > > separately. > > > > > > > > > > > > GIT even supports signing off commits. So > > > each committer who pushes > > > > > to the > > > > > > central repo 'signs' that the contribution > > > is ASL licensed. > > > > > > > > > > > > LieGrue, > > > > > > stru > > > > > > > > > > > > --- On Thu, 9/30/10, Noel J. Bergman > > > wrote: > > > > > > > > > > > > > From: Noel J. Bergman > > > > > > > Subject: RE: Podling to use native git > > > > > > > To: general@incubator.apache.org > > > > > > > Date: Thursday, September 30, 2010, > > > 11:13 PM > > > > > > > > Does any other podling use > > > > > > > git-only workflow. > > > > > > > > > > > > > > No ASF project is permitted to use > > > git-only. And the > > > > > > > typi
Re: Podling to use native git
Hi, On Thu, Sep 30, 2010 at 2:02 PM, Enis Soztutar wrote: > ..In the preparation phase for the recent Gora podling, I realized that the > code needs be restructured to subversion layout. However, most of the > developers here prefer the git way and will never use subversion except for > committing the patches... Just a word of caution regarding incubation: if this means this podling's developers will work outside of Apache and just drop code in svn from time to time, Apache might not be the right place for your guys at this time. Things have to happen on your dev list and in svn if you want to be part of Apache, in order for a community to form around those channels. We've had some projects realize way too late that the Apache way of working was not for them - if that's the case for you guys, better fail early. Volunteering to help improve things is great, of course. I just wanted to point out that the above statement sounds alarming to me. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling to use native git
Interesting discussion. At OPS4J.org we also (practically) flesh out processes to accept GIT projects (parallel to the usual Subversion offering). What we do differently is leveraging GitHub as some sort of outsourced tooling instead of maintaining our own. (This - i think - will never happen with ASF) The idea is to use the best tools available for the job. For a Community its usually good to strive for talented developers and offer an environment where they like to work at. Also (thats a personal view) its something like a blueprint that corporates can learn from in terms of tooling, processes/communication. Its now the question to balance innovation (hence "coolness") and solid, well well known processes. Its also that Subversion is still the king in corporates (well, together with CVS). So you would attract a whole different kind of developers when adopting git. On the other hand you might lose attraction for the really successful (future) projects and/or setting standards for the next decade. Speaking of ASF, i think its worthwhile to think about it and maybe spike out a git incubator (say, "gincubator") that explores the benefits and pitfalls for ASF processes ? For regular podlings its not a question right now, as many have written here. just my 2cts. Toni ;) -- Toni Menzel || http://okidokiteam.com On Fri, Oct 1, 2010 at 11:09 AM, Enis Soztutar wrote: > Wow, I haven't intended to start another flame war : ) > > From a technical standpoint, I do believe that git will be the default > choice of developers more and more > in the upcoming years, and Apache will start to support read-write git one > day. I was just curious if we can > volunteer to be the first podling (I think there is a discussion about using > git-only for some Apache labs projects). > > > Anyway, it seems that the discussions about git usage at the infra dev has > been settled > down to this: "switching to git is the most difficult thing in current > infra". So we should not expect > a first class git repo anytime soon I guess. > > But in the mean time, I was asking about whether any of the podlings use a > git only workflow, I mean > using git as the main tool and svn for commits only. And if so, do you > svn-copy branches and releases, > or use git for that. > > Thanks, > Enis > > On Fri, Oct 1, 2010 at 11:58 AM, Guillaume Nodet wrote: > >> On Fri, Oct 1, 2010 at 10:45, Mark Struberg wrote: >> >> > > > I think it's really worse, as branches aren't maintained >> > > > anymore in the apache svn area, >> > >> > yes, and anyone ever asked yourself _why_ this happens? >> > The answer imo is: because its _sooo_ painful to do feature branches in >> SVN >> > (and merge them back). >> > >> >> Yes, this is the real reason ... and having an offline commit in svn won't >> solve that problem. >> >> >> > >> > GIT otoh has it's flaws too. There is e.g. no way to keep one big fat >> > unique Apache SVN where you can move around directories. This would have >> to >> > be done with git-submodules, which is much less handy. >> > >> > So I'm with Gav here: we need to evaluate this in multiple steps >> > >> > 1st) in theory, and later >> > 2nd) via an incubator podling project >> > >> > If it turns out that we cannot live with GIT, then we could still import >> > all the history of 'master' into our SVN. >> > >> > LieGrue, >> > strub >> > >> > >> > --- On Fri, 10/1/10, Guillaume Nodet wrote: >> > >> > > From: Guillaume Nodet >> > > Subject: Re: Podling to use native git >> > > To: general@incubator.apache.org >> > > Date: Friday, October 1, 2010, 8:20 AM >> > > On Fri, Oct 1, 2010 at 09:44, Gav... >> > > >> > > wrote: >> > > >> > > > >> > > > >> > > > > -Original Message- >> > > > > From: Guillaume Nodet [mailto:gno...@gmail.com] >> > > > > Sent: Friday, 1 October 2010 5:11 PM >> > > > > To: general@incubator.apache.org >> > > > > Subject: Re: Podling to use native git >> > > > > >> > > > > I do agree with you. I don't >> > > really get this argument either. >> > > > > >> > > > > But in the meantime, you need to use an svn >> > > backend, and ask for a git >> > > > > mirror. You can then fork >> > > / merge at github the way you want, merge >> > > > > back >> > > > > into trunk and git svn dcommit from there. >> > > > > >> > > > > I think it's really worse, as branches aren't >> > > maintained anymore in the >> > > > > apache svn area, >> > > > >> > > > What's wrong with 'git tag' ?? >> > > > >> > > >> > > What I'm saying is that having to maintain some branches at >> > > github outside >> > > of svn in git is not the best thing. But >> > > that's really the only option we >> > > have here. >> > > >> > > >> > > > >> > > > >> > > > > but that's what we need to live with until git >> > > can be >> > > > > properly supported at Apache. >> > > > >> > > > It will be a while. >> > > > >> > > > >> > > > Gav... >> > > > >> > > > > >> > > > > On Fri, Oct 1, 2010 at 08:49, Mark Struberg >> > > >> > > wrote: >> > > > > >> > > > > >
Re: Podling to use native git
On Fri, Oct 1, 2010 at 11:40 AM, Toni Menzel wrote: > Its now the question to balance innovation (hence "coolness") and > solid, well well known processes. > Its also that Subversion is still the king in corporates (well, > together with CVS). So you would attract a whole different kind of > developers when adopting git. FWIW people who use git/mercurial don't use it to be cool or innovative, they use it because it has become invaluable to their lives and they will never ever go back willingly to svn or even worse cvs. For them, git/mercurial *is* a well-known process. Florent -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling to use native git
On Fri, Oct 1, 2010 at 11:52 AM, Florent Guillaume wrote: > On Fri, Oct 1, 2010 at 11:40 AM, Toni Menzel wrote: >> Its now the question to balance innovation (hence "coolness") and >> solid, well well known processes. >> Its also that Subversion is still the king in corporates (well, >> together with CVS). So you would attract a whole different kind of >> developers when adopting git. > > FWIW people who use git/mercurial don't use it to be cool or > innovative, they use it because it has become invaluable to their > lives and they will never ever go back willingly to svn or even worse > cvs. For them, git/mercurial *is* a well-known process. This is the next gen folks. And you tried it for a reason before it turned into an essential thing you don't want to go back from. For people who don't know distributed SCMs its a different beast. Its a different branch of developers you attract at the current point in time. In 5 yrs things will look different. I just question if ASF wants that. The cool kids (sorry, "essential distributed scm kids") can come to OPS4J ;) *sorry, hope you guys see the fun here. No offense at all!* > > Florent > > -- > Florent Guillaume, Director of R&D, Nuxeo > Open Source, Java EE based, Enterprise Content Management (ECM) > http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Toni Menzel || http://okidokiteam.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Podling to use native git
> -Original Message- > From: Florent Guillaume [mailto:f...@nuxeo.com] > Sent: Friday, 1 October 2010 7:52 PM > To: general@incubator.apache.org > Subject: Re: Podling to use native git > > On Fri, Oct 1, 2010 at 11:40 AM, Toni Menzel > wrote: > > Its now the question to balance innovation (hence "coolness") and > > solid, well well known processes. > > Its also that Subversion is still the king in corporates (well, > > together with CVS). So you would attract a whole different kind of > > developers when adopting git. > > FWIW people who use git/mercurial don't use it to be cool or > innovative, they use it because it has become invaluable to their > lives and they will never ever go back willingly to svn or even worse > cvs. For them, git/mercurial *is* a well-known process. and to others there are another 15 at least to choose from, where does it stop, do you want infra to support all of them? or just the one *you* prefer. Let's be blunt, Subversion is and will remain the number one canonical repository at the ASF. We are looking at the possibilities of what we can do in terms of git and some of us will be having a meeting about it at ApacheCon. If we end up with a 2nd canonical git repo alongside svn sometime in the future then that is good, but it is also in the future, not now. Those that want it now, go elsewhere. Maybe I should go hack on some Git code and tell them I want them to have a svn repo that I can commit to because that is basically what everyone is doing here regarding Git when the ASF has Apache Subversion in house. We ARE working towards it but those getting there knickers in a twist about wanting it now and we are not with the times, tough. Gav... > > Florent > > -- > Florent Guillaume, Director of R&D, Nuxeo > Open Source, Java EE based, Enterprise Content Management (ECM) > http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling to use native git
Hi, On Fri, Oct 1, 2010 at 12:23 PM, Bertrand Delacretaz wrote: > Hi, > > On Thu, Sep 30, 2010 at 2:02 PM, Enis Soztutar > wrote: > > ..In the preparation phase for the recent Gora podling, I realized that > the > > code needs be restructured to subversion layout. However, most of the > > developers here prefer the git way and will never use subversion except > for > > committing the patches... > > Just a word of caution regarding incubation: if this means this > podling's developers will work outside of Apache and just drop code in > svn from time to time, Apache might not be the right place for your > guys at this time. Things have to happen on your dev list and in svn > if you want to be part of Apache, in order for a community to form > around those channels. > Thanks for bringing that up. But of course it would not be the case. As stated at our proposal, we very much believe in the Apache way of development. Actually, all of the initial committers are ASF committers for other projects. So no worry there. Enis > > We've had some projects realize way too late that the Apache way of > working was not for them - if that's the case for you guys, better > fail early. > > Volunteering to help improve things is great, of course. I just wanted > to point out that the above statement sounds alarming to me. > > -Bertrand > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Incubator PMC/Board report for October 2010 (general@incubator.apache.org)
Dear ALOIS Developers, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 20 October 2010, 12 pm Pacific. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted one week before the board meeting, to allow sufficient time for review. Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is one week prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/October2010 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Incubator PMC/Board report for October 2010 (general@incubator.apache.org)
Dear Gora Developers, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 20 October 2010, 12 pm Pacific. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted one week before the board meeting, to allow sufficient time for review. Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is one week prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/October2010 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling to use native git
Hi Guys, As the project's champion I'll work with the rest of the mentors and PPMC members to make sure we are moving forward in the Apache Way. Cheers, Chris On 10/1/10 2:23 AM, "Bertrand Delacretaz" wrote: Hi, On Thu, Sep 30, 2010 at 2:02 PM, Enis Soztutar wrote: > ..In the preparation phase for the recent Gora podling, I realized that the > code needs be restructured to subversion layout. However, most of the > developers here prefer the git way and will never use subversion except for > committing the patches... Just a word of caution regarding incubation: if this means this podling's developers will work outside of Apache and just drop code in svn from time to time, Apache might not be the right place for your guys at this time. Things have to happen on your dev list and in svn if you want to be part of Apache, in order for a community to form around those channels. We've had some projects realize way too late that the Apache way of working was not for them - if that's the case for you guys, better fail early. Volunteering to help improve things is great, of course. I just wanted to point out that the above statement sounds alarming to me. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: [RESULT] [VOTE] Kitty to Enter the Incubator
I am calling this vote as suggested: IPMC Binding: +1 Jim Jagielski Kevan Miller Davanum Srinivas Niclas Hedhman Julien Vermillard Alan D. Cabrera Mark Struberg (my apologies to anyone I may have missed) Non-binding: Stuart Williams Rainer Jung Niclas Hedhman Mohammad Nour El-Din (my apologies to any folks I may have missed) I will do follow-ups and Wiki page finessing next week. Thanks to all, Matthew Sacks Bitsource, GlassCode, et al. -Original Message- From: "Kevan Miller" Sent: Wednesday, September 29, 2010 6:52pm To: general@incubator.apache.org Subject: Re: [VOTE] Kitty to Enter the Incubator On Sep 29, 2010, at 3:24 PM, matt...@matthewsacks.com wrote: > Hi List, > I would like to do a quick sanity check on this thread. > Please correct me if I am wrong, but we have 2 binding PMC votes, 2 new > contributors (Rainer Jung and Senaka Fernando) and 1 new mentor (Kevan > Miller). More binding votes than that... Senaka, Jim, Kevan, Niclas, Julien, Alan (apologies if I'm missing . You also now have Dims and Mark. > > I believe my facts to be accurate. I plan on updating the Wiki next week to > reflect this when I complete some travels, and create a fork for a Groovy > port to begin that work. IMO, time to call this vote and start podling setup activities. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling to use native git
On Fri, Oct 1, 2010 at 04:45, Mark Struberg wrote: >> > I think it's really worse, as branches aren't maintained >> > anymore in the apache svn area, > > yes, and anyone ever asked yourself _why_ this happens? > The answer imo is: because its _sooo_ painful to do feature branches in SVN > (and merge them back). Why is it painful? I do branches all the time in Subversion, and don't see problems. We periodically update the branch from trunk, and when the work is done, merge the branch back onto trunk. These are straight-forward operations, so I don't understand where your pain point is. If you could explain a bit, then that would be helpful. Thanks, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling to use native git
On Fri, Oct 1, 2010 at 11:44 PM, Greg Stein wrote: > I do branches all the time in Subversion, and don't see problems. We > periodically update the branch from trunk, and when the work is done, > merge the branch back onto trunk. These are straight-forward > operations, so I don't understand where your pain point is. > > If you could explain a bit, then that would be helpful. Just out of curiosity: If you pull in changes from the trunk to the branch, how do you merge the branch later on? I'd consider the changes a problem that have been done in both branches. (Unlike git, which "knows" about these simultaneous changes.) Thanks, Jochen -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT] [VOTE] Kitty to Enter the Incubator
you even have one more, since Niclas is also a member and IPMC [1] ;) LieGrue, strub [1] http://people.apache.org/committer-index.html --- On Fri, 10/1/10, matt...@matthewsacks.com wrote: > From: matt...@matthewsacks.com > Subject: Re: [RESULT] [VOTE] Kitty to Enter the Incubator > To: general@incubator.apache.org > Date: Friday, October 1, 2010, 9:40 PM > I am calling this vote as suggested: > > IPMC Binding: > > +1 > > Jim Jagielski > Kevan Miller > Davanum Srinivas > Niclas Hedhman > Julien Vermillard > Alan D. Cabrera > Mark Struberg > > (my apologies to anyone I may have missed) > > Non-binding: > > Stuart Williams > Rainer Jung > Niclas Hedhman > Mohammad Nour El-Din > > (my apologies to any folks I may have missed) > > I will do follow-ups and Wiki page finessing next week. > > > Thanks to all, > Matthew Sacks > Bitsource, GlassCode, et al. > > > > -Original Message- > From: "Kevan Miller" > Sent: Wednesday, September 29, 2010 6:52pm > To: general@incubator.apache.org > Subject: Re: [VOTE] Kitty to Enter the Incubator > > > On Sep 29, 2010, at 3:24 PM, matt...@matthewsacks.com > wrote: > > > Hi List, > > I would like to do a quick sanity check on this > thread. > > Please correct me if I am wrong, but we have 2 binding > PMC votes, 2 new contributors (Rainer Jung and Senaka > Fernando) and 1 new mentor (Kevan Miller). > > More binding votes than that... Senaka, Jim, Kevan, Niclas, > Julien, Alan (apologies if I'm missing . You also now have > Dims and Mark. > > > > > I believe my facts to be accurate. I plan on updating > the Wiki next week to reflect this when I complete some > travels, and create a fork for a Groovy port to begin that > work. > > IMO, time to call this vote and start podling setup > activities. > > --kevan > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling to use native git
It seems that with 1.6 SVN did learn a bit about the 'git way' (apologize if it was even earlier and has nothing to do with git). SVN now applies merges bit by bit it seems (tested with 1.6.9). But I still have problems with intermediately merged projects (merging the trunk into my branch ~ every 2nd day). Somehow I ended up having the same pieces in my branch and in my trunk, but both got marked as conflict. Anyway, SVN is the way to go for now. LieGrue, strub --- On Fri, 10/1/10, Jochen Wiedmann wrote: > From: Jochen Wiedmann > Subject: Re: Podling to use native git > To: general@incubator.apache.org > Date: Friday, October 1, 2010, 9:48 PM > On Fri, Oct 1, 2010 at 11:44 PM, Greg > Stein > wrote: > > > I do branches all the time in Subversion, and don't > see problems. We > > periodically update the branch from trunk, and when > the work is done, > > merge the branch back onto trunk. These are > straight-forward > > operations, so I don't understand where your pain > point is. > > > > If you could explain a bit, then that would be > helpful. > > Just out of curiosity: If you pull in changes from the > trunk to the > branch, how do you merge the branch later on? I'd consider > the changes > a problem that have been done in both branches. (Unlike > git, which > "knows" about these simultaneous changes.) > > Thanks, > > Jochen > > -- > I Am What I Am And That's All What I Yam (Popeye) > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling to use native git
Well, the last time I had to know, ASF SVN was not 1.6, and the only merge technology was svnmerge.py, and make sure there's no Chinese in your log comments :-) It works. It doesn't work nearly so well as git for merging. CXF developers routinely use git-svn for feature branches. For all I know, ASF svn has since caught up. However, at the day job, the word is that 1.6 has partially broken svnmerge.py without completely replacing it. I have a lot of sympathy for people who want to model ASF development as 'SVN with offline branches and really good merging.' Incubator-wise, I think we may run into more and more communities who have perfectly reasonably community development models (one core trunk in one place) while at the same time having an established development process that uses GIT as a tool. We should be careful not to tar them with the 'many conflicting repositories' brush undeservedly. Hopefully an ASF ability to support this mode of operation will happen at some point -- in the mean time, it's git svn for the podlings just like it is for the projects. On Fri, Oct 1, 2010 at 6:00 PM, Mark Struberg wrote: > It seems that with 1.6 SVN did learn a bit about the 'git way' (apologize if > it was even earlier and has nothing to do with git). SVN now applies merges > bit by bit it seems (tested with 1.6.9). But I still have problems with > intermediately merged projects (merging the trunk into my branch ~ every 2nd > day). Somehow I ended up having the same pieces in my branch and in my trunk, > but both got marked as conflict. > > Anyway, SVN is the way to go for now. > > LieGrue, > strub > > --- On Fri, 10/1/10, Jochen Wiedmann wrote: > >> From: Jochen Wiedmann >> Subject: Re: Podling to use native git >> To: general@incubator.apache.org >> Date: Friday, October 1, 2010, 9:48 PM >> On Fri, Oct 1, 2010 at 11:44 PM, Greg >> Stein >> wrote: >> >> > I do branches all the time in Subversion, and don't >> see problems. We >> > periodically update the branch from trunk, and when >> the work is done, >> > merge the branch back onto trunk. These are >> straight-forward >> > operations, so I don't understand where your pain >> point is. >> > >> > If you could explain a bit, then that would be >> helpful. >> >> Just out of curiosity: If you pull in changes from the >> trunk to the >> branch, how do you merge the branch later on? I'd consider >> the changes >> a problem that have been done in both branches. (Unlike >> git, which >> "knows" about these simultaneous changes.) >> >> Thanks, >> >> Jochen >> >> -- >> I Am What I Am And That's All What I Yam (Popeye) >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT] [VOTE] Kitty to Enter the Incubator
Corrected. Thanks for the catch! -Original Message- From: "Mark Struberg" Sent: Friday, October 1, 2010 5:55pm To: general@incubator.apache.org Subject: Re: [RESULT] [VOTE] Kitty to Enter the Incubator you even have one more, since Niclas is also a member and IPMC [1] ;) LieGrue, strub [1] http://people.apache.org/committer-index.html --- On Fri, 10/1/10, matt...@matthewsacks.com wrote: > From: matt...@matthewsacks.com > Subject: Re: [RESULT] [VOTE] Kitty to Enter the Incubator > To: general@incubator.apache.org > Date: Friday, October 1, 2010, 9:40 PM > I am calling this vote as suggested: > > IPMC Binding: > > +1 > > Jim Jagielski > Kevan Miller > Davanum Srinivas > Niclas Hedhman > Julien Vermillard > Alan D. Cabrera > Mark Struberg > Niclas Hedhman > > (my apologies to anyone I may have missed) > > Non-binding: > > Stuart Williams > Rainer Jung > Mohammad Nour El-Din > > (my apologies to any folks I may have missed) > > I will do follow-ups and Wiki page finessing next week. > > > Thanks to all, > Matthew Sacks > Bitsource, GlassCode, et al. > > > > -Original Message- > From: "Kevan Miller" > Sent: Wednesday, September 29, 2010 6:52pm > To: general@incubator.apache.org > Subject: Re: [VOTE] Kitty to Enter the Incubator > > > On Sep 29, 2010, at 3:24 PM, matt...@matthewsacks.com > wrote: > > > Hi List, > > I would like to do a quick sanity check on this > thread. > > Please correct me if I am wrong, but we have 2 binding > PMC votes, 2 new contributors (Rainer Jung and Senaka > Fernando) and 1 new mentor (Kevan Miller). > > More binding votes than that... Senaka, Jim, Kevan, Niclas, > Julien, Alan (apologies if I'm missing . You also now have > Dims and Mark. > > > > > I believe my facts to be accurate. I plan on updating > the Wiki next week to reflect this when I complete some > travels, and create a fork for a Groovy port to begin that > work. > > IMO, time to call this vote and start podling setup > activities. > > --kevan > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling to use native git
Yup. The 1.5.x release introduced a feature called "merge tracking", but you really want to use 1.6.x (where many merge tracking issues were fixed/improved/sped-up). It remembers which revisions have been merged into a given location in the repository. This means bringing a branch up to date is easy: it just takes any revisions from trunk that haven't (yet) been merged and applies them to the branch. When the branch is ready, you merge back to trunk with the --reintegrate switch. That takes any revisions on the branch which are *not* those which came from trunk, and applies them onto trunk. ie. just the work you did on the branch. If you're getting conflicts, then maybe you missed the --reintegrate switch? Something is going on because (of course) that is exactly what the tracking is there to prevent. It is important that everybody uses at least a 1.5.x client (and even better if the server blocks earlier clients); otherwise, early clients will not report the merge. Cheers, -g On Fri, Oct 1, 2010 at 18:00, Mark Struberg wrote: > It seems that with 1.6 SVN did learn a bit about the 'git way' (apologize if > it was even earlier and has nothing to do with git). SVN now applies merges > bit by bit it seems (tested with 1.6.9). But I still have problems with > intermediately merged projects (merging the trunk into my branch ~ every 2nd > day). Somehow I ended up having the same pieces in my branch and in my trunk, > but both got marked as conflict. > > Anyway, SVN is the way to go for now. > > LieGrue, > strub > > --- On Fri, 10/1/10, Jochen Wiedmann wrote: > >> From: Jochen Wiedmann >> Subject: Re: Podling to use native git >> To: general@incubator.apache.org >> Date: Friday, October 1, 2010, 9:48 PM >> On Fri, Oct 1, 2010 at 11:44 PM, Greg >> Stein >> wrote: >> >> > I do branches all the time in Subversion, and don't >> see problems. We >> > periodically update the branch from trunk, and when >> the work is done, >> > merge the branch back onto trunk. These are >> straight-forward >> > operations, so I don't understand where your pain >> point is. >> > >> > If you could explain a bit, then that would be >> helpful. >> >> Just out of curiosity: If you pull in changes from the >> trunk to the >> branch, how do you merge the branch later on? I'd consider >> the changes >> a problem that have been done in both branches. (Unlike >> git, which >> "knows" about these simultaneous changes.) >> >> Thanks, >> >> Jochen >> >> -- >> I Am What I Am And That's All What I Yam (Popeye) >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
