| mgz | morning! | 08:04 |
|---|---|---|
| vila | hi all ! | 08:10 |
| mgz | hey vila! | 08:32 |
| mgz | how was the holiday? | 08:32 |
| vila | great :) | 08:36 |
| mgz | good :) | 08:38 |
| seany | are there any resources on the kndx and knit file internals? | 08:44 |
| 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:58 |
| 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. | 09:59 |
| 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:00 |
| 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:01 |
| fullermd | If it's a merged rev, the log output probably has a dotted revno for it. | 10:02 |
| 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:04 |
| fullermd | But if it's truly not there, then it's not in the branch history. | 10:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:45 |
| jelmer | seany: in theory, I think so | 10:48 |
| 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:49 | |
| seany | let me try that example | 10:51 |
| seany | right so in a nutshell, do a checkout into a shared repo | 10:52 |
| seany | is that right? | 10:52 |
| 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:53 |
| 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:55 |
| 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:56 |
| 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 | 10:57 |
| mgz | it's pretty easy to make something like you have there: <http://pastebin.ubuntu.com/1106220/> | 11:02 |
| mgz | right fix is probably `bzr branch r r/b && bzr rmbranch r` | 11:03 |
| mgz | plus force, then use pull --remember to fix the parent | 11:04 |
| 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:05 |
| seany | anyways if you guys get a chance to come to sydney then call me up for lunch or something : > | 11:06 |
| mgz | we used to be more antipodean than we are presently :) | 11:08 |
| 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:09 |
| seany | haha i see ;) | 11:10 |
| mgz | you're still far from home fullermd :) | 11:10 |
| === zyga_ is now known as zyga | ||
| === yofel_ is now known as yofel | ||
| abentley | mgz: What sort of extra documentation do you suggest? | 13:29 |
| mgz | there's a shelving_changes.txt under doc/en/user-guide/ though doesn't seem to be a switch equivalent | 13:31 |
| 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:32 |
| mgz | abentley: basically just wants your test_store_and_restore_uncommitted blackbox test in example style with some explaining I think | 13:34 |
| abentley | mgz: okay. | 13:36 |
| mgz | could be a seperate mp if you want to land that one first | 13:37 |
| === slank` is now known as slank | ||
| === slank is now known as Guest49605 | ||
| jelmer | urgh, one of my emails just escaped from a mail queue somewhere | 13:49 |
| 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 |
| === pfrost is now known as bitglue | ||
| jelmer | from 15 june :) | 13:51 |
| mgz | sometimes the epostman takes the long way round :) | 13:51 |
| 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:52 |
| 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:53 |
| 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 ;) | 13:54 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| abentley | bitglue: Then merge -r 10, revert ., commit. | 14:08 |
| 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:09 |
| 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:10 |
| bitglue | well, say in trunk, r10 is the revert, but r9 is the merge | 14:11 |
| 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:12 |
| 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:13 |
| abentley | bitglue: What happens is r10 becomes the BASE revision in your final merge. | 14:14 |
| 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:15 |
| 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:16 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| abentley | bitglue: It's not really saying r10 doesn't exist. | 14:22 |
| abentley | mgz: http://pastebin.ubuntu.com/1106630/ | 15:55 |
| 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:21 |
| 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:31 |
| mgz | that doc page looks really good. | 16:32 |
| 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:33 |
| 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:35 |
| abentley | mgz: You're sure you mean "branch with one set of changes", not "working tree with one set of changes"? | 16:36 |
| 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:37 |
| === zyga is now known as zyga-brb | ||
| abentley | mgz: But why would the changes be stored in the first branch already? That happens as part of the switch. | 16:39 |
| 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:44 |
| abentley | mgz: Right. | 16:45 |
| === zyga-brb is now known as zyga-afk | ||
| 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:51 |
| mgz | I'd add it as a new varient and probably switch back again but yup | 16:52 |
| abentley | mgz: I wouldn't, because then it's trying to unit tests instead of integration tests. | 16:55 |
| 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 | 16:57 |
| abentley | mgz: What will having two variants tell us that having one variant does not? | 17:09 |
| 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:13 |
| mgz | the other potentially interesting integration test case is switch --store -b fresh with changes in the tree | 17:14 |
| mgz | do what ever feels right for you. | 17:15 |
| === deryck is now known as deryck[lunch] | ||
| === zyga-afk is now known as zyga | ||
| === deryck[lunch] is now known as deryck | ||
| ccxCZ | is there tool that would open conflicts in vimdiff, tab per conflict, similarly to diffuse? | 20:36 |
| 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:26 |
| 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:27 |
| wgz | is this involving bzr-svn again? | 21:34 |
| 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:41 |
| 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. | 22:47 |
| 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:03 |
| glyph | hi jelmer | 23:12 |
| glyph | sorry to always be such a downer :( | 23:12 |
| 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:13 |
| glyph | like, svn:-1 | 23:14 |
| glyph | show-ids might get me close enough though | 23:14 |
| 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:22 |
| 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:28 |
| glyph | Looks like --xml doesn't work with --show-ids or -p? That's unfortunate. | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!