Buildbots have trouble checking out the repository due to recent changes.
Hello, I have been working the module renaming for PEP-3108, and I just noticed that some buildbots are throwing errors while updating their checkout. It seems the method I use for renaming modules hits a subversion bug on certain platforms. The error thrown looks like this: ... svn: In directory 'build/Lib/plat-mac' svn: Can't move source to dest svn: Can't move 'build/Lib/plat-mac/.svn/tmp/prop-base/pixmapwrapper.py.svn-base' to 'build/Lib/plat-mac/.svn/prop-base/pixmapwrapper.py.svn-base': No such file or directory program finished with exit code 1 (http://www.python.org/dev/buildbot/all/x86 osx.5 trunk/builds/201/step-svn/0) When I rename a module I use "svn copy", since "svn remove" doesn't pick up changes made to the "deleted" file. For example, here is what I did for PixMapWrapper: svn copy ./Lib/plat-mac/PixMapWrapper.py ./Lib/plat-mac/pixmapwrapper.py edit ./Lib/plat-mac/PixMapWrapper.py svn commit It seems that I could avoid this error by using "cp" instead of "svn copy" (which I did use for renaming copy_reg). However, I am not sure if this method doesn't preserve the full history of file. So, how should I do to fix the failing buildbots? -- Alexandre
Alexandre Vassalotti schrieb:
When I rename a module I use "svn copy", since "svn remove" doesn't pick up changes made to the "deleted" file. For example, here is what I did for PixMapWrapper:
svn copy ./Lib/plat-mac/PixMapWrapper.py ./Lib/plat-mac/pixmapwrapper.py edit ./Lib/plat-mac/PixMapWrapper.py svn commit
It seems that I could avoid this error by using "cp" instead of "svn copy" (which I did use for renaming copy_reg). However, I am not sure if this method doesn't preserve the full history of file.
So, how should I do to fix the failing buildbots?
In any case, how does SVN on Windows handle this situation, having two identical filenames -- except for case -- in one directory? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Sun, May 11, 2008 at 11:45:03PM +0200, Georg Brandl wrote:
In any case, how does SVN on Windows handle this situation, having two identical filenames -- except for case -- in one directory?
Very bad. It's completely confused. It can checkout one of the files and commit the other. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Sun, May 11, 2008 at 5:29 PM, Alexandre Vassalotti <alexandre@peadrop.com> wrote:
Hello,
I have been working the module renaming for PEP-3108, and I just noticed that some buildbots are throwing errors while updating their checkout. It seems the method I use for renaming modules hits a subversion bug on certain platforms. The error thrown looks like this: [SNIP] So, how should I do to fix the failing buildbots?
I reverted the all problematic changes and the buildbots are green again. Thank you all for you support! -- Alexandre
2008/5/12 Alexandre Vassalotti <alexandre@peadrop.com>:
On Sun, May 11, 2008 at 5:29 PM, Alexandre Vassalotti <alexandre@peadrop.com> wrote:
Hello,
I have been working the module renaming for PEP-3108, and I just noticed that some buildbots are throwing errors while updating their checkout. It seems the method I use for renaming modules hits a subversion bug on certain platforms. The error thrown looks like this: [SNIP]
So, how should I do to fix the failing buildbots?
I reverted the all problematic changes and the buildbots are green again.
Thank you all for you support!
\Apps\HGsvn\hgimportsvn.exe -r 63120 http://svn.python.org/projects/python/trunk foo cd foo \apps\hgsvn\hgpullsvn hg log Lib\socketserver.py changeset: 2:e8856fdf9300 branch: trunk tag: svn.63129 user: alexandre.vassalotti date: Mon May 12 02:37:10 2008 +0100
Revision 63129 is not valid on case folding filesystems. In particular, this horribly breaks using hg-svn to make a local mirror of the Python repository: summary: [svn] Renamed SocketServer to 'socketserver'.
hg up -r2 abort: case-folding collision between Lib/socketserver.py and Lib/SocketServer.py
hg up -rtip abort: case-folding collision between Lib/socketserver.py and Lib/SocketServer.py
The hg repository is now totally broken. I'm not sure there is a fix for this, short of going back and manually fixing the history (and I don't know if this is possible at all using Subversion). I know it's a rare situation, but can people PLEASE be careful not to introduce case issues like this - they pollute history for ever (I still hit problems with some of the case funkiness in svn from the early 1990's!!!) Bazaar seems to be OK (ish) with this - it picks just one version to show. Paul.
2008/5/12 Paul Moore <p.f.moore@gmail.com>:
Bazaar seems to be OK (ish) with this - it picks just one version to show.
It seems to be unable to find the history using either bzr log Lib\socketserver.py or bzr log Lib\SocketServer.py, though (but bzr log seems pretty unintuitive to me, so maybe I was using it wrongly...) Paul.
Revision 63129 is not valid on case folding filesystems. In particular, this horribly breaks using hg-svn to make a local mirror of the Python repository:
That would be a bug in hg-svn, right? Yes, the revision is not valid on case-folding systems - but why should that break hg-svn? The tool should be able to represent such stuff in its repository (whatever concept of repository hg may have); it should then only fail if you also want to check out that specific revision. There is no way to remove this revision from the repository now (other than a full dump|filter|load cycle, which I would rather want to avoid).
I know it's a rare situation, but can people PLEASE be careful not to introduce case issues like this - they pollute history for ever (I still hit problems with some of the case funkiness in svn from the early 1990's!!!)
Subversion's first release was in October 2000; it wasn't self-hosting until 2001 :-) Regards, Martin
2008/5/12 "Martin v. Löwis" <martin@v.loewis.de>:
Revision 63129 is not valid on case folding filesystems. In particular, this horribly breaks using hg-svn to make a local mirror of the Python repository:
That would be a bug in hg-svn, right? Yes, the revision is not valid on case-folding systems - but why should that break hg-svn? The tool should be able to represent such stuff in its repository (whatever concept of repository hg may have); it should then only fail if you also want to check out that specific revision.
Absolutely it's a bug in hgsvn (which is a converter for svn -> hg, this isn't a bug in hg), but it's a design issue (hgsvn works by checking out each revision in turn and checking it into hg) triggered by having a svn revision which cannot be represented on a case-folsing system.
There is no way to remove this revision from the repository now (other than a full dump|filter|load cycle, which I would rather want to avoid).
OK, there's no way this is justified for such an obscure issue - all I'm really asking is that people remember case-folding systems when making changes like this.
I know it's a rare situation, but can people PLEASE be careful not to introduce case issues like this - they pollute history for ever (I still hit problems with some of the case funkiness in svn from the early 1990's!!!)
Subversion's first release was in October 2000; it wasn't self-hosting until 2001 :-)
I assume it's pre-svn history, converted from CVS. Or I'm misreading something. Whatever, it's from a long time ago :-) Paul.
2008/5/12 Paul Moore <p.f.moore@gmail.com>:
2008/5/12 "Martin v. Löwis" <martin@v.loewis.de>:
Subversion's first release was in October 2000; it wasn't self-hosting until 2001 :-)
I assume it's pre-svn history, converted from CVS. Or I'm misreading something. Whatever, it's from a long time ago :-)
Hmm, Guido's been at the time machine again :-)
svn log http://svn.python.org/projects/python/trunk | tail
r2161 | guido | 1990-08-09 15:25:15 +0100 (Thu, 09 Aug 1990) | 2 lines Initial revision ------------------------------------------------------------------------ r2160 | (no author) | 1990-08-09 15:25:15 +0100 (Thu, 09 Aug 1990) | 1 line New repository initialized by cvs2svn. ------------------------------------------------------------------------ Paul.
Hmm, Guido's been at the time machine again :-)
svn log http://svn.python.org/projects/python/trunk | tail
r2161 | guido | 1990-08-09 15:25:15 +0100 (Thu, 09 Aug 1990) | 2 lines
Initial revision
------------------------------------------------------------------------ r2160 | (no author) | 1990-08-09 15:25:15 +0100 (Thu, 09 Aug 1990) | 1 line
New repository initialized by cvs2svn. ------------------------------------------------------------------------
Actually, I will borrow the machine five years from now to create these files, after we switch back from hg to svn :-) svn log -r2158 http://svn.python.org/projects ------------------------------------------------------------------------ r2158 | bwarsaw | 2005-10-24 00:39:17 +0200 (Mo, 24 Okt 2005) | 3 lines PEP 351, the freeze protocol. ------------------------------------------------------------------------ Regards, Martin
On Mon, May 12, 2008 at 7:18 AM, Paul Moore <p.f.moore@gmail.com> wrote:
Revision 63129 is not valid on case folding filesystems. In particular, this horribly breaks using hg-svn to make a local mirror of the Python repository:
\Apps\HGsvn\hgimportsvn.exe -r 63120 http://svn.python.org/projects/python/trunk foo cd foo \apps\hgsvn\hgpullsvn hg log Lib\socketserver.py changeset: 2:e8856fdf9300 branch: trunk tag: svn.63129 user: alexandre.vassalotti date: Mon May 12 02:37:10 2008 +0100 summary: [svn] Renamed SocketServer to 'socketserver'.
hg up -r2 abort: case-folding collision between Lib/socketserver.py and Lib/SocketServer.py
hg up -rtip abort: case-folding collision between Lib/socketserver.py and Lib/SocketServer.py
The hg repository is now totally broken.
Which version of mercurial are you using? I know that versions prior 1.0 had some bug with handling case-changes on case-insensitive filesystems. -- Alexandre
2008/5/12 Alexandre Vassalotti <alexandre@peadrop.com>:
Which version of mercurial are you using? I know that versions prior 1.0 had some bug with handling case-changes on case-insensitive filesystems.
1.0. There are still case folding bugs in 1.0 - I'm working on fixing them. But there will never be a complete fix for this situation, as it's simply not possible to checkout the exact svn layout of that revision on a case-folding system, it simply can't be supported (without name mangling of files in the working directory). As I said, it's no big deal, just something people working on case-sensitive systems need to watch out for when interoperation with case-insensitive systems is important. Paul.
1.0. There are still case folding bugs in 1.0 - I'm working on fixing them. But there will never be a complete fix for this situation, as it's simply not possible to checkout the exact svn layout of that revision on a case-folding system, it simply can't be supported (without name mangling of files in the working directory).
Assuming this is NTFS, notice that it is not the file system that is case-folding, but the API. If you pass FILE_FLAGS_POSIX_SEMANTICS to the API, you can get case-sensitive behavior (to some degree, as there are bugs in that API, as well). Regards, Martin
2008/5/12 "Martin v. Löwis" <martin@v.loewis.de>:
1.0. There are still case folding bugs in 1.0 - I'm working on fixing them. But there will never be a complete fix for this situation, as it's simply not possible to checkout the exact svn layout of that revision on a case-folding system, it simply can't be supported (without name mangling of files in the working directory).
Assuming this is NTFS, notice that it is not the file system that is case-folding, but the API. If you pass FILE_FLAGS_POSIX_SEMANTICS to the API, you can get case-sensitive behavior (to some degree, as there are bugs in that API, as well).
Hmm, that's interesting information. I suspect I could easily create more bugs than I solve by using it, but it's interesting to know nevertheless. Thanks, Paul.
Hmm, that's interesting information. I suspect I could easily create more bugs than I solve by using it, but it's interesting to know nevertheless.
I've been trying to use for a few applications. The biggest short-coming is that it won't work for all cases. In particular, for the following operations I could not find a way to make them case-sensitive (as they don't accept any flags parameter): DeleteFile (apparently possible through NtDeleteFile), CreateDirectory, RemoveDirectory, FindFirstFile (and probably others as well). Regards, Martin
On Mon, May 12, 2008 at 3:40 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
When I rename a module I use "svn copy", since "svn remove" doesn't pick up changes made to the "deleted" file. For example, here is what I did for PixMapWrapper:
You want to make changes to the deleted file? Why?
The idea was to replace the orignial module file with its stub. However, the "svn copy" and edit process isn't the cause of the problems. It is the fact that 2 files existed in the same directory differing only by a case-change. Anyway, all the buildbot seems okay now. -- Alexandre
The idea was to replace the orignial module file with its stub. However, the "svn copy" and edit process isn't the cause of the problems. It is the fact that 2 files existed in the same directory differing only by a case-change.
I still don't understand. You wanted to replace the file with a stub, and then delete it? Why not just delete it (or use svn mv in the first place)? Regards, Martin
On Mon, May 12, 2008 at 9:24 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
The idea was to replace the orignial module file with its stub. However, the "svn copy" and edit process isn't the cause of the problems. It is the fact that 2 files existed in the same directory differing only by a case-change.
I still don't understand. You wanted to replace the file with a stub, and then delete it? Why not just delete it (or use svn mv in the first place)?
No. That is exactly what I wanted to avoid by using "svn copy", instead of "svn move". "svn move" mark the original file for removal. which makes it impossible to modify the original file on the same commit. Anyway, Brett updated the PEP with renaming procedure that avoids this problem completely. -- Alexandre
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 12, 2008, at 9:47 AM, Alexandre Vassalotti wrote:
On Mon, May 12, 2008 at 9:24 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
The idea was to replace the orignial module file with its stub. However, the "svn copy" and edit process isn't the cause of the problems. It is the fact that 2 files existed in the same directory differing only by a case-change.
I still don't understand. You wanted to replace the file with a stub, and then delete it? Why not just delete it (or use svn mv in the first place)?
No. That is exactly what I wanted to avoid by using "svn copy", instead of "svn move". "svn move" mark the original file for removal. which makes it impossible to modify the original file on the same commit. Anyway, Brett updated the PEP with renaming procedure that avoids this problem completely.
bzr to the rescue <wink>. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSChX5nEjvBPtnXfVAQK2NwQAgA3Gaa7Ew6uAVrqJe3B9wj/lseMuS88j y4/gtlCcb35Vtff9CpEveCD44IelaB+OFH2iG6TKXxxD47HhYfJD3STRWnphimb8 j4UXJyfJTlMIW7ISWGzv62c+RlyXle8P0VXwdfDvem8h3o8cWDBBACvlqA/6wjb0 FFQuLHedW+8= =r0hs -----END PGP SIGNATURE-----
participants (6)
-
"Martin v. Löwis" -
Alexandre Vassalotti -
Barry Warsaw -
Georg Brandl -
Oleg Broytmann -
Paul Moore