[Date Prev][Date Next]
Re: OpenLDAP 2.5
Simon Wilkinson wrote:
> On 5 Jan 2010, at 18:33, Quanah Gibson-Mount wrote:
>> --On Tuesday, December 22, 2009 7:40 PM -0800 Howard Chu <email@example.com
>>> With 2.4.21 out, and hopefully stable enough to promote to the next
>>> Stable release, it's time to feature-freeze 2.4 and prepare for the
>>> branch. As I already announced to the OpenLDAP-Committers, we're also
>>> planning to switch from CVS to GIT in mid-January. Commits for 2.5
>>> begin after we've settled into GIT.
>> Yeah! One question from the RE side, is how to best handle 2.4
>> fixes with HEAD getting further & further apart.
> You also want to consider how git's tools for branching and merging
> fit together. We went through this with OpenAFS last year, guided by
> some very helpful conversations with Shawn Pearce. Basically, the
> fundamental question is whether you want a merge based workflow, one
> based around cherry-picks, or some hybrid version of the two.
> If you have a merge based workflow, then the model is that you make
> that change on a branch, and then merge that branch into the head.
> OpenAFS (and OpenLDAP, by the sounds of things) had a model where we
> committed to HEAD, and then 'pulled-up' to the relevant branches. You
> can't do that with a git merge, because the commit on HEAD includes
> the history of everything else on head, which you definitely don't
> want to pull into the branch. So, we ended up deciding to cherry-pick
> pullups. This makes it harder to tell whether we've missed anything
> that should be pulled up, but "git cherry" helps ease that pain, and
> it means we keep our existing workflow.
> I'd also strongly recommend that you take a look at Shawn's "gerrit"
> tool. This provides a code review tool for patch submission, and
> hugely simplifies the process of controlling push access to a git
> tree, and reviewing the changes that you accept.
> I'm happy to talk to you about OpenAFS's experiences in all of this,
> if you'd like more details.
Absolutely, thanks for the offer. Up till now my use of git has been extremely
basic. It wouldn't bother me too much to continue the CVS-style workflow we've
had, but if there are better ways that involve less manual labor, we certainly
want to know.
(Though frankly, the fact that git is faster and works from a complete local
repo was convincing enough for me. Being able to perform local commits to save
and backtrack my work-in-progress without requiring network access is already
a huge gain.)
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/