Problem with repository

Scott Aubrey scottaubrey at capuk.org
Tue Apr 20 06:57:45 BST 2010


Hi John

The "missing" rix file contained only 4 revid's, which I found in another .rix file. These revisions have dates in of yesterday and all made by me (e.g. scott at aubrey.org.uk-20100419113048-neoaapncz8s0oeho)

So, maybe a bit more information around my setup will help:

The server is running FreeBSD on UFS2+SU File system. It's running Bzr 2.1 from ports.

My local machine is a MAC OS X 10.6.3, running bzr.dev at 5165. I also run quite a few dev plugins:

bzrtools 2.1.0
   Various useful commands for working with bzr.

colo 0.2.0dev
   Work with colocated branches using current technology.

diffstat 0.2.0
   diffstat - show stats about changes to the working tree

explorer 1.1.0dev
   Version Control for Human Beings.

extmerge 
   external merge plugin for bzr

git 0.5.0
   A GIT branch and repository format implementation for bzr.

hg 0.2.0dev
   Mercurial support for Bazaar.

launchpad 2.2.0dev1
   Launchpad.net integration plugin for Bazaar.

loggerhead 1.17.0
   Loggerhead web viewer for Bazaar branches.

netrc_credential_store 2.2.0dev1
   Use ~/.netrc as a credential store for authentication.conf.

news_merge 2.2.0dev1
   Merge hook for bzr's NEWS file.

qbzr 0.19.0dev1
   QBzr - Qt-based frontend for Bazaar

repodetails 1.9.0dev
   Repository details provides analysis of repository storage.

rewrite 0.6.1dev
   Rebase support.

stats 0.1.0dev
   A Simple bzr plugin to generate statistics about the history.

svn 1.0.3dev
   Support for Subversion branches

xmloutput 0.8.7.dev
   This plugin adds an option (--xml) to log and provides an xml version of some builtin commands.

All four revid in the missing pack index are all on the same branch (following the parent ID part) and this branch is a branch of a branch taken from an svn repo with bzr-svn, i.e.:

publicSvn -> origin/trunk
origin/trunk -> mybranch

commits all in mybranch

Finally, we have three other developers using this repository, all are using bzr 2.1 (AFAIK, one is remote and *maybe* using 2.0.x), using various branches, but noone was using this branch.

Anything else?

- Scott

On 19 Apr 2010, at 20:01, John Arbash Meinel wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Scott Aubrey wrote:
>> Hi John
>> 
>> Thanks for these. I found the .pack and .*ix files in obsolete_packs.
>> copied them back to packs and indices respectively and did bzr check,
>> bzr reconcile, all worked fine AFAIK.
>> 
>> I took a copy of the repository before starting everything I did, is
>> there anything I can do to help figure out what was going on? obviously,
>> I didn't move the pack and index files there, so bazaar must have done
>> something wrong, no?
>> 
>> - Scott
>> 
> 
> It is supposed to only move files to obsolete packs once it has removed
> them from pack-names.
> 
> The only thing I can think of is some sort of concurrency race that we
> didn't catch. Either:
> 
> 1) Hardware based. We issued "write pack-names; mv files", but the OS
>   decided to reorder them into "mv files; write pack-names" and
>   something happened that caused the second bit to fail (power outage,
>   etc).
> 
>   The possibility of the OS reordering our requests and then failing to
>   complete all of them is one of the reasons why we move things to
>   obsolete packs, rather than just deleting them.
> 
>   I don't know the actual likelyhood of this, nor what FS you are
>   using, or OS, or if you had a power outage, or...
> 
> 2) Concurrency between bzr processes, such that we have a bug we don't
>   know about. I recently did a fair amount of work in this area. I
>   don't remember a case where we would have a process rename data out
>   of the way, and another put the old info back.
> 
>   I do remember one where if a 'commit' saw a concurrent operation, it
>   would see that it needed to update its list of known pack files, and
>   would accidentally forget about the one it just generated. That
>   wouldn't trigger what you are seeing, though. (The file would be in
>   packs/* but *wouldn't* be referenced in pack-names.)
> 
> 
> One interesting thing would be to do:
>  bzr dump-btree --raw
> 
> For all of your .rix data. And to see if the data that is in the
> 'obsoleted' pack file was actually all present in some other file. I
> suspect that it would be (we should only ever mark something obsolete
> once we know there is another copy of it being referenced). If so, then
> removing the pack file from pack-names would have been just-as-correct.
> If not, then we certainly need to investigate further.
> 
> John
> =:->
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkvMqJMACgkQJdeBCYSNAAMMhgCg2agtW7VbJpNsH3vk1a5lLqp5
> KS0AoM2Of8L/+QWWxrrnIwFJXTWWalFe
> =zwz/
> -----END PGP SIGNATURE-----




More information about the bazaar mailing list