couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Moving CouchDB to Git
Date Sun, 31 Jul 2011 17:22:24 GMT
On Sun, Jul 31, 2011 at 11:52 AM, Robert Newson <rnewson@apache.org> wrote:
> Sounds good to me. Should we do srcmv before or after this epoch?
>

I am undecided. I think executing srcmv would be easier on Git, but in
a worst case scenario reverting to SVN it would be easier if we had
done it in SVN.

I am open to either method. The srcmv script I wrote a long time ago
to handle the SVN commands to make it happen would need a lot of
cleaning up to handle it though.

> +1 for prohibiting merge commits to stable branches.
>
> B.
>
> On 31 July 2011 17:29, Paul Davis <paul.joseph.davis@gmail.com> 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