Re: [Python-Dev] Buildbots have trouble checking out the repository due to recent changes.
On Sun, May 11, 2008 at 5:44 PM, Paul Moore <p.f.moore@gmail.com> wrote:
2008/5/11 Alexandre Vassalotti <alexandre@peadrop.com>:
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
That seems a very odd usage. You're renaming, not copying. Why aren't you using svn rename (svn move)? I can well imagine this causing serious confusion.
I 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:
Oops, I meant "svn rename" when I said "svn remove". As I said, if I use "svn rename" I cannot make changes to the file being renamed.
Please be very careful here - if you introduce revisions which contain multiple files with names that differ only in case, you're going to really mess up history (and probably the only clean way to fix this will be to actually go back and edit the history).
Oh, you are right. I totally forgot about case-insensible filesystems. This is really going to make such case-change renamings nasty. -- Alexandre
On Sun, May 11, 2008 at 3:16 PM, Alexandre Vassalotti <alexandre@peadrop.com> wrote:
On Sun, May 11, 2008 at 5:44 PM, Paul Moore <p.f.moore@gmail.com> wrote:
2008/5/11 Alexandre Vassalotti <alexandre@peadrop.com>:
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
That seems a very odd usage. You're renaming, not copying. Why aren't you using svn rename (svn move)? I can well imagine this causing serious confusion.
I 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:
Oops, I meant "svn rename" when I said "svn remove". As I said, if I use "svn rename" I cannot make changes to the file being renamed.
Please be very careful here - if you introduce revisions which contain multiple files with names that differ only in case, you're going to really mess up history (and probably the only clean way to fix this will be to actually go back and edit the history).
Oh, you are right. I totally forgot about case-insensible filesystems. This is really going to make such case-change renamings nasty.
The PEP specifies the lib-old directory to hold the old case name so that the svn rename won't lead to two files in the same directory. I was hoping that creating the stub in lib-old would allow a simple ``svn rename`` for the original module on a case-sensitive file-system and the case-insensitive file-systems would just be able to deal with it. Is that just not going to work? Oh, and I am really sorry, Alexandre, but the PixMapWrapper rename should have been taken out of the PEP as the entire Mac directory is going away, so the rename is kind of pointless since the module is going to be deleted. -Brett
On Sun, May 11, 2008 at 6:31 PM, Brett Cannon <brett@python.org> wrote:
The PEP specifies the lib-old directory to hold the old case name so that the svn rename won't lead to two files in the same directory. I was hoping that creating the stub in lib-old would allow a simple ``svn rename`` for the original module on a case-sensitive file-system and the case-insensitive file-systems would just be able to deal with it. Is that just not going to work?
Oh, and I am really sorry, Alexandre, but the PixMapWrapper rename should have been taken out of the PEP as the entire Mac directory is going away, so the rename is kind of pointless since the module is going to be deleted.
Well, I guess I really messed up on that one. So, do you have any idea on how to revert the changes? -- Alexandre
On Sun, May 11, 2008 at 3:38 PM, Alexandre Vassalotti <alexandre@peadrop.com> wrote:
On Sun, May 11, 2008 at 6:31 PM, Brett Cannon <brett@python.org> wrote:
The PEP specifies the lib-old directory to hold the old case name so that the svn rename won't lead to two files in the same directory. I was hoping that creating the stub in lib-old would allow a simple ``svn rename`` for the original module on a case-sensitive file-system and the case-insensitive file-systems would just be able to deal with it. Is that just not going to work?
Oh, and I am really sorry, Alexandre, but the PixMapWrapper rename should have been taken out of the PEP as the entire Mac directory is going away, so the rename is kind of pointless since the module is going to be deleted.
Well, I guess I really messed up on that one.
Eh, how were you to know? It's something I sometimes forget on my Mac since it is case-preserving but case-insensitive. Hopefully the lib-old trick will solve the problem as PixMapWrapper was the only one that is in any form of a package and that module is no longer an issue.
So, do you have any idea on how to revert the changes?
See if having you move Queue.py into lib-old fixes things. Otherwise the patch will need to be reverted. I am on GTalk right now so you can IM me as soon as you have tried if you want and I can see if it fixes the problem on OS X. -Brett
Well, I guess I really messed up on that one. So, do you have any idea on how to revert the changes?
If the changes where in a single revision N, do svn merge -rN:N-1 . svn commit -m "revert rN" If they span over several subsequent revisions, use N-k instead. If they span over several revisions with intermediate revisions that you don't want to revert, try multiple merge commands before a single commit; if that fails, revert and commit each range of changes separately. Regards, Martin P.S. If you want to get the buildbots back in shape (in case they aren't), build a non-existing branch through the UI (which will cause a recursive removal of the entire checkout), then either wait for the next regular commit, or force a build of the respective branch (branches/py3k or trunk). On Windows, if there is still a python.exe process holding onto its binary, that fails, and we need support from the slave admin.
On Mon, May 12, 2008 at 3:49 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Well, I guess I really messed up on that one. So, do you have any idea on how to revert the changes?
If the changes where in a single revision N, do
svn merge -rN:N-1 . svn commit -m "revert rN"
If they span over several subsequent revisions, use N-k instead. If they span over several revisions with intermediate revisions that you don't want to revert, try multiple merge commands before a single commit; if that fails, revert and commit each range of changes separately.
Yes. That is exactly what I did to revert the changes.
P.S. If you want to get the buildbots back in shape (in case they aren't), build a non-existing branch through the UI (which will cause a recursive removal of the entire checkout), then either wait for the next regular commit, or force a build of the respective branch (branches/py3k or trunk). On Windows, if there is still a python.exe process holding onto its binary, that fails, and we need support from the slave admin.
Thanks for the tip. Now, I just hope that I will never have to use it. ;-) -- Alexandre
participants (3)
-
"Martin v. Löwis" -
Alexandre Vassalotti -
Brett Cannon