[02:57] <blahdeblah> Hi. Is there a way to do partial commits a-la "git commit -p"?  The best I've been able to find so far is to "bzr shelve" the bits I don't want, selectively keep the bits I want to commit, commit them, then unshelve, rinse, and repeat, which is a bit tedious; "bzr shelve" also doesn't allow splitting of diffs like "git add -p" does.  Any better ideas?
[22:05] <riderirc> anybody awake?
[22:06] <mgrandi> mmhmm
[22:07] <riderirc> Does anyone actually respond to bugs reported on launchpad?
[22:07] <LeoNerd> About 70% of the planet, most likely
[22:07] <riderirc> I have a rather severe problem (bzr check crashes), and nobody's responded to a bug posted in the beginning of December 2014.
[22:07] <mgrandi> link to the bug report
[22:07] <mgrandi> plz
[22:07] <riderirc> https://bugs.launchpad.net/bzr/+bug/1399773
[22:08] <riderirc> It's like fsck crashing - shouldn't happen, and you're screwed when it does...  :-)
[22:08] <mgrandi> hmm
[22:08] <mgrandi> yeah, i think thats exactly the case
[22:08] <mgrandi> bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///root/ww/.bzr/repository/') has no revision username@domain.com-20120314181329-cpt4dhp0ou1b66k2
[22:08] <riderirc> I need to some way to make the repo consistent (and usable) again, even if I lose certain revisions
[22:08] <mgrandi> So its obviously missing a revision and ....therefore fails the check
[22:09] <riderirc> but I don't want to discard the entire revision history
[22:09] <mgrandi> do you have any other copies of the repo?
[22:09] <riderirc> unfortunately, no.
[22:09] <mgrandi> and that username is weird...username@domain.com ? lol
[22:09] <riderirc> I replaced my actual email addr with that placeholder.
[22:09] <mgrandi> ah
[22:09] <mgrandi> if you check in the /root/ww/.bzr/ folder, do you have a 'obsolete packs'?
[22:10] <mgrandi> folder
[22:10] <riderirc> I was beginning to wonder if bzr devel had just gone completely dead...
[22:10] <riderirc> let me check
[22:10] <mgrandi> canonical seems to of shifted...to other things at the moment
[22:11] <mgrandi> but bzr is more or less in a good state, software can always be improved, etcetc
[22:11] <riderirc> I've been resisting switching to git, but you know, this kind of thing makes me question my choice.
[22:11] <mgrandi> lol, git has this problem to
[22:11] <riderirc> yeah, but honestly it's still pretty buggy...
[22:11] <riderirc> for sure, but the git dev team is pretty quick to respond
[22:11] <mgrandi> read about how KDE almost lost _all_ of their git repos cause git does 'mirrors' without checking pack files?
[22:11] <mgrandi> yeah, git does have the benefit of the entire kernel team behind it pretty much
[22:12] <riderirc> thus its primary attraction, I think...
[22:12] <riderirc>  /root/ww/.bzr/repository/obsolete_packs/ has 61 files in it
[22:12] <mgrandi> well the thing is bzr is telling you whats wrong, it cant find the revision, so it doesn't know what else to do, other then magic
[22:12] <mgrandi> i wonder if that revision is in there, one sec
[22:13] <mgrandi> jelmer: do you know of a way to make bzr look in obsolete_packs for missing revisions to fix a repo?
[22:13] <mgrandi> I have been messing around with the bzr pack format but i dont have anything yet that can just 'insert' a revision in the right spot
[22:13] <mgrandi> let me find my script that lists the revisions at least
[22:13] <riderirc> cool
[22:14] <mgrandi> git loves its simplicity and the revisions are just text files haha
[22:14] <riderirc> btw I appreciate your help; I've been checking in here regularly for weeks but nobody's generally awake  :-)
[22:14] <mgrandi> yeah, they are all eurofolk
[22:14] <fullermd> You could setup a strawman copy of the repo with the "obsolete" packs in the main location.
[22:14] <mgrandi> im not a core developer but i like bazaar so i hang out here when i can
[22:14] <mgrandi> the mailing list would probably be better too, since a lot of people get that, even if they are not on irc all the time (like me lol)
[22:19] <riderirc> FWIW: here's the pack layout: http://pastebin.com/75QbcHWz
[22:19] <riderirc> .{r,s,t,c,i}ix files omitted from the obsolete listing.
[22:25] <mgrandi> well, here is my script that i had, i modified it so it can work on * files
[22:25] <mgrandi> http://paste.pound-python.org/show/t1ARpUd5Ks4ZOmx61zHn/
[22:26] <mgrandi> try calling it like "python2.7 print_out_index_keys.py <REPO_FOLDER>/.bzr/repository/obsolete_packs/*.rix
[22:26] <mgrandi> and then search that file for the revision that bazaar says its missing in your bug report
[22:27] <mgrandi> with the filled in email =P
[22:28] <mgrandi> if you find it in there then hopefully its in one of the .pack files in obsolete_packs
[22:39] <riderirc> I ran it, but I'm going to have to have a quick look at the script as it crashed...
[22:39] <riderirc>   File "print_out_index_keys.py", line 56, in printOutIndexKeys
[22:39] <riderirc>     print("noderef: {}, keyelements: {}, len: {}, rowlength: {}".format(noderef_val, keyelements_val, len_val, rowlength_val))
[22:39] <riderirc> ValueError: zero length field name in format
[22:42] <mgrandi> lol guess python2.6 doesn't like the {}
[22:42] <mgrandi> http://paste.pound-python.org/show/TgvP4QYTQ0l0xuhAHemj/
[22:42] <mgrandi> try that maybe
[22:43] <mgrandi> just added indexes to make it happy
[22:44] <riderirc> yeah, I actually don't use "".format() in 2.x, rather I use ""%(tuple,)  :-)
[22:45] <mgrandi> yeahh, im a python 3 guy
[22:46] <riderirc> I suppose I really should change one of these days...  too many of the 2-3 changes seem pedantic rather than reality based though
[22:46] <riderirc> it annoys me, so I stick with 2.x
[22:47] <fullermd> They all seem nuts to me, so I stick with 5.x  ;p
[22:47] <riderirc> anyway, I gave field numbers to each {} for format and it happily spit out data.  I'm going to check for the missing revisionu
[22:48] <riderirc> if the revision is in the pack file, how the heck can it be 'missing' unless it's a bzr bug that failed to actually put it in there?
[22:48] <riderirc> it's not as if someone rm'ed a discrete file.
[22:48] <fullermd> bzr doesn't look at obsolete_packs
[22:49] <fullermd> Could happen via FS corruption, as one offhand guess.  A bit flip somewhere could make it seem like a different id.
[22:50] <mgrandi> yeah
[22:50] <fullermd> I'd expect internal checks to notice that; you could just check the md5's of the pack files.
[22:50] <mgrandi> It _should_ look in obsolete_packs
[22:50] <riderirc> at any rate, the output from your script doesn't appear to include the missing rev.  (your_script > output_file ; grep 20120328004955 output_file)
[22:50] <fullermd> But if it happened in memory, it wouldn't be found at that level.
[22:50] <fullermd> (of course, that couldn't happen, or you'd have gotten an ECC error message.  Right?)
[22:51] <riderirc> there's nothing from the year 2012 showing up at all in the output
[22:51] <mgrandi> how new is that revision
[22:51] <riderirc> fuller: one would hope
[22:51] <mgrandi> hmm..2012..
[22:51] <mgrandi> so there have been commits since then? like a decent number?
[22:51] <riderirc> and the issue just showed up recently
[22:51] <riderirc> probably not a gigantic number
[22:52] <mgrandi> cause stuff gets put into obsolete_packs after bzr runs a 'pack', but if you commited something, and it gets lost before it repacks, then there is no 'backup' in obsolete_packs
[22:52] <mgrandi> and did you make sure to run it against *.rix ? aka the astrik
[22:52] <mgrandi> not just one .rix file
[22:55] <riderirc> yes, it # grep checking.file rixcheck  | wc -l
[22:55] <riderirc> 11
[22:55] <riderirc> it checked 11 of them
[22:55] <mgrandi> so what are the dates in the backup files? like 2014/2015?
[22:56] <mgrandi> that the output gives you
[22:56] <riderirc> so what actual gets put in the obsolete packs anyway (when bzr pack is run) ?
[22:56] <mgrandi> its sort like git, when you commit stuff they get placed in different packs, and information about them (rix, six, tix, etc)
[22:57] <mgrandi> when you repack, it consolidates all the different ones  in 'repository', and places them all into one, and moves the old ones back into obsolete_packs
[22:57] <riderirc> 38 revisions, ranging from 20130118054022 to 20141223012333
[22:57] <mgrandi> sorta how git does it. git has basically a 'file' for every commit, but it can also repack them into one giant file so it doesn't have to search 8000 files to find the right thing
[22:57] <riderirc> ( grep @ rixcheck  | awk -F- '{print $2}'|sort )
[22:58] <mgrandi> so im confused on how you have commits from 2013 but nothing earlier in the backup? is this imported from svn or something?
[22:58] <mgrandi> dunno how that revision is just not there
[22:58] <riderirc> no, it's been bzr since day 0
[22:58] <riderirc> hmm, let me check something
[22:58] <blahdeblah> Repeating yesterday's question: Is there a way to do partial commits a-la "git commit -p"?  The best I've been able to find so far is to "bzr shelve" the bits I don't want, selectively keep the bits I want to commit, commit them, then unshelve, rinse, and repeat, which is a bit tedious; "bzr shelve" also doesn't allow splitting of diffs like "git add -p" does.  Any better ideas?
[22:58] <mgrandi> you can always try cding into the directory where the repo is (normally), and run 'bzr revision-history'
[22:59] <mgrandi> that prints out just revision ids, does that print out the 2012 date?
[22:59] <mgrandi> I think git shelve is the only thing, its a bit easier with the GUI version of shelve (qshelve)
[22:59] <mgrandi> err bzr shelve
[23:00] <blahdeblah> mgrandi: OK - thanks
[23:00] <riderirc> aha!
[23:00] <fullermd> Somebody once wrote a 'record' plugin, mirroring darcs record, which allows similar things.
[23:00] <riderirc> looks like someone pivoted out the old directory...
[23:00] <fullermd> (darcs records does, I mean; I don't know for sure whether the bzr record did, but I assume so, since that's kinda the point)
[23:00] <riderirc> python print_out_index_keys.py /root/oldww/ww/.bzr/repository/obsolete_packs/*.rix > rixcheck-old
[23:00] <riderirc> bijngo
[23:00] <riderirc> bingo
[23:00] <fullermd> I suspect it's lost in the mists of time and compatibility by now, though.
[23:01] <mgrandi> wait, so someone copied the repo to another folder?
[23:01] <riderirc> looks like they pivoted the /root/ww directory out
[23:01] <mgrandi> (and git -p is basically doing a magical shelve -> unshelve thing after commit anyway behind the scenes)
[23:01] <riderirc> that's what happens when you let monkeys in the kitchen
[23:01] <mgrandi> so does that repo work?
[23:01] <mgrandi> as in bzr check doesn't complain? =P
[23:03] <mgrandi> cause i can't find an easy way to insert that revision into the pack file, bzrlib is big =P
[23:03] <riderirc> hmmm
[23:03] <riderirc> bzr: ERROR: No WorkingTree exists for "file:///root/oldww/ww/.bzr/checkout/".
[23:03] <riderirc> so, it's rather messed up looking
[23:04] <mgrandi> think you can just run 'bzr checkout'
[23:04] <mgrandi> it has the history but no actual checkout
[23:05] <fullermd> If you can get it working in another branch, you could just pull both into the same repository.  Or possibly use 'reconcile'.
[23:05] <mgrandi> unrelated: commit.Commit().commit()
[23:05] <mgrandi> lolol
[23:05] <riderirc> but it's not a branch, so I can't perform a checkout
[23:05] <riderirc> it's evidently a repository
[23:06] <mgrandi> well create a directory, run 'bzr branch <repo_folder>'
[23:07] <fullermd> Can't branch a repo.
[23:07] <fullermd> But you can 'init' an empty branch in it, and then 'pull' a revid you know is in the repo into it.  Creepy, but valid.
[23:07] <mgrandi> wait so its just a repo with no branches in it?
[23:08] <riderirc> yes, some bozo evidently moved out the .bzr repository directory
[23:08] <fullermd> Even betterer and creepier, you might could 'branch' the b0rked branch into that repo, and assuming it has all the revs the b0rked one is missing, it would cleanly pull in all the new ones, and leave you with a full history.
[23:10] <riderirc> the worst thing is that there are some large files that were checked in, so bzr check takes ages to run.  I'll fiddle with it a little bit.   At least I have a better idea of what's going on.
[23:10] <riderirc> Are you guys on regularly?
[23:10] <fullermd> On?  Pretty much always.  Responsive?  That varies a lot...
[23:11] <mgrandi> wait cna you not list the branches that are in a repo if it has no active branches?
[23:11] <fullermd> ML might be a better option, especially with stuff like this that has a lot of state to communicate.
[23:11] <fullermd> List branches with no branches?  Stop smoking coffee grounds   ;p
[23:11] <fullermd> You can list heads, anyway.
[23:12] <mgrandi> yeah
[23:12] <mgrandi> run 'bzr heads --all'
[23:12] <riderirc> I may be back with another question about a damaged branch that 'bzr split' exploded
[23:12] <mgrandi> that lists all the heads, and then you can branch one of those right?
[23:13] <fullermd> Not sure.  You can certainly init an empty branch and pull it.  Dunno whether you can branch it from an empty.
[23:13] <riderirc> there is no bzr heads unless that's a plugin
[23:13] <fullermd> It's in bzrtools
[23:14] <riderirc> that sounds familiar
[23:14] <mgrandi> might be a separate package, but its included in every install i've done
[23:15] <mgrandi> but yeah, you can create a folder, 'bzr init .' to init an empty branch, then 'bzr pull -r <REVISION_ID>' and it will basically recreate the branch
[23:15] <mgrandi> and you get revision_id from 'bzr heads --all', cause it wont list dead branches by default
[23:16] <mgrandi> and then once you do fix it, be sure to 'bzr branch' it to somewhere else so this doesn't happen again lol
[23:17] <riderirc> bzr heads is doing something; we'll see what it spits out.
[23:26] <riderirc> well, it's too slow; I'll check on it tomorrow morning.
[23:26] <riderirc> Thanks again for the help...
[23:29] <mgrandi> ok, good luck, post on the ML if you have more questions