You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Paul Davis <pa...@gmail.com> on 2010/12/04 23:43:48 UTC
Source tree refactoring - TESTERS NEEDED
Heya,
I've just finished getting the refactoring of the source tree to be
more compliant with OTP source code layout. This is a pretty big move
so I'd like at least a couple other people to test this. If you have a
platform that is not OS X or Ubuntu, consider this an extra special
request so that we have confidence that I haven't broken one of the
uncommon platforms.
The repo for the scripts and patches are at [1]. You should be able to
get a fully refactored couch with:
$ git clone git://github.com/davisp/couchdb-srcmv.git
$ cd couchdb-srcmv
$ ./srcmv.py
Once you have that, there's a couchdb.git subdirectory that is a
checkout of the entire source tree. Once there, you can build and test
couchdb as per normal. Also, I would appreciate anyone that goes the
extra effort and runs the install into a tmp location and runs the
Futon tests on the installed version to make sure everything still
passes.
Ideally I'd like to get this into trunk fairly shortly so that it has
as long as possible to sit in trunk before we cut 1.2.x. Let me know
if there are any comments or complaints on it.
Paul Davis
[1] https://github.com/davisp/couchdb-srcmv
Re: Source tree refactoring - TESTERS NEEDED
Posted by Paul Davis <pa...@gmail.com>.
Awesome.
Thanks for the report.
On Thu, Dec 9, 2010 at 5:11 PM, Gabriel Farrell <gs...@gmail.com> wrote:
> Tested trunk and the updated srcmv in Firefox. Both failed the same
> test, view_sandboxing, with this error:
>
> # Assertion 'Warning: installed SpiderMonkey version
> doesn't allow sealing of arrays' failed: expected '2', got '3'
>
> Otherwise, all tests passed.
>
>
> On Wed, Dec 8, 2010 at 5:42 PM, Paul Davis <pa...@gmail.com> wrote:
>> Gabriel,
>>
>> Thanks for the report. Does that attachments test fail on trunk or with FF?
>>
>> On Wed, Dec 8, 2010 at 5:28 PM, Gabriel Farrell <gs...@gmail.com> wrote:
>>> Tested on Maverick on a netbook (sorry, Ubuntu is all I got). JSpec
>>> tests wouldn't run (Chromium 8.0.552.215). When I go to
>>> http://127.0.0.1:5984/_utils/spec/run.html I get a blank screen that
>>> displays only "JSpec 3.3.2".
>>>
>>> Futon test report at
>>> http://g.couchone.com/test_srcmv_reports/46e33f5669a825d0f93dbb115d75bed4.
>>>
>>>
>>> On Sat, Dec 4, 2010 at 5:43 PM, Paul Davis <pa...@gmail.com> wrote:
>>>> Heya,
>>>>
>>>> I've just finished getting the refactoring of the source tree to be
>>>> more compliant with OTP source code layout. This is a pretty big move
>>>> so I'd like at least a couple other people to test this. If you have a
>>>> platform that is not OS X or Ubuntu, consider this an extra special
>>>> request so that we have confidence that I haven't broken one of the
>>>> uncommon platforms.
>>>>
>>>> The repo for the scripts and patches are at [1]. You should be able to
>>>> get a fully refactored couch with:
>>>>
>>>> $ git clone git://github.com/davisp/couchdb-srcmv.git
>>>> $ cd couchdb-srcmv
>>>> $ ./srcmv.py
>>>>
>>>> Once you have that, there's a couchdb.git subdirectory that is a
>>>> checkout of the entire source tree. Once there, you can build and test
>>>> couchdb as per normal. Also, I would appreciate anyone that goes the
>>>> extra effort and runs the install into a tmp location and runs the
>>>> Futon tests on the installed version to make sure everything still
>>>> passes.
>>>>
>>>> Ideally I'd like to get this into trunk fairly shortly so that it has
>>>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
>>>> if there are any comments or complaints on it.
>>>>
>>>> Paul Davis
>>>>
>>>> [1] https://github.com/davisp/couchdb-srcmv
>>>>
>>>
>>
>
Re: Source tree refactoring - TESTERS NEEDED
Posted by Gabriel Farrell <gs...@gmail.com>.
Tested trunk and the updated srcmv in Firefox. Both failed the same
test, view_sandboxing, with this error:
# Assertion 'Warning: installed SpiderMonkey version
doesn't allow sealing of arrays' failed: expected '2', got '3'
Otherwise, all tests passed.
On Wed, Dec 8, 2010 at 5:42 PM, Paul Davis <pa...@gmail.com> wrote:
> Gabriel,
>
> Thanks for the report. Does that attachments test fail on trunk or with FF?
>
> On Wed, Dec 8, 2010 at 5:28 PM, Gabriel Farrell <gs...@gmail.com> wrote:
>> Tested on Maverick on a netbook (sorry, Ubuntu is all I got). JSpec
>> tests wouldn't run (Chromium 8.0.552.215). When I go to
>> http://127.0.0.1:5984/_utils/spec/run.html I get a blank screen that
>> displays only "JSpec 3.3.2".
>>
>> Futon test report at
>> http://g.couchone.com/test_srcmv_reports/46e33f5669a825d0f93dbb115d75bed4.
>>
>>
>> On Sat, Dec 4, 2010 at 5:43 PM, Paul Davis <pa...@gmail.com> wrote:
>>> Heya,
>>>
>>> I've just finished getting the refactoring of the source tree to be
>>> more compliant with OTP source code layout. This is a pretty big move
>>> so I'd like at least a couple other people to test this. If you have a
>>> platform that is not OS X or Ubuntu, consider this an extra special
>>> request so that we have confidence that I haven't broken one of the
>>> uncommon platforms.
>>>
>>> The repo for the scripts and patches are at [1]. You should be able to
>>> get a fully refactored couch with:
>>>
>>> $ git clone git://github.com/davisp/couchdb-srcmv.git
>>> $ cd couchdb-srcmv
>>> $ ./srcmv.py
>>>
>>> Once you have that, there's a couchdb.git subdirectory that is a
>>> checkout of the entire source tree. Once there, you can build and test
>>> couchdb as per normal. Also, I would appreciate anyone that goes the
>>> extra effort and runs the install into a tmp location and runs the
>>> Futon tests on the installed version to make sure everything still
>>> passes.
>>>
>>> Ideally I'd like to get this into trunk fairly shortly so that it has
>>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
>>> if there are any comments or complaints on it.
>>>
>>> Paul Davis
>>>
>>> [1] https://github.com/davisp/couchdb-srcmv
>>>
>>
>
Re: Source tree refactoring - TESTERS NEEDED
Posted by Paul Davis <pa...@gmail.com>.
Gabriel,
Thanks for the report. Does that attachments test fail on trunk or with FF?
On Wed, Dec 8, 2010 at 5:28 PM, Gabriel Farrell <gs...@gmail.com> wrote:
> Tested on Maverick on a netbook (sorry, Ubuntu is all I got). JSpec
> tests wouldn't run (Chromium 8.0.552.215). When I go to
> http://127.0.0.1:5984/_utils/spec/run.html I get a blank screen that
> displays only "JSpec 3.3.2".
>
> Futon test report at
> http://g.couchone.com/test_srcmv_reports/46e33f5669a825d0f93dbb115d75bed4.
>
>
> On Sat, Dec 4, 2010 at 5:43 PM, Paul Davis <pa...@gmail.com> wrote:
>> Heya,
>>
>> I've just finished getting the refactoring of the source tree to be
>> more compliant with OTP source code layout. This is a pretty big move
>> so I'd like at least a couple other people to test this. If you have a
>> platform that is not OS X or Ubuntu, consider this an extra special
>> request so that we have confidence that I haven't broken one of the
>> uncommon platforms.
>>
>> The repo for the scripts and patches are at [1]. You should be able to
>> get a fully refactored couch with:
>>
>> $ git clone git://github.com/davisp/couchdb-srcmv.git
>> $ cd couchdb-srcmv
>> $ ./srcmv.py
>>
>> Once you have that, there's a couchdb.git subdirectory that is a
>> checkout of the entire source tree. Once there, you can build and test
>> couchdb as per normal. Also, I would appreciate anyone that goes the
>> extra effort and runs the install into a tmp location and runs the
>> Futon tests on the installed version to make sure everything still
>> passes.
>>
>> Ideally I'd like to get this into trunk fairly shortly so that it has
>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
>> if there are any comments or complaints on it.
>>
>> Paul Davis
>>
>> [1] https://github.com/davisp/couchdb-srcmv
>>
>
Re: Source tree refactoring - TESTERS NEEDED
Posted by Gabriel Farrell <gs...@gmail.com>.
Tested on Maverick on a netbook (sorry, Ubuntu is all I got). JSpec
tests wouldn't run (Chromium 8.0.552.215). When I go to
http://127.0.0.1:5984/_utils/spec/run.html I get a blank screen that
displays only "JSpec 3.3.2".
Futon test report at
http://g.couchone.com/test_srcmv_reports/46e33f5669a825d0f93dbb115d75bed4.
On Sat, Dec 4, 2010 at 5:43 PM, Paul Davis <pa...@gmail.com> wrote:
> Heya,
>
> I've just finished getting the refactoring of the source tree to be
> more compliant with OTP source code layout. This is a pretty big move
> so I'd like at least a couple other people to test this. If you have a
> platform that is not OS X or Ubuntu, consider this an extra special
> request so that we have confidence that I haven't broken one of the
> uncommon platforms.
>
> The repo for the scripts and patches are at [1]. You should be able to
> get a fully refactored couch with:
>
> $ git clone git://github.com/davisp/couchdb-srcmv.git
> $ cd couchdb-srcmv
> $ ./srcmv.py
>
> Once you have that, there's a couchdb.git subdirectory that is a
> checkout of the entire source tree. Once there, you can build and test
> couchdb as per normal. Also, I would appreciate anyone that goes the
> extra effort and runs the install into a tmp location and runs the
> Futon tests on the installed version to make sure everything still
> passes.
>
> Ideally I'd like to get this into trunk fairly shortly so that it has
> as long as possible to sit in trunk before we cut 1.2.x. Let me know
> if there are any comments or complaints on it.
>
> Paul Davis
>
> [1] https://github.com/davisp/couchdb-srcmv
>
Re: Source tree refactoring - TESTERS NEEDED
Posted by Paul Davis <pa...@gmail.com>.
Sebastian,
Should be fixed now. I just needed to rebase after Adam's last patch.
Paul
On Thu, Dec 9, 2010 at 3:35 AM, Sebastian Cohnen
<se...@googlemail.com> wrote:
> Hey Paul,
>
> ./srcmv.py does throw an error at me, b/c a patch could not be applied:
>
> error: patch failed: test/etap/060-kt-merging.t:14
> error: test/etap/060-kt-merging.t: patch does not apply
> Patch failed at 0002 fix-etap-tests
> When you have resolved this problem run "git am --resolved".
> If you would prefer to skip this patch, instead run "git am --skip".
> To restore the original branch and stop patching run "git am --abort".
> Traceback (most recent call last):
> File "./srcmv.py", line 340, in <module>
> main()
> File "./srcmv.py", line 331, in main
> git_restore()
> File "./srcmv.py", line 290, in git_restore
> run("git am %s/*.patch" % PATCH_DIR)
> File "./srcmv.py", line 38, in run
> raise RuntimeError("Command failed: %s" % cmd)
> RuntimeError: Command failed: git am /Users/basti/Documents/src/sandbox/couchdb-srcmv/couchdb.patches/*.patch
>
> here is the full output: http://friendpaste.com/73PhLSNcRH64dQVDg7B9fr
>
>
> On 04.12.2010, at 23:43, Paul Davis wrote:
>
>> Heya,
>>
>> I've just finished getting the refactoring of the source tree to be
>> more compliant with OTP source code layout. This is a pretty big move
>> so I'd like at least a couple other people to test this. If you have a
>> platform that is not OS X or Ubuntu, consider this an extra special
>> request so that we have confidence that I haven't broken one of the
>> uncommon platforms.
>>
>> The repo for the scripts and patches are at [1]. You should be able to
>> get a fully refactored couch with:
>>
>> $ git clone git://github.com/davisp/couchdb-srcmv.git
>> $ cd couchdb-srcmv
>> $ ./srcmv.py
>>
>> Once you have that, there's a couchdb.git subdirectory that is a
>> checkout of the entire source tree. Once there, you can build and test
>> couchdb as per normal. Also, I would appreciate anyone that goes the
>> extra effort and runs the install into a tmp location and runs the
>> Futon tests on the installed version to make sure everything still
>> passes.
>>
>> Ideally I'd like to get this into trunk fairly shortly so that it has
>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
>> if there are any comments or complaints on it.
>>
>> Paul Davis
>>
>> [1] https://github.com/davisp/couchdb-srcmv
>
>
Re: Source tree refactoring - TESTERS NEEDED
Posted by Sebastian Cohnen <se...@googlemail.com>.
Hey Paul,
./srcmv.py does throw an error at me, b/c a patch could not be applied:
error: patch failed: test/etap/060-kt-merging.t:14
error: test/etap/060-kt-merging.t: patch does not apply
Patch failed at 0002 fix-etap-tests
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
Traceback (most recent call last):
File "./srcmv.py", line 340, in <module>
main()
File "./srcmv.py", line 331, in main
git_restore()
File "./srcmv.py", line 290, in git_restore
run("git am %s/*.patch" % PATCH_DIR)
File "./srcmv.py", line 38, in run
raise RuntimeError("Command failed: %s" % cmd)
RuntimeError: Command failed: git am /Users/basti/Documents/src/sandbox/couchdb-srcmv/couchdb.patches/*.patch
here is the full output: http://friendpaste.com/73PhLSNcRH64dQVDg7B9fr
On 04.12.2010, at 23:43, Paul Davis wrote:
> Heya,
>
> I've just finished getting the refactoring of the source tree to be
> more compliant with OTP source code layout. This is a pretty big move
> so I'd like at least a couple other people to test this. If you have a
> platform that is not OS X or Ubuntu, consider this an extra special
> request so that we have confidence that I haven't broken one of the
> uncommon platforms.
>
> The repo for the scripts and patches are at [1]. You should be able to
> get a fully refactored couch with:
>
> $ git clone git://github.com/davisp/couchdb-srcmv.git
> $ cd couchdb-srcmv
> $ ./srcmv.py
>
> Once you have that, there's a couchdb.git subdirectory that is a
> checkout of the entire source tree. Once there, you can build and test
> couchdb as per normal. Also, I would appreciate anyone that goes the
> extra effort and runs the install into a tmp location and runs the
> Futon tests on the installed version to make sure everything still
> passes.
>
> Ideally I'd like to get this into trunk fairly shortly so that it has
> as long as possible to sit in trunk before we cut 1.2.x. Let me know
> if there are any comments or complaints on it.
>
> Paul Davis
>
> [1] https://github.com/davisp/couchdb-srcmv
Re: Source tree refactoring - TESTERS NEEDED
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, Dec 4, 2010 at 11:43 PM, Paul Davis <pa...@gmail.com> wrote:
> Heya,
>
> I've just finished getting the refactoring of the source tree to be
> more compliant with OTP source code layout. This is a pretty big move
> so I'd like at least a couple other people to test this. If you have a
> platform that is not OS X or Ubuntu, consider this an extra special
> request so that we have confidence that I haven't broken one of the
> uncommon platforms.
>
> The repo for the scripts and patches are at [1]. You should be able to
> get a fully refactored couch with:
>
> $ git clone git://github.com/davisp/couchdb-srcmv.git
> $ cd couchdb-srcmv
> $ ./srcmv.py
>
> Once you have that, there's a couchdb.git subdirectory that is a
> checkout of the entire source tree. Once there, you can build and test
> couchdb as per normal. Also, I would appreciate anyone that goes the
> extra effort and runs the install into a tmp location and runs the
> Futon tests on the installed version to make sure everything still
> passes.
>
> Ideally I'd like to get this into trunk fairly shortly so that it has
> as long as possible to sit in trunk before we cut 1.2.x. Let me know
> if there are any comments or complaints on it.
>
> Paul Davis
>
> [1] https://github.com/davisp/couchdb-srcmv
>
+1
tested on osx, open & fbsd. Works.
- benoît
Re: Source tree refactoring - TESTERS NEEDED
Posted by Jan Lehnardt <ja...@apache.org>.
Dear Mr. Paul, I award you 100 internets for brave heroism. Best, Jan.
On 4 Dec 2010, at 23:43, Paul Davis wrote:
> Heya,
>
> I've just finished getting the refactoring of the source tree to be
> more compliant with OTP source code layout. This is a pretty big move
> so I'd like at least a couple other people to test this. If you have a
> platform that is not OS X or Ubuntu, consider this an extra special
> request so that we have confidence that I haven't broken one of the
> uncommon platforms.
>
> The repo for the scripts and patches are at [1]. You should be able to
> get a fully refactored couch with:
>
> $ git clone git://github.com/davisp/couchdb-srcmv.git
> $ cd couchdb-srcmv
> $ ./srcmv.py
>
> Once you have that, there's a couchdb.git subdirectory that is a
> checkout of the entire source tree. Once there, you can build and test
> couchdb as per normal. Also, I would appreciate anyone that goes the
> extra effort and runs the install into a tmp location and runs the
> Futon tests on the installed version to make sure everything still
> passes.
>
> Ideally I'd like to get this into trunk fairly shortly so that it has
> as long as possible to sit in trunk before we cut 1.2.x. Let me know
> if there are any comments or complaints on it.
>
> Paul Davis
>
> [1] https://github.com/davisp/couchdb-srcmv
Re: Source tree refactoring - TESTERS NEEDED
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Dec 27, 2010 at 5:35 PM, Paul Davis <pa...@gmail.com> wrote:
> On Mon, Dec 27, 2010 at 7:23 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Mon, Dec 27, 2010 at 1:31 AM, Paul Davis <pa...@gmail.com> wrote:
>>> On Sun, Dec 26, 2010 at 7:23 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>> On Mon, Dec 27, 2010 at 12:53 AM, Paul Davis
>>>> <pa...@gmail.com> wrote:
>>>>
>>>>>
>>>>> Its not being done in trunk. The change is being prepared as a script
>>>>> and set of patches that people can test independently which people
>>>>> have been doing.
>>>>>
>>>> Not what I say. Was about testing it first in it's own branch. But
>>>> right patches are enough. Just actually i'm not sure how i can edit
>>>> one or go further ? Another patch ? What's your process to make such
>>>> patches at first ? stashes ?
>>>>
>>>
>>> I use the generated git repo to formulate all of the various patches.
>>> There are git-save and git-restore commands for the srcmv.py script
>>> that work as expected by saving patches to the couchdb.patches
>>> directory.
>>>
>> Will try to work with that then.
>>
>>> This is a scenario that is so distant I'm not going to spend time
>>> thinking about it right now. The current work would in no way allow
>>> for someone to do such things and it will be many many months before
>>> we have things to a point before we can entertain such notions.
>>>
>>
>> It could be months or days. Depends on the the time each others can
>> put in it, *if the process allows it*. This is imo a big priority, we
>> already see a lot of "bricolage" (makeshift?) coming in the code.
>>
>> The goal I wished in the thread I launched was to use rebar and mix it
>> with configure (based on bigcouch work and patches like these one). I
>> don't see how the question is so distant seeing the result of these
>> patches. Neither I see why we shouldn't target this right now. Anyway,
>> maybe we can open a ticket and track progress in it ?
>
> I'm so confused. What process are you talking about? What breakage (I
> assume that's what you mean) do you see coming?
I'm speaking about a way to work with such changes. Patches are good,
but in the mean time vcs are here for a reason. A quick way to
test/merge etc. I'm just looking for a way to work with the patch
between different person. Trying to find a way to make the process
easy.
>
> You're describing two entirely different, completely unrelated use
> cases for rebar. One, which was part of the motivation for this patch
> set, was to integrate it into the build system. This is perfectly
> acceptable. It is why this patch set exists; to make using rebar to
> build CouchDB *possible*. After this very large patch set is committed
> then we can start working on supporting rebar.
>
Well I don't describe unrelated use, just describing what I wished,
and started thread, that wasn't closed nor really discussed. Now I
understand that the patches won't go as far as I would like.
> The situation you described earlier is a bajillion percent different.
> Perhaps in a distant future we will support using only various parts
> of CouchDB but this is a scenario so far distant that I am not going
> to spend any time considering it.
>
I understand that.
Re: Source tree refactoring - TESTERS NEEDED
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Dec 27, 2010 at 7:23 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Mon, Dec 27, 2010 at 1:31 AM, Paul Davis <pa...@gmail.com> wrote:
>> On Sun, Dec 26, 2010 at 7:23 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>> On Mon, Dec 27, 2010 at 12:53 AM, Paul Davis
>>> <pa...@gmail.com> wrote:
>>>
>>>>
>>>> Its not being done in trunk. The change is being prepared as a script
>>>> and set of patches that people can test independently which people
>>>> have been doing.
>>>>
>>> Not what I say. Was about testing it first in it's own branch. But
>>> right patches are enough. Just actually i'm not sure how i can edit
>>> one or go further ? Another patch ? What's your process to make such
>>> patches at first ? stashes ?
>>>
>>
>> I use the generated git repo to formulate all of the various patches.
>> There are git-save and git-restore commands for the srcmv.py script
>> that work as expected by saving patches to the couchdb.patches
>> directory.
>>
> Will try to work with that then.
>
>> This is a scenario that is so distant I'm not going to spend time
>> thinking about it right now. The current work would in no way allow
>> for someone to do such things and it will be many many months before
>> we have things to a point before we can entertain such notions.
>>
>
> It could be months or days. Depends on the the time each others can
> put in it, *if the process allows it*. This is imo a big priority, we
> already see a lot of "bricolage" (makeshift?) coming in the code.
>
> The goal I wished in the thread I launched was to use rebar and mix it
> with configure (based on bigcouch work and patches like these one). I
> don't see how the question is so distant seeing the result of these
> patches. Neither I see why we shouldn't target this right now. Anyway,
> maybe we can open a ticket and track progress in it ?
I'm so confused. What process are you talking about? What breakage (I
assume that's what you mean) do you see coming?
You're describing two entirely different, completely unrelated use
cases for rebar. One, which was part of the motivation for this patch
set, was to integrate it into the build system. This is perfectly
acceptable. It is why this patch set exists; to make using rebar to
build CouchDB *possible*. After this very large patch set is committed
then we can start working on supporting rebar.
The situation you described earlier is a bajillion percent different.
Perhaps in a distant future we will support using only various parts
of CouchDB but this is a scenario so far distant that I am not going
to spend any time considering it.
Re: Source tree refactoring - TESTERS NEEDED
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Dec 27, 2010 at 1:31 AM, Paul Davis <pa...@gmail.com> wrote:
> On Sun, Dec 26, 2010 at 7:23 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Mon, Dec 27, 2010 at 12:53 AM, Paul Davis
>> <pa...@gmail.com> wrote:
>>
>>>
>>> Its not being done in trunk. The change is being prepared as a script
>>> and set of patches that people can test independently which people
>>> have been doing.
>>>
>> Not what I say. Was about testing it first in it's own branch. But
>> right patches are enough. Just actually i'm not sure how i can edit
>> one or go further ? Another patch ? What's your process to make such
>> patches at first ? stashes ?
>>
>
> I use the generated git repo to formulate all of the various patches.
> There are git-save and git-restore commands for the srcmv.py script
> that work as expected by saving patches to the couchdb.patches
> directory.
>
Will try to work with that then.
> This is a scenario that is so distant I'm not going to spend time
> thinking about it right now. The current work would in no way allow
> for someone to do such things and it will be many many months before
> we have things to a point before we can entertain such notions.
>
It could be months or days. Depends on the the time each others can
put in it, *if the process allows it*. This is imo a big priority, we
already see a lot of "bricolage" (makeshift?) coming in the code.
The goal I wished in the thread I launched was to use rebar and mix it
with configure (based on bigcouch work and patches like these one). I
don't see how the question is so distant seeing the result of these
patches. Neither I see why we shouldn't target this right now. Anyway,
maybe we can open a ticket and track progress in it ?
- benoît
Re: Source tree refactoring - TESTERS NEEDED
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Dec 26, 2010 at 7:23 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Mon, Dec 27, 2010 at 12:53 AM, Paul Davis
> <pa...@gmail.com> wrote:
>
>>
>> Its not being done in trunk. The change is being prepared as a script
>> and set of patches that people can test independently which people
>> have been doing.
>>
> Not what I say. Was about testing it first in it's own branch. But
> right patches are enough. Just actually i'm not sure how i can edit
> one or go further ? Another patch ? What's your process to make such
> patches at first ? stashes ?
>
I use the generated git repo to formulate all of the various patches.
There are git-save and git-restore commands for the srcmv.py script
that work as expected by saving patches to the couchdb.patches
directory.
>
>> I reckon it'll be handled exactly the same as any of the Java projects
>> that contain multiple packages, as in, absolutely nothing changes.
>>
>
> mmm, but if we use rebar, how can we tell him to go for x packages. If
> we consider, each package could be replaced separatly on custom
> distributions ?
>
This is a scenario that is so distant I'm not going to spend time
thinking about it right now. The current work would in no way allow
for someone to do such things and it will be many many months before
we have things to a point before we can entertain such notions.
Re: Source tree refactoring - TESTERS NEEDED
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Dec 27, 2010 at 12:53 AM, Paul Davis
<pa...@gmail.com> wrote:
>
> Its not being done in trunk. The change is being prepared as a script
> and set of patches that people can test independently which people
> have been doing.
>
Not what I say. Was about testing it first in it's own branch. But
right patches are enough. Just actually i'm not sure how i can edit
one or go further ? Another patch ? What's your process to make such
patches at first ? stashes ?
> I reckon it'll be handled exactly the same as any of the Java projects
> that contain multiple packages, as in, absolutely nothing changes.
>
mmm, but if we use rebar, how can we tell him to go for x packages. If
we consider, each package could be replaced separatly on custom
distributions ?
- benoît
Re: Source tree refactoring - TESTERS NEEDED
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Dec 26, 2010 at 6:32 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Mon, Dec 27, 2010 at 12:01 AM, Paul Davis
> <pa...@gmail.com> wrote:
>> On Sun, Dec 26, 2010 at 5:46 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>> On Sun, Dec 26, 2010 at 5:30 PM, Paul Davis <pa...@gmail.com> wrote:
>>>> On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>> On Saturday, December 4, 2010, Paul Davis <pa...@gmail.com> wrote:
>>>>>> Heya,
>>>>>>
>>>>>> I've just finished getting the refactoring of the source tree to be
>>>>>> more compliant with OTP source code layout. This is a pretty big move
>>>>>> so I'd like at least a couple other people to test this. If you have a
>>>>>> platform that is not OS X or Ubuntu, consider this an extra special
>>>>>> request so that we have confidence that I haven't broken one of the
>>>>>> uncommon platforms.
>>>>>>
>>>>>> The repo for the scripts and patches are at [1]. You should be able to
>>>>>> get a fully refactored couch with:
>>>>>>
>>>>>> $ git clone git://github.com/davisp/couchdb-srcmv.git
>>>>>> $ cd couchdb-srcmv
>>>>>> $ ./srcmv.py
>>>>>>
>>>>>> Once you have that, there's a couchdb.git subdirectory that is a
>>>>>> checkout of the entire source tree. Once there, you can build and test
>>>>>> couchdb as per normal. Also, I would appreciate anyone that goes the
>>>>>> extra effort and runs the install into a tmp location and runs the
>>>>>> Futon tests on the installed version to make sure everything still
>>>>>> passes.
>>>>>>
>>>>>> Ideally I'd like to get this into trunk fairly shortly so that it has
>>>>>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
>>>>>> if there are any comments or complaints on it.
>>>>>>
>>>>>> Paul Davis
>>>>>>
>>>>>> [1] https://github.com/davisp/couchdb-srcmv
>>>>>>
>>>>>
>>>>> After thinking about it, I don't see the point of having a script to
>>>>> maintain patches, + patches coming with. It make review hard compared
>>>>> to having a branch dedicated to this refactoring. Also it stops
>>>>> somehow any external work of yours hard (eg. can't go further without
>>>>> waiting your updates). Can't we just open a branch on svn and start to
>>>>> work on it. Which would also allow us to wait for fdmanana merge of
>>>>> new replicator
>>>>>
>>>>
>>>> You are free to attempt that. I on the other hand want no part of
>>>> having to deal with rebasing that set of patches using SVN's merge. On
>>>> the other hand, if we did this as a git repository we'd lose the
>>>> history for the entire source tree which would be even worse.
>>>>
>>>>> Related notes from my experiences and reads of the night:
>>>>>
>>>>> There are other needed changes imo:
>>>>>
>>>>> - removing call go http layer in core ( for example in attachments),
>>>>
>>>> These patches don't fix everything. I very explicitly wanted to
>>>> minimize the scope of these patches to solely moving files around and
>>>> then fixing anything that broke. After these land in trunk there's
>>>> still going to be a lot of work left on fixing other aspects of the
>>>> code.
>>>>
>>>>> - having a CouchDB app that reconciliate. core (b-tree, changes, db
>>>>> api) and other members. Such things.
>>>>>
>>>>
>>>> I'm not sure what you mean by reconciling the various apps. As I
>>>> mention above, there's a lot to do. By no means am I suggesting this
>>>> patch is comprehensive. Just enough to get over the large hurdle of
>>>> refactoring the pathnames for files in the source tree.
>>>>
>>>>> I would be happy to work and the work in srcmv is already 70-80% of
>>>>> what we ant. So is there any possibility to have a branch?
>>>>>
>>>>
>>>> I am very scared of SVN's merging. There are nightmares involved. I
>>>> can barely manage to backport patches from trunk. I'm so anti-SVN I'm
>>>> working with infra to try and start us using Git. SVN is the devil.
>>>>
>>>> That said, if you think you'd be all right handling such a large
>>>> branch and the merge back to trunk after the replicator lands then by
>>>> all means feel free to start one. I just chose not to.
>>>>
>>>> HTH,
>>>> Paul Davis
>>>>
>>>
>>> Well at one point we should merge, whatever is the solution. Do we
>>> really want final tests are done in trunk ?
>>>
>>
>> How do you mean final tests?
>>
>
> For such a big changes, I can't imagine we do it directly in trunk. In
> my opinion it should live in a branch while we improve it?
>
> Also related question, if we split couch into modules, how is it
> handle as an apache project?
>
> - benoît
>
Its not being done in trunk. The change is being prepared as a script
and set of patches that people can test independently which people
have been doing.
I'll reiterate my point once again that there's no way that *I* am
going to do this in an SVN branch. I just don't know SVN well enough,
and worse, my limited knowledge instills a huge amount of fear at
attempting such a feat. If there's someone that's more knowledgeable
with SVN than me that wants to drive this project, I would happily
turn it over to them.
I reckon it'll be handled exactly the same as any of the Java projects
that contain multiple packages, as in, absolutely nothing changes.
Re: Source tree refactoring - TESTERS NEEDED
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Dec 27, 2010 at 12:01 AM, Paul Davis
<pa...@gmail.com> wrote:
> On Sun, Dec 26, 2010 at 5:46 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Sun, Dec 26, 2010 at 5:30 PM, Paul Davis <pa...@gmail.com> wrote:
>>> On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>> On Saturday, December 4, 2010, Paul Davis <pa...@gmail.com> wrote:
>>>>> Heya,
>>>>>
>>>>> I've just finished getting the refactoring of the source tree to be
>>>>> more compliant with OTP source code layout. This is a pretty big move
>>>>> so I'd like at least a couple other people to test this. If you have a
>>>>> platform that is not OS X or Ubuntu, consider this an extra special
>>>>> request so that we have confidence that I haven't broken one of the
>>>>> uncommon platforms.
>>>>>
>>>>> The repo for the scripts and patches are at [1]. You should be able to
>>>>> get a fully refactored couch with:
>>>>>
>>>>> $ git clone git://github.com/davisp/couchdb-srcmv.git
>>>>> $ cd couchdb-srcmv
>>>>> $ ./srcmv.py
>>>>>
>>>>> Once you have that, there's a couchdb.git subdirectory that is a
>>>>> checkout of the entire source tree. Once there, you can build and test
>>>>> couchdb as per normal. Also, I would appreciate anyone that goes the
>>>>> extra effort and runs the install into a tmp location and runs the
>>>>> Futon tests on the installed version to make sure everything still
>>>>> passes.
>>>>>
>>>>> Ideally I'd like to get this into trunk fairly shortly so that it has
>>>>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
>>>>> if there are any comments or complaints on it.
>>>>>
>>>>> Paul Davis
>>>>>
>>>>> [1] https://github.com/davisp/couchdb-srcmv
>>>>>
>>>>
>>>> After thinking about it, I don't see the point of having a script to
>>>> maintain patches, + patches coming with. It make review hard compared
>>>> to having a branch dedicated to this refactoring. Also it stops
>>>> somehow any external work of yours hard (eg. can't go further without
>>>> waiting your updates). Can't we just open a branch on svn and start to
>>>> work on it. Which would also allow us to wait for fdmanana merge of
>>>> new replicator
>>>>
>>>
>>> You are free to attempt that. I on the other hand want no part of
>>> having to deal with rebasing that set of patches using SVN's merge. On
>>> the other hand, if we did this as a git repository we'd lose the
>>> history for the entire source tree which would be even worse.
>>>
>>>> Related notes from my experiences and reads of the night:
>>>>
>>>> There are other needed changes imo:
>>>>
>>>> - removing call go http layer in core ( for example in attachments),
>>>
>>> These patches don't fix everything. I very explicitly wanted to
>>> minimize the scope of these patches to solely moving files around and
>>> then fixing anything that broke. After these land in trunk there's
>>> still going to be a lot of work left on fixing other aspects of the
>>> code.
>>>
>>>> - having a CouchDB app that reconciliate. core (b-tree, changes, db
>>>> api) and other members. Such things.
>>>>
>>>
>>> I'm not sure what you mean by reconciling the various apps. As I
>>> mention above, there's a lot to do. By no means am I suggesting this
>>> patch is comprehensive. Just enough to get over the large hurdle of
>>> refactoring the pathnames for files in the source tree.
>>>
>>>> I would be happy to work and the work in srcmv is already 70-80% of
>>>> what we ant. So is there any possibility to have a branch?
>>>>
>>>
>>> I am very scared of SVN's merging. There are nightmares involved. I
>>> can barely manage to backport patches from trunk. I'm so anti-SVN I'm
>>> working with infra to try and start us using Git. SVN is the devil.
>>>
>>> That said, if you think you'd be all right handling such a large
>>> branch and the merge back to trunk after the replicator lands then by
>>> all means feel free to start one. I just chose not to.
>>>
>>> HTH,
>>> Paul Davis
>>>
>>
>> Well at one point we should merge, whatever is the solution. Do we
>> really want final tests are done in trunk ?
>>
>
> How do you mean final tests?
>
For such a big changes, I can't imagine we do it directly in trunk. In
my opinion it should live in a branch while we improve it?
Also related question, if we split couch into modules, how is it
handle as an apache project?
- benoît
Re: Source tree refactoring - TESTERS NEEDED
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Dec 27, 2010 at 12:53 AM, Paul Davis
<pa...@gmail.com> wrote:
> The code to prepare these changes can be found here:
>
> https://github.com/davisp/couchdb-srcmv
>
Was expecting a full git repo ;) but will play with the one generated.
- benoît
Re: Source tree refactoring - TESTERS NEEDED
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Dec 26, 2010 at 6:39 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Mon, Dec 27, 2010 at 12:13 AM, Paul Davis
> <pa...@gmail.com> wrote:
>> On Sun, Dec 26, 2010 at 6:09 PM, Randall Leeds <ra...@gmail.com> wrote:
>>> On Dec 26, 2010 6:02 PM, "Paul Davis" <pa...@gmail.com> wrote:
>>>>
>>>> On Sun, Dec 26, 2010 at 5:46 PM, Benoit Chesneau <bc...@gmail.com>
>>> wrote:
>>>> > On Sun, Dec 26, 2010 at 5:30 PM, Paul Davis <pa...@gmail.com>
>>> wrote:
>>>> >> On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <bc...@gmail.com>
>>> wrote:
>>>> >>> On Saturday, December 4, 2010, Paul Davis <pa...@gmail.com>
>>> wrote:
>>>> >>>> Heya,
>>>> >>>>
>>>> >>>> I've just finished getting the refactoring of the source tree to be
>>>> >>>> more compliant with OTP source code layout. This is a pretty big move
>>>> >>>> so I'd like at least a couple other people to test this. If you have
>>> a
>>>> >>>> platform that is not OS X or Ubuntu, consider this an extra special
>>>> >>>> request so that we have confidence that I haven't broken one of the
>>>> >>>> uncommon platforms.
>>>> >>>>
>>>> >>>> The repo for the scripts and patches are at [1]. You should be able
>>> to
>>>> >>>> get a fully refactored couch with:
>>>> >>>>
>>>> >>>> $ git clone git://github.com/davisp/couchdb-srcmv.git
>>>> >>>> $ cd couchdb-srcmv
>>>> >>>> $ ./srcmv.py
>>>> >>>>
>>>> >>>> Once you have that, there's a couchdb.git subdirectory that is a
>>>> >>>> checkout of the entire source tree. Once there, you can build and
>>> test
>>>> >>>> couchdb as per normal. Also, I would appreciate anyone that goes the
>>>> >>>> extra effort and runs the install into a tmp location and runs the
>>>> >>>> Futon tests on the installed version to make sure everything still
>>>> >>>> passes.
>>>> >>>>
>>>> >>>> Ideally I'd like to get this into trunk fairly shortly so that it has
>>>> >>>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
>>>> >>>> if there are any comments or complaints on it.
>>>> >>>>
>>>> >>>> Paul Davis
>>>> >>>>
>>>> >>>> [1] https://github.com/davisp/couchdb-srcmv
>>>> >>>>
>>>> >>>
>>>> >>> After thinking about it, I don't see the point of having a script to
>>>> >>> maintain patches, + patches coming with. It make review hard compared
>>>> >>> to having a branch dedicated to this refactoring. Also it stops
>>>> >>> somehow any external work of yours hard (eg. can't go further without
>>>> >>> waiting your updates). Can't we just open a branch on svn and start to
>>>> >>> work on it. Which would also allow us to wait for fdmanana merge of
>>>> >>> new replicator
>>>> >>>
>>>> >>
>>>> >> You are free to attempt that. I on the other hand want no part of
>>>> >> having to deal with rebasing that set of patches using SVN's merge. On
>>>> >> the other hand, if we did this as a git repository we'd lose the
>>>> >> history for the entire source tree which would be even worse.
>>>> >>
>>>> >>> Related notes from my experiences and reads of the night:
>>>> >>>
>>>> >>> There are other needed changes imo:
>>>> >>>
>>>> >>> - removing call go http layer in core ( for example in attachments),
>>>> >>
>>>> >> These patches don't fix everything. I very explicitly wanted to
>>>> >> minimize the scope of these patches to solely moving files around and
>>>> >> then fixing anything that broke. After these land in trunk there's
>>>> >> still going to be a lot of work left on fixing other aspects of the
>>>> >> code.
>>>> >>
>>>> >>> - having a CouchDB app that reconciliate. core (b-tree, changes, db
>>>> >>> api) and other members. Such things.
>>>> >>>
>>>> >>
>>>> >> I'm not sure what you mean by reconciling the various apps. As I
>>>> >> mention above, there's a lot to do. By no means am I suggesting this
>>>> >> patch is comprehensive. Just enough to get over the large hurdle of
>>>> >> refactoring the pathnames for files in the source tree.
>>>> >>
>>>> >>> I would be happy to work and the work in srcmv is already 70-80% of
>>>> >>> what we ant. So is there any possibility to have a branch?
>>>> >>>
>>>> >>
>>>> >> I am very scared of SVN's merging. There are nightmares involved. I
>>>> >> can barely manage to backport patches from trunk. I'm so anti-SVN I'm
>>>> >> working with infra to try and start us using Git. SVN is the devil.
>>>> >>
>>>> >> That said, if you think you'd be all right handling such a large
>>>> >> branch and the merge back to trunk after the replicator lands then by
>>>> >> all means feel free to start one. I just chose not to.
>>>> >>
>>>> >> HTH,
>>>> >> Paul Davis
>>>> >>
>>>> >
>>>> > Well at one point we should merge, whatever is the solution. Do we
>>>> > really want final tests are done in trunk ?
>>>> >
>>>>
>>>> How do you mean final tests?
>>>>
>>>> > I think there are way to merge from git to svn too. My point is that
>>>> > right now, we can't work on a branch , just test. And the more code
>>>> > will be added to the trunk the more it become difficult to merge too.
>>>> >
>>>>
>>>> I have no idea how git-svn would handle pushing such a large move up
>>>> to SVN. Perhaps it'd work magically but I didn't feel like setting up
>>>> the infrastructure to go through and test it to make sure that we're
>>>> not dropping our entire repository history.
>>>>
>>>> As to rebasing this patch set, its fairly trivial if a bit boring.
>>>>
>>>
>>> If you can rebase it so it's linear from the end of trunk you can push it up
>>> with git-svn no problem. You do the rebasing locally and then just `git svn
>>> dcommit`. Am I missing something?
>>>
>>
>> The question is about how git-svn would handle a rename. If its a
>> rm+add then its a non-starter. But this is exactly what I didn't want
>> to configure to study the details. When does a git rename get
>> translated to an svn rename, and what are the rules there.
>>
>>>> > - benoît
>>>> >
>>>
>>
>
> didn't test but apparently there is the option -rmdir that you can
> pass to dcommit with git-svn
>
> so using git mv ... then git dcommit -rmdir .. may works. Need to
> test. Can you make available your changes on github? I will try with a
> svnsync then git later this morning.
>
> - benoît
>
The code to prepare these changes can be found here:
https://github.com/davisp/couchdb-srcmv
Re: Source tree refactoring - TESTERS NEEDED
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Dec 27, 2010 at 12:13 AM, Paul Davis
<pa...@gmail.com> wrote:
> On Sun, Dec 26, 2010 at 6:09 PM, Randall Leeds <ra...@gmail.com> wrote:
>> On Dec 26, 2010 6:02 PM, "Paul Davis" <pa...@gmail.com> wrote:
>>>
>>> On Sun, Dec 26, 2010 at 5:46 PM, Benoit Chesneau <bc...@gmail.com>
>> wrote:
>>> > On Sun, Dec 26, 2010 at 5:30 PM, Paul Davis <pa...@gmail.com>
>> wrote:
>>> >> On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <bc...@gmail.com>
>> wrote:
>>> >>> On Saturday, December 4, 2010, Paul Davis <pa...@gmail.com>
>> wrote:
>>> >>>> Heya,
>>> >>>>
>>> >>>> I've just finished getting the refactoring of the source tree to be
>>> >>>> more compliant with OTP source code layout. This is a pretty big move
>>> >>>> so I'd like at least a couple other people to test this. If you have
>> a
>>> >>>> platform that is not OS X or Ubuntu, consider this an extra special
>>> >>>> request so that we have confidence that I haven't broken one of the
>>> >>>> uncommon platforms.
>>> >>>>
>>> >>>> The repo for the scripts and patches are at [1]. You should be able
>> to
>>> >>>> get a fully refactored couch with:
>>> >>>>
>>> >>>> $ git clone git://github.com/davisp/couchdb-srcmv.git
>>> >>>> $ cd couchdb-srcmv
>>> >>>> $ ./srcmv.py
>>> >>>>
>>> >>>> Once you have that, there's a couchdb.git subdirectory that is a
>>> >>>> checkout of the entire source tree. Once there, you can build and
>> test
>>> >>>> couchdb as per normal. Also, I would appreciate anyone that goes the
>>> >>>> extra effort and runs the install into a tmp location and runs the
>>> >>>> Futon tests on the installed version to make sure everything still
>>> >>>> passes.
>>> >>>>
>>> >>>> Ideally I'd like to get this into trunk fairly shortly so that it has
>>> >>>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
>>> >>>> if there are any comments or complaints on it.
>>> >>>>
>>> >>>> Paul Davis
>>> >>>>
>>> >>>> [1] https://github.com/davisp/couchdb-srcmv
>>> >>>>
>>> >>>
>>> >>> After thinking about it, I don't see the point of having a script to
>>> >>> maintain patches, + patches coming with. It make review hard compared
>>> >>> to having a branch dedicated to this refactoring. Also it stops
>>> >>> somehow any external work of yours hard (eg. can't go further without
>>> >>> waiting your updates). Can't we just open a branch on svn and start to
>>> >>> work on it. Which would also allow us to wait for fdmanana merge of
>>> >>> new replicator
>>> >>>
>>> >>
>>> >> You are free to attempt that. I on the other hand want no part of
>>> >> having to deal with rebasing that set of patches using SVN's merge. On
>>> >> the other hand, if we did this as a git repository we'd lose the
>>> >> history for the entire source tree which would be even worse.
>>> >>
>>> >>> Related notes from my experiences and reads of the night:
>>> >>>
>>> >>> There are other needed changes imo:
>>> >>>
>>> >>> - removing call go http layer in core ( for example in attachments),
>>> >>
>>> >> These patches don't fix everything. I very explicitly wanted to
>>> >> minimize the scope of these patches to solely moving files around and
>>> >> then fixing anything that broke. After these land in trunk there's
>>> >> still going to be a lot of work left on fixing other aspects of the
>>> >> code.
>>> >>
>>> >>> - having a CouchDB app that reconciliate. core (b-tree, changes, db
>>> >>> api) and other members. Such things.
>>> >>>
>>> >>
>>> >> I'm not sure what you mean by reconciling the various apps. As I
>>> >> mention above, there's a lot to do. By no means am I suggesting this
>>> >> patch is comprehensive. Just enough to get over the large hurdle of
>>> >> refactoring the pathnames for files in the source tree.
>>> >>
>>> >>> I would be happy to work and the work in srcmv is already 70-80% of
>>> >>> what we ant. So is there any possibility to have a branch?
>>> >>>
>>> >>
>>> >> I am very scared of SVN's merging. There are nightmares involved. I
>>> >> can barely manage to backport patches from trunk. I'm so anti-SVN I'm
>>> >> working with infra to try and start us using Git. SVN is the devil.
>>> >>
>>> >> That said, if you think you'd be all right handling such a large
>>> >> branch and the merge back to trunk after the replicator lands then by
>>> >> all means feel free to start one. I just chose not to.
>>> >>
>>> >> HTH,
>>> >> Paul Davis
>>> >>
>>> >
>>> > Well at one point we should merge, whatever is the solution. Do we
>>> > really want final tests are done in trunk ?
>>> >
>>>
>>> How do you mean final tests?
>>>
>>> > I think there are way to merge from git to svn too. My point is that
>>> > right now, we can't work on a branch , just test. And the more code
>>> > will be added to the trunk the more it become difficult to merge too.
>>> >
>>>
>>> I have no idea how git-svn would handle pushing such a large move up
>>> to SVN. Perhaps it'd work magically but I didn't feel like setting up
>>> the infrastructure to go through and test it to make sure that we're
>>> not dropping our entire repository history.
>>>
>>> As to rebasing this patch set, its fairly trivial if a bit boring.
>>>
>>
>> If you can rebase it so it's linear from the end of trunk you can push it up
>> with git-svn no problem. You do the rebasing locally and then just `git svn
>> dcommit`. Am I missing something?
>>
>
> The question is about how git-svn would handle a rename. If its a
> rm+add then its a non-starter. But this is exactly what I didn't want
> to configure to study the details. When does a git rename get
> translated to an svn rename, and what are the rules there.
>
>>> > - benoît
>>> >
>>
>
didn't test but apparently there is the option -rmdir that you can
pass to dcommit with git-svn
so using git mv ... then git dcommit -rmdir .. may works. Need to
test. Can you make available your changes on github? I will try with a
svnsync then git later this morning.
- benoît
Re: Source tree refactoring - TESTERS NEEDED
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Dec 26, 2010 at 6:09 PM, Randall Leeds <ra...@gmail.com> wrote:
> On Dec 26, 2010 6:02 PM, "Paul Davis" <pa...@gmail.com> wrote:
>>
>> On Sun, Dec 26, 2010 at 5:46 PM, Benoit Chesneau <bc...@gmail.com>
> wrote:
>> > On Sun, Dec 26, 2010 at 5:30 PM, Paul Davis <pa...@gmail.com>
> wrote:
>> >> On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <bc...@gmail.com>
> wrote:
>> >>> On Saturday, December 4, 2010, Paul Davis <pa...@gmail.com>
> wrote:
>> >>>> Heya,
>> >>>>
>> >>>> I've just finished getting the refactoring of the source tree to be
>> >>>> more compliant with OTP source code layout. This is a pretty big move
>> >>>> so I'd like at least a couple other people to test this. If you have
> a
>> >>>> platform that is not OS X or Ubuntu, consider this an extra special
>> >>>> request so that we have confidence that I haven't broken one of the
>> >>>> uncommon platforms.
>> >>>>
>> >>>> The repo for the scripts and patches are at [1]. You should be able
> to
>> >>>> get a fully refactored couch with:
>> >>>>
>> >>>> $ git clone git://github.com/davisp/couchdb-srcmv.git
>> >>>> $ cd couchdb-srcmv
>> >>>> $ ./srcmv.py
>> >>>>
>> >>>> Once you have that, there's a couchdb.git subdirectory that is a
>> >>>> checkout of the entire source tree. Once there, you can build and
> test
>> >>>> couchdb as per normal. Also, I would appreciate anyone that goes the
>> >>>> extra effort and runs the install into a tmp location and runs the
>> >>>> Futon tests on the installed version to make sure everything still
>> >>>> passes.
>> >>>>
>> >>>> Ideally I'd like to get this into trunk fairly shortly so that it has
>> >>>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
>> >>>> if there are any comments or complaints on it.
>> >>>>
>> >>>> Paul Davis
>> >>>>
>> >>>> [1] https://github.com/davisp/couchdb-srcmv
>> >>>>
>> >>>
>> >>> After thinking about it, I don't see the point of having a script to
>> >>> maintain patches, + patches coming with. It make review hard compared
>> >>> to having a branch dedicated to this refactoring. Also it stops
>> >>> somehow any external work of yours hard (eg. can't go further without
>> >>> waiting your updates). Can't we just open a branch on svn and start to
>> >>> work on it. Which would also allow us to wait for fdmanana merge of
>> >>> new replicator
>> >>>
>> >>
>> >> You are free to attempt that. I on the other hand want no part of
>> >> having to deal with rebasing that set of patches using SVN's merge. On
>> >> the other hand, if we did this as a git repository we'd lose the
>> >> history for the entire source tree which would be even worse.
>> >>
>> >>> Related notes from my experiences and reads of the night:
>> >>>
>> >>> There are other needed changes imo:
>> >>>
>> >>> - removing call go http layer in core ( for example in attachments),
>> >>
>> >> These patches don't fix everything. I very explicitly wanted to
>> >> minimize the scope of these patches to solely moving files around and
>> >> then fixing anything that broke. After these land in trunk there's
>> >> still going to be a lot of work left on fixing other aspects of the
>> >> code.
>> >>
>> >>> - having a CouchDB app that reconciliate. core (b-tree, changes, db
>> >>> api) and other members. Such things.
>> >>>
>> >>
>> >> I'm not sure what you mean by reconciling the various apps. As I
>> >> mention above, there's a lot to do. By no means am I suggesting this
>> >> patch is comprehensive. Just enough to get over the large hurdle of
>> >> refactoring the pathnames for files in the source tree.
>> >>
>> >>> I would be happy to work and the work in srcmv is already 70-80% of
>> >>> what we ant. So is there any possibility to have a branch?
>> >>>
>> >>
>> >> I am very scared of SVN's merging. There are nightmares involved. I
>> >> can barely manage to backport patches from trunk. I'm so anti-SVN I'm
>> >> working with infra to try and start us using Git. SVN is the devil.
>> >>
>> >> That said, if you think you'd be all right handling such a large
>> >> branch and the merge back to trunk after the replicator lands then by
>> >> all means feel free to start one. I just chose not to.
>> >>
>> >> HTH,
>> >> Paul Davis
>> >>
>> >
>> > Well at one point we should merge, whatever is the solution. Do we
>> > really want final tests are done in trunk ?
>> >
>>
>> How do you mean final tests?
>>
>> > I think there are way to merge from git to svn too. My point is that
>> > right now, we can't work on a branch , just test. And the more code
>> > will be added to the trunk the more it become difficult to merge too.
>> >
>>
>> I have no idea how git-svn would handle pushing such a large move up
>> to SVN. Perhaps it'd work magically but I didn't feel like setting up
>> the infrastructure to go through and test it to make sure that we're
>> not dropping our entire repository history.
>>
>> As to rebasing this patch set, its fairly trivial if a bit boring.
>>
>
> If you can rebase it so it's linear from the end of trunk you can push it up
> with git-svn no problem. You do the rebasing locally and then just `git svn
> dcommit`. Am I missing something?
>
The question is about how git-svn would handle a rename. If its a
rm+add then its a non-starter. But this is exactly what I didn't want
to configure to study the details. When does a git rename get
translated to an svn rename, and what are the rules there.
>> > - benoît
>> >
>
Re: Source tree refactoring - TESTERS NEEDED
Posted by Randall Leeds <ra...@gmail.com>.
On Dec 26, 2010 6:02 PM, "Paul Davis" <pa...@gmail.com> wrote:
>
> On Sun, Dec 26, 2010 at 5:46 PM, Benoit Chesneau <bc...@gmail.com>
wrote:
> > On Sun, Dec 26, 2010 at 5:30 PM, Paul Davis <pa...@gmail.com>
wrote:
> >> On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <bc...@gmail.com>
wrote:
> >>> On Saturday, December 4, 2010, Paul Davis <pa...@gmail.com>
wrote:
> >>>> Heya,
> >>>>
> >>>> I've just finished getting the refactoring of the source tree to be
> >>>> more compliant with OTP source code layout. This is a pretty big move
> >>>> so I'd like at least a couple other people to test this. If you have
a
> >>>> platform that is not OS X or Ubuntu, consider this an extra special
> >>>> request so that we have confidence that I haven't broken one of the
> >>>> uncommon platforms.
> >>>>
> >>>> The repo for the scripts and patches are at [1]. You should be able
to
> >>>> get a fully refactored couch with:
> >>>>
> >>>> $ git clone git://github.com/davisp/couchdb-srcmv.git
> >>>> $ cd couchdb-srcmv
> >>>> $ ./srcmv.py
> >>>>
> >>>> Once you have that, there's a couchdb.git subdirectory that is a
> >>>> checkout of the entire source tree. Once there, you can build and
test
> >>>> couchdb as per normal. Also, I would appreciate anyone that goes the
> >>>> extra effort and runs the install into a tmp location and runs the
> >>>> Futon tests on the installed version to make sure everything still
> >>>> passes.
> >>>>
> >>>> Ideally I'd like to get this into trunk fairly shortly so that it has
> >>>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
> >>>> if there are any comments or complaints on it.
> >>>>
> >>>> Paul Davis
> >>>>
> >>>> [1] https://github.com/davisp/couchdb-srcmv
> >>>>
> >>>
> >>> After thinking about it, I don't see the point of having a script to
> >>> maintain patches, + patches coming with. It make review hard compared
> >>> to having a branch dedicated to this refactoring. Also it stops
> >>> somehow any external work of yours hard (eg. can't go further without
> >>> waiting your updates). Can't we just open a branch on svn and start to
> >>> work on it. Which would also allow us to wait for fdmanana merge of
> >>> new replicator
> >>>
> >>
> >> You are free to attempt that. I on the other hand want no part of
> >> having to deal with rebasing that set of patches using SVN's merge. On
> >> the other hand, if we did this as a git repository we'd lose the
> >> history for the entire source tree which would be even worse.
> >>
> >>> Related notes from my experiences and reads of the night:
> >>>
> >>> There are other needed changes imo:
> >>>
> >>> - removing call go http layer in core ( for example in attachments),
> >>
> >> These patches don't fix everything. I very explicitly wanted to
> >> minimize the scope of these patches to solely moving files around and
> >> then fixing anything that broke. After these land in trunk there's
> >> still going to be a lot of work left on fixing other aspects of the
> >> code.
> >>
> >>> - having a CouchDB app that reconciliate. core (b-tree, changes, db
> >>> api) and other members. Such things.
> >>>
> >>
> >> I'm not sure what you mean by reconciling the various apps. As I
> >> mention above, there's a lot to do. By no means am I suggesting this
> >> patch is comprehensive. Just enough to get over the large hurdle of
> >> refactoring the pathnames for files in the source tree.
> >>
> >>> I would be happy to work and the work in srcmv is already 70-80% of
> >>> what we ant. So is there any possibility to have a branch?
> >>>
> >>
> >> I am very scared of SVN's merging. There are nightmares involved. I
> >> can barely manage to backport patches from trunk. I'm so anti-SVN I'm
> >> working with infra to try and start us using Git. SVN is the devil.
> >>
> >> That said, if you think you'd be all right handling such a large
> >> branch and the merge back to trunk after the replicator lands then by
> >> all means feel free to start one. I just chose not to.
> >>
> >> HTH,
> >> Paul Davis
> >>
> >
> > Well at one point we should merge, whatever is the solution. Do we
> > really want final tests are done in trunk ?
> >
>
> How do you mean final tests?
>
> > I think there are way to merge from git to svn too. My point is that
> > right now, we can't work on a branch , just test. And the more code
> > will be added to the trunk the more it become difficult to merge too.
> >
>
> I have no idea how git-svn would handle pushing such a large move up
> to SVN. Perhaps it'd work magically but I didn't feel like setting up
> the infrastructure to go through and test it to make sure that we're
> not dropping our entire repository history.
>
> As to rebasing this patch set, its fairly trivial if a bit boring.
>
If you can rebase it so it's linear from the end of trunk you can push it up
with git-svn no problem. You do the rebasing locally and then just `git svn
dcommit`. Am I missing something?
> > - benoît
> >
Re: Source tree refactoring - TESTERS NEEDED
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Dec 26, 2010 at 5:46 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sun, Dec 26, 2010 at 5:30 PM, Paul Davis <pa...@gmail.com> wrote:
>> On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>> On Saturday, December 4, 2010, Paul Davis <pa...@gmail.com> wrote:
>>>> Heya,
>>>>
>>>> I've just finished getting the refactoring of the source tree to be
>>>> more compliant with OTP source code layout. This is a pretty big move
>>>> so I'd like at least a couple other people to test this. If you have a
>>>> platform that is not OS X or Ubuntu, consider this an extra special
>>>> request so that we have confidence that I haven't broken one of the
>>>> uncommon platforms.
>>>>
>>>> The repo for the scripts and patches are at [1]. You should be able to
>>>> get a fully refactored couch with:
>>>>
>>>> $ git clone git://github.com/davisp/couchdb-srcmv.git
>>>> $ cd couchdb-srcmv
>>>> $ ./srcmv.py
>>>>
>>>> Once you have that, there's a couchdb.git subdirectory that is a
>>>> checkout of the entire source tree. Once there, you can build and test
>>>> couchdb as per normal. Also, I would appreciate anyone that goes the
>>>> extra effort and runs the install into a tmp location and runs the
>>>> Futon tests on the installed version to make sure everything still
>>>> passes.
>>>>
>>>> Ideally I'd like to get this into trunk fairly shortly so that it has
>>>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
>>>> if there are any comments or complaints on it.
>>>>
>>>> Paul Davis
>>>>
>>>> [1] https://github.com/davisp/couchdb-srcmv
>>>>
>>>
>>> After thinking about it, I don't see the point of having a script to
>>> maintain patches, + patches coming with. It make review hard compared
>>> to having a branch dedicated to this refactoring. Also it stops
>>> somehow any external work of yours hard (eg. can't go further without
>>> waiting your updates). Can't we just open a branch on svn and start to
>>> work on it. Which would also allow us to wait for fdmanana merge of
>>> new replicator
>>>
>>
>> You are free to attempt that. I on the other hand want no part of
>> having to deal with rebasing that set of patches using SVN's merge. On
>> the other hand, if we did this as a git repository we'd lose the
>> history for the entire source tree which would be even worse.
>>
>>> Related notes from my experiences and reads of the night:
>>>
>>> There are other needed changes imo:
>>>
>>> - removing call go http layer in core ( for example in attachments),
>>
>> These patches don't fix everything. I very explicitly wanted to
>> minimize the scope of these patches to solely moving files around and
>> then fixing anything that broke. After these land in trunk there's
>> still going to be a lot of work left on fixing other aspects of the
>> code.
>>
>>> - having a CouchDB app that reconciliate. core (b-tree, changes, db
>>> api) and other members. Such things.
>>>
>>
>> I'm not sure what you mean by reconciling the various apps. As I
>> mention above, there's a lot to do. By no means am I suggesting this
>> patch is comprehensive. Just enough to get over the large hurdle of
>> refactoring the pathnames for files in the source tree.
>>
>>> I would be happy to work and the work in srcmv is already 70-80% of
>>> what we ant. So is there any possibility to have a branch?
>>>
>>
>> I am very scared of SVN's merging. There are nightmares involved. I
>> can barely manage to backport patches from trunk. I'm so anti-SVN I'm
>> working with infra to try and start us using Git. SVN is the devil.
>>
>> That said, if you think you'd be all right handling such a large
>> branch and the merge back to trunk after the replicator lands then by
>> all means feel free to start one. I just chose not to.
>>
>> HTH,
>> Paul Davis
>>
>
> Well at one point we should merge, whatever is the solution. Do we
> really want final tests are done in trunk ?
>
How do you mean final tests?
> I think there are way to merge from git to svn too. My point is that
> right now, we can't work on a branch , just test. And the more code
> will be added to the trunk the more it become difficult to merge too.
>
I have no idea how git-svn would handle pushing such a large move up
to SVN. Perhaps it'd work magically but I didn't feel like setting up
the infrastructure to go through and test it to make sure that we're
not dropping our entire repository history.
As to rebasing this patch set, its fairly trivial if a bit boring.
> - benoît
>
Re: Source tree refactoring - TESTERS NEEDED
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Dec 26, 2010 at 5:30 PM, Paul Davis <pa...@gmail.com> wrote:
> On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Saturday, December 4, 2010, Paul Davis <pa...@gmail.com> wrote:
>>> Heya,
>>>
>>> I've just finished getting the refactoring of the source tree to be
>>> more compliant with OTP source code layout. This is a pretty big move
>>> so I'd like at least a couple other people to test this. If you have a
>>> platform that is not OS X or Ubuntu, consider this an extra special
>>> request so that we have confidence that I haven't broken one of the
>>> uncommon platforms.
>>>
>>> The repo for the scripts and patches are at [1]. You should be able to
>>> get a fully refactored couch with:
>>>
>>> $ git clone git://github.com/davisp/couchdb-srcmv.git
>>> $ cd couchdb-srcmv
>>> $ ./srcmv.py
>>>
>>> Once you have that, there's a couchdb.git subdirectory that is a
>>> checkout of the entire source tree. Once there, you can build and test
>>> couchdb as per normal. Also, I would appreciate anyone that goes the
>>> extra effort and runs the install into a tmp location and runs the
>>> Futon tests on the installed version to make sure everything still
>>> passes.
>>>
>>> Ideally I'd like to get this into trunk fairly shortly so that it has
>>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
>>> if there are any comments or complaints on it.
>>>
>>> Paul Davis
>>>
>>> [1] https://github.com/davisp/couchdb-srcmv
>>>
>>
>> After thinking about it, I don't see the point of having a script to
>> maintain patches, + patches coming with. It make review hard compared
>> to having a branch dedicated to this refactoring. Also it stops
>> somehow any external work of yours hard (eg. can't go further without
>> waiting your updates). Can't we just open a branch on svn and start to
>> work on it. Which would also allow us to wait for fdmanana merge of
>> new replicator
>>
>
> You are free to attempt that. I on the other hand want no part of
> having to deal with rebasing that set of patches using SVN's merge. On
> the other hand, if we did this as a git repository we'd lose the
> history for the entire source tree which would be even worse.
>
>> Related notes from my experiences and reads of the night:
>>
>> There are other needed changes imo:
>>
>> - removing call go http layer in core ( for example in attachments),
>
> These patches don't fix everything. I very explicitly wanted to
> minimize the scope of these patches to solely moving files around and
> then fixing anything that broke. After these land in trunk there's
> still going to be a lot of work left on fixing other aspects of the
> code.
>
>> - having a CouchDB app that reconciliate. core (b-tree, changes, db
>> api) and other members. Such things.
>>
>
> I'm not sure what you mean by reconciling the various apps. As I
> mention above, there's a lot to do. By no means am I suggesting this
> patch is comprehensive. Just enough to get over the large hurdle of
> refactoring the pathnames for files in the source tree.
>
>> I would be happy to work and the work in srcmv is already 70-80% of
>> what we ant. So is there any possibility to have a branch?
>>
>
> I am very scared of SVN's merging. There are nightmares involved. I
> can barely manage to backport patches from trunk. I'm so anti-SVN I'm
> working with infra to try and start us using Git. SVN is the devil.
>
> That said, if you think you'd be all right handling such a large
> branch and the merge back to trunk after the replicator lands then by
> all means feel free to start one. I just chose not to.
>
> HTH,
> Paul Davis
>
Well at one point we should merge, whatever is the solution. Do we
really want final tests are done in trunk ?
I think there are way to merge from git to svn too. My point is that
right now, we can't work on a branch , just test. And the more code
will be added to the trunk the more it become difficult to merge too.
- benoît
Re: Source tree refactoring - TESTERS NEEDED
Posted by Paul Davis <pa...@gmail.com>.
On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Saturday, December 4, 2010, Paul Davis <pa...@gmail.com> wrote:
>> Heya,
>>
>> I've just finished getting the refactoring of the source tree to be
>> more compliant with OTP source code layout. This is a pretty big move
>> so I'd like at least a couple other people to test this. If you have a
>> platform that is not OS X or Ubuntu, consider this an extra special
>> request so that we have confidence that I haven't broken one of the
>> uncommon platforms.
>>
>> The repo for the scripts and patches are at [1]. You should be able to
>> get a fully refactored couch with:
>>
>> $ git clone git://github.com/davisp/couchdb-srcmv.git
>> $ cd couchdb-srcmv
>> $ ./srcmv.py
>>
>> Once you have that, there's a couchdb.git subdirectory that is a
>> checkout of the entire source tree. Once there, you can build and test
>> couchdb as per normal. Also, I would appreciate anyone that goes the
>> extra effort and runs the install into a tmp location and runs the
>> Futon tests on the installed version to make sure everything still
>> passes.
>>
>> Ideally I'd like to get this into trunk fairly shortly so that it has
>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
>> if there are any comments or complaints on it.
>>
>> Paul Davis
>>
>> [1] https://github.com/davisp/couchdb-srcmv
>>
>
> After thinking about it, I don't see the point of having a script to
> maintain patches, + patches coming with. It make review hard compared
> to having a branch dedicated to this refactoring. Also it stops
> somehow any external work of yours hard (eg. can't go further without
> waiting your updates). Can't we just open a branch on svn and start to
> work on it. Which would also allow us to wait for fdmanana merge of
> new replicator
>
You are free to attempt that. I on the other hand want no part of
having to deal with rebasing that set of patches using SVN's merge. On
the other hand, if we did this as a git repository we'd lose the
history for the entire source tree which would be even worse.
> Related notes from my experiences and reads of the night:
>
> There are other needed changes imo:
>
> - removing call go http layer in core ( for example in attachments),
These patches don't fix everything. I very explicitly wanted to
minimize the scope of these patches to solely moving files around and
then fixing anything that broke. After these land in trunk there's
still going to be a lot of work left on fixing other aspects of the
code.
> - having a CouchDB app that reconciliate. core (b-tree, changes, db
> api) and other members. Such things.
>
I'm not sure what you mean by reconciling the various apps. As I
mention above, there's a lot to do. By no means am I suggesting this
patch is comprehensive. Just enough to get over the large hurdle of
refactoring the pathnames for files in the source tree.
> I would be happy to work and the work in srcmv is already 70-80% of
> what we ant. So is there any possibility to have a branch?
>
I am very scared of SVN's merging. There are nightmares involved. I
can barely manage to backport patches from trunk. I'm so anti-SVN I'm
working with infra to try and start us using Git. SVN is the devil.
That said, if you think you'd be all right handling such a large
branch and the merge back to trunk after the replicator lands then by
all means feel free to start one. I just chose not to.
HTH,
Paul Davis
Re: Source tree refactoring - TESTERS NEEDED
Posted by Benoit Chesneau <bc...@gmail.com>.
On Saturday, December 4, 2010, Paul Davis <pa...@gmail.com> wrote:
> Heya,
>
> I've just finished getting the refactoring of the source tree to be
> more compliant with OTP source code layout. This is a pretty big move
> so I'd like at least a couple other people to test this. If you have a
> platform that is not OS X or Ubuntu, consider this an extra special
> request so that we have confidence that I haven't broken one of the
> uncommon platforms.
>
> The repo for the scripts and patches are at [1]. You should be able to
> get a fully refactored couch with:
>
> $ git clone git://github.com/davisp/couchdb-srcmv.git
> $ cd couchdb-srcmv
> $ ./srcmv.py
>
> Once you have that, there's a couchdb.git subdirectory that is a
> checkout of the entire source tree. Once there, you can build and test
> couchdb as per normal. Also, I would appreciate anyone that goes the
> extra effort and runs the install into a tmp location and runs the
> Futon tests on the installed version to make sure everything still
> passes.
>
> Ideally I'd like to get this into trunk fairly shortly so that it has
> as long as possible to sit in trunk before we cut 1.2.x. Let me know
> if there are any comments or complaints on it.
>
> Paul Davis
>
> [1] https://github.com/davisp/couchdb-srcmv
>
After thinking about it, I don't see the point of having a script to
maintain patches, + patches coming with. It make review hard compared
to having a branch dedicated to this refactoring. Also it stops
somehow any external work of yours hard (eg. can't go further without
waiting your updates). Can't we just open a branch on svn and start to
work on it. Which would also allow us to wait for fdmanana merge of
new replicator
Related notes from my experiences and reads of the night:
There are other needed changes imo:
- removing call go http layer in core ( for example in attachments),
- having a CouchDB app that reconciliate. core (b-tree, changes, db
api) and other members. Such things.
I would be happy to work and the work in srcmv is already 70-80% of
what we ant. So is there any possibility to have a branch?