| igc | morning | 01:27 |
|---|---|---|
| spiv | igc: morning | 01:29 |
| matt2000 | I'm trying to upgrade from bzr 1.13 to 2.0... yum doesn't seem to know about bzr (yum upgrade bzr says 'Could not find update match for bzr' and yum install bzr complains about missing dependencies)I don't think I compiled from src; anyway I can't find any bzr sources lying around. Is there a way to figure out how it was installed in the first place? I'm on Centos 4.7. | 01:36 |
| spiv | "bzr --version" will tell you where bzrlib is installed, which may give a clue. | 01:39 |
| SamB_XP | you can install software on breathmints now ? | 01:40 |
| jderose | matt2000: also, `rpm -qi bzr` will show if there's an rpm package installed | 01:41 |
| igc | hi spiv | 01:42 |
| matt2000 | thanks. bzr --version says ' bzrlib: /usr/local/lib/python2.4/site-packages/bzrlib' | 01:42 |
| matt2000 | rpm says 'package bzr is not installed' | 01:42 |
| spiv | matt2000: /usr/local suggests you did something like "python setup.py install" from a tarball or a checkout. | 01:42 |
| spiv | (And maybe even used stow!) | 01:43 |
| * SamB_XP thinks centos sounds like a breath mint | 01:43 | |
| matt2000 | spiv, thats possible. so can python setup.py help me upgrade to 2.0? | 01:43 |
| spiv | matt2000: python's distutils (the library behind setup.py) doesn't really do upgrades or uninstalls :( | 01:44 |
| matt2000 | SamB_XP: I think XP sounds like something I get for slaying orcs & dragons. | 01:44 |
| spiv | It can install over the top, which often works, but isn't really a good idea. | 01:44 |
| SamB_XP | matt2000: no, I think you need to slay software engineers to get XP | 01:44 |
| matt2000 | spiv: so what happens if I gather up the dependencies yum is asking for and do yum install bzr ? | 01:45 |
| spiv | matt2000: the good news is that probably uninstalling is a matter of deleting /usr/local/lib/python2.4/site-packages/bzrlib, /usr/local/bin/bzr, and maybe one or two other things. | 01:45 |
| spiv | matt2000: (have a quick poke around /usr/local for likely stuff) | 01:45 |
| matt2000 | also, I though yum was supposed to get dependencies for me. Or am I spoiled by apt-get ? | 01:45 |
| spiv | matt2000: then if you install it the regular way with yum it should all be good. | 01:45 |
| spiv | matt2000: For future reference, GNU stow is really handy for installing stuff manually into /usr/local, because it makes it easy to delete later. | 01:46 |
| matt2000 | hmm, maybe I did compile form source... I've got pycrpyto & paramiko src tarballs in /root, which are bzr deps I think? | 01:48 |
| matt2000 | how would I upgrade to 2.0 form sources? Does `make install` take care of that? | 01:49 |
| spiv | "make install" doesn't know anything about upgrading as such. It will happily write files over the top of an existing install, which is very roughly the same. | 01:49 |
| spiv | (But has been known to cause mysterious failures with some past releases) | 01:50 |
| matt2000 | ah ha! bzr --version == 2.0.0 | 01:57 |
| matt2000 | spiv, thanks for the guidance | 01:57 |
| spiv | matt2000: you're welcome | 01:57 |
| johnf | jelmer, lifeless: ping | 02:03 |
| spiv | jam: you wouldn't happen to still be around would you? | 02:26 |
| poolie | hello spiv | 02:33 |
| spiv | poolie: hello | 02:36 |
| spiv | poolie: https://code.edge.launchpad.net/~spiv/bzr/debug-flag-relock/+merge/12972 is still waiting for a re-review from you, should be an easy one :) | 02:36 |
| poolie | ok | 02:39 |
| === abentley1 is now known as abentley | ||
| poolie | igc, did you get my mail of Bazaar strategy from London? | 03:08 |
| igc | poolie: yep | 03:10 |
| poolie | ok | 03:10 |
| poolie | so that kind of subsumes the previous 'news from london' thread, in that it's a summary at the end of the week | 03:11 |
| poolie | thanks | 03:11 |
| mwhudson | poolie: it looked like there were some unfinished sentences in your strategy mail | 03:13 |
| poolie | yes, i blame jetlag, sorry | 03:14 |
| mwhudson | ok :) | 03:14 |
| poolie | i see one of them was probably just missing an "etc" | 03:14 |
| spiv | poolie: I'll make a mental note to just fill in all your unfinished sentences with "etc" :) | 03:16 |
| poolie | "I think we should etc" | 03:17 |
| poolie | :) | 03:17 |
| === lamont` is now known as lamont | ||
| emmajane | igc, ping? | 04:37 |
| igc | hi emmajane! | 04:38 |
| emmajane | igc, hey :) | 04:38 |
| emmajane | I've read the documentation, but I need help. :/ | 04:38 |
| emmajane | igc, I think in your email you're saying to set up a working tree (e.g. http://www.emmajane.net/node/884) but I don't actually see that in the documentation on "how to work on LP projects" so I just want to make sure I'm not going to mess stuff up again. | 04:40 |
| jam | spiv: I'm around now for a bit | 04:42 |
| spiv | jam: oh, hey | 04:42 |
| spiv | jam: I was just going to ask about your thoughts on my reply on the only_raises review, seeing as you hadn't responded yet and I wanted to land it. | 04:42 |
| jam | spiv: I replied to your review of my branch | 04:42 |
| jam | spiv: as for your stuff... | 04:43 |
| jam | the problem is that if you supress something, nobody ever knows to go look for anything | 04:43 |
| spiv | jam: but then I realised you gave me permission to land it so that discussion can happen independently. | 04:43 |
| jam | you never "get the information back" | 04:43 |
| jam | I don't feel terribly strongly, but it is just a general statement | 04:43 |
| jam | as for the "abort_write_group" stuff | 04:43 |
| jam | that is not quite the same | 04:43 |
| * igc reads emmajane's article | 04:43 | |
| jam | because if we didn't print the error then | 04:43 |
| jam | it ends up being printed at the end | 04:44 |
| jam | (often we see: "abort_write_group: Foo failed\nFoo failed\n" | 04:44 |
| spiv | The problem is that often (practically all the time? -- Not A Metric) the fact unlock failed doesn't actually contain any real information. | 04:44 |
| jam | spiv: it says you need to run break lock | 04:44 |
| emmajane | igc, I didn't have anything that I'd worked on, so I've just chucked all my branches and will start again. :) | 04:44 |
| emmajane | igc, I just want to make sure I set it up correctly this time though | 04:44 |
| emmajane | I was specifically looking at: http://doc.bazaar-vcs.org/test/en/tutorials/using_bazaar_with_launchpad.html | 04:45 |
| spiv | jam: that only happened when LockContention is acquired on a lock attempt, I thought/ | 04:45 |
| spiv | ? | 04:45 |
| emmajane | but there wasn't anything about best practices for working trees | 04:45 |
| jam | spiv: so, if you are getting an error during unlock, that means you had a write lock | 04:45 |
| jam | as read locks are no-ops | 04:45 |
| jam | so if you get an unlock error, that means the branch is left locked | 04:45 |
| spiv | jam: grep doesn't show anywhere talks about break-lock during unlock for me. | 04:46 |
| jam | spiv: I'm not saying the error specifically says that, I'm saying it tells someone that | 04:46 |
| jam | as in, it can be inferred | 04:46 |
| jam | / we can fix the error message | 04:46 |
| jam | I won't say there is lots of useful information that you must not suppress | 04:46 |
| spiv | Oh, I see. The problem is often it doesn't convey that, or it is already being conveyed. | 04:47 |
| johnf | Anyone seen this before? | 04:47 |
| johnf | bzr: ERROR: documents is not an index of type <class 'bzrlib.index.GraphIndex'>. | 04:47 |
| jam | just being conservative | 04:47 |
| jam | spiv: "bzr:interrupted" doesn't convey that to me at all | 04:47 |
| igc | emmajane: that tutorial probably needs some love - LP is more powerful now with merge proposals and other goodies | 04:47 |
| jam | though when I try to push again, it will tell me | 04:47 |
| emmajane | igc, :) | 04:47 |
| igc | emmajane: http://doc.bazaar-vcs.org/latest/en/user-guide/organizing_branches.html is the key thing to read | 04:47 |
| spiv | i.e. if the unlock is happening because of "connection reset" then allowing that error through is going to more clearly hint "you probably need break-lock" than "TooManyConcurrentRequests" | 04:47 |
| emmajane | igc, lovely!! | 04:48 |
| jam | spiv: though connection reset can happen at any time | 04:48 |
| spiv | So it seems to me that it's an improvement for at least some cases. KeyboardInterrupt is a tricky case. | 04:48 |
| igc | emmajane: and one more thing ... | 04:48 |
| jam | whether or not a lock was taken | 04:48 |
| emmajane | igc, I started at the "in five minutes" and then went to the tutorial and then to LP. | 04:48 |
| jam | and I certainly agree "TooManyConcurrentRequests" is generally completely bogus | 04:48 |
| igc | you don't need to merge your feature branch back into your trunk & push | 04:48 |
| jam | I've never had *that* actually be true | 04:49 |
| spiv | jam: and it can happen while waiting for a response to an unlock RPC, in which case you don't actually know if you need to break-lock or not :) | 04:49 |
| spiv | Oh, it's always true. | 04:49 |
| jam | TooMany has only ever happened IME when the connection was closed, etc. | 04:49 |
| spiv | Just not in any sense that's relevant to users. | 04:49 |
| igc | instead, you can push your feature branch to LP as ~emmajane/projectname/branchname | 04:49 |
| jam | spiv: 1 request cannot be concurrent | 04:49 |
| igc | emmajane: then propose it as a merge | 04:49 |
| emmajane | igc, ok | 04:49 |
| jam | spiv: can it? | 04:49 |
| emmajane | igc, I should be able to do this quickly and then I'll ping you again when I'm ready to upload. | 04:50 |
| igc | emmajane: to propose a merge, run "bzr lp-open" and click the necessary link | 04:50 |
| spiv | jam: no, but it won't be raised unless the medium has been asked to track multiple requests. | 04:50 |
| jam | spiv: then is the bug that ConnectionReset doesn't clear the current pending request? | 04:50 |
| jam | since it certainly doesn't seem like it is still active | 04:50 |
| spiv | More likely a bug that code attempts to keep using a connection after a ConnectionReset. | 04:51 |
| jam | We're a bit off topic, but I've never felt that I've gotten a genuine case where we issued 2 requests concurrently. Just that one gets interrupted, so we go on to the next | 04:51 |
| jam | and the lower level thinks we issued 2 | 04:51 |
| spiv | It's pretty much always a symptom of a bug, like an AssertionError. | 04:52 |
| jam | spiv: right. I think the intent of it is even a 'programmer error' if it was actually genuine | 04:52 |
| jam | something like issuing a request while iterating over the results of a record stream, etc. | 04:52 |
| spiv | Right. Although reentrantly trying to issue an RPC during cleanup while the previous response hasn't been completed also fits the description of 'programmer error'. | 04:53 |
| jam | perhaps | 04:53 |
| jam | though if the connection is broken transiently | 04:53 |
| jam | one could argue that you reset and try again | 04:53 |
| jam | which would allow clean shutdown even after a hiccup | 04:54 |
| AfC | It's amazing that we spend huge amounts of time worrying about bandwidth and performance of our DVCS system transmitting a few bytes of patch from A to B, and yet for a few lines of kernel patch our distro is mirroring and then each of us are downloading 30 MB of binary package | 04:54 |
| jam | AfC: I've been suprised that debs don't do any sort of incremental updates as well | 04:54 |
| jam | surprised | 04:55 |
| spiv | Or we perhaps should arrange to keep raising ConnectionReset (or whatever) on subsequent attempts to use that connection. | 04:55 |
| AfC | jam: yeah. I mean, that's just the use case that rsync is optimized for | 04:55 |
| AfC | jam: although that would assume that the tar files we create were more or less consistently ordered to some defined spec [which I believe is, by accident, the case], | 04:56 |
| AfC | jam: but more to the point the compression algorithm would have to have clear boundaries so that (for example) a new file mean new compression headers etc so that rsync could easily detect the unchanged regions (ie, unchanged files) | 04:57 |
| AfC | but that would seem worth achieving | 04:57 |
| spiv | Anyway, my basic theory is that the original error which will now be reported cleanly to the user ought to be conveying the idea that "your operation has failed, some human cleanup may be necessary" better that saying "unlock failed with TooManyConncurrentErrors." | 04:57 |
| spiv | Especially given that some unlocks don't actually involve releasing locks on disk (read locks, or locks acquired with a token or when leave_lock_in_place has been called). | 04:58 |
| jam | spiv: but those unlocks won't actually raise errors... | 04:58 |
| spiv | Probably they won't. | 04:59 |
| * igc grabs some lunch - bbiab | 04:59 | |
| spiv | Except for MemoryError, or novel bugs, or ... | 04:59 |
| jam | spiv: given that they aren't issuing rpcs, they won't raise TMCE | 04:59 |
| poolie | hi igc, jam, spiv | 04:59 |
| poolie | afc | 04:59 |
| jam | hi poolie | 04:59 |
| spiv | I see emitting a friendly "I could not release this physical lock" as an orthogonal issue, really. | 04:59 |
| spiv | I'm not against doing that at all, I just don't see it as more than tangentially related to a patch to suppress unwanted exceptions from quashing other exceptions. | 05:00 |
| jam | spiv: and my concern is that squashing too hard means we may lose information, and never know about it. | 05:01 |
| poolie | i agree with spiv | 05:01 |
| jam | generally, I'm fine with always squashing TMCE | 05:01 |
| jam | but that isn't the only thing being squashed | 05:01 |
| poolie | it's possible we could squash say SyntaxError | 05:01 |
| spiv | Because for instance it needs to be done at a slightly lower layer to be correct, because "Repository.unlock" doesn't directly map to "release physical lock on disk". | 05:01 |
| poolie | i think maybe for developers this should always print to stderr | 05:01 |
| poolie | for some appropriate value of 'developres' | 05:02 |
| jam | poolie: well, the path we've taken to date is version_info[3] == 'final' | 05:02 |
| spiv | Also, TMCR isn't the only exception that has caused this, just the most common one. | 05:02 |
| jam | spiv: I'm certainly not asking for a traceback, and I think you did completely the right thing there | 05:03 |
| poolie | mm | 05:03 |
| jam | my concern is whether we want a one-line warning versus just mutter | 05:03 |
| poolie | i'm thinking we should have -Developer | 05:03 |
| jam | debug_flags = eveloper,hpss ? | 05:03 |
| poolie | it's also a bit connected to python warnings | 05:03 |
| poolie | mm, or -Ddeveloper | 05:04 |
| poolie | like libowfat :) | 05:04 |
| poolie | i think if we're going to far, we'll start getting bugs about "why am i always told the branch is already locked?" | 05:04 |
| jam | poolie: I have to say I don't have a clue how to parse libowfat :) | 05:04 |
| poolie | too* | 05:04 |
| spiv | I expect that an unfortunately timed connection loss during SFTP could trigger the same problem, for example. Or a wireless card drop out during HTTP, or while accessing something over NFS, etc. | 05:04 |
| poolie | on the gcc command line, '-lowfat' | 05:04 |
| jam | poolie: ahh | 05:05 |
| jam | fun | 05:05 |
| poolie | and then the first step would be to say 'an error prevented %s being unlocked' | 05:05 |
| poolie | and then we could take it further | 05:05 |
| poolie | spiv, it is still going into mutter right? | 05:05 |
| spiv | Which is why I'm whitelisting rather than blacklisting, because I don't think it's feasible to anticipate all the possible errors. | 05:05 |
| spiv | Yep. | 05:05 |
| jam | poolie: so I tried to get the queue down, but still no response on the cache cix stuff | 05:07 |
| poolie | i saw your swathe of review mails | 05:07 |
| poolie | that was impressive | 05:07 |
| jam | also, does anyone know how to get LP to do partial merge requests? | 05:07 |
| jam | I'd like to split up my static-tuple branch | 05:07 |
| jam | but I'm not going to put in the effort if I can't generate nice merge proposals | 05:07 |
| poolie | with partial diffs? | 05:08 |
| emmajane | igc, Ok. I tried doing the push from my feature branch just to my own stuff on LP and I'm getting an error. | 05:13 |
| emmajane | igc, I did: bzr push lp:~emmajane/bzr-website/utility-nav | 05:14 |
| emmajane | and it said: | 05:14 |
| emmajane | (apologies for the four-line spam) | 05:14 |
| emmajane | Using default stacking branch /~bzr/bzr-website/trunk at lp-46082192:///~emmajane/bzr-website | 05:14 |
| emmajane | bzr: ERROR: KnitPackRepository('lp-46082192:///~bzr/bzr-website/trunk/.bzr/repository') | 05:14 |
| emmajane | is not compatible with | 05:14 |
| emmajane | CHKInventoryRepository('lp-46082192:///~emmajane/bzr-website/utility-nav/.bzr/repository') | 05:14 |
| emmajane | different serializers | 05:14 |
| emmajane | (five line) | 05:15 |
| emmajane | (more if I keep counting incorrectly and continue to correct myself) | 05:15 |
| jam | poolie: right, I want to create N branches, each one building on the other | 05:16 |
| jam | but I want to submit it relative to the previous branch | 05:16 |
| jam | so it can actually be reviewed in pieces | 05:16 |
| jam | I thought you could do something like that via email | 05:16 |
| jam | but I've never tried | 05:16 |
| jam | so I was hoping someone else had | 05:16 |
| spiv | jam: I think I have in the past, when lp code reviews would use the preview diff from the email. | 05:18 |
| jam | spiv: I thought if you sent a cherrypick request "bzr send -r X..Y" it would do so | 05:19 |
| spiv | (or whatever the terminology was) | 05:19 |
| jam | but you think that was because of the preview diff? | 05:19 |
| spiv | But I think now that there's only one kind of diff, and LP generates it, I'm not sure that would work. | 05:19 |
| spiv | But I haven't tried recently, so I might be wrong. | 05:19 |
| spiv | mwhudson: ^ ? | 05:20 |
| mwhudson | spiv: i think you're right | 05:20 |
| mwhudson | i haven't tried it myself either | 05:21 |
| jam | spiv: question for you | 05:22 |
| jam | about python | 05:22 |
| poolie | jam, i've heard something about them working on mp dependencies | 05:22 |
| jam | foo = MyObject() | 05:22 |
| poolie | but it's not live yet | 05:22 |
| spiv | emmajane: your local branch is in the shiny new 2a format, but lp:bzr-website isn't (it's 1.9-rich-root) | 05:22 |
| jam | assert 1 = sys.getrefcount(foo) -1 | 05:22 |
| jam | foo = ('tuple') | 05:22 |
| jam | assert 2 = sys.getrefcount(foo) -1 | 05:23 |
| jam | Is this because the compiler is adding the static tuple into the function frame? | 05:23 |
| * emmajane grumbles. | 05:23 | |
| emmajane | spiv, thanks :) | 05:23 |
| spiv | emmajane: if you do "bzr init --1.9-rich-root lp:~emmajane/bzr-website/utility-nav" before pushing it should work. You may need to delete the old branch first. | 05:23 |
| jam | spiv: or we should just upgrade lp:bzr-website | 05:23 |
| spiv | emmajane: or get igc to upgrade lp:bzr-website to 2a :) | 05:23 |
| spiv | jam: almost, except your phrasing sounds dangerously like you're going to volunteer! ;) | 05:24 |
| spiv | jam: that hypothesis sounds close | 05:25 |
| spiv | jam: although I think it's because the static tuple is defined in the function or code object, rather than the frame. | 05:25 |
| spiv | But ICBW. | 05:25 |
| AfC | Did I understand the 2.0.0 release announcement to mean that any bzr >= 1.16.0 can read from a public branch that is in 2a format? | 05:26 |
| emmajane | spiv, It didn't like it when I just pasted that command. So probably I need to nuke the .bzr folder in the feature branch and re-initialize? | 05:27 |
| emmajane | (Warning: never be the last one to talk to the newbie or you'll get all the pings.) ;) | 05:27 |
| spiv | AfC: that sounds correct. | 05:28 |
| spiv | (I don't remember the precise version offhand, but that's the right ballpark.) | 05:28 |
| spiv | emmajane: right. Or go to https://code.launchpad.net/~emmajane/bzr-website/utility-nav and delete it through the web UI. | 05:29 |
| AfC | spiv: ok, thanks. Now that I think of it, that makes sense (as thereabouts was when the format was introduced experimentally) ... | 05:29 |
| AfC | I wonder if I was to upgrade my public branches to 2a whether that would screw over people using (say) 1.18.1 (ie, has all this furious bug fixing been in new code, or does it mean that that 1.18.1 is also buggy with respect to the 2a format?) | 05:30 |
| igc | emmajane, poolie: it sounds like we ought to switch bzr-website to 2a | 05:30 |
| emmajane | spiv, ok, deleted from the web interface, re-ran the init and am now pushing the featurebranch | 05:31 |
| * emmajane scrolls back up to find igc 's next instruction. :) | 05:31 | |
| poolie | igc, it would be good but i think you'd need to check escudero had a new bzr first | 05:31 |
| poolie | afc, i think 1.18.1 is ok, but it'd be better to get them onto 2.0.x | 05:32 |
| poolie | or otoh wait until everyone is on 2.0.x | 05:32 |
| AfC | poolie: right. I'm balancing the [very few] hackers I have (using Debian's bzr or Ubuntu Intrepid's bzr or whatever ancient code) versus the gain I'd see as the person who interacts with said public branch the most :) | 05:33 |
| spiv | AfC: skimming the NEWS file I don't see any critical correctness bugs relating to 2a fixed in 2.0.0 vs. 1.18.1, but there were quite a few performance bugs and even one segfault fixed. | 05:33 |
| * emmajane clicks all the buttons | 05:33 | |
| emmajane | igc, ok, I think there's something there for you to review now? | 05:33 |
| AfC | spiv: yeah. Well. I'll be "responsible" and wait a bit longer before upgrading. But once Ubuntu and Fedora have 2.0.x in them (Gentoo does already) then really there won't be much justification for me to hold back further. | 05:34 |
| spiv | emmajane: looks like a decent merge proposal to me. | 05:36 |
| * emmajane blinks at AfC. *gentoo* is ahead of Ubuntu? | 05:36 | |
| zobi1 | is there a working bazaar bundle for textmate? | 05:37 |
| emmajane | that's awesome :) | 05:37 |
| AfC | emmajane: of course | 05:37 |
| emmajane | spiv, \o/ | 05:38 |
| zobi1 | oops, just got disconnected. repost: is there a working bazaar bundle for textmate? | 05:38 |
| AfC | emmajane: the only place where Ubuntu or Fedora tend to be ahead of Gentoo is in and around the GNOME constellation, since they're always is such a rush to get it ready for their next 6 monthly release AND they have an "exception" or whatever hardwired into their release guidelines. | 05:39 |
| AfC | emmajane: But for most other things they're all tight about freezing and thereby shipping ancient code. Fedora seems to update more broadly and willingly than [the Debian culture inherited by] Ubuntu. | 05:39 |
| AfC | but I don't have an objective measure of that yet. | 05:39 |
| emmajane | AfC, huh. | 05:39 |
| igc | thanks emmajane. I'll review that now | 05:40 |
| arkanes | that doesn't really match my experience | 05:40 |
| idnar | AfC: you should probably specify whether you're talking about stable releases or not | 05:40 |
| idnar | eg. bzr 2.0 has been in debian sid for a while now | 05:41 |
| arkanes | there's a lot of things you need to manually unmask to get half-decent recent versions of in gentoo, and broken ebuilds in those unmasked packages are really common | 05:41 |
| AfC | idnar: I'm encompassing both stable and development experiences in one sweep. But taking the example you cite, bzr, what version is in Intrepid? | 05:41 |
| jam | AfC, emmajane: Depends if you consider ppas, etc. But yeah, I think gentoo tends to be a bit closer to crack-of-the-day | 05:41 |
| idnar | which would probably be a better comparison with Gentoo than, say, Debian 4.0 | 05:41 |
| mneptok | AfC: depends on if you use default repos, backports, or a PPA | 05:41 |
| AfC | mneptok: whatever Canonical Inc is officially supporting and shipping (so, no PPA) | 05:42 |
| idnar | intrepid apparently has 1.6.1, but that's, what, a year old? | 05:42 |
| AfC | idnar: and that's my point. | 05:42 |
| * emmajane nods | 05:42 | |
| mneptok | what does Gentoo officially support? | 05:43 |
| mneptok | (i.e. when i dial Gentoo paid support, what version do they expect me to have?) | 05:43 |
| emmajane | mneptok, don't be difficult just because you're right. ;) | 05:43 |
| idnar | AfC: yeah, but I don't really understand the issue; if you want software that's newer than a year old, run a release that's newer than a year old. you might then want to complain that Debian doesn't release often enough, but Ubuntu seems to release often enough that that's not such a major issue | 05:43 |
| AfC | mneptok: it's a community distro. It doesn't officially support anything. But as a rolling-release distro (ie, Gentoo, Arch) it tends to have fairly up to date packages, taken as an average. | 05:43 |
| arkanes | it doesn't seem very reasonable to compare what is essentially a static distribution with constantly updating packages (gentoo) with a distro with rapid, regular releases | 05:43 |
| idnar | and if you want the latest and greatest, then run the latest and greatest | 05:44 |
| mneptok | AfC: it's easy to decide to potentially break things when you have no paying customers ;) | 05:44 |
| arkanes | you can view ubuntu releases as snapshots if you want instead | 05:44 |
| mneptok | !info bzr | 05:45 |
| ubottu | bzr (source: bzr): easy to use distributed version control system. In component main, is optional. Version 1.13.1-1 (jaunty), package size 5171 kB, installed size 17768 kB | 05:46 |
| mneptok | 1.13 in Jaunty | 05:46 |
| AfC | and you're proud of this? | 05:46 |
| mneptok | (using default repos) | 05:46 |
| idnar | AfC: what I'm saying is | 05:46 |
| mneptok | 2.0 is default in Karmic | 05:46 |
| idnar | AfC: if you want "always being updated", Debian already provides that, as does Ubuntu to an extent | 05:47 |
| mneptok | so, upgrade your distro. you know, just like you would do with a rolling release. | 05:47 |
| AfC | Yeah, well, I've made that mistake. Running Karmic has been hell the last month. | 05:47 |
| m3ga | i've created a repo using bzr 2.0.0 and i'd like to pull it from a machine 1.13.1, but can't because of version mismatch. can't the repo be downgraded? | 05:47 |
| arkanes | AfC: I'm not really sure where you're going with this | 05:48 |
| m3ga | thats what you're talking about isn't it? (hi AfC) | 05:48 |
| idnar | anyhow, having said all of that, I'm not planning to rush out and upgrade everything to 2.0/2a right away either, I'd rather take my time ;) | 05:48 |
| arkanes | AfC: it's not like unmasking every experimental and half-working ebuild in gentoo is going to get yuo a stable system | 05:48 |
| AfC | m3ga: yeah, if you init{,-repo} a branch in --format=$something_older and then pull into it, it'll convert | 05:49 |
| m3ga | ah, thanks | 05:49 |
| bob2 | I don't think you can go back from 2a | 05:49 |
| bob2 | well, you can, but only to a rich root format | 05:49 |
| AfC | bob2: yeah, that sounds familiar | 05:49 |
| AfC | m3ga: but in that case, --format=1.9-rich-root or such | 05:50 |
| bob2 | --1.9-rich-root | 05:50 |
| bob2 | 2slow | 05:50 |
| m3ga | hmm, can't create --pack-0.92 like all my other repos. | 05:52 |
| m3ga | bzr 2 available for jaunty? | 05:55 |
| AfC | m3ga: not from Ubuntu, but in the Bazaar PPA, yes | 05:58 |
| mneptok | https://edge.launchpad.net/~bzr/+archive/ppa | 05:58 |
| igc | emmajane: I'll approve and merge that change | 06:01 |
| emmajane | igc, does that mean I can go to sleep now? :) | 06:01 |
| igc | emmajane: sure :-) night | 06:01 |
| emmajane | igc, thanks :) | 06:01 |
| emmajane | oh. wait. | 06:01 |
| emmajane | I have the new icon too. | 06:01 |
| m3ga | thanks mneptok and AfC. Got it | 06:01 |
| * emmajane figures out where to put that. | 06:01 | |
| igc | you can use the same branch and push again if you like | 06:02 |
| emmajane | k | 06:03 |
| bob2 | mneptok: ah, --rich-root-pack | 06:04 |
| bob2 | oops | 06:04 |
| emmajane | igc, erm I get an error when I try to merge into the same place. | 06:07 |
| emmajane | propose a merge into the same place rather | 06:07 |
| emmajane | "There is already a branch merge proposal registered for branch lp:~emmajane/bzr-website/utility-nav to land on lp:bzr-website that is still active." | 06:07 |
| igc | emmajane: when you push? | 06:07 |
| emmajane | igc, when I use the web interface to request a merge | 06:07 |
| igc | emmajane: try "resubmit proposal" | 06:08 |
| emmajane | igc, I don't see an option for resubmit... | 06:09 |
| igc | right hand top corner? | 06:10 |
| emmajane | https://code.edge.launchpad.net/~emmajane/bzr-website/utility-nav | 06:10 |
| igc | of the current merge proposal | 06:10 |
| emmajane | and that's an internal server error. | 06:11 |
| emmajane | um. | 06:11 |
| emmajane | http://bazaar.launchpad.net/~emmajane/bzr-website/utility-nav/files | 06:11 |
| igc | yuk | 06:11 |
| igc | I'll pull your branch in any case | 06:11 |
| emmajane | :) | 06:11 |
| emmajane | the only change was adding the new icon from danno | 06:11 |
| igc | well, merge your branch into my trunk to be more explicit | 06:11 |
| idnar | you should still be able to resubmit from https://code.edge.launchpad.net/~emmajane/bzr-website/utility-nav/+merge/13038 | 06:12 |
| idnar | even if the code browser is spewing errors (which seems to happen far too frequently) | 06:12 |
| emmajane | idnar, thanks | 06:12 |
| emmajane | igc, I resubmitted | 06:13 |
| igc | thanks. looks good. | 06:13 |
| igc | emmajane: committed to trunk now. | 06:14 |
| emmajane | \o/ | 06:14 |
| igc | emmajane: night (and thanks) | 06:15 |
| emmajane | igc, thanks for making sure I was doing it right :) | 06:15 |
| igc | np | 06:15 |
| igc | emmajane: I figure telling you is double value as you often tell others :-) | 06:15 |
| emmajane | :) | 06:16 |
| emmajane | igc, it's true. :) | 06:16 |
| emmajane | igc, is it on your plate to update the In 5 Minutes guide to include the working tree info? | 06:17 |
| emmajane | if not I'll add it to my plate. | 06:17 |
| igc | emmajane: it's not on my plate | 06:17 |
| emmajane | ok | 06:18 |
| igc | my plate is struggling with enough other stuff :-( | 06:18 |
| emmajane | heh. have you been up to the buffet and overloaded your plate? ;) | 06:18 |
| igc | emmajane: the one downside to pulling stuff into separate projects is that I'm now managing merges to a dozen or more of them! | 06:19 |
| emmajane | :( | 06:19 |
| * emmajane gives you a tray to put your plate on? :/ | 06:19 | |
| igc | emmajane: I can easily spend all day on bzr and never touch the core project | 06:20 |
| emmajane | I've got a few people firing me explorer docs as well. | 06:20 |
| igc | emmajane: cool. Some screencasts on explorer would be sweet btw | 06:21 |
| igc | hint hint :-) | 06:21 |
| emmajane | heh. I was just complaining about screen casting to someone :) | 06:21 |
| emmajane | Ubuntu + screencasting = fail. | 06:21 |
| emmajane | I've had to buy a windows box. :( | 06:21 |
| igc | :-( | 06:21 |
| emmajane | yeah | 06:21 |
| emmajane | I record in Ubuntu and then transfer to windows to add voice and render. | 06:22 |
| emmajane | I'll see if I can bribe jacine into doing one for OSX though. | 06:22 |
| igc | emmajane: karmic? | 06:22 |
| emmajane | whatever 9.04 is. | 06:22 |
| igc | jaunty | 06:22 |
| emmajane | I'm lousy at remembering the animal names. | 06:23 |
| igc | emmajane: I just upgraded to karmic today | 06:23 |
| emmajane | I should upgrade my laptop that never gets used just to see how it all looks. | 06:24 |
| emmajane | i'm afraid of upgrading production machines though | 06:24 |
| igc | it looks really nice | 06:24 |
| emmajane | cool :) | 06:24 |
| jam | first patch on the static-tuple wagon is up for review: https://code.launchpad.net/~jameinel/bzr/2.1-simple-set/+merge/13039 | 06:24 |
| jam | second is in the email queue | 06:24 |
| jam | 3 4 5 I'll probably work on tomorrow | 06:25 |
| jam | night all | 06:25 |
| emmajane | igc, Ok. I'll scan through the list again tomorrow to see if there's any leftover things before starting on the inner pages. | 06:25 |
| igc | night jam | 06:26 |
| jam | 2 is up https://code.launchpad.net/~jameinel/bzr/2.1-export-c-api/+merge/13041 | 06:29 |
| jam | though it royally screwed things up | 06:29 |
| jam | the email looks like it through out my carefully worded submit request | 06:30 |
| jam | and then inlined the attachment | 06:30 |
| jam | and then generated its own *full* merge result | 06:30 |
| jam | ignoring the fact that I asked for a cherrpyick | 06:30 |
| * jam grumpy | 06:30 | |
| jam | abentley: ^^ I'm going to bed, and I assume you are sleeping, but if you could explain what is going on, I'd like to understand. | 06:30 |
| jam | Is it just not possible in launchpad's code-review to get decent stacked changes reviewed? | 06:31 |
| jam | hmm... I wonder if I could cheat and actually request the submission to be merged into my other branch | 06:32 |
| jam | and just make 'bzr-core' the reviewer... | 06:32 |
| jam | anyway, will try something tomorrow | 06:32 |
| spiv | jam: g'night | 06:49 |
| vila | hi all | 07:28 |
| vila | jml: testtools requires python >= 2.5 (more precisely functools), is that a bug or a feature ? | 07:44 |
| mtaylor | bzr: ERROR: bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///home/mordred/src/drizzle/.bzr/repository/') has no revision ('mordred@inaugust.com-20090924230420-zc4vxrr30uxgo4eb',) | 08:02 |
| mtaylor | anything in general I can do to work around it when bzr tells me things like that? | 08:02 |
| jelmer | johnf: ping | 08:03 |
| poolie | mtaylor: is this when pushing? | 08:04 |
| mtaylor | poolie: no... I was giving the rebase plugin a try | 08:04 |
| mtaylor | poolie: I'm guessing it doesn't like stacked branches? | 08:04 |
| poolie | maybe, i'd have to see the traceback | 08:05 |
| poolie | probably best if you file a bug on that | 08:05 |
| mtaylor | poolie: k. will do | 08:05 |
| poolie | thanks | 08:05 |
| mtaylor | poolie: should I file it on bzr or on bzr-rebase? | 08:05 |
| poolie | probably rebase at first | 08:05 |
| mtaylor | k | 08:06 |
| mtaylor | poolie: fwiw: bug 446075 | 08:12 |
| ubottu | Launchpad bug 446075 in bzr-rewrite "bzr crashed while trying to run bzr rebase" [Undecided,New] https://launchpad.net/bugs/446075 | 08:12 |
| vila | For those interested in bug #405745, the failure with python-2.4 was due to some bits missing in socket.py and SocketServer.py, nothing really problematic | 08:13 |
| ubottu | Launchpad bug 405745 in bzr "blackbox.test_check.ChrootedCheckTests.test_check_missing_branch hangs on AIX" [Medium,In progress] https://launchpad.net/bugs/405745 | 08:13 |
| poolie | we should get the crash message to tell people what bug subject to use | 08:13 |
| mtaylor | poolie: yeah. | 08:13 |
| mtaylor | poolie: sorry - that's like the worst bug subject every isn't it | 08:13 |
| poolie | not the worst :) | 08:14 |
| mtaylor | :) | 08:14 |
| poolie | 'bzr crash' is better | 08:14 |
| poolie | or 'problem' | 08:14 |
| poolie | 'halp' | 08:14 |
| poolie | :) | 08:14 |
| spiv | Or "ubuntu cds" | 08:14 |
| mtaylor | or 'discount viagra' | 08:14 |
| vila | so the leaks due to http (bug #392127) are still down ~300 to 0 | 08:14 |
| ubottu | Launchpad bug 392127 in bzr "bzr >= 1.16 on gentoo: can't start new thread" [High,In progress] https://launchpad.net/bugs/392127 | 08:14 |
| poolie | woo vila | 08:15 |
| vila | s/down/down from/ | 08:15 |
| poolie | can we enforce that there are 0 now? | 08:15 |
| vila | and I have good hopes the same fix could be applied to ftp (I'm not sure hpss needs it though I seem to remember spiv telling so, ref?) | 08:15 |
| vila | enforcing 0 is one or two patches away I'd say | 08:16 |
| spiv | vila: maybe, I'd have to look to check... | 08:16 |
| vila | The main problem is that the threading module seems to be less than reliable when it comes to counting active threads... | 08:16 |
| spiv | There's a thorny thread leak involving sftp and a blackbox test. | 08:17 |
| vila | spiv: don't worry, I'll look at the code for hpss, but I've already fixed RecordingServer and I'm not sure you were referring to that or something else | 08:17 |
| spiv | vila: sure it's not simply a matter of a race between when you check the count and when you do the enumerate? | 08:17 |
| spiv | There's a SmartTCPServer_for_testing that you may need to look at. | 08:18 |
| vila | spiv: what race ? I ask for the count and get 2, I do enumerate I get 1 | 08:18 |
| vila | spiv: ok, I'll look at that | 08:18 |
| spiv | vila: so between doing the count and the enumerate one thread finished? | 08:18 |
| poolie | igc, what's the deal with https://code.edge.launchpad.net/~ian-clatworthy/bzr/faster-log-file/+merge/7535 | 08:19 |
| vila | spiv: no, AFAICT it's already finished, the proof being that enumerate() doesn't see it and all involved threads has been joined | 08:19 |
| spiv | vila: the implementation of active_count and enumerate in 2.6 don't leave much room for disagreement. | 08:19 |
| igc | I need to test it on an LP file (bushy tree project) | 08:20 |
| spiv | vila: i.e. they are identical except one does len(_active) + len(_limbo), and the other does _active.values() + _limbo.values() (and those two vars are ordinary dicts). | 08:20 |
| vila | spiv: it's as if the thread was still alive for a short time after join() | 08:20 |
| spiv | Ah, that sort of thing I could easily believe. | 08:21 |
| vila | spiv: I can't reproduce reliably, but I've seen it in ~5% of the cases | 08:21 |
| vila | spiv: but then it becomes a bit hard to detect leaks...All I got is false positives... | 08:21 |
| poolie | igc, is https://code.edge.launchpad.net/~ian-clatworthy/bzr/eol-update-bug/+merge/10959 the one you were asking me to read? | 08:22 |
| vila | So the answer to poolie question: "Can we enforce 0" is: "No, because of the false positives :-/" | 08:22 |
| poolie | i'm sure i won't work on it before i go | 08:22 |
| igc | that's the one | 08:22 |
| igc | it's mainly tests but 2 bits of code iirc | 08:23 |
| poolie | so is there anything i can sensibly do today/tomorrow? | 08:23 |
| igc | that's the main thing I was hoping for | 08:23 |
| vila | spiv: anyway, my goal to reduce it as much as I can, bug #392127 is significant here as the "Can't create new thread" was blocking the full test suite on gentoo, OSX and windows | 08:23 |
| ubottu | Launchpad bug 392127 in bzr "bzr >= 1.16 on gentoo: can't start new thread" [High,In progress] https://launchpad.net/bugs/392127 | 08:23 |
| vila | I don't know the *next* bug that will block the full test suite on windows though :) | 08:24 |
| poolie | igc: what's the main thing? just a review? | 08:24 |
| igc | yes | 08:24 |
| poolie | it's not redundant with robert's comments? | 08:25 |
| poolie | it looks basically ok but i'm a bit dopey so i'll look again tomorrow | 08:25 |
| igc | poolie: I wanted to land that in 2.1b1 so we have a public dowlonad for using really needing content filtering to work | 08:25 |
| poolie | i'd be a bit wary of putting it into 2.0.1 | 08:25 |
| igc | users | 08:25 |
| poolie | just because of the history leading up to 2.0 | 08:25 |
| poolie | mm | 08:25 |
| igc | right | 08:25 |
| * poolie looks | 08:26 | |
| bialix | hello all | 08:26 |
| johnf | Before I file a bug has anyone seen this before | 08:26 |
| johnf | bzr: ERROR: documents is not an index of type <class 'bzrlib.index.GraphIndex'>. | 08:26 |
| bialix | poolie made my day: "There is a good amount of work in bzr.dev - 4 a4 pages of news - so it'd be good to get it out." ROTFL | 08:27 |
| vila | hello bialix | 08:27 |
| spiv | johnf: no, that's new to me. I wonder if it's something to do with a plugin? | 08:27 |
| bialix | bonjour vila | 08:27 |
| johnf | spiv: remind me how do I make plugins not load? | 08:27 |
| awilkins | --no-plugins | 08:28 |
| vila | johnf: rings no bell, the 'documents' token makes me think it could realted to a plugin | 08:28 |
| vila | johnf: you can also do 'BZR_PDB=1 bzr <command>' to have pdb called and do 'bt' there | 08:28 |
| spiv | vila: so in Python 2.6 when a thread finishes it acquires the global _active_limbo_lock, calls self.__stop (which would wake up the thread doing the join), deletes its entry from the _actives dict and then releases the lock. | 08:29 |
| spiv | vila: but active_count and enumerate both acquire that global lock before doing their work | 08:29 |
| spiv | vila: so, I would expect that when join returns that the other thread is still alive momentarily, but that you would not be able to see that by calling threading.enumerate or threading.activeCount | 08:30 |
| johnf | ok it is a plugin | 08:30 |
| vila | spiv: I agree with the theory :D | 08:30 |
| vila | spiv: to add data: using 'del thread ;thread = None' helped | 08:31 |
| johnf | ahh search plugin is the culprit | 08:31 |
| vila | I'm not sure I've addressed the issue completely though... | 08:31 |
| vila | since that wasn't reproducible nor my main goal, I'd look into it when the ~2000 remaining leaks will be fixed... | 08:32 |
| spiv | vila: maybe set threading._VERBOSE = True? | 08:32 |
| spiv | (and run without -O) | 08:32 |
| vila | spiv: I note that | 08:32 |
| igc | hi vila, bialix, johnf | 08:33 |
| bialix | hi igc | 08:36 |
| spiv | vila: yeah, doing "del thread ;thread = None" sounds likely to help more for the fact of just adding a small delay rather than because of what it does. | 08:37 |
| bialix | wow! bzr.dev's NEWS is almost 500KiB in size! crazy | 08:37 |
| vila | spiv, poolie: Anyway, given the amount of work and thinking involved when tracking leaked threads, a warning still sounds fine, we use threads in the test infrastructure and so far this has triggered bugs for selftest only, no need to block | 08:40 |
| vila | In a given working tree where 'make' has been run, py2.4 do not want to load some extensions that 2.5 and 2.6 happily load, any takers ? | 08:45 |
| spiv | vila: extensions were built with 2.5? | 08:46 |
| vila | python --version | 08:47 |
| vila | Python 2.6.2 | 08:47 |
| vila | So I think it was with 2.6 | 08:47 |
| vila | s/I think/I'm sure/ | 08:47 |
| vila | ha, .bzr.log mentions pycurl not available for 2.4, may be related... | 08:47 |
| vila | eeerk, pycurl not supported for 2.4 ? The package dependencies says: Depends: python (>=2.5) ??? | 08:49 |
| vila | on jaunty | 08:49 |
| vila | well, yeah, makes sense, sorry | 08:49 |
| bialix | vila: btw is pycurl still needed? esp @ py2.6? | 08:50 |
| vila | what matters is that pycurl is supported by the default python version | 08:50 |
| vila | bialix: for windows you mean ? Still the same answer: do you care about verifying the certificates ? | 08:50 |
| bialix | for windows yes, I don't care but if I do then I need? The problem is there is no pycurl build for 2.6 for windows | 08:51 |
| * vila cries | 08:51 | |
| bialix | sorry, I did not want | 08:52 |
| vila | :D | 08:52 |
| bialix | that's better | 08:52 |
| fullermd | Oooh, it's THAT easy to make vila cry? I'll hvae to remember that... | 08:52 |
| bialix | I don't understand what I do but I'll try to not do it in the future | 08:53 |
| vila | bialix: nice try ! | 08:53 |
| vila | lol | 08:53 |
| bialix | :-) | 08:53 |
| vila | The problem when you think you will fix a bug tomorrow is that you still encounter it today (or something like that) :D | 08:53 |
| spiv | fullermd: mentioning any random collection of frustrating software is a good way to make a developer cry. "pycurl + windows" -> sad. "sourcesafe + anything" -> sad ;) | 08:53 |
| bialix | LOL | 08:54 |
| bialix | what's bad about pycurl on windows? | 08:54 |
| fullermd | Funny you should mention that, I was just thinking we should try and get sourcesafe working on SCO... | 08:54 |
| vila | fullermd: by the way, not a single 8.0rc1 crash since I swapped the IDE controller | 08:55 |
| bialix | or maybe you mean "anything + windows" == mwhaa-mwhaa-haa | 08:55 |
| vila | bialix: nope, he just refer to the fact that pycurl is not packaged for 2.6 on windows (you just mentioned that) | 08:55 |
| fullermd | Wacky. I wonder what it didn't like about the original choice. | 08:55 |
| vila | fullermd: I don't :-) | 08:56 |
| bialix | vila: oh, I was not aware you are aware that pycurl is not packaged | 08:56 |
| vila | bialix: *you* just said it | 08:56 |
| vila | err, too many negatives here I think :D | 08:56 |
| bialix | I'm working as answering machine in ru_bzr, so just yesterday one man asking me about pycurl. | 08:57 |
| bialix | vila: I'm happy to not think about pycurl anymore, I'm just need to know right answer | 08:57 |
| vila | bialix: nothing has really changed | 08:58 |
| vila | 2.6 allows a true https test server, so we have better test coverage which allows adding new features more easily, adding the features is still needed though... | 08:58 |
| bialix | vila: I remember you've tried to use ssl module from py2.6. Hence my naive question | 08:59 |
| vila | yes, the ssl module is used for that *and* can be used to implement certificate verification, I "just" need "time" :D | 09:00 |
| fullermd | Well, you don't really NEED all that sleep, do you? | 09:02 |
| bialix | as you said: sometimes people need to lie down and stare to the ceil ;-) | 09:03 |
| vila | fullermd: well, no, but I hoped I could continue to sleep a bit without being noticed... thanks.... | 09:03 |
| * igc dinner | 09:21 | |
| vila | working around 2.4 missing features by trying to use other 2.5 features is.... bound to fail | 09:27 |
| fullermd | Well, obviously. 2.5 features aren't advanced enough for that, you need to use some of the 2.6 stuff. | 09:27 |
| vila | yeah, finally a good use case for 'from future import _feature_' | 09:28 |
| vila | spiv: if you're still there and can re-review https://code.edge.launchpad.net/~vila/bzr/405745-http-hangs/+merge/13050, that would be very nice :) | 09:53 |
| hsn | is somewhere documented bazaar api for plugin writers? | 11:30 |
| mzz | hsn: pointing your favorite apidoc tool at bzrlib should do the trick | 11:32 |
| mzz | hsn: (also reading other plugins) | 11:32 |
| mzz | hsn: I don't know if there's a nice introduction to writing plugins up anywhere | 11:32 |
| hsn | you mean eclipse? | 11:32 |
| mzz | hsn: that's definitely not *my* favorite apidoc tool, but just use whatever you like :) | 11:32 |
| bob2 | http://bazaar-vcs.org/WritingPlugins | 11:32 |
| mzz | ah, great | 11:33 |
| hsn | i need to write repo export plugin | 11:33 |
| mzz | hsn: might want to use the existing fastimport one | 11:33 |
| hsn | what is fastimport? | 11:34 |
| mzz | hsn: imports and exports a format that was originally invented for git iirc but supported by many dvcs systems now | 11:41 |
| mzz | hsn: depends a bit on what your "repo export plugin" is for, obviously | 11:41 |
| hsn | we will move from bazaar to Jazz SCM | 11:42 |
| james_w | yeah, look at writing a fastimport importer for Jazz | 11:44 |
| hsn | https://jazz.net/wiki/bin/view/Main/SCMChangeSetArchive - Jazz import SCM format | 11:50 |
| mzz | yeah, consider writing something that converts from fastimport format to that | 11:55 |
| * awilkins looks at Jazz, sees word "Rational" and shudders | 12:13 | |
| * mzz wonders why he's not allowed to read that wiki page without an account | 12:18 | |
| === sabdfl1 is now known as sabdfl | ||
| === menesis1 is now known as menesis | ||
| bialix | why commit don't commit files in alphabetical order? | 13:34 |
| bialix | http://pastebin.com/m5b205d56 | 13:36 |
| === mrevell is now known as mrevell-lunch | ||
| smartgpx | bialix - 'bzr ci' does commit in alpha order, but 'bzr qci' does not. | 14:37 |
| jam | bialix: from the paste you gave, it looks like we commit in the order you supplied the arguments. | 14:37 |
| jam | so "bzr commit" does | 14:38 |
| jam | but "bzr commit foo bar a q z" will commit in that order | 14:38 |
| === Noldorin_ is now known as Noldorin | ||
| === mrevell-lunch is now known as mrevell | ||
| smartgpx | bialix: my python is close to non-existent, but I think the | 14:50 |
| smartgpx | question becomes " what order is used to build the tree passed | 14:50 |
| smartgpx | to QBzrCommitData in commit.py in QBzr?" | 14:51 |
| bialix | jam: if you look closely on arguments passed to commit -- you'll see they all in alpha order | 14:55 |
| bialix | jam: [u'host.c', u'host.h', u'i2c.c', u'i2c.h', u'main.c', u'packets.h', u'version.h'] | 14:55 |
| bialix | jam: but commit emits different order: host.c host.h packets.h i2c.c version.h main.c i2c.h | 14:56 |
| bialix | smartgpx: "'bzr ci' does commit in alpha order, but 'bzr qci' does not." -- qci invokes plain commit under the hood, do you know? | 14:57 |
| bialix | hi jam | 14:58 |
| smartgpx | bialix: yes, I realise that - but try for yourself - | 14:58 |
| bialix | try what? | 14:58 |
| smartgpx | ci and qci give different results. (I can see that the | 14:59 |
| smartgpx | logging gives the same file order... ) | 14:59 |
| jam | bialix: we go through "osutils.minimum_path_selection()" which seems to use a set() and then passes that to the next level | 14:59 |
| jam | so we step through the supplied filenames in a 'set()' ordering | 14:59 |
| bialix | it sounds like the case | 15:00 |
| smartgpx | bialix: compare "bzr ci" with [after uncommit] "bzr qci" | 15:00 |
| smartgpx | file size and datestamp seem NOT to be an influence | 15:01 |
| bialix | smartgpx: see http://pastebin.com/m6d4ac53b | 15:02 |
| bialix | jam is right -- it's a set() issue | 15:02 |
| bialix | jam: may I file a bug and provide the patch to fix this? | 15:02 |
| jam | smartgpx: 'bzr ci a b c' will have the same issue | 15:02 |
| jam | bialix: I would be ok with it, but why does it matter? | 15:03 |
| jam | just visually pleasing? | 15:03 |
| bialix | because I pedantic and this was my wtf moment for today | 15:03 |
| bialix | and visualy pleasing | 15:03 |
| smartgpx | bialix: sorry, hadn't thought of passing the explicit file | 15:04 |
| bialix | np | 15:04 |
| smartgpx | list to 'bxr ci'. Yes, its does not do what one would | 15:05 |
| smartgpx | expect. (But perhaps there was never a contract that the | 15:06 |
| jam | bialix: so interestingly, I think minimum_path_selection already has the sorted list | 15:06 |
| smartgpx | commits would be performed in the order you expected. :-) ) | 15:06 |
| jam | and just turns it into a set for the heck of it | 15:06 |
| jam | we might consider changing that | 15:07 |
| bialix | I hope it's not performance critical change | 15:07 |
| smartgpx | Right, that's one bit of tinkering for today. Now, is | 15:07 |
| smartgpx | Vincent (vila) active right now? | 15:08 |
| jam | bialix: well, there are going to be some other issues | 15:08 |
| jam | looking at the code | 15:08 |
| vila | smartgpx: pong | 15:08 |
| jam | for example, we may add items to the search list | 15:08 |
| jam | and see this comment | 15:09 |
| smartgpx | vila: are you free to discuss the webdav issue I raised? | 15:09 |
| jam | http://paste.ubuntu.com/288646/ | 15:09 |
| jam | where it specifically asks "should we be sorting here?" | 15:09 |
| vila | smartgpx: bug # ? | 15:09 |
| smartgpx | vila: probably my misunderstanding and not a bug, so no # yet | 15:10 |
| vila | oh, yes, wait a min | 15:10 |
| bialix | jam: it seems (commit.py) that specific files should be sorted http://pastebin.com/d5b846202 | 15:11 |
| vila | smartgpx: I need to find your mail back | 15:11 |
| bialix | but apparently they're not. | 15:11 |
| smartgpx | vila: don't bother, no details in it | 15:11 |
| vila | smartgpx: ok, shoot then | 15:11 |
| jam | bialix: so the iter_changes code needs a set at the moment, because it uses things like 'set.add()' | 15:14 |
| bialix | heh | 15:14 |
| jam | which is why I pointed at the line that is doing the 'consuming' and asks whether we should be in sorted order | 15:14 |
| smartgpx | vila: this is probably a deficiency in the webdav'd server | 15:14 |
| smartgpx | I am trying to push to.. | 15:15 |
| smartgpx | I tried bzr push https+webdav to a path I have access to | 15:15 |
| bialix | jam: it's in commit.py? | 15:15 |
| jam | bialix: that code is in _dirstate_helpers_pyx.pyx | 15:15 |
| bialix | oh | 15:15 |
| smartgpx | and got back bzr: ERROR: Invalid http response for https://zdrive.le.ac.uk/d/djr/TryBzrWD/webdav: Unable to handle http code 415: Unsupported Media Type | 15:16 |
| jam | commit is now layered on top of 'iter_changes' | 15:16 |
| jam | on the flip side it also probably means that 'bzr diff foo bar baz' isn't going to be in sorted order either | 15:16 |
| smartgpx | vila: but on reading the docs for the Server again it says... | 15:16 |
| jam | I would say that in iter_changes you could keep a sorted list, along with the set | 15:16 |
| jam | and work that way | 15:16 |
| jam | or change the internal set into a list, and extract one, and always append to the end, etc | 15:17 |
| * bialix checking diff | 15:17 | |
| vila | 415 !!! lol, what's that :) | 15:17 |
| bialix | jam: diff is sorted | 15:17 |
| bialix | jam: IIRC filenames for diff sorted manually | 15:17 |
| bialix | maybe I can just sort entries after iter_changes in commit.py? | 15:18 |
| vila | smartgpx: do you administer that webdav server ? | 15:18 |
| jam | bialix: I think it would be better to have the search_specific_files be a sorted list | 15:19 |
| bialix | in qdiff we did: | 15:19 |
| bialix | for (file_id, paths, changed_content, versioned, parent, name, kind, | 15:19 |
| bialix | executable) in sorted(changes, key=changes_key): | 15:19 |
| bialix | so diff is sorted | 15:19 |
| vila | down to 44 leaking tests... | 15:19 |
| vila | ... but still chasing a random hang :-/ | 15:20 |
| bialix | but iter_changes apparently returns unsorted list | 15:20 |
| smartgpx | vila: No, I don't run the server. The docs say \ | 15:20 |
| bialix | jam: it seems some clients of iter_changes (like status and diff) sort the list ourselves; but commit is not | 15:20 |
| smartgpx | "Known Problem 1: You cannot create new files using WebDAV. | 15:21 |
| smartgpx | You can move, delete, rename, open and view the properties of a file, but you cannot create new files. | 15:21 |
| jam | bialix: I would like to avoid batching if we can | 15:21 |
| jam | and sorting afterwards requires batchnig | 15:21 |
| jam | batching | 15:21 |
| bialix | what is batching? | 15:21 |
| smartgpx | vila: www.w3.org says "10.4.16 415 Unsupported Media Type | 15:21 |
| jam | bialix: grouping everything together before going on to the next step | 15:21 |
| vila | smartgpx: that sounds coherent with 415 Unsupported media type | 15:21 |
| smartgpx | The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method. " | 15:21 |
| vila | smartgpx: yeah, got my RC2616 handy | 15:22 |
| vila | smartgpx: I never encounter 415 before | 15:22 |
| smartgpx | vila: So, I just wanted to close the dangling query with | 15:22 |
| bialix | jam: I don't understand | 15:22 |
| vila | s/RC2616/RFC2616/ | 15:22 |
| smartgpx | you to say that I am prepared to accept this is a server | 15:22 |
| smartgpx | shortcoming, not failure in the webdav plugin. | 15:22 |
| vila | smartgpx: well, if the server doesn't let us *create* files, there is little we can do... | 15:23 |
| bialix | jam: commit.py has 2 methods: _update_builder_with_changes, _filter_iter_changes | 15:23 |
| bialix | the former invokes iter_changes | 15:23 |
| bialix | I can sort there | 15:23 |
| smartgpx | vila: Yes agreed. It's odd that I can create directories | 15:24 |
| vila | the webdav plugin requirement is that the server implement a subset of commands that allows emulating a remote file system, a very rough file system, but a file system, so not being able to create files... | 15:25 |
| smartgpx | but not files. And the IE 'web folders' client must have | 15:25 |
| jam | bialix: consider the 'initial commit' case, where you don't supply any specific files, and it commits 10-20k files | 15:25 |
| jam | I don't want to wait to sort those 20k entries before we commit | 15:25 |
| jam | I'd rather have it just stream | 15:25 |
| vila | smartgpx: that may be because directories are not really on disk but "collections" in DAV lingo, may be that server has some special purposes to begin with ? | 15:25 |
| jam | 'specific files' is always going to be a fairly small list | 15:25 |
| jam | because it is supplied by a human (most times) | 15:25 |
| smartgpx | a way of creating the files when it uploads them. | 15:26 |
| bialix | unless it supplied by our dumb qcommit | 15:26 |
| vila | smartgpx: IE web folders ? | 15:26 |
| Tak | yeah, md-bzr often specifies a large list of files as well | 15:26 |
| bialix | so what about to not filter is there is no specific_files? | 15:26 |
| bialix | or to not sort if len(iter_changes) > 100, say? | 15:27 |
| jam | bialix: I really think sorting specific files is the 'right' approach | 15:27 |
| jam | and I even think it isn't too hard to do in the internals | 15:27 |
| bialix | jam: but they're sorted | 15:27 |
| jam | search_specific_files is a set | 15:27 |
| jam | change that into a sorted list | 15:27 |
| jam | inside _iter_changes | 15:27 |
| jam | or submit a bug, and see if one of us gets around to it | 15:28 |
| bialix | unlikely | 15:29 |
| bialix | this turns to be not 5-minutes fix, so I don't want to increase entropy | 15:30 |
| bialix | it's only for me the page https://launchpad.net/bzr loading toooooo long? | 15:31 |
| bialix | because of downloads links? | 15:31 |
| bialix | sheeze, 1718 Open bugs. | 15:32 |
| bialix | according to kfogel book number of open bugs is good sign, but I think it's actually Gaussian graph | 15:32 |
| bialix | jam: no sir, I'd keep myself from filing new non-critical bugs | 15:33 |
| fullermd | I can open a bunch if that'll help ;) | 15:33 |
| bialix | fullermd: it does not help me | 15:38 |
| jam | bialix: filed as bug #446382 | 15:42 |
| ubottu | Launchpad bug 446382 in bzr "commit with specified files does not go in lexicographical order" [Medium,Confirmed] https://launchpad.net/bugs/446382 | 15:42 |
| bialix | jam: thanks | 15:42 |
| bialix | so fixing iter_changes will definitely provides benefits for other clients as status and diff | 15:43 |
| hsn | fastimport format can handle all bazaar features? i.e. tags and directory renames? | 15:45 |
| bialix | hsn: no | 15:46 |
| bialix | hsn: there was discussion in ML about extending fastimport format | 15:46 |
| bialix | you need to ask Ian (igc) | 15:46 |
| === deryck is now known as deryck[lunch] | ||
| tsmith | hey is there such a thing as bzr diff -r9..HEAD ? | 16:16 |
| bialix | bzr diff -r9..-1 | 16:20 |
| Lo-lan-do | "bzr diff -r9.." should be enough, no? | 16:21 |
| idnar | what is bzr cbranch? | 16:22 |
| idnar | somehow the help text fails to explain what it actually /does/ | 16:23 |
| roychri | Hello fellow bzrers, I am new to bzr and I have troubles. I created a local repo (bzr init) added some file and committed. I use "bzr push sftp://..." and it created a folder on my remote server with folder .brz and no errors. When I try to branch from the "http" version, I get bzr: ERROR: Not a branch: "http://example.org/code/bzrtest/.bzr/branch/". | 16:29 |
| roychri | where example.org is replaced with my actual site domain, of course. | 16:29 |
| roychri | Any ideas? | 16:29 |
| bialix | roychri: permissions? | 16:30 |
| roychri | bialix: readable by all. | 16:30 |
| bialix | Lo-lan-do: maybe, but in fact it's easier for git-man to remember that HEAD is -1 in bzr | 16:30 |
| bialix | roychri: can you open the URL in the error? | 16:31 |
| bialix | and see there format file | 16:31 |
| roychri | I see branch.conf but I do not see any file called "format" | 16:32 |
| roychri | by openiing the url | 16:32 |
| roychri | But the branch.conf file is empty. | 16:33 |
| bialix | that's the problem | 16:33 |
| bialix | without format file the branch is inconsistent | 16:33 |
| roychri | hmm | 16:34 |
| roychri | why would the "push" not put it there and not report any errors? | 16:34 |
| bialix | can you check over sftp? | 16:34 |
| bialix | that the file is there? | 16:35 |
| roychri | I am on the server with SSH. Not there. but it's in my local repo. | 16:35 |
| roychri | wait | 16:35 |
| roychri | it's there | 16:35 |
| roychri | sorry | 16:35 |
| roychri | but not listed on the web | 16:35 |
| roychri | ok, I see the problem | 16:36 |
| bialix | permissions? | 16:36 |
| roychri | I have an .htaccess file in one of the parent folder | 16:36 |
| roychri | <FilesMatch "...lots of stuf...|format">Order allow,deny</FilesMatch> | 16:37 |
| bialix | ok | 16:39 |
| roychri | nice, thanks bialix :) | 16:41 |
| roychri | works now. | 16:41 |
| bialix | happy to help (TM) | 16:42 |
| * bialix feels that quote is a bit incorrect, vila should know the right one | 16:43 | |
| vila | bialix: *always* happy to help (tm) and the original author is jam (from my pov :) | 16:44 |
| bialix | right | 16:46 |
| * bialix writes this on the wall | 16:47 | |
| Tak | jelmer: ping | 16:59 |
| === beuno is now known as beuno-lunch | ||
| === deryck[lunch] is now known as deryck | ||
| vila | . o 0 (threads... sockets... You're soooo funny... not) | 17:36 |
| vila | down to 50 tests leaking (from 2000 this morning) but.... --parallel=fork now hands...... | 17:37 |
| * vila cries | 17:37 | |
| vila | s/hands/hangs/ | 17:37 |
| fullermd | vila: Well, look at the bright side; if it's hung, it's not leaking :p | 17:57 |
| vila | fullermd: Yeah, I thought that for a while and then... the idea that fixing socket and thread related bugs can trigger another one that seems so unrelated, but I just realized how I should balance join(timeout) to track such hangs (since each one is a painful bug) | 18:03 |
| vila | and, well, I stopped crying :) | 18:04 |
| bialix | jelmer, lifeless: ohloh is failed to import bzr.dev branch: https://www.ohloh.net/p/bazaar/enlistments | 18:11 |
| jam | well, I finally got up all of my static-tuple work up for review | 18:14 |
| jam | split into 6 easier-to-review proposals | 18:16 |
| jam | now I just need to find someone who will actually do a review. | 18:16 |
| bialix | jam: nice post | 18:19 |
| jfroy|work | I have a branch of a svn repository that has a bunch of ghost revisions and some sha1 mismatches | 18:22 |
| jfroy|work | reconciling doesn't solve any of those things | 18:22 |
| jfroy|work | is there a way to clean things up, perhaps by replaying each commit into a new branch? | 18:22 |
| jfroy|work | I don't care about creating a new history -- I just want to preserve the content of the history | 18:23 |
| bialix | jam: why in purple branch you don't merge blue branch; according to your method it should be done, no? | 18:24 |
| bialix | oj, you merged green one | 18:25 |
| bialix | nice | 18:25 |
| jam | bialix: they are independent features, both based on one earlier feature | 18:26 |
| bialix | I see now | 18:26 |
| jam | (use static tuples in chk map is independent of using it in btree index, but both require static tuples to exist first) | 18:26 |
| Tak | jfroy|work: ugh, I've had that a couple of times | 18:27 |
| jam | wow, I've finally managed to have more commits in bzr than poolie. Not bad considering he had a 1500 commit head start :) | 18:27 |
| * bialix dreaming about the tool of preserving annotations when only space changed inside the line | 18:27 | |
| jam | bialix: with the current code it would actually not be too hard to do | 18:27 |
| bialix | not be too hard? | 18:28 |
| Tak | I've transitioned to only dpush/pull/rebase with svn branches | 18:28 |
| bialix | according to soe theory if you drop any "no" and "not" you'll see the truth | 18:28 |
| bialix | too hard | 18:28 |
| bialix | :-) | 18:28 |
| jfroy|work | Tak: I used bzr-svn 0.3 on that branch and every version since then, including development version | 18:28 |
| jfroy|work | So I blame it on that -- pretty sure bzr-svn 1.0 is reliable now | 18:29 |
| jfroy|work | I just kind of want to start over with that branch w/r to bazaar (and I'm transitioning to a new svn repo soon) | 18:29 |
| jam | bialix: well, define 'too hard', but there is 1 line of code that needs to be changed... | 18:30 |
| jfroy|work | maybe I should just migrate using svn and filter out all the bzr-svn metadata out, but last time I looked at doing that, it didn't seem entirely trivial | 18:30 |
| jam | well, 2 lines if you count word-wrap | 18:30 |
| bialix | lol | 18:30 |
| jam | _annotator_py.py line 143 | 18:30 |
| jam | matcher = patiencediff.PatienceSequenceMatcher(None, | 18:30 |
| jam | parent_lines, text) | 18:30 |
| jam | change that to something that creates matches ignoring whitespace | 18:30 |
| jam | and boom | 18:30 |
| jam | it is something I wanted to get to with annotation policies, etc | 18:30 |
| jam | the code is mostly factored out to do so | 18:30 |
| jam | I just didn't finish it | 18:30 |
| bialix | cool | 18:31 |
| jam | bialix: as a trivial example, you could do: | 18:32 |
| jam | http://paste.ubuntu.com/288759/ | 18:33 |
| jam | well, technically this: http://paste.ubuntu.com/288760/ | 18:34 |
| jam | the previous paste had a typo where I used parent_lines twice | 18:34 |
| jam | I'm not sure that ignoring whitespace changes completely is the right answer, since indentation is meaningful in python | 18:35 |
| jam | change the .strip() to .rstrip() | 18:35 |
| jam | and you have one that ignores changes to trailing whitespace | 18:35 |
| jam | which would include \r\n => \n conversions | 18:35 |
| bialix | well, in C identation is not so critical | 18:35 |
| jam | sure | 18:35 |
| jam | thus the change would be application specific | 18:35 |
| jam | there are also those who feel you should do it via an AST | 18:36 |
| jam | since changing | 18:36 |
| bialix | and even in Python if you change identation, it's not always you're new author then | 18:36 |
| jam | foo = bar | 18:36 |
| jam | to foo = \ | 18:36 |
| jam | bar | 18:36 |
| jam | also is not a real change | 18:36 |
| bialix | yes, this is too | 18:36 |
| bialix | but more complex | 18:36 |
| jam | bialix: anyway, annotation is a fuzzy concept anyway. but if you just want to ignore whitespace, my patch should work | 18:37 |
| bialix | *nods* | 18:37 |
| bialix | always when I think about this whitespace stuff I'm leaning to show 2 authors: original author and the second one who made whitespace changes only | 18:38 |
| barry | hi everybody. i'm starting to play with bzr-pipeline and i'm stuck on something. is anybody able to help me? | 18:40 |
| jam | barry: while usually I would refuse to help you on principle, right now I'm refusing because I need to get food. :) | 18:42 |
| jam | but when I get back I'll give you a hand | 18:42 |
| barry | jam: :D | 18:42 |
| === beuno-lunch is now known as beuno | ||
| bialix | jam: ??? | 18:44 |
| tsmith | wow! BZR 2.0 is out! | 18:50 |
| jfroy|work | mmm | 19:31 |
| jfroy|work | branching lp:bzr/2.0 is stuck in "Finding revisions" slow mode | 19:32 |
| jfroy|work | and isn't on the fast stream fetching code path | 19:32 |
| jfroy|work | as far as I can tell anyways. I'm branching into a brand new 2.0 repo | 19:32 |
| jfroy|work | nevermind | 19:32 |
| jfroy|work | it just started | 19:32 |
| jfroy|work | I guess finding revisions takes a while | 19:33 |
| jfroy|work | could use better progress though, if possible | 19:33 |
| arkanes_ | whats the magic switch to get bzr to show tracebacks instead of just "error"? | 20:01 |
| bialix | bzr -Derror foo | 20:03 |
| arkanes_ | thanks | 20:03 |
| === jfroy|work_ is now known as jfroy|work | ||
| Noldorin | can bzr handle symbolic links in repos? | 21:55 |
| Noldorin | and additionally, can it handles LNK files? | 21:56 |
| bob2 | yes for symlinks | 21:59 |
| bob2 | I guess yes for shortcuts, since they're just normal files | 22:00 |
| Noldorin | bob2: yeah, but i mean actually getting it to resolve the lnk file into the destination file | 22:02 |
| soren | I'm trying to make use of the package branches on Launchpad. The package in question is of an upstream project that also uses bzr. Even though these branches share most of the current code, they share no ancestry. I would like to be able to get to the point where I can take the package branch, and merge from the upstream branch so that changes since the last sync point (upload of a new release to Ubuntu) get applied and nothing else. | 22:03 |
| soren | I /thought/ I had done this.. | 22:03 |
| soren | I took the package branch, and did a "bzr merge -r 0..tag:RELEASE_someversion <upstream branch>". | 22:03 |
| soren | Then I did "bzr revert .". | 22:04 |
| soren | This reverted all the code changes (which was basically a load of conflicts (presumably because bzr has internal file id's for the files in the individual branches)), but kept the merge marker. | 22:04 |
| soren | I committed this change. | 22:04 |
| soren | At this point, I expected to be able to do a "bzr merge <upstream branch>" and end up with a branch with the changes between tag:RELEASE_someversion and tip applied. | 22:05 |
| soren | However, the file id business came back to haunt me :) | 22:05 |
| soren | It basically reported everything as being a big conflict. | 22:06 |
| soren | My use of "bzr revert ." is new. I saw it in "bzr help revert". I've previously done something like this by doing "bzr diff | patch -p0 -R", but when I have to deal with conflicts, this does not give the expected results. | 22:07 |
| bob2 | Noldorin: isn't that a job for your os? | 22:07 |
| Noldorin | bob2: it should be, yes. but this is windows we're talking about here :P | 22:08 |
| soren | I suppose my question is: Is there are way to /really/ make bzr think that I've merged two branches (leading it to believe that files named the same are actually the same file, rather than remembering that they have no common ancestry and must as such be in conflict). | 22:08 |
| fullermd | soren: Not at present. Your problem is that you need a way to say 'these file-id's are the same file' (at the least). | 22:14 |
| soren | fullermd: Right. Hm... That's a shame. | 22:16 |
| tsmith | hey | 22:17 |
| tsmith | in a nutshell waht's the major reason to upgrade from bzr 1.18 to 2.0? | 22:17 |
| fullermd | There's discussion about it every so often, and there are proposals about it. It's just a SMOP at this point. | 22:17 |
| soren | fullermd: SMOP? | 22:17 |
| tsmith | simple matter of programming | 22:17 |
| soren | Simple Matter Of.. | 22:17 |
| soren | Ah. | 22:17 |
| tsmith | he's saying it's very possible but no one takes or has the time | 22:18 |
| tsmith | i'm firmly in the "has no time" category ;/ | 22:18 |
| tsmith | money seems to help SMOP be resolved, from what i see lol | 22:18 |
| soren | I understand. | 22:19 |
| fullermd | Everybody pretty much agrees in broad that it should be done. It's just always a little ways down the stack. | 22:19 |
| tsmith | does bzr have the concept of "HEAD"? like what if i want to diff -r10 to r12 (HEAD) but don't know it's r12? | 22:20 |
| soren | I can't even figure out a proper way to do it manually. :( | 22:20 |
| tsmith | it doesn't seem possible to do bzr diff -r10..HEAD | 22:20 |
| soren | tsmith: -1 | 22:20 |
| soren | tsmith: -1 references the last commit. | 22:20 |
| tsmith | -1? | 22:20 |
| soren | Yes. It indexes from the end of the list rather than the beginning. | 22:21 |
| awilkins | Or you can use an open ended range | 22:22 |
| awilkins | bzr diff -r 10.. | 22:22 |
| soren | True, true. | 22:22 |
| tsmith | -r120.. is taking FOREVER | 22:22 |
| tsmith | but -r120..-1 was quite zippy | 22:22 |
| awilkins | (not sure if that diffs against TREE or TIP though | 22:22 |
| tsmith | what's the difference? | 22:23 |
| awilkins | Ah, is the tree pretty large? | 22:23 |
| tsmith | it has many branches and each branch is ~80 MB | 22:23 |
| awilkins | Tip will be the last committed revision, which is a known state. Tree would be your current working tree. | 22:23 |
| awilkins | Which it will have to iterate over to determine it's state | 22:23 |
| awilkins | Although the dirstate stuff will help | 22:24 |
| fullermd | Neither will go to the tree. That would happen if you did '-r120' | 22:24 |
| fullermd | '-rX..' and '-rX..-1' should be exactly equivalent. Except when they're not. | 22:24 |
| * awilkins believes fullermd but cannot see why r120..-1 would be faster than r120.. in that case | 22:25 | |
| tsmith | -r120..-1 took 0.673s; -r120.. took 3.822s | 22:25 |
| tsmith | the diffs are the same | 22:25 |
| tsmith | i did -r120..-1 first so it can't be memory cache | 22:26 |
| fullermd | It's not impossible that it's doing something shupid. | 22:27 |
| tsmith | like diffing every revision between 120 and 138? | 22:27 |
| tsmith | soren, thank you very much for the -1 concept | 22:28 |
| fullermd | No, but maybe something like building and walking the whole ancestry tree to figure out the latest rev. | 22:28 |
| tsmith | yeah my diskk was quite busy | 22:28 |
| fullermd | Though with 138 revs, unless it's a very broad history tree, that shouldn't take 3 seconds. | 22:28 |
| fullermd | Unless it had to suck it all in from disk, maybe. What's it like with the cache all warmed from the previous run? | 22:28 |
| tsmith | 0m0.641s | 22:29 |
| tsmith | alright here's a protip for everyone | 22:30 |
| tsmith | to have Linux trash your disk cache: | 22:30 |
| tsmith | sudo sync ; sudo echo 3 | sudo tee /proc/sys/vm/drop_caches | 22:30 |
| fullermd | So, same order of actual _work_, but spun a lot on the disk loading stuff presumably unused for doing it. | 22:30 |
| tsmith | same command w/o cache: 0m6.330s | 22:30 |
| pingveno | How do I branch at a specific revision of a branch? | 22:31 |
| pingveno | Another branch, that is. | 22:31 |
| fullermd | File a bug for it, please. That magnitude difference is way out of line. | 22:32 |
| tsmith | bzr branch -r | 22:32 |
| fullermd | pingveno: branch -rX $SRC | 22:32 |
| mathepic | bzr branch has a -r option | 22:32 |
| tsmith | lol that's a simple question ;) | 22:32 |
| pingveno | For revision? | 22:32 |
| pingveno | -r = revision | 22:32 |
| mathepic | -r specifies the revision number (--revision is its long one) | 22:32 |
| awilkins | See `bzr help revisionspec` for all the manifold ways of stating revision numbers | 22:33 |
| mathepic | You also can find the option listed under "bzr help branch", but it tells you to see "bzr help revisionspec" | 22:33 |
| pingveno | Arg! This computer doesn't have bzr installed. | 22:33 |
| mathepic | Download it. :D | 22:34 |
| pingveno | I'm not the administrator on this computer. ;) | 22:34 |
| pingveno | I wish my laptop was working... | 22:34 |
| awilkins | pingveno: Windows or Linux? | 22:35 |
| awilkins | pingveno: You can run it on either without admin rights | 22:35 |
| pingveno | Both. It's a hardware issue. | 22:35 |
| awilkins | No, "this" computer, what's it running | 22:35 |
| mathepic | Does anyone know if its possible to get bzr cdiff working on windows or at least redirect it to bzr diff | colordiff (I have colordiff on cygwin) | 22:37 |
| mathepic | Might not be the right place to ask that though, since its from bzrtools | 22:38 |
| awilkins | mathepic: there's `bzr diff --using colordiff | 22:38 |
| pingveno | awilkins: The keyword is "can". | 22:38 |
| tsmith | mathepic, i have an alias for "diff --using colordiff" nin my cygwin | 22:38 |
| pingveno | Perhaps talking to the administrators would help... | 22:39 |
| awilkins | pingveno: If you have a need to do things with bzr to be productive... I see no issues with downloading it and running it from your home folder / windows user profile | 22:39 |
| pingveno | awilkins: I'll be seeing the guys who do the server administration tomorrow, so I'm not particularly worried. ;) | 22:40 |
| mathepic | What happens if I aliase something to cdiff | 22:43 |
| mathepic | Even though its already there | 22:43 |
| mathepic | Alias seemed to overide it | 22:46 |
| mathepic | Its not finding colordiff | 22:47 |
| mathepic | I think its because colordiff is only available over bash | 22:47 |
| mathepic | Is there a way to make bzr recognize commands available from bash | 22:49 |
| fullermd | You mean for bzr aliases to run external commands? No. | 22:50 |
| mathepic | Thats not what I mean | 22:52 |
| mathepic | I'm trying to alias bzr cdiff to bzr diff --using colordiff | 22:53 |
| mathepic | colordiff is not an exe | 22:53 |
| mathepic | so it doesn't recognize it as a program when trying to use it as a diff backend | 22:53 |
| fullermd | Well, I presume it looks through the path. A fully qualified path might work. | 22:57 |
| fullermd | Don't really know. | 22:57 |
| johnf | lifeless, jelmer; ping | 23:06 |
| lifeless | johnf: hi? | 23:07 |
| johnf | howdy | 23:07 |
| johnf | so I wanted to discuss bzr packaging in debian and version numbers. | 23:08 |
| johnf | Was hoping jelmer would be around as well. Maybe I should send an email to the packaging list | 23:08 |
| lifeless | johnf: you should | 23:16 |
| poolie | hello | 23:16 |
| poolie | hello lifeless | 23:16 |
| lifeless | hi poolie | 23:17 |
| poolie | hi jam? | 23:18 |
| * spiv yawns | 23:27 | |
| fullermd | That 'waking up' thing will kill you yet... | 23:27 |
| poolie | mathepic: that should work, i'm not sure why not | 23:37 |
| lifeless | -> food | 23:38 |
| mathepic | It doesn't find colordiff though - I checked /cygwin/bin and colordiff is not an exe | 23:38 |
| poolie | there is a colordiff plugin you could try | 23:38 |
| mathepic | I'd prefer to make diff use my existing backend though | 23:40 |
| poolie | mathepic: please file a bug for it | 23:43 |
| poolie | it may be easy to fix | 23:43 |
| mathepic | Okay, I will. | 23:44 |
| mathepic | do I file it in the master project (Bazaar VCS and Tools) or the main one (Bazaar Version Control System) | 23:45 |
| mathepic | nevermind, the master project doesn't bug track | 23:45 |
| jam | poolie: hi, I can't stay long, though | 23:47 |
| jam | thought I'd mention that the static tuple stuff is up for review | 23:47 |
| jam | in hopefully 'bite-sized' chunks | 23:47 |
| spiv | jam: oh, nice. You got LP code review to cope with that? | 23:50 |
| mathepic | Okay, I submitted the bug report | 23:50 |
| zsquareplusc | and there is a problem... i have a branch. it says its out of date and i need to use "bzr update" when i do it says i need to check some files in a hidden folder. but it leaves the lock set. | 23:53 |
| mathepic | exact message? | 23:54 |
| zsquareplusc | i've deleteted the files, ran update -> error, break-lock, delete, update->error, break-lock... like 3 or four times until it stopped complaining and update actually worked :/ | 23:54 |
| zsquareplusc | bzr: ERROR: This tree contains left-over files from a failed operation. | 23:55 |
| zsquareplusc | Please examine <..>/.bzr/checkout/pending-deletion to see if it contains any files you wish to keep, and delete it when you are done. | 23:55 |
| zsquareplusc | my complaint is that it leaves the lock set and that i had to repeat the procedure multiple times | 23:56 |
| mathepic | Report the bug | 23:56 |
| poolie | jam, just tell me the email address for your wordpress username? | 23:57 |
| igc | morning | 23:58 |
| igc | hi jam, poolie, spiv | 23:58 |
| poolie | hi igc | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!