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 <[email protected]> wrote: >> +1 for doing the move afterwards. >> >> On 1 August 2011 21:34, Randall Leeds <[email protected]> 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 >>> <[email protected]>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
