couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Moving CouchDB to Git
Date Mon, 01 Aug 2011 21:26:47 GMT
On Mon, Aug 1, 2011 at 4:14 PM, Noah Slater <> wrote:
> What does it do?

If by "it" you mean srcmv, it was the script to reorganize the source tree.

If by "it" you mean Git, it makes coffee and walks the dogs.

> On 1 Aug 2011, at 22:34, Randall Leeds <> 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 <>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

View raw message