Hi, This bug is still present in 0.8.0.dev5656: ====================================================================== FAIL: test_pbdv (test_basic.TestCephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_basic.py", line 370, in test_pbdv assert_equal(cephes.pbdv(1,0),(0.0,0.0)) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 182, in assert_equal assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), verbose) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 189, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: item=1 ACTUAL: 1.0 DESIRED: 0.0 A bug free testsuite is a very important item to advertise scipy in a industrial context. Could someone help me to kill this old bug? (ubuntu 64bits). Xavier
Mon, 13 Apr 2009 19:38:04 +0200, Xavier Gnata wrote:
This bug is still present in 0.8.0.dev5656: [clip] A bug free testsuite is a very important item to advertise scipy in a industrial context. Could someone help me to kill this old bug? (ubuntu 64bits).
If you want to help, the first step in fixing special.pbdv would be to write improved tests for it; just edit test_basic.py to add relevant tests, and do svn diff test_basic.py > test-special-pbdv.patch and attach the patch to the corresponding Trac ticket: http://projects.scipy.org/scipy/ticket/803 Tests for checking the function values at a couple of special points and around "difficult points" (singularities, zeros) would be useful for us. -- Pauli Virtanen
Pauli Virtanen wrote:
Mon, 13 Apr 2009 19:38:04 +0200, Xavier Gnata wrote:
This bug is still present in 0.8.0.dev5656:
[clip]
A bug free testsuite is a very important item to advertise scipy in a industrial context. Could someone help me to kill this old bug? (ubuntu 64bits).
If you want to help, the first step in fixing special.pbdv would be to write improved tests for it; just edit test_basic.py to add relevant tests, and do
svn diff test_basic.py > test-special-pbdv.patch
and attach the patch to the corresponding Trac ticket:
http://projects.scipy.org/scipy/ticket/803
Tests for checking the function values at a couple of special points and around "difficult points" (singularities, zeros) would be useful for us.
Well it could be no problem but first I would like to get some feedback on my comments on http://projects.scipy.org/scipy/ticket/803 Special functions are tricky things...many slightly different ways to define them... Xavier
Mon, 13 Apr 2009 23:47:16 +0200, Xavier Gnata wrote: [clip]
Well it could be no problem but first I would like to get some feedback on my comments on http://projects.scipy.org/scipy/ticket/803 Special functions are tricky things...many slightly different ways to define them...
Yes, the test is wrong (fixed in r5657), and it appears the second output from pbdv has nothing to do with the gradient of Dv even though the docstring says otherwise. Apparently, the Specfun Fortran code for PBDV is bogus or incorrectly documented. -- Pauli Virtanen
Mon, 13 Apr 2009 19:38:04 +0200, Xavier Gnata wrote:
Hi,
This bug is still present in 0.8.0.dev5656:
====================================================================== FAIL: test_pbdv (test_basic.TestCephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/ test_basic.py", line 370, in test_pbdv [clip]
Should be fixed in r5658. There was at least a likely off-by-one memory overflow issue in the PBDV wrappers. Please test the most recent SVN version to see if it works now as expected. -- Pauli Virtanen
Pauli Virtanen wrote:
Mon, 13 Apr 2009 19:38:04 +0200, Xavier Gnata wrote:
Hi,
This bug is still present in 0.8.0.dev5656:
====================================================================== FAIL: test_pbdv (test_basic.TestCephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/
test_basic.py",
line 370, in test_pbdv
[clip]
Should be fixed in r5658. There was at least a likely off-by-one memory overflow issue in the PBDV wrappers.
Please test the most recent SVN version to see if it works now as expected.
ok it is fixed. Thanks. Xavier
Pauli Virtanen wrote:
Mon, 13 Apr 2009 19:38:04 +0200, Xavier Gnata wrote:
Hi,
This bug is still present in 0.8.0.dev5656:
====================================================================== FAIL: test_pbdv (test_basic.TestCephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/
test_basic.py",
line 370, in test_pbdv
[clip]
Should be fixed in r5658. There was at least a likely off-by-one memory overflow issue in the PBDV wrappers.
Please test the most recent SVN version to see if it works now as expected.
'0.8.0.dev5661' and there is still a bug: ====================================================================== FAIL: test_pbdv (test_basic.TestCephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_basic.py", line 370, in test_pbdv assert_equal(cephes.pbdv(1,0),(0.0,0.0)) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 182, in assert_equal assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), verbose) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 189, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: item=1 ACTUAL: 1.0 DESIRED: 0.0 BWT, is there a way to compile scipy/numpy in debug mode and to run it under valgrind? Xavier
Wed, 15 Apr 2009 22:13:26 +0200, Xavier Gnata wrote: [clip]
'0.8.0.dev5661' and there is still a bug: ====================================================================== FAIL: test_pbdv (test_basic.TestCephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/ test_basic.py", line 370, in test_pbdv
assert_equal(cephes.pbdv(1,0),(0.0,0.0))
You have a stale install or something similar, that line is not there any more in r5661. [clip]
BWT, is there a way to compile scipy/numpy in debug mode and to run it under valgrind?
Yes, python2.5 setup.py build --debug valgrind python2.5 -c 'import scipy; scipy.test()' -- Pauli Virtanen
Pauli Virtanen wrote:
Wed, 15 Apr 2009 22:13:26 +0200, Xavier Gnata wrote: [clip]
'0.8.0.dev5661' and there is still a bug: ====================================================================== FAIL: test_pbdv (test_basic.TestCephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/
test_basic.py",
line 370, in test_pbdv
assert_equal(cephes.pbdv(1,0),(0.0,0.0))
You have a stale install or something similar, that line is not there any more in r5661.
Well I'm do not understand this point Looking at http://svn.scipy.org/svn/scipy/trunk/scipy/special/tests/test_basic.py I can read : def test_pbdv(self): assert_equal(cephes.pbdv(1,0),(0.0,0.0) This website claims I'm looking at Revision 5661: /trunk/scipy/special/tests I'm must be missing something...sorry for the noise....
[clip]
BWT, is there a way to compile scipy/numpy in debug mode and to run it under valgrind?
Yes,
python2.5 setup.py build --debug
valgrind python2.5 -c 'import scipy; scipy.test()'
ok thanks. Xavier
Hi all, Commit r5661 apparently reverted some previous commits: compare http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic... http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic... looking at the line "cephes.pbdv(1,0),(0.0,0.0)", which previously read "cephes.pbdv(1,0),(0.0,1.0)". The strange thing is that http://projects.scipy.org/scipy/changeset/5661 does not show that this change was made. It seems like bzr-svn did something clever... Moreover, svn diff -r 5660:5661 test_basic.py says svn: Unable to find repository location for 'test_basic.py' in revision 5660 which is unexpected. The Git repository indicates that something like this occurred: 5655 5656 5657 5658 5659 5660 o----o----o----o----o----o----o 5661 \___________________________/ So, the revision 5661 is based on 5655. Now, bzr-svn has done something and silently reverted the changesets 5656-5660 so that the reversion does not appear in the commit 5661. (Surprisingly, git-svn *recognized* this as a merge!) The full diff appears to be $ git diff --stat 746e23..svn/trunk INSTALL.txt | 222 ++++++++++++++------- scipy/io/matlab/tests/data/test_skip_variable.mat | Bin 20225 -> 0 bytes scipy/io/matlab/tests/test_mio.py | 31 +--- scipy/special/specfun_wrappers.c | 6 +- scipy/special/tests/test_basic.py | 31 +--- scipy/stats/distributions.py | 2 +- So, it seems that bzr-svn does some "deep" SVN-fu on merges. Looking at the commit message for r5661 more closely, it says ". (copied from trunk)", and indeed "svn log ." indicates that r5661 is based on r5660. Does someone understand SVN enough to know what happened and how to revert it, if needed? My guess would be svn cp http://svn.scipy.org/svn/scipy/trunk@5660 http://svn.scipy.org/svn/scipy/trunk *** Wed, 15 Apr 2009 23:31:39 +0200, Xavier Gnata wrote: [clip]
Well I'm do not understand this point Looking at http://svn.scipy.org/svn/scipy/trunk/scipy/special/tests/test_basic.py I can read :
def test_pbdv(self): assert_equal(cephes.pbdv(1,0),(0.0,0.0)
This website claims I'm looking at
Revision 5661: /trunk/scipy/special/tests
I'm must be missing something...sorry for the noise....
Good catch, you're completely right! Something strange is going on. I only checked it via looking at the commits in http://projects.scipy.org/scipy/timeline and as you can see, none of the commits after 5657 actually reverts the change, so I assumed it was still there... -- Pauli Virtanen
On Wed, Apr 15, 2009 at 7:06 PM, Pauli Virtanen <pav@iki.fi> wrote:
Hi all,
Commit r5661 apparently reverted some previous commits: compare
http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic... http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic...
looking at the line "cephes.pbdv(1,0),(0.0,0.0)", which previously read "cephes.pbdv(1,0),(0.0,1.0)". The strange thing is that
http://projects.scipy.org/scipy/changeset/5661
does not show that this change was made. It seems like bzr-svn did something clever...
Moreover,
svn diff -r 5660:5661 test_basic.py
says
svn: Unable to find repository location for 'test_basic.py' in revision 5660
which is unexpected.
The Git repository indicates that something like this occurred:
5655 5656 5657 5658 5659 5660 o----o----o----o----o----o----o 5661 \___________________________/
So, the revision 5661 is based on 5655. Now, bzr-svn has done something and silently reverted the changesets 5656-5660 so that the reversion does not appear in the commit 5661. (Surprisingly, git-svn *recognized* this as a merge!) The full diff appears to be
$ git diff --stat 746e23..svn/trunk INSTALL.txt | 222 ++++++++++++++------- scipy/io/matlab/tests/data/test_skip_variable.mat | Bin 20225 -> 0 bytes scipy/io/matlab/tests/test_mio.py | 31 +--- scipy/special/specfun_wrappers.c | 6 +- scipy/special/tests/test_basic.py | 31 +--- scipy/stats/distributions.py | 2 +-
So, it seems that bzr-svn does some "deep" SVN-fu on merges. Looking at the commit message for r5661 more closely, it says ". (copied from trunk)", and indeed "svn log ." indicates that r5661 is based on r5660.
Does someone understand SVN enough to know what happened and how to revert it, if needed?
My guess would be
svn cp http://svn.scipy.org/svn/scipy/trunk@5660 http://svn.scipy.org/svn/scipy/trunk
***
Wed, 15 Apr 2009 23:31:39 +0200, Xavier Gnata wrote: [clip]
Well I'm do not understand this point Looking at http://svn.scipy.org/svn/scipy/trunk/scipy/special/tests/test_basic.py I can read :
def test_pbdv(self): assert_equal(cephes.pbdv(1,0),(0.0,0.0)
This website claims I'm looking at
Revision 5661: /trunk/scipy/special/tests
I'm must be missing something...sorry for the noise....
Good catch, you're completely right! Something strange is going on. I only checked it via looking at the commits in
http://projects.scipy.org/scipy/timeline
and as you can see, none of the commits after 5657 actually reverts the change, so I assumed it was still there...
-- Pauli Virtanen
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
I think that's my fault, but I haven't figured out how to revert this. I tried to use bzr-svn but something looked strange, but I thought it is only the large commit message. Can you undo whatever happened in http://projects.scipy.org/scipy/changeset/5661, and I won't try this anymore if it messes up the repository and not just the commit message. Sorry, Josef
On Wed, Apr 15, 2009 at 5:30 PM, <josef.pktd@gmail.com> wrote:
On Wed, Apr 15, 2009 at 7:06 PM, Pauli Virtanen <pav@iki.fi> wrote:
Hi all,
Commit r5661 apparently reverted some previous commits: compare
http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic...
http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic...
looking at the line "cephes.pbdv(1,0),(0.0,0.0)", which previously read "cephes.pbdv(1,0),(0.0,1.0)". The strange thing is that
http://projects.scipy.org/scipy/changeset/5661
does not show that this change was made. It seems like bzr-svn did
clever...
Moreover,
svn diff -r 5660:5661 test_basic.py
says
svn: Unable to find repository location for 'test_basic.py' in revision 5660
which is unexpected.
The Git repository indicates that something like this occurred:
5655 5656 5657 5658 5659 5660 o----o----o----o----o----o----o 5661 \___________________________/
So, the revision 5661 is based on 5655. Now, bzr-svn has done something and silently reverted the changesets 5656-5660 so that the reversion does not appear in the commit 5661. (Surprisingly, git-svn *recognized*
as a merge!) The full diff appears to be
$ git diff --stat 746e23..svn/trunk INSTALL.txt | 222 ++++++++++++++------- scipy/io/matlab/tests/data/test_skip_variable.mat | Bin 20225 -> 0 bytes scipy/io/matlab/tests/test_mio.py | 31 +--- scipy/special/specfun_wrappers.c | 6 +- scipy/special/tests/test_basic.py | 31 +--- scipy/stats/distributions.py | 2 +-
So, it seems that bzr-svn does some "deep" SVN-fu on merges. Looking at the commit message for r5661 more closely, it says ". (copied from
something this trunk)",
and indeed "svn log ." indicates that r5661 is based on r5660.
Does someone understand SVN enough to know what happened and how to revert it, if needed?
My guess would be
svn cp http://svn.scipy.org/svn/scipy/trunk@5660 http://svn.scipy.org/svn/scipy/trunk
***
Wed, 15 Apr 2009 23:31:39 +0200, Xavier Gnata wrote: [clip]
Well I'm do not understand this point Looking at http://svn.scipy.org/svn/scipy/trunk/scipy/special/tests/test_basic.pyI can read :
def test_pbdv(self): assert_equal(cephes.pbdv(1,0),(0.0,0.0)
This website claims I'm looking at
Revision 5661: /trunk/scipy/special/tests
I'm must be missing something...sorry for the noise....
Good catch, you're completely right! Something strange is going on. I only checked it via looking at the commits in
http://projects.scipy.org/scipy/timeline
and as you can see, none of the commits after 5657 actually reverts the change, so I assumed it was still there...
-- Pauli Virtanen
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
I think that's my fault, but I haven't figured out how to revert this.
I tried to use bzr-svn but something looked strange, but I thought it is only the large commit message.
Can you undo whatever happened in http://projects.scipy.org/scipy/changeset/5661, and I won't try this anymore if it messes up the repository and not just the commit message.
I found reverting the central svn repository to be a total PITA. If someone still has the correct versions of the files the easiest thing to do is just commit them. Chuck
On Wed 15 Apr, 18:25, Charles R Harris wrote:
The Git repository indicates that something like this occurred:
5655 5656 5657 5658 5659 5660 o----o----o----o----o----o----o 5661 \___________________________/
I think that's my fault, but I haven't figured out how to revert this.
Can you undo whatever happened in http://projects.scipy.org/scipy/changeset/5661, and I won't try this anymore if it messes up the repository and not just the commit message.
I found reverting the central svn repository to be a total PITA. If someone still has the correct versions of the files the easiest thing to do is just commit them.
I had just checked out revision 5660, so I could commit it back again if it's needed, but one would probably need to change all relevant files in order to convince svn that they are new, and then manually solve all conflicts by accepting my own version. Let me know, I could do it around 6:30 AM UTC on Apr 16! ciao, tiziano
On Wed, Apr 15, 2009 at 7:27 PM, Tiziano Zito <opossumnano@gmail.com> wrote:
On Wed 15 Apr, 18:25, Charles R Harris wrote:
The Git repository indicates that something like this occurred:
5655 5656 5657 5658 5659 5660 o----o----o----o----o----o----o 5661 \___________________________/
I think that's my fault, but I haven't figured out how to revert this.
Can you undo whatever happened in http://projects.scipy.org/scipy/changeset/5661, and I won't try this anymore if it messes up the repository and not just the commit message.
I found reverting the central svn repository to be a total PITA. If someone still has the correct versions of the files the easiest thing to do is just commit them.
I had just checked out revision 5660, so I could commit it back again if it's needed, but one would probably need to change all relevant files in order to convince svn that they are new, and then manually solve all conflicts by accepting my own version. Let me know, I could do it around 6:30 AM UTC on Apr 16!
Rename the relevent good files, check out the latest svn revision, replace the files with your good versions and commit. If someone knows an easier way please let me know. Fixing svn after a corrupted commit almost drove me crazy when I had to do it. Chuck
On Wed 15 Apr, 19:34, Charles R Harris wrote:
I had just checked out revision 5660, so I could commit it back again if it's needed, but one would probably need to change all relevant files in order to convince svn that they are new, and then manually solve all conflicts by accepting my own version. Let me know, I could do it around 6:30 AM UTC on Apr 16!
Rename the relevent good files, check out the latest svn revision, replace the files with your good versions and commit. If someone knows an easier way please let me know. Fixing svn after a corrupted commit almost drove me crazy when I had to do it.
ok. can you come up with a list of the relevant good files? I don't want to screw up things even more. joseph? pauli? if someone posts the list of files I can immediately start the rescuing procedure ;-) ciao, tiziano
On Wed, Apr 15, 2009 at 7:30 PM, <josef.pktd@gmail.com> wrote:
On Wed, Apr 15, 2009 at 7:06 PM, Pauli Virtanen <pav@iki.fi> wrote:
Hi all,
Commit r5661 apparently reverted some previous commits: compare
http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic... http://projects.scipy.org/scipy/browser/trunk/scipy/special/tests/test_basic...
looking at the line "cephes.pbdv(1,0),(0.0,0.0)", which previously read "cephes.pbdv(1,0),(0.0,1.0)". The strange thing is that
http://projects.scipy.org/scipy/changeset/5661
does not show that this change was made. It seems like bzr-svn did something clever...
Moreover,
svn diff -r 5660:5661 test_basic.py
says
svn: Unable to find repository location for 'test_basic.py' in revision 5660
which is unexpected.
The Git repository indicates that something like this occurred:
5655 5656 5657 5658 5659 5660 o----o----o----o----o----o----o 5661 \___________________________/
So, the revision 5661 is based on 5655. Now, bzr-svn has done something and silently reverted the changesets 5656-5660 so that the reversion does not appear in the commit 5661. (Surprisingly, git-svn *recognized* this as a merge!) The full diff appears to be
$ git diff --stat 746e23..svn/trunk INSTALL.txt | 222 ++++++++++++++------- scipy/io/matlab/tests/data/test_skip_variable.mat | Bin 20225 -> 0 bytes scipy/io/matlab/tests/test_mio.py | 31 +--- scipy/special/specfun_wrappers.c | 6 +- scipy/special/tests/test_basic.py | 31 +--- scipy/stats/distributions.py | 2 +-
So, it seems that bzr-svn does some "deep" SVN-fu on merges. Looking at the commit message for r5661 more closely, it says ". (copied from trunk)", and indeed "svn log ." indicates that r5661 is based on r5660.
Does someone understand SVN enough to know what happened and how to revert it, if needed?
My guess would be
svn cp http://svn.scipy.org/svn/scipy/trunk@5660 http://svn.scipy.org/svn/scipy/trunk
***
Wed, 15 Apr 2009 23:31:39 +0200, Xavier Gnata wrote: [clip]
Well I'm do not understand this point Looking at http://svn.scipy.org/svn/scipy/trunk/scipy/special/tests/test_basic.py I can read :
def test_pbdv(self): assert_equal(cephes.pbdv(1,0),(0.0,0.0)
This website claims I'm looking at
Revision 5661: /trunk/scipy/special/tests
I'm must be missing something...sorry for the noise....
Good catch, you're completely right! Something strange is going on. I only checked it via looking at the commits in
http://projects.scipy.org/scipy/timeline
and as you can see, none of the commits after 5657 actually reverts the change, so I assumed it was still there...
-- Pauli Virtanen
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
I think that's my fault, but I haven't figured out how to revert this.
I tried to use bzr-svn but something looked strange, but I thought it is only the large commit message.
Can you undo whatever happened in http://projects.scipy.org/scipy/changeset/5661, and I won't try this anymore if it messes up the repository and not just the commit message.
Sorry,
Josef
I figured out what I did wrong. It is all my fault for over-riding a bzr warning. The short version: I forced a branch/checkout based on svn r5655 together with a new change (revision 5661) back into the svn repository. my setup: C:/Josef/eclipsegworkspace/scipy-trunk-new/ is a checkout branch, but didn't realize that if I push anything on this branch, it gets by default immediately committed to the svn repository also. Now, I know that when I pushed my changes this checkout was at svn r5655 C:\Josef\eclipsegworkspace\scipy-branch is a regular branch in which I am working in, this was also at svn r5655 Next is a case of ignored warnings even if nothing seemed wrong. These are the relevant commands, I checked several other things, but I never checked with the remote svn repository.
cd C:\Josef\eclipsegworkspace\scipy-branch bzr push C:/Josef/eclipsegworkspace/scipy-trunk-new/ bzr: ERROR: These branches have diverged. Try using "merge" and then "push".
bzr merge C:/Josef/eclipsegworkspace/scipy-trunk-new/ Nothing to do.
bzr push --overwrite C:/Josef/eclipsegworkspace/scipy-trunk-new/ All changes applied successfully. Pushed up to revision 4967.
The last overwrite push, not only pushed to my local checkout, but directly also to the scipy svn repository. My mistake was that I thought, I still had one safety layer between me and the scipy svn, that I will still need to push from the checkout to the remote repository. Additionally, I'm pretty sure, I never told bzr my scipy svn password. For now I stick with svn, and set up my own test repository until I have more practice with decentralized version control. Are the svn data base (svnadmin verify) and the trac data base internally still consistent? Sorry about this. Josef "Foolproof systems to not take into account the ingenuity of fools." Gene Brown
Pauli Virtanen wrote:
$ git diff --stat 746e23..svn/trunk INSTALL.txt | 222 ++++++++++++++------- scipy/io/matlab/tests/data/test_skip_variable.mat | Bin 20225 -> 0 bytes scipy/io/matlab/tests/test_mio.py | 31 +--- scipy/special/specfun_wrappers.c | 6 +- scipy/special/tests/test_basic.py | 31 +--- scipy/stats/distributions.py | 2 +-
So, it seems that bzr-svn does some "deep" SVN-fu on merges. Looking at the commit message for r5661 more closely, it says ". (copied from trunk)", and indeed "svn log ." indicates that r5661 is based on r5660.
Does someone understand SVN enough to know what happened and how to revert it, if needed?
I am looking at it right now. Since I can make a copy of the svn repository, I will try your approach locally, and put it online if it works. cheers, David
Pauli Virtanen wrote:
The Git repository indicates that something like this occurred:
5655 5656 5657 5658 5659 5660 o----o----o----o----o----o----o 5661 \___________________________/
So, the revision 5661 is based on 5655.
You can see this from svn as well, using the -v option of log: svn log -r -v HEAD http://svn.scipy.org/svn/numpy/trunk """ ------------------------------------------------------------------------ r5661 | josef | 2009-04-16 02:30:58 +0900 (Thu, 16 Apr 2009) | 1 line Changed paths: R /trunk (from /trunk:5655) M /trunk/scipy/stats/distributions.py use np.power in rdist (test commit with bzr) ------------------------------------------------------------------------ """ The 'R' meaning replace. I don't know why bzr did this - it looks like a bzr-svn bug to me. I don't know what's best. I tried your suggestion locally: svn cp file:///usr/media/src/dsp/scipy_trans/yo/trunk@5660 file:///usr/media/src/dsp/scipy_trans/yo/trunk but this creates a new trunk directory inside trunk. Omitting the trunk for the copy destination does not work, svn complains about overwriting an existing directory. I don't know what's best: rewriting the svn repository (keep everything up to 5660 and then commit 5661 as Josef intended, i.e. just changing distributions.py), or doing the same by reverting the changes. cheers, David
Thu, 16 Apr 2009 16:41:33 +0900, David Cournapeau kirjoitti:
Pauli Virtanen wrote:
The Git repository indicates that something like this occurred:
5655 5656 5657 5658 5659 5660 o----o----o----o----o----o----o 5661 \___________________________/
So, the revision 5661 is based on 5655.
You can see this from svn as well, using the -v option of log:
svn log -r -v HEAD http://svn.scipy.org/svn/numpy/trunk
Yes, if you know to look for it. But in Git it was obvious what happened, since its data model is simpler, so I looked first at it :) [clip]
The 'R' meaning replace. I don't know why bzr did this - it looks like a bzr-svn bug to me.
I don't know what's best. I tried your suggestion locally:
svn cp file:///usr/media/src/dsp/scipy_trans/yo/trunk@5660 file:///usr/media/src/dsp/scipy_trans/yo/trunk
but this creates a new trunk directory inside trunk. Omitting the trunk for the copy destination does not work, svn complains about overwriting an existing directory.
Does svn rm file:///.../yo/trunk svn cp file:///.../yo/trunk@5660 file:///.../yo/trunk work then?
I don't know what's best: rewriting the svn repository (keep everything up to 5660 and then commit 5661 as Josef intended, i.e. just changing distributions.py), or doing the same by reverting the changes.
I'd rather try to restore the trunk tree to 5660 and commit on top of that; otherwise you can't do svn diff -r 5660:5661 test_basic.py since SVN thinks 5660 lives in a different directory than 5661 although the directories have the same name... Who said SVN is simple :) -- Pauli Virtanen
Pauli Virtanen wrote:
Yes, if you know to look for it. But in Git it was obvious what happened, since its data model is simpler, so I looked first at it :)
Oh, yes, definitely :) I felt safer to check that svn reported this as well, though.
Does
svn rm file:///.../yo/trunk svn cp file:///.../yo/trunk@5660 file:///.../yo/trunk
work then?
I guess it would, but I am afraid it would horribly break the whole history (the file ids would be different).
I'd rather try to restore the trunk tree to 5660 and commit on top of that; otherwise you can't do
svn diff -r 5660:5661 test_basic.py
since SVN thinks 5660 lives in a different directory than 5661 although the directories have the same name...
Rewriting/restoring the repository is technically better, because we can erase the error, and it is guaranteed it won't break any history-related features in svn. But I don't know what it means for people who have checked out revision 5661 before the rewriting, which worries me a bit. Maybe that's not very important.
Who said SVN is simple :)
:) David
On Thu, Apr 16, 2009 at 2:35 AM, David Cournapeau < david@ar.media.kyoto-u.ac.jp> wrote:
Pauli Virtanen wrote:
Yes, if you know to look for it. But in Git it was obvious what happened, since its data model is simpler, so I looked first at it :)
Oh, yes, definitely :) I felt safer to check that svn reported this as well, though.
Does
svn rm file:///.../yo/trunk svn cp file:///.../yo/trunk@5660 file:///.../yo/trunk
work then?
I guess it would, but I am afraid it would horribly break the whole history (the file ids would be different).
I'd rather try to restore the trunk tree to 5660 and commit on top of that; otherwise you can't do
svn diff -r 5660:5661 test_basic.py
since SVN thinks 5660 lives in a different directory than 5661 although the directories have the same name...
Rewriting/restoring the repository is technically better, because we can erase the error, and it is guaranteed it won't break any history-related features in svn. But I don't know what it means for people who have checked out revision 5661 before the rewriting, which worries me a bit. Maybe that's not very important.
The diffs on trac for r5656-r5660 look valid. Just download them and patch the files. Chuck
On Fri, Apr 17, 2009 at 1:42 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Apr 16, 2009 at 2:35 AM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Rewriting/restoring the repository is technically better, because we can erase the error, and it is guaranteed it won't break any history-related features in svn. But I don't know what it means for people who have checked out revision 5661 before the rewriting, which worries me a bit. Maybe that's not very important.
I ended up using git revert functionality to revert Josef commit, and replay commit 5661 on the current svn "tip" as Josef intended (only changing pow to np.pow). According to diff at least, there no unexpected diff between r5660 and HEAD, David
participants (7)
-
Charles R Harris -
David Cournapeau -
David Cournapeau -
josef.pktd＠gmail.com -
Pauli Virtanen -
Tiziano Zito -
Xavier Gnata