[08:04] morning! [08:10] hi all ! [08:32] hey vila! [08:32] how was the holiday? [08:36] great :) [08:38] good :) [08:44] are there any resources on the kndx and knit file internals? [09:58] 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] what's the likely scenario here? [09:59] it's no longer present in the branch, but is still in the repo? [09:59] eg, after pull --overwrite or uncommit. [10:00] Merged rev? [10:00] I don't see any seperate docs on knits under doc/developers but you can always look at bzrlib/knit.py [10:01] thanx mgz and fullermd [10:01] i suspect that it is part of a merged rev [10:01] ah yes, and just use log -n0 to see everything [10:01] (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] If it's a merged rev, the log output probably has a dotted revno for it. [10:04] hmm that particular revision doesn't show even under -n0 [10:04] let me try again [10:04] You probably need --show-ids to make it show the revids in the output, if you were looking for it that way. [10:05] But if it's truly not there, then it's not in the branch history. [10:06] yeah i'm using the --show-ids flag.. [10:06] 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] so the only likely scenario is an uncommit? [10:07] thought that'd get rid of the revision from the repo as well.. [10:07] nope, deliberately leaves it in, so you can undo [10:07] ah ok [10:07] Oh, there are a handful of ways. An uncommit. A --overwrite of some sort. Repo shared with another branch. [10:07] anything else that changes the branch head also can do it [10:08] Pulled in via a merge that was reverted instead of committed. [10:08] Probably a bunch of other ways that don't immediately come to mind. [10:09] 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] some of the qbzr tools are also useful for visualising this stuff. [10:10] Hmm yeah I'll give that a shot now and let you know how I go.. [10:45] can a shared repository be a repository tree at the same time? [10:45] i'm looking at one of our legacy codebases, and 'bzr info' returns: [10:45] Repository tree (format: unnamed) [10:45] Location: shared repository: . [10:48] seany: in theory, I think so [10:49] you can do some weird things, some of which aren't useful [10:49] I just make this trying to reproduce that: [10:49] Repository checkout (format: 2a) [10:49] Location: [10:49] repository checkout root: r [10:49] checkout of branch: b [10:49] shared repository: r [10:49] * fullermd hates those rollup names... [10:51] let me try that example [10:52] right so in a nutshell, do a checkout into a shared repo [10:52] is that right? [10:53] 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] hmm in the example i mentioned earlier, bzr info recognizes a repository tree [10:55] but i guess it could've come from an earlier tree format [10:55] format: unnamed looks suspicious [10:55] it's less suspicious than it looks [10:56] what's an unnamed format? [10:56] it's anything that's not an exact mix of repo/branch/tree formats that happen to have a name [10:56] oh right [10:56] so precisely what we have in your example [10:57] well we could've embellished and complicated that example a bit [10:57] right, and remember info -v gives you more details [10:57] yep [11:02] it's pretty easy to make something like you have there: [11:03] right fix is probably `bzr branch r r/b && bzr rmbranch r` [11:04] plus force, then use pull --remember to fix the parent [11:05] hmm not sure why anyone would not make a subdirectory inside the shared repo for a branch.. [11:05] likely just a mistake [11:05] the legacy codebase looks really messed up [11:06] anyways if you guys get a chance to come to sydney then call me up for lunch or something : > [11:08] we used to be more antipodean than we are presently :) [11:09] as in an expat aussie? [11:09] at one point half the people who worked on bazaar were in aus or nz [11:09] I tried being antipodean once, but I pulled my shoulder. [11:10] haha i see ;) [11:10] you're still far from home fullermd :) === zyga_ is now known as zyga === yofel_ is now known as yofel [13:29] mgz: What sort of extra documentation do you suggest? [13:31] there's a shelving_changes.txt under doc/en/user-guide/ though doesn't seem to be a switch equivalent [13:32] 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] mgz: This doesn't have an interactive mode, so there's not a lot of examples to give. [13:34] abentley: basically just wants your test_store_and_restore_uncommitted blackbox test in example style with some explaining I think [13:36] mgz: okay. [13:37] could be a seperate mp if you want to land that one first === slank` is now known as slank === slank is now known as Guest49605 [13:49] urgh, one of my emails just escaped from a mail queue somewhere [13:51] as in you sent something that should have been deleted? [13:51] or just a very delayed email? [13:51] *very* delayed === pfrost is now known as bitglue [13:51] from 15 june :) [13:51] sometimes the epostman takes the long way round :) [13:52] one of our local mailmen was fired a while ago for hamstering mail [13:52] yeah, sorry jelmer, it was held in moderation [13:52] james_w: ah :) [13:53] blame james! [13:53] hopefully you won't fire me? [13:53] jelmer: well, sometimes breeding season comes and they just have to make a nest [13:54] without a good bed of letters there wouldn't be lots of new little posties [13:54] I would expect mwhudson to be the one keeping emails behind in that case ;) [14:03] 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] bitglue, merge trunk back in to the other branch [14:04] that will likely cause some conflicts, but hopefully they will be easy to resolve. [14:04] if trunk only did the revert in the meantime then a "bzr revert ." might suffice for that [14:04] then commit and merge the branch to trunk again [14:05] what if trunk did more than just the revert in the meantime? [14:05] your conflict fixing will be more involved [14:05] but the process is the same [14:06] a "bzr revert ." in that case would revert the other changes trunk made, which you presumably want to keep [14:06] there are no conflicts, but merging production also merges the revert, thus discarding all the changes in my branch. [14:06] right, so you could fix that up during the merge [14:06] ok, can you elaborate on "fix up"? [14:07] or replay the commits on the branch back on top [14:07] i mean, besides going through all the changes line-by-line and essentially re-writing my branch. [14:07] fix up = make the branch contain all of the changes again [14:07] yeah [14:07] if you lost everything merging back then replaying the commits might be easiest [14:07] jelmer, mgz: am I missing an easier way to do this? [14:07] 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] bitglue: Then merge -r 10, revert ., commit. [14:09] 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] 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] bitglue: Sorry, that's wrong. [14:10] bitglue: It will include that revision. But I don't understand what you think will happen because of that. [14:11] well, say in trunk, r10 is the revert, but r9 is the merge [14:12] 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] 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] bitglue: It will include your changes, because the revision that could have removed them (r10) is something you've already merged. [14:13] bitglue: That means your changes take precedence over the changes r10 made. [14:13] i don't understand how that works, but i'll try it [14:14] bitglue: What happens is r10 becomes the BASE revision in your final merge. [14:15] 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] bitglue: Right. [14:16] bitglue: but you don't have to. Your choice. [14:16] understood. Well, it seems to work. A bit odd, but I can't argue with the result. [14:18] 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] bitglue: The complete revert makes it as if you make your changes from scratch, based on -r10. [14:19] i guess that makes sense [14:20] the mental trap seems to be in merging r10, but committing something other than r10. ie, committing nothing. [14:20] it's like the branch says, "yeah, I know about r10. Except it doesn't exist." [14:20] which i guess...is really what i wanted all along. [14:21] 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] bitglue: It's not really saying r10 doesn't exist. [15:55] mgz: http://pastebin.ubuntu.com/1106630/ [16:21] mgz: What is it about the case where both branches have uncommitted changes that you find interesting? [16:21] mgz: Is it the fact that it errors? Because that happens regardless of whether the target branch has uncommitted changes. [16:31] abentley: I think it's interesting because it's what I'd end up with if shelves were tied to branches [16:31] I'd be switching from feature_a to feature_b both of which could have pending uncommitted changes [16:32] that doc page looks really good. [16:33] nit, paragraph starting 'switch --store', I'd put a 'Using ' in front of. [16:33] and maybe wants some ``markup`` round inline commands? [16:33] 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] nothing else jumps out. [16:35] 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] mgz: You're sure you mean "branch with one set of changes", not "working tree with one set of changes"? [16:37] well, a store is attached to the branch, rather than the tree [16:37] but yeah, the tree gives one diff, you switch, and get a different diff === zyga is now known as zyga-brb [16:39] mgz: But why would the changes be stored in the first branch already? That happens as part of the switch. [16:44] 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] mgz: Right. === zyga-brb is now known as zyga-afk [16:51] 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] I'd add it as a new varient and probably switch back again but yup [16:55] mgz: I wouldn't, because then it's trying to unit tests instead of integration tests. [16:57] blackbox tests end up being a bit of both [16:57] you've already got good coverage for the lower level bits with more unit-y tests [17:09] mgz: What will having two variants tell us that having one variant does not? [17:13] 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] your pick [17:14] the other potentially interesting integration test case is switch --store -b fresh with changes in the tree [17:15] do what ever feels right for you. === deryck is now known as deryck[lunch] === zyga-afk is now known as zyga === deryck[lunch] is now known as deryck [20:36] is there tool that would open conflicts in vimdiff, tab per conflict, similarly to diffuse? [21:26] Hello bizarros [21:26] I have hit the dreaded 'BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys' yet again [21:26] and I am looking for a way to save my ~300-revision branch without writing a giant shell script [21:27] 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] is this involving bzr-svn again? [22:41] 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] 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] 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] 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] hi glyph [23:03] 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] hi jelmer [23:12] sorry to always be such a downer :( [23:13] 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] like, svn:-1 [23:14] show-ids might get me close enough though [23:22] glyph: there is no revisionspec for anything like that [23:22] 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] 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] Looks like --xml doesn't work with --show-ids or -p? That's unfortunate.