Can't merge a directory deletion in a wt with a pending subdirectory deletion

Bug #632704 reported by RayH
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
High
Unassigned

Bug Description

All of the clients were running version 1.10. repository server is Ubuntu Linux also was running 1.10. Development Clients are Windows XP and server 2003.

I have about 14 active repositories of various sizes for a project. They're all pretty simple structures with no branching.

The repositories were all OK. Now moved today to version 2.2.0 on both client and server

Whilst updating one copy of the repository on a client I got an error. All others were OK.
This particular repository contains large binary files where we store 3rd party sources for installing.

I've searched the bug database and can't find this one.

Text of the bzr update is:
Connected (version 2.0, client OpenSSH_4.7p1)
Authentication (publickey) successful!
Secsh channel 1 opened.
{Preparing for file merge x/1091}
{pass X flashes up and disappears}
bzr: ERROR: Tree transform is malformed [('unversioned parent', 'new-141'), ('versioning no contents', 'new-162')]

bzr check on the client gives NO errors on the local (outdated) repository

C:\nms\xxxx\bin>bzr check
Checking working tree at 'C:/nms/xxxx/bin'.
Checking branch at 'file:///C:/nms/xxxx/bin/'.
Checking repository at 'file:///C:/nms/xxxx/bin/'.
checked repository file:///C:/nms/xxxx/bin/ format RepositoryFormatKnitPack1()

     2 revisions
  1090 file-ids
checked branch file:///C:/nms/xxxx/bin/ format Branch format 6

C:\nms\xxxx\bin>

Checking the repository on the server also gives 0 errors. NB the bzr repository server has NO working tree: it is purely a repository.

bzr@xxxx01:~/gnms-xxxx-bin$ bzr check
Checking branch at 'file:///home/bzr/gnms-xxxx-bin/trunk/'.
No working tree found at specified location.
Checking repository at 'file:///home/bzr/gnms-xxxx-bin/'.
checked repository file:///home/bzr/gnms-xxxx-bin/ format RepositoryFormatKnitPack1()
     2 revisions
  1090 file-ids
checked branch file:///home/bzr/gnms-xxxx-bin/trunk/ format Branch format 6
bzr@globis01:~/gnms-globis-bin$

Any advice???

It would be possible to recreate this repository from scratch but it doesn't build confidence in the development team.

bzr status lists a whole load of files that need updating {I can attach this if it helps}
They are indeed files that were updated on another client and commited to the repository (with 0 errors)

Revision history for this message
RayH (ray-hunter) wrote :

Just found the traceback log file. You'll want this too obviously.

Tue 2010-09-07 23:05:56 +0200
0.140 bazaar version: 2.2.0
0.140 bzr arguments: [u'update']
0.156 looking for plugins in C:/Documents and Settings/Administrator/Application Data/bazaar/2.0/plugins
0.156 looking for plugins in C:/Program Files/Bazaar/plugins
0.359 encoding stdout as sys.stdout encoding 'cp437'
0.390 opening working tree 'C:/nms/xxxx/bin'
0.500 bzr-svn: using Subversion 1.6.6 ()
0.687 falling back to default implementation
0.687 failed to load system host keys: [Errno 2] No such file or directory: 'C:\\Documents and Settings\\Administrator/.ssh/known_hosts'
[ 5300] 2010-09-07 23:05:57.249 INFO: Connected (version 2.0, client OpenSSH_4.7p1)
1.031 Trying SSH agent key AEE90FEE030A2B04B37D01EE7568889F
[ 5300] 2010-09-07 23:05:57.624 INFO: Authentication (publickey) successful!
[ 5300] 2010-09-07 23:05:57.687 INFO: Secsh channel 1 opened.
2.171 Using fetch logic to copy between RemoteRepository(bzr+ssh://<email address hidden>:1022///home/bzr/gnms-xxxx-bin/.bzr/)(RemoteRepositoryFormat(_network_name='Bazaar pack repository format 1 (needs bzr 0.92)\n')) and KnitPackRepository('file:///C:/nms/xxxx/bin/.bzr/repository/')(RepositoryFormatKnitPack1())
2.171 fetch up to rev {commissioning@nlvhtcsemims119-20100901110637-5oxlpt60ew8bp9g0}
70.625 Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 911, in exception_to_return_code
  File "bzrlib\commands.pyo", line 1111, in run_bzr
  File "bzrlib\commands.pyo", line 689, in run_argv_aliases
  File "bzrlib\commands.pyo", line 704, in run
  File "bzrlib\cleanup.pyo", line 135, in run_simple
  File "bzrlib\cleanup.pyo", line 165, in _do_with_cleanups
  File "bzrlib\builtins.pyo", line 1440, in run
  File "bzrlib\workingtree.pyo", line 2257, in update
  File "bzrlib\mutabletree.pyo", line 49, in tree_write_locked
  File "bzrlib\workingtree.pyo", line 2325, in _update_tree
  File "bzrlib\merge.pyo", line 1968, in merge_inner
  File "bzrlib\merge.pyo", line 704, in do_merge
  File "bzrlib\cleanup.pyo", line 135, in run_simple
  File "bzrlib\cleanup.pyo", line 165, in _do_with_cleanups
  File "bzrlib\merge.pyo", line 675, in _do_merge_to
  File "bzrlib\merge.pyo", line 814, in do_merge
  File "bzrlib\cleanup.pyo", line 131, in run
  File "bzrlib\cleanup.pyo", line 165, in _do_with_cleanups
  File "bzrlib\merge.pyo", line 819, in _do_merge
  File "bzrlib\merge.pyo", line 865, in _compute_transform
  File "bzrlib\merge.pyo", line 875, in _finish_computing_transform
  File "bzrlib\transform.pyo", line 2805, in resolve_conflicts
MalformedTransform: Tree transform is malformed [('unversioned parent', 'new-141'), ('versioning no contents', 'new-162')]

70.625 Transferred: 4kB (0.1kB/s r:2kB w:2kB)
70.625 return code 3

Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 632704] Re: After upgrading from 1.10 to 2.2.0 I get "unversioned parent" on one particular repository

Hi,

It might help if you keep a snapshot of the checkout affected by this.
 As a workaround, if you just make a new checkout you should be ok.

--
Martin

Revision history for this message
RayH (ray-hunter) wrote : Re: After upgrading from 1.10 to 2.2.0 I get "unversioned parent" on one particular repository

Thankyou for your suggestion. I have kept a local copy of the server repostory and the local branch for any future debugging and recreated the repository (minus any version info of course)

I achieved this by doing the following (for future reference if anyone else hits this problem)

on the Linux repository server

# move corrupted repo out of the way
bzr@xxxx01:~$ mv gnms-xxxx-bin gnms-xxxx-bin-safe

# create a new clean repo
bzr@xxxx01:~$ ./repo.bash gnms-xxxx-bin

the contents of the repository creation repo.bash script are:

#!/bin/sh
if [$1 = ""] ; then
  echo Must have arg name of directory
  exit
fi
echo creating top level repo $1

/usr/bin/bzr init-repo /home/bzr/$1 --no-trees
cd /home/bzr/$1

echo initing next level repo trunk

# create a clean branch
/usr/bin/bzr init trunk

cd /home/bzr
chown -R :xxxx $1
find $1 -type d -print0| xargs -0 echo "changing directories"
find $1 -type d -print0| xargs -0 chmod 2775
find $1 -type d -print0| xargs -0 echo "changing files"
find $1 -type f -print0 | xargs -0 chmod 664

on local client machine

de-install old version of bzr
install new version of bzr

make a safe copy of your_branch on the local machine somewhere else outside of the version control directories

cd your_branch

  Make a note of the binding for the checkout of your branch: depends on machine location so look in .bzr/branch/branch.conf
  The file should contain a line "bound_location = blah blah"
  Make a note of this e.g.
  bzr+ssh://<email address hidden>:10xx///home/bzr/gnms-xxxx-bin/trunk/
  bzr://127.0.0.1/gnms-xxxx-bin/trunk/

#unbind existing repo
bzr unbind

# stop this being a branch
manually move .bzr folder out of root directory to somewhere else (keep a copy for future debugging)

check contents of .bzrignore
should be something like

*.bak
*/blib/*
blib
*.pid
*.log

# create a new clean repository in original code directory
# this will create a new clean .bzr directory
bzr init

# bind it to the new clean version on the server using the binding "blah blah" that you noted earlier
bzr bind bzr://127.0.0.1/gnms-xxxx-bin/trunk

# set who you are for info
bzr whoami "RayH <RayH@xxxx>"

# check what will be added: alter .bzrignore if unhappy
bzr add --dry-run|more

# really add it
bzr add

# commit the changes
bzr commit -m "clean commit of branch"

check everything is still OK

Revision history for this message
Vincent Ladeuil (vila) wrote :

So, the checkout where the 'bzr update' failed should still be able to run a 'bzr status' successfully.

Could you confirm there are changes there ? Presumably, some removal of a directory or file that would need to be updated leading to an unusual conflict.

Sorry for the vagueness, but 'Malformed Transform' generally indicates a bug in place where displaying the *paths* involved is tricky (and I can't deduce them from the traceback alone).

Changed in bzr:
status: New → Incomplete
Revision history for this message
RayH (ray-hunter) wrote :
Download full text (23.4 KiB)

I'm not sure I can 100% confirm what changes were made where: that's why we use a version control system :)

There were probably changes on the development 2 machine (I was testing install scripts and may have also changed the install location to keep this directory a bit cleaner)

There were definitely changes made on the remote development machine 1: a new version of a program was installed manually, also for testing.

These changes made on machine 1 were successfully committed to the repository.
On the repository: there's no working tree so you can't see anything with bzr status.

At the end that was 'broken' = development machine 2, I get.

C:\gnms\bin-safe>bzr info
Standalone tree (format: pack-0.92)
Location:
  branch root: .

C:\gnms\bin-safe>bzr status >c:\bzr_status.txt
working tree is out of date, run 'bzr update'

The contents from stdout show that nmap and snmp (both 3rd party binaries) seem to be out of synch with the repository:

removed:
  CHANGELOG
  COPYING
  Cfg.ini
  Help.chm
  Nmap/
  Nmap/3.01alpha-WinPcap.exe
  Nmap/CHANGELOG
  Nmap/COPYING
  Nmap/README-WIN32
  Nmap/Uninstall.exe
  Nmap/WinPcap_3_0.exe
  Nmap/icon1.ico
  Nmap/nmap-3.75/
  Nmap/nmap-3.75/CHANGELOG
  Nmap/nmap-3.75/COPYING
  Nmap/nmap-3.75/README-WIN32
  Nmap/nmap-3.75/nmap-mac-prefixes
  Nmap/nmap-3.75/nmap-os-fingerprints
  Nmap/nmap-3.75/nmap-protocols
  Nmap/nmap-3.75/nmap-rpc
  Nmap/nmap-3.75/nmap-service-probes
  Nmap/nmap-3.75/nmap-services
  Nmap/nmap-3.75/nmap_performance.reg
  Nmap/nmap-mac-prefixes
  Nmap/nmap-os-db
  Nmap/nmap-protocols
  Nmap/nmap-rpc
  Nmap/nmap-service-probes
  Nmap/nmap-services
  Nmap/nmap.exe
  Nmap/nmap.xsl
  Nmap/nmap_performance.reg
  Nmap/nselib/
  Nmap/nselib-bin/
  Nmap/nselib-bin/bit.dll
  Nmap/nselib/ipOps.lua
  Nmap/nselib/listop.lua
  Nmap/nselib/match.lua
  Nmap/nselib/packet.lua
  Nmap/nselib/shortport.lua
  Nmap/nselib/stdnse.lua
  Nmap/nselib/strbuf.lua
  Nmap/nselib/url.lua
  Nmap/scripts/
  Nmap/scripts/HTTPAuth.nse
  Nmap/scripts/HTTP_open_proxy.nse
  Nmap/scripts/HTTPpasswd.nse
  Nmap/scripts/HTTPtrace.nse
  Nmap/scripts/MSSQLm.nse
  Nmap/scripts/MySQLinfo.nse
  Nmap/scripts/PPTPversion.nse
  Nmap/scripts/RealVNC_auth_bypass.nse
  Nmap/scripts/SMTP_openrelay_test.nse
  Nmap/scripts/SMTPcommands.nse
  Nmap/scripts/SNMPsysdesr.nse
  Nmap/scripts/SQLInject.nse
  Nmap/scripts/SSHv1-support.nse
  Nmap/scripts/SSLv2-support.nse
  Nmap/scripts/UPnP-info.nse
  Nmap/scripts/anonFTP.nse
  Nmap/scripts/bruteTelnet.nse
  Nmap/scripts/chargenTest.nse
  Nmap/scripts/daytimeTest.nse
  Nmap/scripts/dns-test-open-recursion.nse
  Nmap/scripts/echoTest.nse
  Nmap/scripts/finger.nse
  Nmap/scripts/ftpbounce.nse
  Nmap/scripts/iax2Detect.nse
  Nmap/scripts/ircServerInfo.nse
  Nmap/scripts/ircZombieTest.nse
  Nmap/scripts/kibuvDetection.nse
  Nmap/scripts/mswindowsShell.nse
  Nmap/scripts/nbstat.nse
  Nmap/scripts/netbios-smb-os-discovery.nse
  Nmap/scripts/promiscuous.nse
  Nmap/scripts/ripeQuery.nse
  Nmap/scripts/robots.nse
  Nmap/scripts/rpcinfo.nse
  Nmap/scripts/script.db
  Nmap/scripts/showHTMLTitle.nse
  Nmap/scripts/showHTTPVersion.nse
  Nmap/scripts/showOwner.nse
  Nmap/scripts/showSMTPVersion.nse
  Nmap/scripts/s...

Revision history for this message
Vincent Ladeuil (vila) wrote :

 > Does this information help you?

Yes. But not enough to translate new-141 and new-162 into paths :-/

> The contents from stdout show that nmap and snmp (both 3rd party binaries) seem to be out of synch with the repository:

Well, no. 'bzr st' reports about changes between your working tree and the revision its basis revision. It does not report about the changes
between this revision and master branch on the server. 'bzr missing' can tell us that.

'bzr missing -v' will tells us what changes 'bzr update' fails to bring in, if they are files or directories modified on one side and deleted on the other we may be able to guess which combination is failing and try to reproduce the problem.

Now your working tree contains *a lot* of uncommitted changes so 'bzr update' has even more work to do, to work around the problem, I'd commit first and *then* do the update, or shelve/update/unshelve maybe...

Revision history for this message
RayH (ray-hunter) wrote :

Thanks for the concern but we have recreated these repositories from scratch: there's no lost production data. There's also only the one revision difference between the corrupted client working tree (rev 2) and the repository (rev 3).

The debug is from the (corrupted) working tree and the repository that I saved for debugging only.

I'm more concerned about avoiding this situation again in the future (for myself and other bzr users)

Is it even possible to force a commit from a working tree that was originally rev 2 and then had some changes made, to a shared repository that is already happily updated at rev 3, without doing a bzr update of the rev 2 working tree first?

BTW we've moved on to bzr 2.2.0 in the meantime (the repository formats have not been updated). The error persists.

Here's the debug:

C:\gnms\bin-safe>bzr missing -v bzr+ssh://<email address hidden>:xxxx///home/bzr/gnms-xxxx-bin-safe/trunk/
Connected (version 2.0, client OpenSSH_4.7p1)
Authentication (publickey) successful!
Secsh channel 1 opened.
Branches are up to date.

C:\gnms\bin-safe>bzr update
Connected (version 2.0, client OpenSSH_4.7p1)
Authentication (publickey) successful!
Secsh channel 1 opened.
bzr: ERROR: Tree transform is malformed [('unversioned parent', 'new-144'), ('versioning no contents', 'new-165')]

C:\gnms\bin-safe>bzr commit -m "trycommit"
Connected (version 2.0, client OpenSSH_4.7p1)
Authentication (publickey) successful!
Secsh channel 1 opened.
bzr: ERROR: Working tree is out of date, please run 'bzr update'.

C:\gnms\bin-safe>

Revision history for this message
RayH (ray-hunter) wrote :
Download full text (5.8 KiB)

bzr shelve also creates errors I'm afraid.

for example no newline at end of file.

[snip]

Shelve removing file "uninstall.exe"? [yNfq?]
--- watchdog.pid 2009-01-28 11:59:31 +0000
+++ watchdog.pid 2009-02-02 10:54:27 +0000
@@ -1 +1 @@
-5048
\ No newline at end of file
+3032
\ No newline at end of file

[end snip]

Watchdog.pid is a one line file with no newline. bzr seems to want more.
It should never have been version controlled in the first place, but there you go. Sometimes it happens.

Here's the end of the error. Also malformed tree.

Selected changes:
 M .bzrignore
 N CHANGELOG
 N COPYING
 N Cfg.ini
 N Help.chm
 N Nmap/3.01alpha-WinPcap.exe
 N Nmap/WinPcap_3_0.exe
 N Nmap/nmap-3.75/
 N Nmap/nmap-3.75/CHANGELOG
 N Nmap/nmap-3.75/COPYING
 N Nmap/nmap-3.75/README-WIN32
 N Nmap/nmap-3.75/nmap-mac-prefixes
 N Nmap/nmap-3.75/nmap-os-fingerprints
 N Nmap/nmap-3.75/nmap-protocols
 N Nmap/nmap-3.75/nmap-rpc
 N Nmap/nmap-3.75/nmap-service-probes
 N Nmap/nmap-3.75/nmap-services
 N Nmap/nmap-3.75/nmap_performance.reg
 N Nmap/nselib-bin/
 N Nmap/nselib-bin/bit.dll
 N Nmap/scripts/SNMPsysdesr.nse
 N Nmap/scripts/kibuvDetection.nse
 N Nmap/scripts/mswindowsShell.nse
 N Nmap/winpcap-nmap-4.02.exe
 N Nmap/zenmap/_psyco.pyd
 N Nmap/zenmap/share/icons/
 N Nmap/zenmap/share/icons/nmap-eye.ico
 N Nmap/zenmap/share/icons/umit_128.ico
 N Nmap/zenmap/share/icons/umit_16.ico
 N Nmap/zenmap/share/icons/umit_24.ico
 N Nmap/zenmap/share/icons/umit_32.ico
 N Nmap/zenmap/share/icons/umit_48.ico
 N Nmap/zenmap/share/pixmaps/
 N Nmap/zenmap/share/pixmaps/default.svg
 N Nmap/zenmap/share/pixmaps/default_32.png
 N Nmap/zenmap/share/pixmaps/default_75.png
 N Nmap/zenmap/share/pixmaps/freebsd.svg
 N Nmap/zenmap/share/pixmaps/freebsd_32.png
 N Nmap/zenmap/share/pixmaps/freebsd_75.png
 N Nmap/zenmap/share/pixmaps/irix.svg
 N Nmap/zenmap/share/pixmaps/irix_32.png
 N Nmap/zenmap/share/pixmaps/irix_75.png
 N Nmap/zenmap/share/pixmaps/linux.svg
 N Nmap/zenmap/share/pixmaps/linux_32.png
 N Nmap/zenmap/share/pixmaps/linux_75.png
 N Nmap/zenmap/share/pixmaps/logo.png
 N Nmap/zenmap/share/pixmaps/macosx.svg
 N Nmap/zenmap/share/pixmaps/macosx_32.png
 N Nmap/zenmap/share/pixmaps/macosx_75.png
 N Nmap/zenmap/share/pixmaps/openbsd.svg
 N Nmap/zenmap/share/pixmaps/openbsd_32.png
 N Nmap/zenmap/share/pixmaps/openbsd_75.png
 N Nmap/zenmap/share/pixmaps/redhat.svg
 N Nmap/zenmap/share/pixmaps/redhat_32.png
 N Nmap/zenmap/share/pixmaps/redhat_75.png
 N Nmap/zenmap/share/pixmaps/shadow_man.svg
 N Nmap/zenmap/share/pixmaps/shadow_man_32.png
 N Nmap/zenmap/share/pixmaps/shadow_man_75.png
 N Nmap/zenmap/share/pixmaps/solaris.svg
 N Nmap/zenmap/share/pixmaps/solaris_32.png
 N Nmap/zenmap/share/pixmaps/solaris_75.png
 N Nmap/zenmap/share/pixmaps/splash.png
 N Nmap/zenmap/share/pixmaps/ubuntu.svg
 N Nmap/zenmap/share/pixmaps/ubuntu_32.png
 N Nmap/zenmap/share/pixmaps/ubuntu_75.png
 N Nmap/zenmap/share/pixmaps/unknown.svg
 N Nmap/zenmap/share/pixmaps/unknown_32.png
 N Nmap/zenmap/share/pixmaps/unknown_75.png
 N Nmap/zenmap/share/pixmaps/vl_1.svg
 N Nmap/zenmap/share/pixmaps/vl_1_32.png
 N Nmap/zenmap/share/pixma...

Read more...

Revision history for this message
Vincent Ladeuil (vila) wrote :

Wait, re-reading the initial report you updated from bzr-1.10 to bzr-2.2.0 ?

Did you run 'bzr check -v' on the repositories and 'bzr reconcile' if errors are reported ?

This may be unrelated to your actual problem but it would be good to do it anyway.

Also upgrading the repositories to the newer 2a format (introduced in 1.16) should reduce the disk usage and enhance the performances.

Revision history for this message
RayH (ray-hunter) wrote :

yes, the recreated repositories are in 2a format.

All of the clients were updated at the same time
(bzr fora also states the newest latest and greatest release is always backwards compatible, so I believed them)

I didn't tun bzr check -v before now

I have now:

So this is bzr 2.2.0 running on the original (broken) working tree created under 1.10

C:\gnms\bin-safe>bzr check -v
Checking working tree at 'C:/gnms/bin-safe'.
Checking branch at 'file:///C:/gnms/bin-safe/'.
Checking repository at 'file:///C:/gnms/bin-safe/'.
checked repository file:///C:/gnms/bin-safe/ format RepositoryFormatKnitPack1()
     2 revisions
  1090 file-ids
     0 unreferenced text versions
checked branch file:///C:/gnms/bin-safe/ format Branch format 6

No errors reported, so I did not reconcile.

Revision history for this message
RayH (ray-hunter) wrote :

OK tried reconciling. No difference.

C:\gnms\bin-safe>bzr reconcile
Reconciling branch file:///C:/gnms/bin-safe/
revision_history ok.
Reconciling repository file:///C:/gnms/bin-safe/
Reconciliation complete.

C:\gnms\bin-safe>bzr check -v
Checking working tree at 'C:/gnms/bin-safe'.
Checking branch at 'file:///C:/gnms/bin-safe/'.
Checking repository at 'file:///C:/gnms/bin-safe/'.
checked repository file:///C:/gnms/bin-safe/ format RepositoryFormatKnitPack1()
     2 revisions
  1090 file-ids
     0 unreferenced text versions
checked branch file:///C:/gnms/bin-safe/ format Branch format 6

C:\gnms\bin-safe>
C:\gnms\bin-safe>bzr commit -m "test commit"
Connected (version 2.0, client OpenSSH_4.7p1)
Authentication (publickey) successful!
Secsh channel 1 opened.
bzr: ERROR: Working tree is out of date, please run 'bzr update'.

C:\gnms\bin-safe>

Now check at the repository end of things.
Again bzr 2.2.0 working on a repository created under 1.10

bzr check -v
Checking branch at 'file:///home/bzr/gnms-xxxx-bin-safe/trunk/'.
No working tree found at specified location.
Checking repository at 'file:///home/bzr/gnms-xxxx-bin-safe/'.
checked repository file:///home/bzr/gnms-xxxx-bin-safe/ format RepositoryFormatKnitPack1()
     2 revisions
  1090 file-ids
     0 unreferenced text versions
checked branch file:///home/bzr/gnms-xxxx-bin-safe/trunk/ format Branch format 6
bzr@xxxx01:~/gnms-xxxx-bin-safe/trunk$
bzr reconcile
Reconciling branch file:///home/bzr/gnms-xxxx-bin-safe/trunk/
revision_history ok.
Reconciling repository file:///home/bzr/gnms-xxxx-bin-safe/
Reconciliation complete.
bzr@xxxx01:~/gnms-xxxx-bin-safe/trunk$ bzr check -v
Checking branch at 'file:///home/bzr/gnms-xxxx-bin-safe/trunk/'.
No working tree found at specified location.
Checking repository at 'file:///home/bzr/gnms-xxxx-bin-safe/'.
checked repository file:///home/bzr/gnms-xxxx-bin-safe/ format RepositoryFormatKnitPack1()
     2 revisions
  1090 file-ids
     0 unreferenced text versions
checked branch file:///home/bzr/gnms-xxxx-bin-safe/trunk/ format Branch format 6

Again No difference.

C:\gnms\bin-safe>bzr commit -m "test commit"
Connected (version 2.0, client OpenSSH_4.7p1)
Authentication (publickey) successful!
Secsh channel 1 opened.
bzr: ERROR: Working tree is out of date, please run 'bzr update'.

Revision history for this message
Vincent Ladeuil (vila) wrote :

Yes, we maintain compatibility with previous versions and formats, but given the difficulty to diagnose without accessing the repository, I wanted to eliminate some possible old causes.

Now we know the repo is a clean one to start with.

Revision history for this message
RayH (ray-hunter) wrote :

OK. Thanks. There's nothing secret in this particular repository. So if it would make life easier I can tar up the repository and zip up the working directory so you can look at it direct. All I'd have to do would be to be able to send you a download link from our website.

Revision history for this message
Vincent Ladeuil (vila) wrote :

Oh yes, this would greatly simplify the diagnosis !

Revision history for this message
RayH (ray-hunter) wrote :

Download link sent via pm.

Revision history for this message
Vincent Ladeuil (vila) wrote :
Download full text (29.8 KiB)

Pfew, so:

   u'snmp/snmptt_gui/scripts': 'new-144',
   u'snmp/snmptt_gui/scripts/images': 'new-165',

Your working tree contains a pending deletion for:

  snmp/snmptt_gui/scripts/images/Thumbs.db

and the merge (triggered by the update) brings in:

   snmp/snmptt_gui/scripts/images/
  snmp/snmptt_gui/scripts/images/arrow_first.gif
  snmp/snmptt_gui/scripts/images/arrow_last.gif
  snmp/snmptt_gui/scripts/images/arrow_next.gif
  snmp/snmptt_gui/scripts/images/arrow_prev.gif
  snmp/snmptt_gui/scripts/images/CVS/
  snmp/snmptt_gui/scripts/images/CVS/Entries
  snmp/snmptt_gui/scripts/images/CVS/Entries.Extra
  snmp/snmptt_gui/scripts/images/CVS/Repository
  snmp/snmptt_gui/scripts/images/CVS/Root
  snmp/snmptt_gui/scripts/images/info_black.gif
  snmp/snmptt_gui/scripts/images/info_green.gif

I suspect the pending deletion also removed snmp/snmptt_gui/scripts/images and this probably leads to the 'malformed transform'

Definitely a bug, but I haven't been able to find a simpler recipe yet.

Note that I get no error with:

 bzr shelve --all -m 'Put stuff aside'
 bzr update

vila:~/tmp/bin-safe :) $ wbzr shelve --all -m 'cleaning up'
Selected changes:
 M .bzrignore
 N CHANGELOG
 N COPYING
 N Cfg.ini
 N Help.chm
 N Nmap/
 N Nmap/3.01alpha-WinPcap.exe
 N Nmap/CHANGELOG
 N Nmap/COPYING
 N Nmap/README-WIN32
 N Nmap/Uninstall.exe
 N Nmap/WinPcap_3_0.exe
 N Nmap/icon1.ico
 N Nmap/nmap-3.75/
 N Nmap/nmap-3.75/CHANGELOG
 N Nmap/nmap-3.75/COPYING
 N Nmap/nmap-3.75/README-WIN32
 N Nmap/nmap-3.75/nmap-mac-prefixes
 N Nmap/nmap-3.75/nmap-os-fingerprints
 N Nmap/nmap-3.75/nmap-protocols
 N Nmap/nmap-3.75/nmap-rpc
 N Nmap/nmap-3.75/nmap-service-probes
 N Nmap/nmap-3.75/nmap-services
 N Nmap/nmap-3.75/nmap_performance.reg
 N Nmap/nmap-mac-prefixes
 N Nmap/nmap-os-db
 N Nmap/nmap-protocols
 N Nmap/nmap-rpc
 N Nmap/nmap-service-probes
 N Nmap/nmap-services
 N Nmap/nmap.exe
 N Nmap/nmap.xsl
 N Nmap/nmap_performance.reg
 N Nmap/nselib/
 N Nmap/nselib-bin/
 N Nmap/nselib-bin/bit.dll
 N Nmap/nselib/ipOps.lua
 N Nmap/nselib/listop.lua
 N Nmap/nselib/match.lua
 N Nmap/nselib/packet.lua
 N Nmap/nselib/shortport.lua
 N Nmap/nselib/stdnse.lua
 N Nmap/nselib/strbuf.lua
 N Nmap/nselib/url.lua
 N Nmap/scripts/
 N Nmap/scripts/HTTPAuth.nse
 N Nmap/scripts/HTTP_open_proxy.nse
 N Nmap/scripts/HTTPpasswd.nse
 N Nmap/scripts/HTTPtrace.nse
 N Nmap/scripts/MSSQLm.nse
 N Nmap/scripts/MySQLinfo.nse
 N Nmap/scripts/PPTPversion.nse
 N Nmap/scripts/RealVNC_auth_bypass.nse
 N Nmap/scripts/SMTP_openrelay_test.nse
 N Nmap/scripts/SMTPcommands.nse
 N Nmap/scripts/SNMPsysdesr.nse
 N Nmap/scripts/SQLInject.nse
 N Nmap/scripts/SSHv1-support.nse
 N Nmap/scripts/SSLv2-support.nse
 N Nmap/scripts/UPnP-info.nse
 N Nmap/scripts/anonFTP.nse
 N Nmap/scripts/bruteTelnet.nse
 N Nmap/scripts/chargenTest.nse
 N Nmap/scripts/daytimeTest.nse
 N Nmap/scripts/dns-test-open-recursion.nse
 N Nmap/scripts/echoTest.nse
 N Nmap/scripts/finger.nse
 N Nmap/scripts/ftpbounce.nse
 N Nmap/scripts/iax2Detect.nse
 N Nmap/scripts/ircServerInfo.nse
 N Nmap/scripts/ircZombieTest.nse
 N Nmap/scripts/kibuvDetection.nse
 N Nmap/script...

Revision history for this message
RayH (ray-hunter) wrote :

OK. So it is a bug. Possibly a pretty obscure one I guess.

Question is, are we likely to hit it again in 2a format?
And is it worth the effort of you pursuing?

I guess you can only answer that by examining the code in detail :(

We should not have version controlled Thumbs.db. Freely admit that.
Thumbs.db is auto-generated by Windows in directories containing gif/jpeg image files.
Again we live and learn. Stuff like this happens.

But it is very likely we shall have two version controlled sets of binary files that may conflict at some point.
I'm thinking of version controlled directories of web contents including logos, buttons etc.
Two developers could simultaneously come up with a great new idea for a 'back' button.

Revision history for this message
Vincent Ladeuil (vila) wrote :

Got it:

$ bzr init --format=pack-0.92 trunk
$ cd trunk
$ mkdir dir
$ mkdir dir/sub
$ mkdir dir/sub/subsubdir
$ echo 'file content' >dir/sub/subsubdir/file
$ bzr add
$ bzr commit -m 'Initial content'
$ cd ..
$ bzr checkout -r1 trunk branch
$ cd trunk
$ rm -fr dir/sub
$ bzr commit -m 'Remove sub'
$ cd ../branch
$ rm -fr dir/sub/subsubdir
$ bzr st
$ bzr update

Revision history for this message
Vincent Ladeuil (vila) wrote :

So the bug is in transform when trying to merge a directory deletion when the working tree already contains a pending subdirectory deletion.

Changed in bzr:
importance: Undecided → High
status: Incomplete → Confirmed
summary: - After upgrading from 1.10 to 2.2.0 I get "unversioned parent" on one
- particular repository
+ Can't merge a directory deletion in a wt with a pending subdirectory
+ deletion
Revision history for this message
Vincent Ladeuil (vila) wrote :

@Ray: Yes, it's an obscure bug and I suspect there are others when you try to merge into a working tree with pending changes. On the bright side, we only encounter them in pretty obscure cases too :)

So my recommendation will be to avoid it by either reverting/shelving or committing before doing an update.

I'm still a bit surprised that we got different 'new-nnn' numbers for the same operation and that you weren't able to use shelve.

Otherwise, the bug is not related to the repo format used. so stay with 2a anyway.

Oh, and, 2.2.1 has been released too ;)

Jelmer Vernooij (jelmer)
tags: added: merge treetransform
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.