[08:04] <mgz> morning!
[08:10] <vila> hi all !
[08:32] <mgz> hey vila!
[08:32] <mgz> how was the holiday?
[08:36] <vila> great :)
[08:38] <mgz> good :)
[08:44] <seany> are there any resources on the kndx and knit file internals?
[09:58] <seany> i have a revision that doesn't show in the series of revno's, and shows only in the log only by specifying -r revid:user@...
[09:59] <seany> what's the likely scenario here?
[09:59] <mgz> it's no longer present in the branch, but is still in the repo?
[09:59] <mgz> eg, after pull --overwrite or uncommit.
[10:00] <fullermd> Merged rev?
[10:00] <mgz> I don't see any seperate docs on knits under doc/developers but you can always look at bzrlib/knit.py
[10:01] <seany> thanx mgz and fullermd
[10:01] <seany> i suspect that it is part of a merged rev
[10:01] <mgz> ah yes, and just use log -n0 to see everything
[10:01] <fullermd> (though the case could be made that if you're looking for knit docs, the right answer is probably more like "hey, y'know, the Flood has receeded..."  ;p)
[10:02] <fullermd> If it's a merged rev, the log output probably has a dotted revno for it.
[10:04] <seany> hmm that particular revision doesn't show even under -n0
[10:04] <seany> let me try again
[10:04] <fullermd> You probably need --show-ids to make it show the revids in the output, if you were looking for it that way.
[10:05] <fullermd> But if it's truly not there, then it's not in the branch history.
[10:06] <seany> yeah i'm using the --show-ids flag..
[10:06] <fullermd> You may be able to craft up an invocation of missing to tell you more too.  But I wouldn't be confident in saying how without experimenting, which kinda reduces the usefulness...
[10:07] <seany> so the only likely scenario is an uncommit?
[10:07] <seany> thought that'd get rid of the revision from the repo as well..
[10:07] <mgz> nope, deliberately leaves it in, so you can undo
[10:07] <seany> ah ok
[10:07] <fullermd> Oh, there are a handful of ways.  An uncommit.  A --overwrite of some sort.  Repo shared with another branch.
[10:07] <mgz> anything else that changes the branch head also can do it
[10:08] <fullermd> Pulled in via a merge that was reverted instead of committed.
[10:08] <fullermd> Probably a bunch of other ways that don't immediately come to mind.
[10:09] <mgz> one thing you can do is branch -rrevid:... . /somewhere_else which will give you a branch with just the history of that rev
[10:10] <mgz> some of the qbzr tools are also useful for visualising this stuff.
[10:10] <seany> Hmm yeah I'll give that a shot now and let you know how I go..
[10:45] <seany> can a shared repository be a repository tree at the same time?
[10:45] <seany> i'm looking at one of our legacy codebases, and 'bzr info' returns:
[10:45] <seany> Repository tree (format: unnamed)
[10:45] <seany> Location: shared repository: .
[10:48] <jelmer> seany: in theory, I think so
[10:49] <mgz> you can do some weird things, some of which aren't useful
[10:49] <mgz> I just make this trying to reproduce that:
[10:49] <mgz> Repository checkout (format: 2a)
[10:49] <mgz> Location:
[10:49] <mgz>   repository checkout root: r
[10:49] <mgz>         checkout of branch: b
[10:49] <mgz>          shared repository: r
[10:49]  * fullermd hates those rollup names...
[10:51] <seany> let me try that example
[10:52] <seany> right so in a nutshell, do a checkout into a shared repo
[10:52] <seany> is that right?
[10:53] <mgz> right, that's what I did there. it's not a sensible thing to do, because it mixes tree contents in with branches
[10:55] <seany> hmm in the example i mentioned earlier, bzr info recognizes a repository tree
[10:55] <seany> but i guess it could've come from an earlier tree format
[10:55] <seany> format: unnamed looks suspicious
[10:55] <mgz> it's less suspicious than it looks
[10:56] <seany> what's an unnamed format?
[10:56] <mgz> it's anything that's not an exact mix of repo/branch/tree formats that happen to have a name
[10:56] <seany> oh right
[10:56] <seany> so precisely what we have in your example
[10:57] <seany> well we could've embellished and complicated that example a bit
[10:57] <mgz> right, and remember info -v gives you more details
[10:57] <seany> yep
[11:02] <mgz> it's pretty easy to make something like you have there: <http://pastebin.ubuntu.com/1106220/>
[11:03] <mgz> right fix is probably `bzr branch r r/b && bzr rmbranch r`
[11:04] <mgz> plus force, then use pull --remember to fix the parent
[11:05] <seany> hmm not sure why anyone would not make a subdirectory inside the shared repo for a branch..
[11:05] <mgz> likely just a mistake
[11:05] <seany> the legacy codebase looks really messed up
[11:06] <seany> anyways if you guys get a chance to come to sydney then call me up for lunch or something : >
[11:08] <mgz> we used to be more antipodean than we are presently :)
[11:09] <seany> as in an expat aussie?
[11:09] <mgz> at one point half the people who worked on bazaar were in aus or nz
[11:09] <fullermd> I tried being antipodean once, but I pulled my shoulder.
[11:10] <seany> haha i see ;)
[11:10] <mgz> you're still far from home fullermd :)
[13:29] <abentley> mgz: What sort of extra documentation do you suggest?
[13:31] <mgz> there's a shelving_changes.txt under doc/en/user-guide/ though doesn't seem to be a switch equivalent
[13:32] <mgz> a file with a couple of short examples like that which would appear on website and get indexed would be helpful I think
[13:32] <abentley> mgz: This doesn't have an interactive mode, so there's not a lot of examples to give.
[13:34] <mgz> abentley: basically just wants your test_store_and_restore_uncommitted blackbox test in example style with some explaining I think
[13:36] <abentley> mgz: okay.
[13:37] <mgz> could be a seperate mp if you want to land that one first
[13:49] <jelmer> urgh, one of my emails just escaped from a mail queue somewhere
[13:51] <mgz> as in you sent something that should have been deleted?
[13:51] <mgz> or just a very delayed email?
[13:51] <jelmer> *very* delayed
[13:51] <jelmer> from 15 june :)
[13:51] <mgz> sometimes the epostman takes the long way round :)
[13:52] <jelmer> one of our local mailmen was fired a while ago for hamstering mail
[13:52] <james_w> yeah, sorry jelmer, it was held in moderation
[13:52] <jelmer> james_w: ah :)
[13:53] <mgz> blame james!
[13:53] <james_w> hopefully you won't fire me?
[13:53] <mgz> jelmer: well, sometimes breeding season comes and they just have to make a nest
[13:54] <mgz> without a good bed of letters there wouldn't be lots of new little posties
[13:54] <jelmer> I would expect mwhudson to be the one keeping emails behind in that case ;)
[14:03] <bitglue> so let's say i had a branch, and I merged that branch into trunk. Then I decided it was a bad idea, and in trunk, I reverted the commit where I did the merge. Now I fixed the problem in the branch. How can I reconcile the two branches?
[14:04] <james_w> bitglue, merge trunk back in to the other branch
[14:04] <james_w> that will likely cause some conflicts, but hopefully they will be easy to resolve.
[14:04] <james_w> if trunk only did the revert in the meantime then a "bzr revert ." might suffice for that
[14:04] <james_w> then commit and merge the branch to trunk again
[14:05] <bitglue> what if trunk did more than just the revert in the meantime?
[14:05] <james_w> your conflict fixing will be more involved
[14:05] <james_w> but the process is the same
[14:06] <james_w> a "bzr revert ." in that case would revert the other changes trunk made, which you presumably want to keep
[14:06] <bitglue> there are no conflicts, but merging production also merges the revert, thus discarding all the changes in my branch.
[14:06] <james_w> right, so you could fix that up during the merge
[14:06] <bitglue> ok, can you elaborate on "fix up"?
[14:07] <james_w> or replay the commits on the branch back on top
[14:07] <bitglue> i mean, besides going through all the changes line-by-line and essentially re-writing my branch.
[14:07] <james_w> fix up = make the branch contain all of the changes again
[14:07] <james_w> yeah
[14:07] <james_w> if you lost everything merging back then replaying the commits might be easiest
[14:07] <james_w> jelmer, mgz: am I missing an easier way to do this?
[14:07] <abentley> bitglue: What I do is merge trunk upto the revision before the trunk reverted the branch.  Say trunk's revert is 10.  I'd merge -r 9 and commit normally.
[14:08] <abentley> bitglue: Then merge -r 10, revert ., commit.
[14:09] <bitglue> won't that include the revision in trunk where i merged the branch? So, when I later re-merge my branch, it won't include changes I made before the reverted merge?
[14:10] <abentley> bitglue: It will exclude the revision in trunk where you merged the branch, because that revision is the last common revision, so it is selected as the BASE.
[14:10] <abentley> bitglue: Sorry, that's wrong.
[14:10] <abentley> bitglue: It will include that revision.  But I don't understand what you think will happen because of that.
[14:11] <bitglue> well, say in trunk, r10 is the revert, but r9 is the merge
[14:12] <bitglue> now, if i merge trunk's r9 into the branch, and I do what you said, keeping the merge marker but not the changes for r10, then my branch has the right code in it. But, when I later merge this into production again, I'm afraid it won't include the changes I originally made, because r10 will be the LCR.
[14:13] <bitglue> I think the significant thing here is that I will have merged r9 from trunk into the branch, so now as far as bzr is concerned, everything from before the merge-then-revert is reconciled between the branches (but it's not, because it was reverted)
[14:13] <abentley> bitglue: It will include your changes, because the revision that could have removed them (r10) is something you've already merged.
[14:13] <abentley> bitglue: That means your changes take precedence over the changes r10 made.
[14:13] <bitglue> i don't understand how that works, but i'll try it
[14:14] <abentley> bitglue: What happens is r10 becomes the BASE revision in your final merge.
[14:15] <bitglue> so after i merge, revert, commit the revision from trunk that reverted the merge of the branch into trunk, i can merge the head of trunk, to also get other things that changed in trunk, right?
[14:16] <abentley> bitglue: Right.
[14:16] <abentley> bitglue: but you don't have to.  Your choice.
[14:16] <bitglue> understood. Well, it seems to work. A bit odd, but I can't argue with the result.
[14:18] <abentley> bitglue: the first merge ensures that you've got everything merged except the revert, so that in your next merge, it's safe to completely revert.
[14:19] <abentley> bitglue: The complete revert makes it as if you make your changes from scratch, based on -r10.
[14:19] <bitglue> i guess that makes sense
[14:20] <bitglue> the mental trap seems to be in merging r10, but committing something other than r10. ie, committing nothing.
[14:20] <bitglue> it's like the branch says, "yeah, I know about r10. Except it doesn't exist."
[14:20] <bitglue> which i guess...is really what i wanted all along.
[14:21] <abentley> bitglue: I think of it as saying "I'm overriding what the results of this merge should be.  My changes should survive this merge".
[14:22] <abentley> bitglue: It's not really saying r10 doesn't exist.
[15:55] <abentley> mgz: http://pastebin.ubuntu.com/1106630/
[16:21] <abentley> mgz: What is it about the case where both branches have uncommitted changes that you find interesting?
[16:21] <abentley> mgz: Is it the fact that it errors?  Because that happens regardless of whether the target branch has uncommitted changes.
[16:31] <mgz> abentley: I think it's interesting because it's what I'd end up with if shelves were tied to branches
[16:31] <mgz> I'd be switching from feature_a to feature_b both of which could have pending uncommitted changes
[16:32] <mgz> that doc page looks really good.
[16:33] <mgz> nit, paragraph starting 'switch --store', I'd put a 'Using ' in front of.
[16:33] <mgz> and maybe wants some ``markup`` round inline commands?
[16:33] <abentley> mgz: It's pretty rare that feature_a will already be storing uncommitted changes when you switch to feature b, but if you do, it doesn't matter whether feature_b has uncommitted changes.
[16:33] <mgz> nothing else jumps out.
[16:35] <mgz> abentley: so, what I'd expect is to start with a branch with one set of changes, then switch, and have a different set of changes, which as I understand it will work find if --store is passed and the switched to branch has 'stored-transform'
[16:36] <abentley> mgz: You're sure you mean "branch with one set of changes", not "working tree with one set of changes"?
[16:37] <mgz> well, a store is attached to the branch, rather than the tree
[16:37] <mgz> but yeah, the tree gives one diff, you switch, and get a different diff
[16:39] <abentley> mgz: But why would the changes be stored in the first branch already?  That happens as part of the switch.
[16:44] <mgz> right, that's not really the common case, the current branch would be creating its 'stored-transform' and the target branch would be applying its one
[16:45] <abentley> mgz: Right.
[16:51] <abentley> mgz: So if I tweak test_store_and_restore_uncommitted so that we have uncommitted changes when we switch to "orig", that tests what you wanted to test?
[16:52] <mgz> I'd add it as a new varient and probably switch back again but yup
[16:55] <abentley> mgz: I wouldn't, because then it's trying to unit tests instead of integration tests.
[16:57] <mgz> blackbox tests end up being a bit of both
[16:57] <mgz> you've already got good coverage for the lower level bits with more unit-y tests
[17:09] <abentley> mgz: What will having two variants tell us that having one variant does not?
[17:13] <mgz> probably nothing, my thinking is just that a regression with say, ordering of operations, might make one tes fail and not the other
[17:13] <mgz> your pick
[17:14] <mgz> the other potentially interesting integration test case is switch --store -b fresh with changes in the tree
[17:15] <mgz> do what ever feels right for you.
[20:36] <ccxCZ> is there tool that would open conflicts in vimdiff, tab per conflict, similarly to diffuse?
[21:26] <glyph> Hello bizarros
[21:26] <glyph> I have hit the dreaded 'BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys' yet again
[21:26] <glyph> and I am looking for a way to save my ~300-revision branch without writing a giant shell script
[21:27] <glyph> is there a way to do rewrite which works exclusively on patches and won't try to do common-ancestor reconciliation or whatever the heck triggers that error?
[21:34] <wgz> is this involving bzr-svn again?
[22:41] <glyph> wgz: Yes.  We're not going to switch off SVN until we've had at least a month with bzr not emitting a catastrophic, data-losing traceback ;-)
[22:41] <glyph> I am currently trying really hard to avoid coming to the conclusion that this isn't worth the trouble and we should just switch to git because git-svn doesn't seem to have these issues.
[22:47] <glyph> So, here's a question.  It looks like I am going to have to write the shell script, but I'd like to automate this workaround since it seems like I'm going to have to do it a couple dozen more times before all the repos which are infected with this bug have been cleaned up.
[22:47] <glyph> In order to automate it, the question "what is the most recent revision which has an svn revision associated with it in this branch" is interesting.
[23:03] <jelmer> hi glyph
[23:03] <jelmer> glyph: "bzr log" and grepping for "svn revno:" should tell you, or alternatively "bzr log --show-ids" and grepping for "revision-id: svn-"
[23:12] <glyph> hi jelmer
[23:12] <glyph> sorry to always be such a downer :(
[23:13] <glyph> jelmer: I know how to look for it manually, I was just hoping there would be a convenient command, or maybe a revisionspec, that would give it to me
[23:14] <glyph> like, svn:-1
[23:14] <glyph> show-ids might get me close enough though
[23:22] <jelmer> glyph: there is no revisionspec for anything like that
[23:22] <jelmer> I'm afraid scanning is the only thing you can do (either from the bzr python API or in a script that parses the "bzr log" output)
[23:28] <glyph> I am probably just going to write something in python with plumbum, because I already know what bzr's output looks like but I have no idea what its API looks like :)
[23:53] <glyph> Looks like --xml doesn't work with --show-ids or -p?  That's unfortunate.