You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Ken Giusti <kg...@redhat.com> on 2011/01/19 19:27:08 UTC
RFC: svn branching for new feature development
Hi all,
I've been working on the C++ broker flow control feature that I QIP'ed about last week. I'm planning on having the feature complete in time for the 0.10 release.
My concern is that I've been making a number of changes in my local sandbox that are, well, _local_. I'm just a dropped laptop or a spilled bottle of NightTrain away from losing all this work.
Actually, I've been working in an git clone of the apache/qpid git repo on github - so my changes are safe. But what I'd really like to do is develop this off a branch on the qpid trunk. Couple of reasons:
1) better visibility to other qpid developers - no need to track my github repo.
2) better history with respect to merging from trunk.
3) we can better control the introduction of this feature into trunk with respect to the release schedule.
Would it make sense, in general, to allow developers to create branches for the development of new or possibly disruptive features? We could leave it up to the release manager to make the go/no-go call for merging the branch prior to the alpha release.
Opinions?
-K
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: RFC: svn branching for new feature development
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2011-01-19 at 22:27 +0000, Robbie Gemmell wrote:
> You can use svn branches as well using git-svn in much the same way, no need to use github. You just make a new local branch based off a remote svn branch (or use git-svn to make the svn branch I believe) and then the workflow is really just the same as when working with trunk but dcommiting to the branch instead.
The one thing this scheme makes hard is rebasing the git-svn branch, but
I accept that this could be avoided (and perhaps should be!)
A
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: RFC: svn branching for new feature development
Posted by Robbie Gemmell <ro...@gmail.com>.
You can use svn branches as well using git-svn in much the same way, no need to use github. You just make a new local branch based off a remote svn branch (or use git-svn to make the svn branch I believe) and then the workflow is really just the same as when working with trunk but dcommiting to the branch instead.
The only thing you might have to watch out for is doing straight git merges between the 'svn branches' directly as the log messages will probably end up with unintended git-svn-id in them. That's easily fixed with an interactive rebase and a quick edit of the commit logs though, and as the 'proper' way of working with git would probably be to make local branch off the svn backed 'master' branches anyway that shouldn't actually be a problem in the first place.
Robbie
> -----Original Message-----
> From: Andrew Stitcher [mailto:astitcher@redhat.com]
> Sent: 19 January 2011 19:07
> To: dev@qpid.apache.org
> Subject: Re: RFC: svn branching for new feature development
>
> On Wed, 2011-01-19 at 13:27 -0500, Ken Giusti wrote:
> > ...
> > Would it make sense, in general, to allow developers to create
> branches for the development of new or possibly disruptive features?
> We could leave it up to the release manager to make the go/no-go call
> for merging the branch prior to the alpha release.
>
>
> As far as I know this is already the way that we are "supposed" to be
> developing substantial features.
>
> However, at least for me, a reason not to do this and to use github is
> precisely that svn makes the eventual merge more painful than
> necessary.
> Whereas git makes it between trivial and very easy (in my experience)
> and allows you to keep the full development history on check in too (I
> "git rebase" my branch on trunk then "git svn dcommit" all of it)
>
> Personally I'd vote for doing the work on github and posting the
> repo/branch url to the dev list to allow people to follow what's going
> on.
>
> Andrew
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: RFC: svn branching for new feature development
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2011-01-19 at 13:27 -0500, Ken Giusti wrote:
> ...
> Would it make sense, in general, to allow developers to create branches for the development of new or possibly disruptive features? We could leave it up to the release manager to make the go/no-go call for merging the branch prior to the alpha release.
As far as I know this is already the way that we are "supposed" to be
developing substantial features.
However, at least for me, a reason not to do this and to use github is
precisely that svn makes the eventual merge more painful than necessary.
Whereas git makes it between trivial and very easy (in my experience)
and allows you to keep the full development history on check in too (I
"git rebase" my branch on trunk then "git svn dcommit" all of it)
Personally I'd vote for doing the work on github and posting the
repo/branch url to the dev list to allow people to follow what's going
on.
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: svn branching for new feature development
Posted by Robbie Gemmell <ro...@gmail.com>.
Isn't that what branches are there for in the end? Seems reasonable to me..
Robbie
> -----Original Message-----
> From: Ken Giusti [mailto:kgiusti@redhat.com]
> Sent: 19 January 2011 18:27
> To: dev@qpid.apache.org
> Subject: RFC: svn branching for new feature development
>
> Hi all,
>
> I've been working on the C++ broker flow control feature that I QIP'ed
> about last week. I'm planning on having the feature complete in time
> for the 0.10 release.
>
> My concern is that I've been making a number of changes in my local
> sandbox that are, well, _local_. I'm just a dropped laptop or a
> spilled bottle of NightTrain away from losing all this work.
>
> Actually, I've been working in an git clone of the apache/qpid git repo
> on github - so my changes are safe. But what I'd really like to do is
> develop this off a branch on the qpid trunk. Couple of reasons:
>
> 1) better visibility to other qpid developers - no need to track my
> github repo.
> 2) better history with respect to merging from trunk.
> 3) we can better control the introduction of this feature into trunk
> with respect to the release schedule.
>
> Would it make sense, in general, to allow developers to create branches
> for the development of new or possibly disruptive features? We could
> leave it up to the release manager to make the go/no-go call for
> merging the branch prior to the alpha release.
>
> Opinions?
>
> -K
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: svn branching for new feature development
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2011-01-19 at 14:26 -0500, Steve Huston wrote:
> ...
>
> I also recommend a JIRA for the work being done that tracks what the
> goal is, the branch name/URL and a central tracked place for all this
> info.
Notwithstanding everything I said in my other email, I agree that
creating a JIRA (perhaps with a link to github etc.) is the way to go
too.
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: svn branching for new feature development
Posted by Steve Huston <sh...@riverace.com>.
Hi Ken,
> I've been working on the C++ broker flow control feature that
> I QIP'ed about last week. I'm planning on having the feature
> complete in time for the 0.10 release.
Cool.
> My concern is that I've been making a number of changes in my
> local sandbox that are, well, _local_. I'm just a dropped
> laptop or a spilled bottle of NightTrain away from losing all
> this work.
>
> Actually, I've been working in an git clone of the
> apache/qpid git repo on github - so my changes are safe. But
> what I'd really like to do is develop this off a branch on
> the qpid trunk. Couple of reasons:
>
> 1) better visibility to other qpid developers - no need to
> track my github repo.
> 2) better history with respect to merging from trunk.
> 3) we can better control the introduction of this feature
> into trunk with respect to the release schedule.
All good points.
> Would it make sense, in general, to allow developers to
> create branches for the development of new or possibly
> disruptive features? We could leave it up to the release
> manager to make the go/no-go call for merging the branch
> prior to the alpha release.
>
> Opinions?
My opinion is that the svn branch is the preferred way to go for all the
reasons you stated plus it ensures that only committers are putting
things into the code base.
I also recommend a JIRA for the work being done that tracks what the
goal is, the branch name/URL and a central tracked place for all this
info.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: RFC: svn branching for new feature development
Posted by Steve Huston <sh...@riverace.com>.
> Thanks for all the input - greatly appreciated. Here's my plan:
>
> Due to my weak git-fu skills
I can relate ;-)
> (my copy of ProGit should be
> arriving tomorrow, btw), I'll go with the svn branch for now.
> I've used the "main" jira number for the proposed feature as
> the name of the new branch:
>
> http://svn.apache.org/viewvc/qpid/branches/qpid-2935/
>
Perfect - thanks for the update.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: RFC: svn branching for new feature development
Posted by Ken Giusti <kg...@redhat.com>.
Thanks for all the input - greatly appreciated. Here's my plan:
Due to my weak git-fu skills (my copy of ProGit should be arriving tomorrow, btw), I'll go with the svn branch for now. I've used the "main" jira number for the proposed feature as the name of the new branch:
http://svn.apache.org/viewvc/qpid/branches/qpid-2935/
-K
----- Original Message -----
> Hi all,
>
> I've been working on the C++ broker flow control feature that I QIP'ed
> about last week. I'm planning on having the feature complete in time
> for the 0.10 release.
>
> My concern is that I've been making a number of changes in my local
> sandbox that are, well, _local_. I'm just a dropped laptop or a
> spilled bottle of NightTrain away from losing all this work.
>
> Actually, I've been working in an git clone of the apache/qpid git
> repo on github - so my changes are safe. But what I'd really like to
> do is develop this off a branch on the qpid trunk. Couple of reasons:
>
> 1) better visibility to other qpid developers - no need to track my
> github repo.
> 2) better history with respect to merging from trunk.
> 3) we can better control the introduction of this feature into trunk
> with respect to the release schedule.
>
> Would it make sense, in general, to allow developers to create
> branches for the development of new or possibly disruptive features?
> We could leave it up to the release manager to make the go/no-go call
> for merging the branch prior to the alpha release.
>
> Opinions?
>
> -K
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org