incubator-couchdb-dev mailing list archives

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.
Adam
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 <rnewson@apache.org> wrote:
>> +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
>>>>
>>>>
>>>
>>
>
>
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couchbase.com