Bazaar takes issue with Windows case-insensitivity

[Bulgrien, Kevin]

Continuing the effort described in my prior e-mail titled "Checkout of branch w/ long file names to deep path fails on Windows XP"...

To review, I created a shared repository to hold Windows system configuration... namely, things like browser bookmarks, and other environmental resources that I miss when I have to work from a computer other than my regular workstation.  I made a repository called common that and branched it to a repository named after my hostname.  I put my favorite stuff in the hostname branch and pushed what I wanted to share to the common repository.

I now want to get all the goodies on another system, so I branch common to a new hostname, then make a temporary checkout of the new branch to the workstation where I want the stuff that is in the repository.  This temporary checkout was made to C:\bzr_tmp\hostname2.

As I do not know another way to do this via bzr command, I copy C:\bzr_tmp\hostname2\.bzr to C:\.bzr

When I run bzr status, indeed, all the goodies I want copied to this system are "removed".

I successfully run `bzr revert .bzrignore` and, indeed, the file appears in the file system.

I get more brave, and run ` bzr revert "Documents and Settings/kbulgrien/Desktop/vbs".

That works.  Various utilities stored there appear on the system.

Now I go for the gusto and run:

bzr revert "Documents and Settings/kbulgrien/Favorites"

bzr: ERROR: bzrlib.errors.MalformedTransform: Tree transform is malformed [('ove
rwrite', 'new-17', u'GForge Welcome.url.moved')]

Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 920, in exception_to_return_code
  File "bzrlib\commands.pyo", line 1131, in run_bzr
  File "bzrlib\commands.pyo", line 673, in run_argv_aliases
  File "bzrlib\commands.pyo", line 695, in run
  File "bzrlib\cleanup.pyo", line 136, in run_simple
  File "bzrlib\cleanup.pyo", line 166, in _do_with_cleanups
  File "bzrlib\builtins.pyo", line 4798, in run
  File "bzrlib\builtins.pyo", line 4804, in _revert_tree_to_revision
  File "bzrlib\mutabletree.pyo", line 52, in tree_write_locked
  File "bzrlib\workingtree.pyo", line 1332, in revert
  File "bzrlib\transform.pyo", line 2855, in revert
  File "bzrlib\transform.pyo", line 2887, in _prepare_revert_transform
  File "bzrlib\transform.pyo", line 3033, in resolve_conflicts
MalformedTransform: Tree transform is malformed [('overwrite', 'new-17', u'GForg
e Welcome.url.moved')]

bzr 2.5.1 on python 2.6.6 (Windows-XP-5.1.2600-SP3)
arguments: ['c:\\Program Files\\Bazaar\\bzr.exe', 'revert', 'Documents and
    Settings/kbulgrien/Favorites']
plugins: bzrtools[2.5.0], changelog_merge[2.5.1], colo[0.4.0],
    explorer[1.2.2], fastimport[0.14.0dev], git[0.6.8], launchpad[2.5.1],
    loom[2.3.0dev], netrc_credential_store[2.5.1], news_merge[2.5.1],
    pipeline[1.4.0], qbzr[0.22.3], rewrite[0.6.4dev], svn[1.2.2],
    upload[1.2.0dev], xmloutput[0.8.8]
encoding: 'cp1252', fsenc: 'mbcs', lang: None

*** Bazaar has encountered an internal error.  This probably indicates a
    bug in Bazaar.  You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/bzr/+filebug
    including this traceback and a description of the problem.

Bazaar is re-populating my browser bookmarks.  Before I got this idea of saving bookmarks in a Bazaar repository so I could reference them from anywhere, I had already manually set up a bookmark called "gforge Welcome" that mapped to a file called "gforge Welcome.url" in the file system.

In the repository, the bookmark is the same except that some case has changed:

Documents and Settings/kbulgrien/Favorites/GForge Welcome.url

Apparently Bazaar is unable to handle this situation.  I'm not sure what I would expect, but I certainly did not expect to have Bazaar bail out entirely.  Nothing at all was reverted.  Now of course I realize that to work around this, I need to remove my local bookmark and retry... Once I do that, all my bookmarks appear as I expected.

Maybe that's "ok".  Maybe its sub-optimal behavior to fail so completely over a single file that has case issues on Windows.  I'm not sure, but it seems there could have been a better way to fail... along the lines of explaining that it is a case issue rather than aborting with an "internal error".

Should I really follow the suggestion and file a bug report?  Opinions?


________________________________
This message and/or attachments may include information subject to GD Corporate Policy 07-105 and is intended to be accessed only by authorized personnel of General Dynamics and approved service providers. Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties. Recipients should refer to the policies or contract to determine proper handling. Unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender and destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20120822/066769fc/attachment.html>