Bazaar

Bug #248333
Comment #1

Comment 1 for bug 248333

Revision history for this message

Vernon Cole (vernondcole) wrote on 2010-01-09:

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~bazaar1~karmic from Launchpad
  Bazaar (bzr) 2.0.3
    Python interpreter: /usr/bin/python 2.6.4
    Python standard library: /usr/lib/python2.6
    Platform: Linux-2.6.31-17-generic-i686-with-Ubuntu-9.10-karmic
    bzrlib: /usr/lib/python2.6/dist-packages/bzrlib
    Bazaar configuration: /home/vernon/.bazaar
    Bazaar log file: /home/vernon/.bzr.log
… under Windows – bzr-2.0.3-2 from the setup.exe on Launchpad.
  Bazaar (bzr) 2.0.3
    Python interpreter: C:\Program Files\Bazaar\python25.dll 2.5.4
    Python standard library: C:\Program Files\Bazaar\lib\library.zip
    Platform: Windows-Vista-6.0.6002-SP2
    bzrlib: C:\Program Files\Bazaar\lib\library.zip\bzrlib
    Bazaar configuration: C:\Users\vernon\AppData\Roaming\bazaar\2.0
    Bazaar log file: C:\Users\vernon\Documents\.bzr.log
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.6.28-16-server-i686-with-Ubuntu-9.04-jaunty
    bzrlib: /usr/lib/python2.6/dist-packages/bzrlib
    Bazaar configuration: /home/vernon/.bazaar
    Bazaar log file: /home/vernon/.bzr.log
All systems are intertwined using SSH.

vernon@ubuntu:/host/BZR/sterling$ ls -al
  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@ubuntu:/host/BZR/sterling$ ls -al anc/
  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@ubuntu:/host/BZR/sterling$ bzr version-info
  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@ubuntu:/host/BZR/sterling$ bzr status
  modified:
    .bzrignore*
    DRG/7C.CSN*
    DRG/7CCNN.PY*
    DRG/7c.txt*
    DRG/7x.CCE*
    HL7/ADT.FCT*
    HL7/ADT.FFT*
    HL7/ADTCTRL.DSC*
<etc for every file in the tree>

Now boot the workstation back into Windows....

C:\BZR\sterling>bzr version-info
  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\sterling>bzr status
  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\sterling>bzr remove-tree
bzr: ERROR: Working tree "C:/BZR/sterling/" has uncommitted changes (See bzr status).

  C:\BZR\sterling>bzr remove-tree --force
  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\sterling>bzr status
bzr: ERROR: No WorkingTree exists for "file:///C:/BZR/sterling/.bzr/checkout/".

C:\BZR\sterling>bzr checkout
Conflict adding file ga/GA.CMT. Moved existing file to ga/GA.CMT.moved.

  C:\BZR\sterling>bzr status
  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

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~bazaar1~karmic from Launchpad
		Bazaar (bzr) 2.0.3 
  		Python interpreter: /usr/bin/python 2.6.4 
  		Python standard library: /usr/lib/python2.6 
  		Platform: Linux-2.6.31-17-generic-i686-with-Ubuntu-9.10-karmic 
  		bzrlib: /usr/lib/python2.6/dist-packages/bzrlib 
  		Bazaar configuration: /home/vernon/.bazaar 
  		Bazaar log file: /home/vernon/.bzr.log 
	… under Windows – bzr-2.0.3-2 from the setup.exe on Launchpad.
		Bazaar (bzr) 2.0.3
		  Python interpreter: C:\Program Files\Bazaar\python25.dll 2.5.4
		  Python standard library: C:\Program Files\Bazaar\lib\library.zip
		  Platform: Windows-Vista-6.0.6002-SP2
		  bzrlib: C:\Program Files\Bazaar\lib\library.zip\bzrlib
		  Bazaar configuration: C:\Users\vernon\AppData\Roaming\bazaar\2.0
		  Bazaar log file: C:\Users\vernon\Documents\.bzr.log
	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.6.28-16-server-i686-with-Ubuntu-9.04-jaunty 
 		 bzrlib: /usr/lib/python2.6/dist-packages/bzrlib 
 		 Bazaar configuration: /home/vernon/.bazaar 
 		 Bazaar log file: /home/vernon/.bzr.log 
	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@ubuntu:/host/BZR/sterling$ pwd 
  /host/BZR/sterling 
 
 vernon@ubuntu:/host/BZR/sterling$ ls -al 
  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@ubuntu:/host/BZR/sterling$ ls -al anc/ 
  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@ubuntu:/host/BZR/sterling$ bzr version-info 
  revision-id: vernondcole@gmail.com-20100108070340-kn1iyx8g4nue4jl8 
  date: 2010-01-08 00:03:40 -0700 
  build-date: 2010-01-08 15:24:18 -0700 
  revno: 163 
  branch-nick: sterling

Now boot the workstation back into Windows....
 
 C:\BZR\sterling>bzr version-info
  revision-id: vernondcole@gmail.com-20100108070340-kn1iyx8g4nue4jl8
  date: 2010-01-08 00:03:40 -0700
  build-date: 2010-01-08 16:10:34 -0700
  revno: 163
  branch-nick: sterling

C:\BZR\sterling>bzr status
  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\sterling>bzr remove-tree
  bzr: ERROR: Working tree "C:/BZR/sterling/" has uncommitted changes (See bzr status).

C:\BZR\sterling>bzr remove-tree --force
  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\sterling>bzr status
  bzr: ERROR: No WorkingTree exists for "file:///C:/BZR/sterling/.bzr/checkout/".

C:\BZR\sterling>bzr checkout
  Conflict adding file ga/GA.CMT.  Moved existing file to ga/GA.CMT.moved.

C:\BZR\sterling>bzr status
  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