couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: Moving CouchDB to Git
Date Mon, 08 Aug 2011 12:53:54 GMT
All good points, I think the counterargument is that it becomes rather difficult to rollback
to svn after we do something as complicated as srcmv in git.  That being said, I'm +1 on git
first, especially since the original srcmv instructions have probably suffered from some code
rot at this point.


On Aug 7, 2011, at 2:41 PM, Chris Anderson wrote:

> I agree we should do the srcmv thing after we move to git. No need to
> introduce more complexity to the git/svn question.
> Plus git is better at that sort of thing, in general, than svn, so
> waiting until we are git makes sense to me.
> Chris
> On Mon, Aug 1, 2011 at 1:37 PM, Robert Newson <> wrote:
>> +1 for doing the move afterwards.
>> On 1 August 2011 21: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.
>>>>> 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
>>>>> 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
> -- 
> Chris Anderson

View raw message