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