I have been having 2 big problems with the code in trunk since about a week ago and I would advise you not to merge trunk into your branch if you can avoid it for the time being.

  1. The first reason is that trunk now contains an updated version of the Grid recently posted by the author. This version does not currently work with our code. It handles events in a different way and causes Open Petra to crash rather than just misbehave. I am thinking that Chris made changes to the previous source grid source code and we will need to make the same changes to the current (new) source? Maybe? What do you think, Chris? If you do get the code form trunk, and thereby get the new grid DLL, you can get round this problem temporarily by copying the 'old' DLL from a previous branch on your PC into the ThirdParty|DevAge folder of the new branch you want to run. Then you will have to do a complete rebuild of the solution. The grid that works is version 4.20.1.0 and is 644KB. The new, non-working, grid is 4.30.4631.29004 and is 580KB. For the branch I am working on I have swapped the two DLL's successfully, and am running again OK.

  2. A different issue is that some recent checkins have caused Bazaar to have problems with tracking changes. I get a lot of messages to say that some of Christian's checkins are 'ghosts' - ie they have no parent. The consequence is that it has become impossible to view Differences - not just of recent changes but any changes once these ghost checkins are part of your branch. So I can check Differences on my older branches that have not been brought up to date, but I have a couple of branches now that are 'up-to-date' and these ones have lost the ability to see Differences under any circumstances because the differencing engine cannot glue the combined differences together any more. I am concerned that the only solution might be to take trunk back to an earlier revision prior to Christian's checkins and then try and check those changes in again (and any others by other people - but I don't think there are many). But I am finding it very difficult to work without being able to check what differences exist now, and in my Daily Exchange Rate branch,, which I hope to return to, I will want to remind myself of the changes I already made in the branch.

I just wanted to let everyone know about these two issues because you may be best advised not to get trunk into your branch - or indeed to check anything in to trunk until we can be sure that trunk is stable. Oh and one more point - it is not just me that has seen these issues. Chris has reported them as well.

Hi Alan

The change I made to the grid source code was simply to rem out two lines of code in an if statement that allowed a repeat focus leave event to happen, so hopefully I should be able to reproduce the change but testing will obviously be needed.

My big concern here is how the new grid ended up in the trunk, although it is easy for it to get sucked in with a commit. We need to revert to the modified (and ratified) grid in trunk a.s.a.p to allow examination of the changes.

The basic problem and cause of the repeat events is that a cell leaving event happens before a row leaving event, but both are regarded as row leaving events from OpenPetra's perspective. Plus, a deletion of a row did not give an expected event sequence, hence my introduction of InvokeFocusRowChanged (see wiki on the grid for full explanation plus mention of code I remmed out in grid source: sourceforge.net/apps/mediawiki/ ... nd_testing ).

It will be important to see what the grid changes are to justify moving the control up to the latest version, and we don't want to break too many things at this point. If we are going to incorporate the new grid then it needs to fit in with your work on the grid events (which is not earmarked for inclusion in this next release). This wll allow you time for a review of impact on OpenPetra and what needs to change more broadly.

I have made good progress over the weekend regarding the integration of the grid with the details panel. I think I have a good solution so I thought I would have another look at the new grid and see if it worked with my new code. The good news is that nothing crashes. The bad news is that it doesn't work! There have obviously been some significant changes to the grid code. I commented out all the leaving event code just to see what the event sequence is now. I do get the leaving and changed events once, say from row 1 to 2 - but after that, when I cursor down, I never get the leaving event for 2 to 3. So I guess we would then have to start looking at our wrapper code and/or the control validation code and start commenting out a bunch of that.

Anyway - we won't be able to use the new grid yet, and, as it contributes about 1600 files to trunk we should maybe not check it in yet? I have definitely gone back to the old one at the moment.

Hi all,

thanks Alan for spotting and reporting those issues.

I haven't had time to look into issue #2 yet as I was busy fixing issue #1, which is fixed in trunk now.

How issue #1 came about:
On Wed. Sept. 6th I made a commit to trunk that contained what I thought was the SourceGrid source code we were using plus a fix of mine that fixed a rather bad Bug, #415 (sourceforge.net/apps/mantisbt/o ... php?id=451).

Our source code repository didn't contain source code of SourceGrid so far, so I downloaded source code of what I deemed to be the version that we were using (v. 4.30.4094.31750). Unfortunately, this was a newer version than we were actually using, and it apparently caused major changes to behaviour in our screens!

So today I traced back with ChristopherT which version of the SourceGrid source code he really was using for the incorporation of his fixes for the Focus-leave issues discussed here: sourceforge.net/apps/mediawiki/o ... d_handling. It turned out to be based on a somewhat earlier version of the SourceGrid source code, v. 4.30.3904.16709.

A few minutes ago I ended up pulling my last two commits from Wed. Sept. 6th off trunk to restore it back to what it was before my two commits. Then I committed SourceGrid source code that is based on the version Chris was using (v. 4.30.3904.16709) that incorporated both Chris' fixes and my fixes from that day.

So - we should be back to the SourceGrid behaviour we had before my commits on Wed. Sept. 6th and have my fix from that day incorporated as well.

Apologies for the confusion caused by that glitch of mine...

I will look into issue #2 as well.

Kind regards,

ChristianK

Hi Alan,

now addressing Issue #2 you mentioned earlier:

I had a look around the Internet what other people report about 'ghosts' in Bazaar Repositories. From what I find is that they are caused by internal bugs of Bazaar (or by imports from svn repositories, which we didn't do [but from a git repo...]) and one shouldn't need to worry about them.

The bazaar documentation about ghosts can be found here: wiki.bazaar.canonical.com/GhostRevision and it all sounds quite benign. It doesn't mention possible problems with Diff.

What I also found out is that there exists a 'bzr check' command, which I ran against trunk. It took longer than 30 minutes and gave the following output:

Run command: bzr check C:/openpetraorg/trunk
Connected (version 2.0, client Twisted)
Authentication (publickey) successful!
Secsh channel 1 opened.
Checking working tree at 'C:/openpetraorg/trunk'.
Checking branch at 'bzr+ssh://bazaar.launchpad.net/+branch/openpetraorg/'.
Checking repository at 'bzr+ssh://bazaar.launchpad.net/+branch/openpetraorg/'.
checked repository bzr+ssh://bazaar.launchpad.net/+branch/openpetraorg/ format RepositoryFormat2a()
  4610 revisions
  8616 file-ids
 51223 inconsistent parents
checked branch bzr+ssh://bazaar.launchpad.net/+branch/openpetraorg/ format Remote: Branch format 7

According to what I read on various Forums and bug posts of Bazaar, 'ghosts' should be included in this output if there are any - so there seem to be none on our trunk. What is possibly worrying is the 51223 'inconsistent parents', which sounds not quite alright. Again, I found out on the internet that they are likely introduced by internal Bazaar bugs and can apparently be fixed automatically with another bazaar command, bzr reconcile.

I am hesitating to run a bzr reconcile on trunk, though, at least for the moment. What I suggest is that you run 'bzr check' on your branch and post the output in this Forum post. It will be interesting to see whether it mentions anything about 'ghosts'.
[One can issue that command in Bazaar Explorer by clicking the yellow 'All' icon in the toolbar (next to the 'Refresh' icon), then select 'check' from the 'Command' Combobox. Click 'Insert directory' to browse to your branches' directory and run the command by clicking 'OK'.]

It also would be good if you could include the exact error trace that Bazaar throws at you when a Diff fails - please add it to this Forum post.

That's where I got to on this issue for now. I am interested to see what you find out in your branch with bzr check.

Kind regards,

ChristianK

I tried bzr check yesterday evening and after about 90 minutes it had done 233840 kB and then seemed to get stuck.

So I cancelled and started again and left it running overnight. (By 11pm the internet was about twice as fast for me!) Came down this morning and it was stuck at exactly the same 233840kB. I used the -v switch overnight to try and get more verbose output if it had succeeded - but I got the same both times - below

Run command: bzr check -v
Connected (version 2.0, client Twisted)
Authentication (publickey) successful!
Secsh channel 1 opened.
Checking working tree at 'C:/OM_Source/dev_0000950_auto_code_for_add_delete'.
Checking branch at 'bzr+ssh://bazaar.launchpad.net/~alan-paterson/openpetraorg/dev_0000950_auto_code_for_add_delete/'.
Checking repository at 'bzr+ssh://bazaar.launchpad.net/~alan-paterson/openpetraorg/dev_0000950_auto_code_for_add_delete/'.
bzr: interrupted

So we might assume that there is something bad with my branch at launchpad - which is sort of what the messages imply with the Diff problem - something like 'Did not understand the response from the server'. But the important thing to realise is that I did not make the branch go bad with my merges/updates - because afterwards I made a completely NEW branch (alan-paterson/000950A) and checked it out to my PC and did nothing more with it - but I still could not look at the log and see what the file diff's were.

So I guess that I would like to know if you can do that now, having backed out the changes to the grid. Can you try

  1. Create a new branch and get it to your PC
  2. Open the log, select a change, and see if you can pick one of the files from that checkin and see its differences.
  3. Maybe run bzr check on that branch

Yes I too had messages before about missing parents - but 51000 is a lot!

If you can do all those things ok, I am happy to do the same - I know the files I have changed. I can make a new branch (000950B)and put them in and go from there. I have to go to work now, but I can do a bit more tonight in between printing off more Orders of Service for Rachel's wedding!

Here is what I get from running the diff command:

Run command: bzr diff C:/OM_Source/dev_0000950_auto_code_for_add_delete/inc/template/src/Winforms/controlMaintainTable.cs -v
=== modified file 'inc/template/src/Winforms/controlMaintainTable.cs'
Connected (version 2.0, client Twisted)
Authentication (publickey) successful!
Secsh channel 1 opened.
bzr: ERROR: Could not understand response from smart server: ['x\x9c\xcd=ks\xdbF\x92\x9f\xa9_1\x96\xab6dY&\xe3\xdc\x97\xab(\xf6\x16\xcd\x87\xcd\x8bD\xeaH\xca\xbeT*\xb5\x05\x11C\x11k\x10\xe0\x02\xa0\x14\x9dW\xff\xfd\xba{f\x80y\x01\xa4\x14g\xf7X\x89%\x023==\xfd\x9a\xee\x9e\x9eQ\xaf\xc7\x82}\x91\xb2[\x9e\xf0,(x\xc8\xee\xa3b\xc3\x92 )\xcag\x9f\xa3d\x9df\xdb\x9c\xad\xb3t\xcb\xbe\xbe\xfc\x9f\xfe\xe5\xc5b>\x18O.F\x8f,HBV\xf0\xed.\x86\x86l\x95&E\x96\xc6\x97A\x94\x14\xf0\xff2\xb8\x89\xf9I\xaf\x07\xff\xb1\xe1\x8cMgK\xc6\xc3\xa8`\xdb \xd9\x07q\xfcpf<\xa5\x81\x8b\rg!\xcf\xa3[\x18\x1a{~}\xf9\xe1\xea\x02G\xfa8\xea\x0fG\xf3\xc7\x93}\x1e%\xb7l\xf1\x90\xc3\xa0\xe7\xc6\xb7\xee0\x0b\xee\xe1\xab\xf5t\x90\xc61_\x15Q\x9a\xe4\xce\x9b\xed.MxR\\\xa6!\x8f\xad\x970\xe90\xbd\xcf\xbbc\x9c\xb9\xf5n\xce\xd7\x12\xa4\x8dAP\x04N\xdb<\xddg+\xee\x0e^\xa2\xd5]\xec\xf8*']

If I run Diff on one of my changes the Diff window opens but after a few KB it just closes.

If I open the Log and pick a file change from the history I get stuff like:

bzr: ERROR: Server sent an unexpected error: ('error', 'GhostRevisionsHaveNoRevno', 'Could not determine revno for {christian.kendel@[deleted].org-20120830194932-gqz755a569lx7ww0} because its ancestry shows a ghost at {christian.kendel@[deleted].org-20120905152623-r4b3x9z99se7lqxz}')

or

bzr: ERROR: Server sent an unexpected error: ('error', 'GhostRevisionsHaveNoRevno', 'Could not determine revno for {timotheus.pokorra@[deleted].com-20120824082719-4hf225o0m0iqfcez} because its ancestry shows a ghost at {christian.kendel@[deleted].org-20120905152623-r4b3x9z99se7lqxz}')

Sorry - got to go now. I can't find an example of 'no parent' right now.

I did more investigations on this issue today and believe we have come across a bug in Bazaar. Hence I have filed a bug report with Launchpad: bugs.launchpad.net/bzr/+bug/1049124

An interesting observation I have is the following: Using TortoiseBzr or Bazaar Explorer on a recent branch in which we experience the Diff problems to bring up the Log window and selecting one changed file in any revision, I can right-click on it and select 'Show differences -> WinMerge' - and that succeeds (WinMerge being an external Diff tool). Selecting 'Show differences -> Buildin Diff' results in an Error. Alan, can you try that as well and report back?

Thanks for the suggestion. I did not have WinMerge so I just got the standard Builtin Diff. So I downloaded WinMerge and now I too have the choice - and yes It succeeds for me. I am not sure what I have to tell Bazaar the command line for WinMerge is - at present I just have C:\Program Files (x86)\WinMerge\WinMergeU.exe. When I select this I don't actually get the Winmerge screen - but I get a window which I assume is still Bazaar, titled External Diff. It has the following content. I used Revision 1875 - "Add a file that should have been part of my last commit".

Run command: bzr diff --using "C:\Program Files (x86)\WinMerge\Winmergeu.exe" -rrevid.kendel@[deleted].org-20120829081213-bma71kwi3dhqmtk4...

=== added file 'csharp/ICT/Petra/Shared/lib/MConference/validation/Cacheable.Validation.cs'

--- csharp/ICT/Petra/Shared/lib/MConference/validation/Cacheable.Validation.cs 1970-01-01 00 +0000

+++ csharp/ICT/Petra/Shared/lib/MConference/validation/Cacheable.Validation.cs 2012-08-29 08 +0000

@ @ -0,0 +1,80 @ @

+//

+// DO NOT REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

+//

+// @[deleted]:

+// christiank

+//

+// Copyright 2004-2010 by OM International

+//

+// This file is part of OpenPetra.org.

+//

+// OpenPetra.org is free software: you can redistribute it and/or modify

+// it under the terms of the GNU General Public License as published by

+// the Free Software Foundation, either version 3 of the License, or

+// (at your option) any later version.

+//

+// OpenPetra.org is distributed in the hope that it will be useful,

+// but WITHOUT ANY WARRANTY; without even the implied warranty of

+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

+// GNU General Public License for more details.

+//

+// You should have received a copy of the GNU General Public License

+// along with OpenPetra.org. If not, see .

+//

+using System;

+using System.Data;

+using System.Windows.Forms;

+

+using Ict.Common;

+using Ict.Common.Data;

+using Ict.Common.Verification;

+using Ict.Petra.Shared;

+using Ict.Petra.Shared.MConference.Data;

+

+namespace Ict.Petra.Shared.MConference.Validation

+{

+ ///

+ /// Contains functions for the validation of Cacheable DataTables.

+ ///

+ public static partial class TSharedValidation_CacheableDataTables

+ {

+ ///

+ /// Validates the MPartner Marital Status screen data.

+ ///

+ /// Context that describes where the data validation failed.

+ /// The which holds the the data against which the validation is run.

+ /// Will be filled with any items if

+ /// data validation errors occur.

+ /// A containing the Controls that

+ /// display data that is about to be validated.

+ public static void ValidateConferenceCostType(object AContext, PcCostTypeRow ARow,

+ ref TVerificationResultCollection AVerificationResultCollection, TValidationControlsDict AValidationControlsDict)

+ {

+ DataColumn ValidationColumn;

+ TValidationControlsData ValidationControlsData;

+ TVerificationResult VerificationResult = null;

+

+ // Don't validate deleted DataRows

+ if (ARow.RowState == DataRowState.Deleted)

+ {

+ return;

+ }

+

+ // 'UnassignableDate' must not be empty if the flag is set

+ ValidationColumn = ARow.Table.Columns;

+

+ if (AValidationControlsDict.TryGetValue(ValidationColumn, out ValidationControlsData))

+ {

+ if (ARow.UnassignableFlag)

+ {

+ VerificationResult = TDateChecks.IsNotUndefinedDateTime(ARow.UnassignableDate,

+ ValidationControlsData.ValidationControlLabel,

+ true, AContext, ValidationColumn, ValidationControlsData.ValidationControl);

+ }

+

+ // Handle addition to/removal from TVerificationResultCollection

+ AVerificationResultCollection.Auto_Add_Or_AddOrRemove(AContext, VerificationResult, ValidationColumn);

+ }

+ }

+ }

+}

\ No newline at end of file

Connected (version 2.0, client Twisted)

Authentication (publickey) successful!

Secsh channel 1 opened.

Which looks all right to me. What command do you have in the User Configuration of Bazaar for WinMerge??

I have been trying a few more things. Having installed WinMerge I am trying to use it and I have put an alias in my config file to try and make bzr use Winmerge by default. But I just tried running the following from the DOS prompt....

bzr diff path_to_file --using WinMergeU

and I get this...

C:\>C:\Program Files (x86)\Bazaar>bzr diff \OM_Source\dev_0000950_auto_code_for_add_delete\inc\template\src\Winforms\controlMaintainCachableTable.cs --using WinMergeU
Connected (version 2.0, client Twisted)
Authentication (publickey) successful!
Secsh channel 1 opened.
=== modified file 'inc/template/src/Winforms/controlMaintainCachableTable.cs'
bzr: ERROR: Could not understand response from smart server: ['x\x9c\xdd=]s\xdb8
\x92\xcf\xf2\xaf@ \x9c\xaa\x8dTQ\xe4\xc9\xdc\xcb\xd5d\x92+Y\x92\x1d\xdd\xd8\x92O\
x92\x93\x9b\x9a\x9a\x9a\xa2EH\xe6\x86"\xb5$e\xc7\x97\xf5\x7f\xbf\xee\xc6\x07\x01
\x10\xa4dOv\xf7\xeaT\xbb\x19\x8b\x04\x1a\xdd\x8d\xeeF\xa3\xd1h\x9d\x9c\xb0`W\xa4
l\xcd\x13\x9e\x05\x05\x0f\xd9}T\xdc\xb2$H']

So now you can see how far it gets with the response - the first bit is there (modified file), but then it goes wrong.

But I can now go the the Log and see the change in the WinMerge GUI. So the external Diff part of Bazaar works ok there. The internal Diff does not. And no Diff works on the working file differences because of the bad interpretation of the server response.

So I guess from what you say that we are all in the same boat - none of us can see the changes we have made to our own branches any more???

Hi Alan and Christian,

I've been following your conversation.

Alan, you were asking if nobody could see the differences on his own branch.
Well, I made a commit of a branch I'm currently working on (code.launchpad.net/jomammele/o ... 012_joejoe).

After making a small change on a file I could

  • see the diff in the built-in diff viewer of bazaar explorer.
  • see the diff in WinMerge on executing "bzr diff D:\openpetra\bzr\work-improve
    translations\csharp\ICT\PetraTools\GuidedTranslation\TProcessPot.cs --using WinM
    ergeU"
    I didn't get the "Could not understand response from smart server"-error you got.

Hope that helped.
Joachim

D:\openpetra\bzr\work-improvetranslations>bzr diff D:\openpetra\bzr\work-improve
translations\csharp\ICT\PetraTools\GuidedTranslation\TProcessPot.cs --using WinM
ergeU
Connected (version 2.0, client Twisted)
Authentication (publickey) successful!
Secsh channel 1 opened.
=== modified file 'csharp/ICT/PetraTools/GuidedTranslation/TProcessPot.cs'
10kB 4kB/s \

Hi all,

I spent a few more hours on further investigations and augmented the bug report at Launchpad with the information I gathered.
I found a way how to get Diffs successfully and how to not get them and have posted this information there.

Alan, I would be interested to see if you can reproduce what I found in my last two updates on that bug report - both on the command line and in Bazaar Explorer.

joejoe, thanks for joining in the conversation. It is likely that you might not be able to reproduce the problems as your branch isn't new and you didn't do a merge from trunk recently. Those two conditions create the problems we are seeing, according to what Alan has found out earlier.

Yes I would say that I see exactly the same as you have said when I am working in my 0000950 branch. Having set up WinMerge as an alternative to the Builtin I get the down arrow both at the bottom of the Log window and as an option for a selected file in the modified files window. Using either of these does bring up WinMerge with the differences showing (eg Revision 1883 - "This file should have been part of my last commit" (by Christian). I do have a version of trunk that I have edited, so I do have some differences. This seems to behave the same as my branch. In the past I have definitely seen both 'Cannot understand message from server" and stuff about ghosts. I think It may depend on which part of the Log I do a diff on????

Yes if I run "bzr diff -rrevid:@om.org-20120911071731-5eips99nkud84v3o">christian.kendel@[deleted].org-20120911071731-5eips99nkud84v3o" I get a good response in Bazaar and presumably in a DOS window.

bzr diff [path_to_file]\fileName.cs fails, as you say.

So I think we are seeing exactly the same issues. The annoying thing is that the Diff that I want to work is the one on the main page - which is showing my changes. I am not so bothered about the one from the Log - which shows other people's changes, or ones I have already checked in.

You have to think that the basic cause is that something has gone a bit wrong with our database, in such a way that it can send responses to the applications that they do not understand. So we either would need to get the database free of 'errors', or need a new Bazaar app that can cope with the responses it gets. So it is disappointing that fetch-ghosts didn't do anything.

I just tried running bzr info --verbose at the DOS prompt in my working branch folder and got this.....

C:\OM_Source\dev_0000950_auto_code_for_add_delete>bzr info --verbose
Connected (version 2.0, client Twisted)
Authentication (publickey) successful!
Secsh channel 1 opened.
Lightweight checkout (format: 2a)
Location:
  light checkout root: .
   checkout of branch: bzr+ssh://bazaar.launchpad.net/~alan-paterson/openpetraorg/dev_0000950_auto_code_for_add_delete/

Related branches:
  parent branch: bzr+ssh://bazaar.launchpad.net/+branch/openpetraorg/
  submit branch: bzr+ssh://bazaar.launchpad.net/+branch/openpetraorg/
     stacked on: /+branch-id/550521

Format:
       control: Meta directory format 1
  working tree: Working tree format 6
        branch: Remote: Branch format 7
    repository: Remote: Repository format 2a - rich roots, group compression and
 chk inventories

Control directory:
Connected (version 2.0, client Twisted)
Authentication (publickey) successful!
Secsh channel 1 opened.
         1 branches

In the working tree:
      4546 unchanged
        16 modified
         0 added
         0 removed
         0 renamed
         3 unknown
      1076 ignored
       688 versioned subdirectories

Branch history:
      1885 revisions
bzr: ERROR: bzrlib.errors.NoSuchRevision: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~alan-paterson/openpetraorg/dev_0000950_auto_code_for_add_delete/.bzr/) has no revision alan.paterson@[deleted].org-20120906121449-uxbdrbt4d03c3wd5

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\commands.pyo", line 1148, in ignore_pipe
  File "bzrlib\builtins.pyo", line 1842, in run
  File "bzrlib\info.pyo", line 378, in show_bzrdir_info
  File "bzrlib\info.pyo", line 416, in show_component_info
  File "bzrlib\info.pyo", line 305, in _show_branch_stats
  File "bzrlib\remote.pyo", line 1475, in gather_stats
  File "bzrlib\remote.pyo", line 81, in _call_expecting_body
  File "bzrlib\remote.pyo", line 1347, in _translate_error
  File "bzrlib\remote.pyo", line 491, in _translate_error
  File "bzrlib\remote.pyo", line 4194, in _translate_error
NoSuchRevision: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~alan-paterson/openpetraorg/dev_0000950_auto_code_for_add_delete/.bzr/) has no revision alan.paterson@[deleted].org-0120906121449-uxbdrbt4d03c3wd5

bzr 2.5.1 on python 2.6.6 (Windows-7-6.1.7601-SP1)
arguments: ['bzr', 'info', '--verbose']
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.

So this falls over because of an inconsistency in revision numbers.

bzr verify-signatures also has the same revision number error

The database is not happy. How hard would it be to get trunk back to a prior revision that is consistent and then make all the checkins again?? I realise its not pretty, but I can't see how any tool is going to be able to fix the revision trail. It would be hard to 'guess' which revisions need to be glued to which.

Yesssssssss!!!!

Bazaar 2.4.2-1 does manage to use the builtin diff to show changes between your current files and the ones in your branch. Hurrah!

So it does look like the problem has come in with 2.5 and hopefully there is nothing wrong with our trunk database that can't be lived with.

I have just written this having tried Diff on one file in my main window. I will carry on trying to use this version now.

Following from the suspicion that Bazaar 2.4.2 fixes the problems we encountered, I uninstalled Bazaar 2.5.1, installed Bazaar 2.4.2 and did a thorough examination how that version fares with the problems we encountered.

The result is that the problems with log and diff go away with 2.4.2, which is good. However, I can still produce an error followed by a stack trace when running the 'bzr verify-signatures' command on either the branch or on trunk, and I get an 'bzrlib.errors.NoSuchRevision' error when running the 'bzr info --verbose' on my test branch.

So unfortunately the result is inconclusive, and I added my findings to the bug report at Launchpad. I suggest that we all use Bazaar 2.4.2 until we hear from the Launchpad/Bazaar people.

Kind regards,

ChristianK