© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
The "obvious workaround" suggested above does not work -- because this bug "poisons" a windows implementation as well.
I spent the entire morning writing this up as a new bug -- and I am going to include the whole document I created here. Post it near the water cooler -- it's good for a chuckle.
--
Vernon Cole
v v v v v v
I have to write this up as a bug report, because there is no other way to correctly document it. Will it ever be “fixed?” Probably not. In fact, by the time you get to the end of this document, you may add a new priority for bug fixes – lower than “Low.” Perhaps you should call it “Are You Kidding?”
There is an old joke about the guy who goes in to his doctor, complaining about a pain when he performs some very unnatural action. The doctor's advice is: “well, don't DO that!”
But then the doctor just HAS to ask what brought about the situation, and the story comes out. This is like that. I can't help myself. I am an eccentric geek. We do this sort of thing. I also wrote a Python class implementing PEP 313 (also known as PEP CCCXIII) and published it on Launchpad. I can't help myself, it just HAPPENS!
In reality, this is praise – not a complaint. If it were not for the countless hours spent by dedicated FOSS software engineers, I would never have been able to get into this situation. My situation is a result of the resounding success you have achieved in creating cross-platform software. Well done!
So before you read on, get up, take a break, go to the rest room, and get a fresh Coke on the way back to your desk. Then proceed.
- - - - - - - - - - - - - - - - - - - - -
The situation and the guilty parties and components:...
Me:
I first started going crazy when employed by John Fluke (the company) in Washington state. John Fluke (Junior -- the person) had the idea that Test Engineers would be more efficient if they had a better language in which to express their design of programs for Automatic Test Equipment. A young electrical engineer came up with the idea of a table of test steps and responses, and wrote a program to implement the idea in RSTS/E BASIC+ which he called Test Table Interpreter. This would have been around 1977. I was given the job of re-implementing Test Table Interpreter, first on FORTRAN IV on an RSX-11M system, and then in assembly language on a Zilog Z80 running in a Fluke 8500 voltmeter chassis. A goodly portion of the factory was soon using TTI test programs. I have been fascinated by the idea of cross platform software, and table driven programming, ever since.
Fast Forward … 1981 – Portland, Oregon … I became aware of a small software house who was creating a new method of producing Data Processing systems using table driven software. Their system, called RDM, was written in Oregon Software Pascal, and ran on RT-11 and RSTS/E. It used a new idea called a relational database. I took the job of porting their code to RSX-11M and then VAX/VMS Pascal.
Fast Forward … 1991 – Orem, Utah … My sister came to me with a problem. And accounting system she supported, written in Data General Business Basic, was dieing due to lack of hardware. It was too complex, she said, to re-write for an IBM PC. Ahah! I replied: “RDM has now been ported to MS DOS and Novell networking – I can rewrite it for you in RDM in less than a year.” We formed a partnership.
Fast Forward … yesterday – Wendover, Nevada … I am working on an update to the RDM financial system, which is now maintained in a Bazaar tree. I need a printer, and can't print using Vista (see below) so I am running my laptop (see below) on Ubuntu Linux. RDM (now a 32 bit Windows version) is running on Linux under Wine – surprisingly well I might add.
The local computer:
A Dell Vostro Laptop running Windows Vista Home Basic (or whatever it is called this week.) Patch level current via automatic update. Dual boot with Ubuntu 9.10 (karmic) at current patch level.
Ubuntu is installed on the stock Dell Vista NTFS partition using a loop install. (Handy when you can't find a Vista driver for a two year old inkjet – and it boots up so much faster.)
The remote computer:
An old generic system composed of scrounged parts. It is running Ubuntu 9.04 server.
The Bazaar setup:
On the laptop under Ubuntu – 2.0.3-1~
Bazaar (bzr) 2.0.3
Python interpreter: /usr/bin/python 2.6.4
Python standard library: /usr/lib/python2.6
Platform: Linux-2.
bzrlib: /usr/lib/
Bazaar configuration: /home/vernon/
Bazaar log file: /home/vernon/
… under Windows – bzr-2.0.3-2 from the setup.exe on Launchpad.
Bazaar (bzr) 2.0.3
Python interpreter: C:\Program Files\Bazaar\
Python standard library: C:\Program Files\Bazaar\
Platform: Windows-
bzrlib: C:\Program Files\Bazaar\
Bazaar configuration: C:\Users\
Bazaar log file: C:\Users\
On the server:Bazaar (bzr) 2.0.3
Python interpreter: /usr/bin/python 2.6.2
Python standard library: /usr/lib/python2.6
Platform: Linux-2.
bzrlib: /usr/lib/
Bazaar configuration: /home/vernon/
Bazaar log file: /home/vernon/
All systems are intertwined using SSH.
The weird twist:
The bazaar tree is on the NTFS volume, accessed from the loop file system as /host. This means that every file seems to have execute permission, due to the way NTSF works on Linux.
vernon@
/host/
vernon@
total 285
drwxrwxrwx 1 root root 4096 2010-01-07 23:56 .
drwxrwxrwx 1 root root 4096 2009-12-31 15:21 ..
drwxrwxrwx 1 root root 0 2009-03-12 11:17 anc
drwxrwxrwx 1 root root 4096 2009-03-12 11:17 .bzr
-rwxrwxrwx 2 root root 116 2010-01-07 23:56 .bzrignore
drwxrwxrwx 1 root root 32768 2009-06-23 12:57 cu
<etc>
vernon@
total 44
drwxrwxrwx 1 root root 0 2009-03-12 11:17 .
drwxrwxrwx 1 root root 4096 2010-01-07 23:56 ..
-rwxrwxrwx 1 root root 32256 2009-03-12 11:17 lgn.cmt
-rwxrwxrwx 1 root root 5120 2009-03-12 11:17 lgn.MNU
vernon@
revision-id: <email address hidden>
date: 2010-01-08 00:03:40 -0700
build-date: 2010-01-08 15:24:18 -0700
revno: 163
branch-nick: sterling
So, therefore, when you check the status you get:
vernon@
modified:
.bzrignore*
DRG/7C.CSN*
DRG/7CCNN.PY*
DRG/7c.txt*
DRG/7x.CCE*
HL7/ADT.FCT*
HL7/ADT.FFT*
HL7/
<etc for every file in the tree>
Now boot the workstation back into Windows....
C:\BZR\
revision-id: <email address hidden>
date: 2010-01-08 00:03:40 -0700
build-date: 2010-01-08 16:10:34 -0700
revno: 163
branch-nick: sterling
C:\BZR\
modified:
.bzrignore*
DRG/7C.CSN*
DRG/7CCNN.PY*
DRG/7c.txt*
DRG/7x.CCE*
HL7/ADT.FCT*
HL7/ADT.FFT*
<and so forth – every file in the tree>
Which is, of course, impossible, because Windows does not have an executable status. I made the error of committing and pushing. It was late, okay? This took some time to figure out what happened and how to recover.
The shortest recovery method that seems to work:
(Running under Windows)
C:\BZR\
bzr: ERROR: Working tree "C:/BZR/sterling/" has uncommitted changes (See bzr status).
C:\BZR\
Conflict: can't delete HL7 because it is not empty. Not deleting.
Conflict: can't delete Verns-CU because it is not empty. Not deleting.
Conflict: can't delete docs because it is not empty. Not deleting.
Conflict: can't delete ga because it is not empty. Not deleting.
Conflict: can't delete med because it is not empty. Not deleting.
C:\BZR\
bzr: ERROR: No WorkingTree exists for "file:/
C:\BZR\
Conflict adding file ga/GA.CMT. Moved existing file to ga/GA.CMT.moved.
C:\BZR\
unknown:
x
ga/GA.CMT.moved
conflicts:
Conflict adding file ga/GA.CMT. Moved existing file to ga/GA.CMT.moved.
The two files it complained about I had actually been using, so the conflict is genuine. – All fixed.
Why this whole thing really is meaningful....
BDFL has decided to use mercurial as the new DVCS for Python.
Mark Hammond followed that decision for pywin32.
Hg on Windows seems to have a strange interaction with wxPython – and I had to remove it.
I want to use bzr-hg to get the sources for pywin32 – since I am a developer.
Bzr-hg only works on Linux (at this time).
… but if I use Linux Bazaar on NTFS...
Thanks, again, for all your great work!
–
Vernon