couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Moving CouchDB to Git
Date Mon, 01 Aug 2011 20:37:07 GMT
+1 for doing the move afterwards.

On 1 August 2011 21:34, Randall Leeds <randall.leeds@gmail.com> wrote:
> I think the big question Paul was trying to get an answer to was "srcmv
> before or after?".
> I'm not sure I have strong feelings, but I feel like we need to answer that
> or all these +1s aren't going to move us forward.
>
> On Mon, Aug 1, 2011 at 12:11, Robert Dionne <dionne@dionne-associates.com>wrote:
>
>> +1
>>
>>
>>
>>
>> On Jul 31, 2011, at 12:29 PM, Paul Davis wrote:
>>
>> > Dearest Devs,
>> >
>> > A few months ago I did some work in preparing a solution to using Git
>> > as a primary VCS at the ASF. Now that we have released 1.1.0 and 1.0.3
>> > there's a bit of a lull in large events dealing with the code base. As
>> > such I thought now would be a good time to propose the idea of moving
>> > CouchDB to Git.
>> >
>> > A few things on what this would mean for the community:
>> >
>> > 1. The SVN repository would no longer be the primary source for
>> > CouchDB source code. It'll still exist for house keeping things like
>> > the website and other bits.
>> >
>> > 2. For the time being there is no fancy integration with anything like
>> > Gerrit. The initial phase of moving to Git will be to just test the
>> > infrastructure aspects of the system to make sure its all configured
>> > correctly and works reliably. This also applies to GitHub. There's no
>> > magical "Pull request turns into JIRA ticket" or similar. GitHub will
>> > remain as it is a currently, a read-only mirror in the GitHub
>> > ecosystem.
>> >
>> > 3. There are a couple minor restrictions on our Git usage as required
>> > by ASF policy. First, rewriting Git commits on master is prohibited. I
>> > also added a feature that allows us to make branches that can't be
>> > rewritten either in the interest of protecting release branches.
>> > Currently, this is just a regular expression that matches
>> > "(master)|(rel/*)" in the branch name. The second issue is that
>> > there's always a possibility we have to revert to SVN if things break.
>> > In this interest I've disabled inserting merge commits into those same
>> > branches.
>> >
>> > 4. Before making the complete switch I'll end up making a handful of
>> > Git clones to check that our history is preserved. I plan on writing a
>> > script to make Graphviz images of the branch history and so on, but
>> > having people volunteer to look back at the history to spot errors
>> > would be helpful as well.
>> >
>> > 5. There are probably other things, but this is mostly to just kick
>> > off serious discussion on making the switch.
>> >
>> > Thoughts?
>> >
>> > Paul
>>
>>
>

Mime
View raw message