[00:05] jelmer: http://paste.lisp.org/display/123948 [06:27] hello all? [06:35] poolie: hi ;) [06:35] hello [06:35] could you sanity check https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71154 [06:45] poolie: ugh, but +1 [06:47] Morning all ! [06:47] hi vila, and goodbye [06:47] i might be back later [06:47] hi poolie, cu later [08:08] morning vila and poolie (if you are back) [08:08] hello jam [08:09] brb, pidgeon forgot who I am again [08:41] hi jam, vila, poolie [08:41] morning jelmer [08:41] jelmer: hey ! [08:44] * fullermd continues in his quest to outlaw mornings... [08:45] * vila suggests to shut down the sun [08:45] oh wait Oracle did that already [08:45] * fullermd *rimshot* [08:46] Shutting down the sun would have the added bonus of the temperature staying out of the 3 digit range. For a while, anyway. [08:48] nah, bad plan, it will make it harder to boil water (that's what the 3 digit temperatures are about really) and as such coffee production will become harder, definitely a no-go [08:49] You can cold press coffee, in extremis. I just wish it would stop trying to boil water everywhere outside my front door. [08:50] :) [08:51] In other news, with tag fetching being optional and equality_funcs.clear workaround in place and bug #822571 fix backported to 2.4, I'm ready to freeze 2.4.0 [08:51] Launchpad bug 822571 in Bazaar 2.4 "bzrlib.tests.blackbox.test_version.TestVersionUnicodeOutput.test_unicode_bzr_home fails" [High,Fix released] https://launchpad.net/bugs/822571 [08:51] vila: \o/ [08:51] hi Riddell [08:52] jam, poolie, jelmer: pqm was very slow the day before yesterday, dunno if this has changed, but to be safe, please leave pqm alone (or I'll ask losas to kill the submissions ;) [08:52] hello jelmer [08:52] Riddell: hey ! You're back :) [08:52] Riddell: welcome back then :) [08:53] Riddell: how's the desktop summit? [08:53] Riddell: please leave pqm alone too ;) [08:53] vila: :) [08:53] jelmer: desktop summit was fun, I got some ideas for Bazaar [08:53] Apparently I'm still allowed to ridicule pqm about its childhood etc though. [08:54] fullermd: sure :) [08:55] Riddell: cool === kedare_ifr is now known as kedare === yofel_ is now known as yofel [09:40] poolie: I'm curious about your UDD change today, because the previously existing code in udd should have already accounted for the issues concerned [09:53] vila: babune just stopped responding for me, did something happen? [09:54] jam: nothing I'm aware if [09:54] of [09:54] even [10:05] maxb: that probably explains why his change didn't make any difference on production :) [10:06] vila: seems it was just slow because I was loading multiple pages at once [10:07] or maybe something on my end, given I just DCd from IRC [10:08] vila: I can't reproduce the "PermissionError" bugs, but some of the others I can fix [10:12] \o/ [10:29] vila, mgz: One of the tests is a testtools bug [10:29] well, test_selftest is asserting the output [10:29] however the "if" check says "if version <= (0,9,11)" [10:30] but my testtools.__version__ == (0, 9, 11, 'final', 0) [10:30] which is > version [10:30] anyway, "testtools_version[:3] <= " works [10:31] jam: I plan on upgrading testtools on the slaves asap, will that workaround the issue ? (a fix would be better nevertheless) [10:31] I guess we could fix the check to use testtools_version[:2] [10:31] jelmer: [:3] [10:31] :2 is (0,9) [10:31] (it is an exclusive range) [10:33] jam: ah, right [10:33] vila: both selftest failures were because of that [10:33] I don't know if there is anything else, though, and this is an easy fix [10:34] jam: you mean for windows or you looked at all slaves ? [10:34] vila: https://code.launchpad.net/~jameinel/bzr/2.5-win32-fixes/+merge/71176 [10:35] vila: On the windows slave is what I was looking at [10:35] k [10:35] it was checking against 0.9.11 but the checks had the wrong bounds because of the 3-tuple vs 5-tuple [11:23] hello maxb [11:25] maxb, i think my change was misguided anyhow, as it doesn't seem to have fixed it [11:27] poolie: I think I lost track about what was planned for pqm, but landing a patch takes more than 3 hours these days so we probably want to do *something* ;) [11:28] ah, maybe due to it syncing a lot while running the tests? [11:28] ouch [11:30] I was hoping for some unusual load there or some other misbehavior of the host instead :-} [11:30] that's possible too [11:30] ask a losa for help? [11:31] poolie: sure, I wanted to check if I was up-to-date first. So nothing has occurred lately right ? [11:31] i'm not aware of anything else that could have broken it [11:31] ok [11:31] What sort of hardware does it sit on? [11:31] oh, tom was doing some work on setting up a new pqm box, but i didn't read anything about him having changed the existing machine [11:32] fullermd: an old DL-series hp server i think [11:32] Running raw, not virtualized? [11:32] in a chroot [11:32] biab [11:34] Wouldn't expect the fsync stuff to make a night and day change. [11:34] fullermd: I don't have hard numbers but it seems we went from < 2 hours to > 3 hours [11:35] Though the cost isn't trivial. Still, sounds like an OOM-ish hit on PQM from whatever. [11:35] Hm. I figured pqm ran the test suite in 20, 30 minutes. [11:35] vila: are you done with pqm? [11:36] The timing poolie gave in the MP for fdatasyn showed ~20% increase. [11:37] jelmer: not yet, still at least one submission to open 2.4.1 (which requires the current one to finish) and potentially a second submission to merge 2.4 to trunk [11:38] vila: *nod* [11:38] jelmer: thanks for your patience (though mine is running thin....) [11:39] hi vila, jelmer [11:40] hey poolie1 [11:40] poolie1: so, tom said the new pqm may be ready in a week or two [11:40] also, it seems we're racing with u1 on the actual one which may explain the slowing [11:44] ok [11:44] we should see about turning off fdatasync during tests [11:45] poolie1: did you see that your config stuff for fdatasync doesn't work? [11:45] the new ConfigStack doesn't know about 'bool' [11:45] so setting it to "False" returns a string which evaluates to True always [11:45] I think you could set it to the empty string [11:45] or an empty list [11:45] (btw, you don't have any tests for it working. :) [11:46] :/ [11:46] poolie1: I only found out because I was trying to copy your work for my config [11:46] and hey, setting it to False doesn't do anything wth? [11:46] we'd better fix that for 2.4.0 then [11:51] that would be for 2.4.1, 2.4.0 is already cut and landing on pqm, with tag [11:54] are the criticals all fixed+ [11:54] apparently yes,that's great [11:55] jam, did you file a bug for that? [11:55] yes, I downgraded one since it was covered by the optional tag fetching [11:55] we way still want to bump it to critical for udd though [12:04] poolie1: I'm talking about bug #806348 [12:04] Launchpad bug 806348 in Launchpad itself "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged] https://launchpad.net/bugs/806348 [12:06] surprising... ubot5, why do you report about launchpad when bzr is the first project listed on the page and the primary project seems to be udd... [12:06] (primary as in: http://pad.lv/806348 resolves to https://bugs.launchpad.net/udd/+bug/806348) [12:06] Launchpad bug 806348 in Launchpad itself "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged] [12:07] bah [12:07] mm? [12:11] vila: can I send things to PQM yet? [12:11] Riddell: nope [12:11] Riddell: :) [12:11] Riddell: or rather, you can, but I will ask a losa to kill it ;) === hexsprite_ is now known as hexsprite [12:16] vila, when did you first notice problems? [12:17] I think I asked to jelmer a couple of days ago [12:17] I tried toying with webnumber but it's not accurate enough to be conclusive [12:18] http://webnumbr.com/bzr-pqm-queue-length.from%282011-06-27%29.to%282011-06-28%29 [12:18] http://webnumbr.com/bzr-pqm-queue-length.from%282011-08-09%29 [12:43] i don't think that's going to really correlate with much though [12:44] i guess we could look at mail that was sent to pqm and when it was returned but it's probably easier to see if the sysadmins can find a log for you [12:52] poolie1: yeah, but since the new hardware is expected soon-ish, I'm not sure it's worth investigating either (tom prefer to focus on the new hardware and I see no point disturbing it) [12:52] vila: because L comes before U, but magically after B? [12:52] ok i think i understand the httperror bug [12:53] poolie1: \o/ [12:53] jam: I killed your windows fixes submission and re-submitted it [12:53] vila: you're the one that killed my submission? [12:53] k [12:53] I was a bit concerned about a failed test run with no failures [12:53] jelmer, Riddell : feel free to overload pqm now ;) [12:54] \o/ [12:54] vila: what happened? [12:55] vila, did you actually kill it or just ask for it to be killed? [12:56] Riddell: cutting a release requires two submissions: one for the release and its tag, one to open the branch for bugfixes, I prefer to pull between the two and not leave the branch in the transient state where nobody can land [12:56] poolie1: I asked a losa [12:57] jelmer: sorry I didn't get back to you earlier last night. [12:58] poolie1: he rooted the machine via DDOS and a bug in pqm's web front end, I think :) [12:58] he's really determined that his patch be next [12:58] urbanape: np, I'm afraid I don't really have an answer either though. It seems like the issue is with the way the vcs-bzr script in emacs runs [12:58] urbanape: (without a tty) [12:58] gotcha. okay, bummer [13:01] aha! [13:01] awesome [13:01] I added --no-tty to my agent-gpg script [13:01] ta-da [13:01] poolie1, vila: Even more fun. If you do "c = ConfigStack(); c.set('foo', True); c.get()" Returns True the object. But if you write it out, and then create "c2 = ConfigStack(); c2.get()" it returns u'True' the string. [13:02] urbanape: ah, that was easy :) [13:02] yuk [13:02] jelmer: it was [13:03] jam: see my boolean-option (submitted to pqm) [13:04] vila: sure. I'd put it pretty high in the 2.4.1 queue, given that one of the caveats for fdatasync is that people can disable it if they notice a slowdown [13:04] thanks vila [13:05] vila: I'm a bit concerned that it requires an api break for a stable series. Should we just switch the code to config.get_user_option_as_bool() ? [13:06] (I guess it isn't a major break) [13:06] jam: the easiest may be to not use configstack at all for the datasync options then. Alternatively, options are strings unless specified otherwise (and in 2.4 nobody specifies otherwise ;) [13:06] jam: yup, that's another alternative, whatever works [13:07] jam: but I agree, backporting boolean-option to 2.4 is a no-go [13:08] jam: and thanks for spotting the issue [13:08] bug #824513 [13:08] Launchpad bug 824513 in Bazaar 2.4 "config item repository.fdatasync doesn't work as expected" [High,Confirmed] https://launchpad.net/bugs/824513 [13:10] the 2.4.1 milestone has been created and the lp:bzr/2.4 is almost opened for bugfixes (you have to wait for the current submission to land to base your branch and get the proper news file) [13:10] Riddell: see above for why I don't like to leave the branch in this transient state :0D [13:12] poolie1: the suspense is killing me, what caused the httperror ?? [13:12] :) [13:13] see the bug [13:18] wow [13:20] where does bzr cdiff get its colour information from? [13:24] that was such an annoying api break [13:24] i have some uncommitted changes that i think ought to fix it, but perhaps they don't === mwhudson_ is now known as mwhudson [13:42] Gruuh, LP makes bzrtools difficult... [13:42] It says the latest is 2.3.0. You have to dig to find that (a) there's a 2.3.1 succeeding that, and scroll way down in a list to find 2.4.0. [13:55] fullermd: gigo :-/ [13:57] It always makes me laugh (funny dear-god-no, more than funny ha-ha...) at how every new bzr release makes me have to work with CVS :| [13:59] jelmer: hmm, I must have done something slightly odd, because now subsequent commits are now blocked. Getting errno 13: Permission denied. I don't see any lock files in the branch-lock directory under .bzr. [14:16] urbanape: are you sure it's bzr that's blocked, not gpg? [14:36] hello there, can someone help me with a bzr branch issue I am having, trying to deploy branches for ISD ? [14:36] jelmer: I was given your name to try to see if you could help me. :) [14:37] Chex: hey! [14:37] Chex: Of course, happy to help [14:37] jelmer: awesome, thank you.. look here: https://pastebin.canonical.com/51102/ [14:37] and here, for related info: https://bugs.launchpad.net/config-manager/+bug/823010 [14:38] Ubuntu bug 823010 in config-manager "bzrlib error, cannot find revision in branch" [Undecided,New] [14:39] jelmer: this is a private branch, you wont be able to pull it yourself, but the account we are using has proper access to the branch [14:58] is colo-branches same thing as hg's named branches? [15:01] hi gour [15:02] jelmer: hiya [15:02] gour: in some regards [15:02] I'm now pulling via bzr-hg from google [15:02] gour: it's not exactly the same thing, but they both allow using multiple branches under one file system location. [15:02] gour: did 2.4 work any better for the large branch for you yesterday? [15:03] jelmer: not much...i killed it...however repo @google is 24M..it makes a difference [15:04] it was more speedy, but still too slow [15:05] ahh...conection with google dies after 8mins [15:05] gour: well, it's almost 600Mb of compressed data [15:06] jelmer: right...it's big repo [15:06] now tryingto pull from google with 2.4 [15:07] otoh, hg's named branches are cool...they're, iirc, in mtn, fossil [15:08] gour: branch nicks in bzr are pretty similar [15:08] gour: when tracking what branch a revision came from [15:08] colo-branches is more like git branches [15:08] the combination gives you something similar to hg branches [15:09] hmm...it looks i've to re-read bzr docs a bit [15:09] based on taht i read in hg docs, bookmarks are similar to git branches [15:10] gour: that's hg bookmarks probably, though? [15:10] yes, hg bookmarks [15:13] too bad LP does not have project wikis like bitbucket... [15:13] there was somebody working on that [15:13] jml: do you know how far that's gotten? [15:14] well, bug is quite old and still not on horizon (low priority) [15:15] jelmer: how do bzr & hg compare today, considering 2.4 & 1.9.x ? [15:15] (in general) [15:15] gour: There was a community developer actively working on it a month or two ago [15:16] gour: I'm not sure, my familiarity with hg doesn't really extend beyond the lower levels [15:20] ok [15:21] vila: when is 2.4.0 scheduled for? [15:21] pulling with bzr-hr from google is slow.. [15:22] gour: sure, bzr-hg is still fairly experimental and not really optimized yet [15:22] jelmer: next Tuesday [15:23] vila: roger [15:23] jelmer: if pqm can handle the load :-/ [15:23] err :) [15:26] jelmer: how far what? [15:26] jml: the wiki LEP, do you know what happened to it? [15:28] jelmer: yeah. it's finished & rotting. [15:28] jml: :-( [15:29] jelmer: I didn't expect otherwise. Long drawn-out conversations about how we should do something that no one is actually planning to do tend to end this way. [15:29] ok...16mins...let's try to push to LP now === zyga is now known as zyga-afk [15:37] jml: I guess it means at least we have *some* idea of the constraints and requirements [15:39] jelmer: yeah, I hope so. Although until people are actually using it, it's all just waste. === beuno is now known as beuno-lunch [15:49] jelmer: not sure. But removing arguments from my vc-bzr-gpg script so that it just calls '/usr/bin/gpg $@' doesn't clear it up, and adding -v to the bzr ci doesn't offer any more information. [15:53] anyone able to help me troubleshoot the new PQM server? [15:54] getting https://pastebin.canonical.com/51118/ and test suite has been running for 50 mins or so [16:05] mthaddon: for bzr ? [16:06] vila: yeah, for the new bzr pqm server [16:07] 50mins is not unusual [16:07] the warnings are a bit worrying though, pqm needs some update obviously [16:07] vila: but this is on much faster hardware, with nothing else happening on the box [16:08] do you have /tmp on a tmpfs ? [16:08] vila: it's running the same version of PQM as the current PQM instance [16:08] vila: nope (nor does the current one) [16:08] (will be doing that later once we get one successful run) [16:08] huge boost for bzr test suite, but you're the judge [16:09] anyway, there should be one or two files to track progress, let me check the makefile [16:09] 'selftest.log' in the directory where the command run [16:10] mthaddon: running 'subunit-stats < selftest.log' may even gives you a summary [16:11] vila: that doesn't seem to have updated since 2011-07-27... [16:11] nm, my mistake [16:11] np [16:12] vila: https://pastebin.canonical.com/51122/ [16:15] mthaddon: something bad is going on, NoSuchFile in _check_safety_net... doesn't make sense [16:15] vila: what kind of bad? [16:15] unless the tmp dir was deleted before the end of the run ??? [16:15] mthaddon: a kind I don't understand [16:16] check_safety_net is there to protect against some test bugs, but I almost never see it fail [16:17] spiv changed it recently IIRC but that was for performance reasons and I never see it fails either [16:17] mthaddon: does /tmp/testbzr-W7TYpR.tmp/ exists ? [16:18] vila: https://pastebin.canonical.com/51124/ [16:18] -R ? [16:19] https://pastebin.canonical.com/51125/ [16:21] mthaddon: do you get the same result if you do that again ? (ls I mean) [16:21] a lot of files are missing there [16:22] and dirs [16:22] yeah, same result [16:23] mthaddon: my best guess would be that something went wrong very early in the test suite and failed to build the safety net (a bzr tree that no test should modify) [16:24] and now all tests fail because the net has been damaged (in fact, it looks like a branch lock failed halfway) [16:24] mthaddon: but that's a wild guess as I said, I never saw such a failure [16:24] hmm [16:24] mtaylor: the begining of selftest.log may shed some light ? [16:27] mtaylor: sry, silly auto-completion [16:27] mthaddon: the begining of selftest.log may shed some light ? [16:29] vila: chinstrap:~mthaddon/selftest.log.gz [16:36] does bzr + pristine-tar have the ability to reproduce .bz2 tarballs? [16:36] mthaddon: wow [16:36] KeyError: 'getpwuid(): uid not found: 2005 [16:36] micahg: Yes, I think it's just .xz that's the problem at the moment. [16:37] hmm, ok, I guess it was a bad merge-upstream then... [16:37] mthaddon: and indeed it was in _create_safety_net [16:37] vila: so is that an environment issue, or a test suite issue? [16:38] mthaddon: I suspect it's a chroot issue as we are trying to expand ~ and fails [16:38] mtaylor: /etc/passwd missing entries in the chroot kind of stuff [16:39] vila: I think I can reproduce - thx, will get that fixed and retry [16:40] mthaddon: cool, './bzr selftest -s bb.test_add.TestAdd.test_add_control_dir' in the chroot should reproduce it without running the full test suite [16:40] k [16:43] maxb: .xz should work too, it's just fairly inefficient because pristine-tar doesn't have proper support for xz [16:43] micahg: are you running oneiric? [16:44] jelmer: not on the machine I was doing this on [16:44] micahg: there's a bug with bz2 support in natty, that might explain the issue you were seeing [16:45] * micahg tries in oneiric [16:47] jelmer: nope, still fails to make a .bz2 tarball [16:48] micahg: what fails exactly? [16:48] jelmer: I have no guarantee a bz2 tarball was even imported into the branch [16:48] it makes a .orig.tar.gz [16:48] micahg: what command are you running? [16:49] bzr bd --orig-dir=../tarballs/ [16:50] micahg: how was the upstream tarball imported into the branch? [16:50] no idea [16:50] micahg: it's likely that it went wrong there [16:50] supposedly using bzr merge-upstream, will have to find out later, too close to FF to debug [16:50] micahg: is the branch public? [16:51] jelmer: let me get some more information from the committer and get back to you, wouldn't want you to go on a wild goose chase [16:53] micahg: thanks === kedare is now known as kedare_ifr === beuno-lunch is now known as beuno === abentley_ is now known as abentley === zyga-afk is now known as zyga === Vorpal_ is now known as Vorpal [18:13] mgz: this bytes/unicode thing is doing my head in [18:13] ehhee [18:14] jml: and if you've not read PEP 383 yet, which poolie linked the other day, know that it only gets messiuer [18:14] -u [18:15] I think testtools is basically there, on a hard problem, apart from two things [18:15] I haven't. [18:16] 1) Matcher and Mismatch classes need to not use %s, specifically StartsWith and MatchesRegex [18:17] 2) __str__ on Python 2 should mangle to ascii rather than return unicode and blow things up [18:17] Ahhh, you *say* that. [18:18] testtools can be smart and try __unicode__ first, and other if the objects leak into other less careful libraries they won't be harmed [18:18] in fact, testtools already is smart. [18:18] mgz: you mean something like http://paste.ubuntu.com/663608/? [18:19] I'd have spelled it differently, but yup, looks about what I was thinking [18:19] did it cause issues? [18:20] the only issue remaining from there is to not let non-ascii bytestrings in, which is why StartsWith etc needs chaning [18:20] mgz: yeah [18:20] *changing [18:20] mgz: even on Equals(), you get an unprintable assertion. [18:21] that's the describe() return issue. [18:23] I think it might be best to check the type in that __unicode__ function and do something similar to how bytes() get repr-ed in Python 3, rather than trying to fix every method... [18:23] hm. [18:24] http://paste.ubuntu.com/663616/ for something to muck around with. [18:24] yup, that's the kind of assertion that we want to work for people. [18:25] okay, I'll think a bit and throw some code up [18:25] ...not as in vomit, though I don't guarentee it won't look like that [18:25] http://paste.ubuntu.com/663619/ [18:26] more data [18:26] mgz: heh heh [18:26] mgz: also, I didn't really know how to turn your demo tests into actual tests. [18:27] mgz: just pushed up my latest changes, fixes the _exception_to_text abstraction violation. [18:28] mgz: but, however you choose to project your code onto the internet, it would be much appreciated. [18:31] yeah, I left the demo file as was because getting into another layer of assertions gets really confusing, it's clearer to just see the output as a testtools user would [18:31] fair enough [18:31] tests for the things that then make those cases work as intended are writable [18:32] (what type the describe() method returns on non-ascii mismatches etc) [18:32] cool. I tried naively turning them into tests, and they all passed, which isn't really what we want. [18:32] yeah [18:32] fwiw, https://bugs.launchpad.net/testtools/+bug/686807 might be relevant [18:32] Ubuntu bug 686807 in testtools "Having __str__ not __repr__ as part of the matcher protocol is awkward" [Wishlist,Triaged] [18:32] * mgz looks [18:34] yeah, that change could probably just be made, the __str__ methods already return things that should work as object creation code, and str() falls back to repr() [18:36] ids in reprs only matter when the object identity is significant, newer Python code tends to omit them from the repr string when the objects are interchangable [18:37] repr(Exception("whatever")) has gone from '' to "Exception('whatever',)" [18:43] cool [18:43] I might do that post release [18:44] (I want to have this assertThat bug fixed for the next release though) [18:44] I also just tried to reproduce the only remaining critical bug (https://bugs.launchpad.net/testtools/+bug/672056) and failed. [18:44] Ubuntu bug 672056 in testtools "UnicodeEncodeError: 'ascii' codec can't encode characters in position 2217-2258: ordinal not in range(128)" [Critical,Incomplete] [18:45] * jml goes to make some dinner [18:46] me too :) [18:47] [18:47] ^I have hope that the issues involved in that bug have been seperately resolved, [18:48] mgz: me too. I'm going to give Thomi a few days to reproduce the bug, and close it if he doesn't respond. === micahg_ is now known as micahg [21:08] Hello jelmer. [21:08] micahg said to me that I've to chat with you about a bzr issue. [21:08] I used this command (I think but pretty sure, on natty but it was with another computer...) [21:08] bzr merge-upstream --version 2.1.1 --distribution=oneiric http://ftp.gnome.org/pub/GNOME/sources/latexila/2.1/latexila-2.1.1.tar.bz2 [21:08] And it seems that if 'bzr bd' is used to create the source package, it creates a .tar.gz tarball from bzr instead of a .tar.bz2. So a problem to import the right package. [21:12] merge proposal with branch here: https://code.launchpad.net/~latexila/ubuntu/oneiric/latexila/2.1.1/+merge/70964 === Quintasan_ is now known as Quintasan [21:31] sorry, was away for a bit [21:31] matttbe: thanks === yofel_ is now known as yofel [21:53] hi all [21:56] moinmoin [22:03] hi mgz [22:03] hey poolie! [23:18] How can I switch branch on a lightweight checkout, but keep uncommitted changes in that branch for when I come back? The only way I've found is shelve everything, unshelve when I switch back... [23:18] But can't I somehow tell switch to preserve local changes, and do it in one step? [23:22] jimis: oh, you mean you want the uncommitted changes to be hidden until you switch back? [23:23] jimis: shelving and unshelving is currently the best way to do what you want, I think. [23:23] jimis: It would be fairly easily to write a switch-and-auto-shelve plugin to automate that, I think. [23:24] (it'd override the 'switch' command to first shelve uncommitted changes to a shelf named after the current branch, do the switch, then unshelve from the shelf corresponding to the new branch) [23:25] thanks spiv [23:25] would be very useful as a switch option too [23:25] --shelve for example [23:26] jimis: hmm, could be. File a bug asking for the feature :) [23:26] jimis: (just paste in this IRC chat as the description if you want to be lazy) [23:27] spiv: the reason it's important for changes to be hidden when switching, is avoid unwanted conflicts [23:27] That said, a good way to prototype that feature would be to write the plugin :) [23:27] I've had such conflicts before and it took lot of my time [23:28] jimis: hmm, I think that's just as much an argument for a cheap way to undo the switch (and its conflicts) [23:28] spiv: that's doable? [23:28] it would be a live-savour, for *after* the conflict happened :-p [23:29] jimis: or perhaps an argument for being able to shelve the original changes after the switch [23:29] whatever [23:29] (i.e. a way to say “please shelf the unconflicted changes I had a moment ago”) [23:29] I think it's doable, I don't think it's *easy* currently. [23:29] but after the conflict, you are left with various files injected with conflict marks etc... it's a mess [23:29] Yeah, I know the feeling. [23:30] yeah, that's why I think it's better to watch out during the switch [23:30] And often you don't realise that conflicts are going to be messy until after you've got them. [23:31]