[00:00] "This is an easy way to check out a particular version without having to make up a name for the new branch. You can still create a new branch (or tag) for this version later if you decide to." [00:00] BUT HOW DO I DO THAT??? [00:01] james_w: context? [00:01] git [00:01] * SamB suspects jelmer of knowing the answer [00:01] james_w: oh, fail ;) [00:01] * SamB suspected that even without context [00:01] james_w: are you talking about vanilla git or bzr-git? [00:02] just git [00:02] oh, well, first of all, why not ask in #git? [00:03] secondly I believe it's just "git checkout -b branchname sha1" if you want to check out this new branch [00:03] because its not as entertaining? [00:03] I wasn't asking so much as venting [00:14] morning [00:49] hey, if someone will tell me if my diagnosis in https://bugs.edge.launchpad.net/bzr/+bug/400003 is correct, i'll fix the bug [00:49] Ubuntu bug 400003 in bzr "readv(directory, ...) blows up in strange way" [Undecided,New] [00:54] mwhudson: shallowly, it seems ok to 'fix' it by implementing seek [00:56] lifeless: when you say shallowly do you mean simply "i haven't thought about it hard" or "if i thought about it hard i have this niggling feeling i'd have a different answer" ? [00:57] I'm curious why its blowing up here and not other places we might use it [00:57] and I haven't thought hard or even looked at the code to try to answer that [00:58] If I knew *why* I might be able to answer ehther I'd have a different answer or not [01:02] fair enough [01:14] mwhudson: when you file bugs please mark them confirmed and have a stab at setting the priority [01:14] it avoids roundtrips [01:14] even if we sometimes want to change the prioritiy [01:14] i realize not every team does it that way [01:14] poolie: ok [01:14] i don't think i can set the priority [01:14] oh that sucks a bit [01:14] you can join ~bzr if you want though? [01:15] i guess i should [01:16] poolie: i think you need to add me? [01:17] ok [01:17] i'll warn you, you will get more bug spam [01:17] but probably less than you get from lp [01:17] or should i say regarding lp [01:35] * igc kicks off performance test to check whether proposed inv-delta checks make much difference or not [01:36] lifeless: ^^^. I'm still going over the dirstate.py and inventory.py changes in your patch. All the rest is ok by me. [01:44] * Luke-Jr_ spams jelmer with https://code.launchpad.net/~luke-jr/bzr-svn/0.6-WildcardLayout-get_tag_path-basic/+merge/8858 === Luke-Jr_ is now known as Luke-Jr [01:46] igc: thanks [02:04] mwhudson: oh also, not to be picky, but you can do better as far as titles [02:04] poolie: probably [02:05] i actually had a far more specific title at first, and then tried to step back to describing the problem, not my presumed solution [02:05] but great work on the bug number :) [02:05] :) [02:08] Ok, I think I have no test failures finally. [02:11] nirvana :) [02:23] nammo tassa bhagavato arahato sammasambuddhasa :) [02:40] bbiab [02:48] fooding [03:41] poolie: inventory-delta branch sent to lp for review. If you would like something to occupy your afternoon... ;) [03:46] spiv: hai; I can has review then? [03:47] lifeless: some feedback re your patch ... [03:47] igc: yup [03:47] on OOo, simple commit time goes from 1.8s to 3.3s [03:47] ah, apply-delta [03:47] 2. the test suite is failing too [03:48] I ran the full suite on ec2 :( [03:48] could you get me the failing test names? [03:48] lifeless: sure, but after I get some lunch! [03:48] igc: so, that could be in create_by_delta *or* in dirstate's update_basis_by_delta, both of which change [03:49] igc: is the 'simple commit' adding a file or just changing something? [03:49] lifeless: http://pastebin.com/d7954f8c6 [03:49] lifeless: changing a committed file [03:50] lifeless: the test suite hung completely btw in test_get_nested_trees [03:50] lifeless: I'll try it again [03:50] I'll see if I can get a handle on it; but I may need you to get an lsprof of the commit time before and after [03:50] to see which of the appliers is regressing [03:50] heh those deltas are bogus [03:51] lifeless: thanks. I haven't tried to see how reproducible the issue is [03:51] if the applier were to choose to apply the second component first it would end up deleting [03:51] so - thats good to know, its an existing bug I suspect, and really quite a bad one ;) [03:52] lifeless: long live defensive programming! [03:53] lifeless: some other quick feedback ... [03:53] the while in update_minimal will loop forever? [03:54] the messages in dirstate._apply_removal ... [03:54] 1. should the first 2 be exactly the same text? [03:55] 2. "wrong has wrong id" in the 3rd message [03:55] man I *hate* reviewing dirstate changes :-( [04:01] igc: perhaps those three are best done via a pastebin of the diff with notes [04:02] or a reply to the merge proposal [04:02] sure [04:03] lifeless: also http://pastebin.com/d35918166 [04:14] * SamB wishes somebody would vote for http://bundlebuggy.aaronbentley.com/project/bzr/request/%3CE1MQZOB-0003MV-Id%40hydrogen%3E -- perhaps jelmer? [04:19] lifeless: commit of whole tree with one file changed [04:19] commit of a single file is 73+ seconds [04:20] SamB: jelmer is having a life this week IIUIC - attending some concert event or something like that [04:20] igc: yup, thats what we're aiming at to fix;) [04:20] igc: noooo! that's impossible! [04:21] you killed my father! [04:21] SamB: I am your ... - um, no I'm not [04:27] * SamB thinks yoda ought to have warned anakin about self-fulfilling prophecies ... [04:42] howdy [04:43] Does --no-trees and lightweight checkouts work flawlessly on Windows? [06:35] poolie: ciao, see you tomorrow [06:35] igc: I'm essentially waiting on lsprof before-after for the bad case to progress that branch. [06:36] lifeless: did you see my approve for ~lifeless/bzr/bug-216541, btw? [06:36] lifeless: ok. I'll collect some data for you [06:36] spiv: thanks [06:36] (i.e. fire it at PQM kthxbye :) [06:36] doing now :) [06:37] then going for the day (\o/ starting at 6:30) [06:37] hmm, technically I'm finishing late as per :P [06:38] igc: to be clear, I'll fix the test fallout, but I don't know where to go with the perf overhead as there are two delta applications made, and in theory a new file should be slower than a mutation to an existing :) [06:40] lifeless: I'll dig and add the profiles to the associated bug [06:40] igc: thanks [07:05] hi all [07:06] hi vila! [07:06] lifeless: done === h4ck3rm1k3 is now known as phurl [08:12] Wow PQM is slow these days. [08:13] It's been on the same branch for nearly two hours, I think. [08:13] (and making progress) [08:13] maybe it's making /real sure/ [08:24] Oh, there we go, one of my branches passed. I guess it was already onto the second branch. [08:25] So probably it's "only" an hour for a branch to land. [08:26] Ah well. [08:56] spiv: argh; NEWS conflict with your branch :( [08:58] lifeless: :( [08:58] lifeless: that's what you get for taking credit for your work! [09:03] lifeless: fwiw, the branch of mine currently playing on PQM doesn't add a NEWS entry (it's pretty trivial) [09:03] good to know thanks [09:05] * igc dinner [09:17] If PQM showed the diffstat of merges in its queue it might help people spot potential conflicts... *handwave* [09:49] Offtopic : can you mount a subfolder of a filesystem? === awilkins_ is now known as awilkins [09:51] e.g. - I have a FS that is a "home" folder, but I want to mount a subfolder of it on another system - a softlink isn't working 100% well because when applications are in the folder they see the path through the mountpoint and not the softlink === eyda|mon is now known as eydaimon [09:55] awilkins: You may find it under the heading of 'nullfs'. [09:56] fullermd: Aha, that sounds rather like something useful, ta [09:57] (an additional way of faking it if performance/quirks/etc aren't fatal is via NFS mounting it over loopback) [09:58] awilkins: what os? [09:59] lifeless: Ubuntu Jaunty [09:59] so you have (say) /home as a fs, and want to mount /home/foo at /bar? [10:00] or are you actually talking about network sharing? [10:00] lifeless: I have an external HD with an home folder in it and I currently link a subfolder of that to the same subfolder in my desktop home folder at home [10:01] I boot from the external HD and work from it when I'm in the office [10:01] The problem is that Eclipse adds projects with a path of "/media/tachikoma-home/adrian/...." instead of "/home/adrian/....." when I'm using it via the softlink [10:01] ok [10:02] so on your home machine [10:02] rather than symlinking [10:02] do a bind mount [10:02] mount --bind olddir newdir [10:02] Aha, yes, that's just what I want [10:02] (after mounting it) [10:03] I'm disappointed that didn't show up for googling "mount subfolder of filesystem" [10:03] you should blog about it [10:03] so that it can [10:04] * fullermd adds that to his mental list of 'other names for nullfs'. [10:06] Excellent, not as automatic as a softlink but it actually works properly [10:08] Hate to say it, not as easy as Windows drive letters (although I usually need a drive-letter manager service for similar reasons) [10:08] you should be able to hook it into the automount stuff [10:08] patches++ === abentley1 is now known as abentley [14:49] hi! Is there a way to undo an `unshelve` command? [14:50] maploin: only by doing shelve again. [14:51] So if the change you unshelved is mixed up with other changes you'll have to manually pick them apart again. [14:52] yeah, that's what I was afraid of :( [14:52] thanks, spiv === kiko-afk is now known as kiko [15:08] jelmer: ping === ja1 is now known as jam [15:39] Hhm, since shelve is based on tree transforms now, there's no reason why you couldn't have an "undo shelve" option [15:40] It calculates tree transforms and persists them when you shelve stuff, therefore it could also persist treetransforms that it was unshelving, so you could reverse them if required [15:42] is tortoisebzr supposed to work on mapped drives in windows? I have a branch on a mapped drive and when I right click to bring up the menu, I have none of the bzr options [15:43] just get the Help, Settings, About options [15:43] nothing else [15:44] pdragon: By default it's configured not to examine .bzr folders on network drives, for performance reasons [15:45] pdragon: You can change that in the settinsg [15:45] ahh ok === mvo__ is now known as mvo [15:46] awilkins: thanks, that was it [15:47] and i see what you mean :) [15:48] pdragon: I confess I don't use it ; I'm happy enough just using a Powershell and spawning the qbzr dialogs from there if I want them [15:48] I've actually uninstalled it because I have some horrific bzr trees on my drive and it thrases rather [15:49] yeah, well, I'm introducing version control to a place where it's never been used before [15:49] so trying to start out one something very easy [15:49] I know the feeling [15:49] :-) [15:49] just version controlling different websites in different folders [15:49] no branching or anything. [15:50] As long as it isn't visual sourcesafe [15:50] TortoiseSVN is very mature and usable by the nontechnical [15:50] oh nope... will be all bzr [15:50] I can understand that [15:51] i've been using tortoisebzr for my own project for a while, learning how to use it [15:51] finally had some crap happen at work where i've got them convinced version control is a good idea :) [15:51] but, need to keep it stupid simple to start [15:52] Heavyweight checkouts and a central server :-) [15:55] yeah, i'm starting even simpler. just version controlling our local copy of the website [15:55] it's only 3 people [15:56] will work up to checkouts later :) [15:57] Editing live websites can only lead you to ruin :-) === Pilky_ is now known as Pilky [16:02] oh it's not editing it live [16:02] it's editing our local copy [16:02] which then gets pushed to the server [16:02] i versioned our local copy [16:02] Ah, this is the folder on the network share [16:02] yeah [16:03] pdragon: sorry, I'm back. Wireless failure... [16:05] so much pain... :) [16:05] * fullermd makes a note to buy jam some wires for Christmas. [16:28] Does LP accept/work well with --2a branches? [16:29] woo... got the web developer using it and he likes it :) [16:30] There's a fairly awesome git/ruby-on-rails video that demonstrates branching that might impress him more... [16:31] But I can't find it [16:33] oh trust me... branching is more than these guys want to deal with now since it's such a small team [16:33] they're just interested in a file change history at this point [16:35] our problem is our website is hosted by a third party that does a lot of the behind the scenes stuff on their end since they host all our data (real estate company) [16:36] they're not "supposed" to touch our stuff without talking to us first. but they keep doing it. and they will not share their versioning history with us. so now, we've got a way to keep track of all changes [16:36] it's a shitty system, yeah, but it's what we've got to deal with :/ === FryGuy_ is now known as FryGuy- === abeaumont_ is now known as abeaumont [16:53] thanks for the help awilkins. later [17:20] oh hai [17:20] I broke bzr [19:19] hello [19:20] I'm having a problem with following the emacs bzr repos, which is experimental [19:20] now I get: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. [19:21] how can I extract the changes I made to a branch in a patch? [19:21] my local branch is called xwidget [20:33] ls [20:35] . .. [20:45] <_oggy> hi all. i need to version control a PHP script. it's part of a project whose repository directory is outside of Apache's DocumentRoot. obviously i'd like to track the "live" version of the script instead of copying back and forth. is there a way to do that? [20:52] _oggy, well, ideally, you aren't making "live" changes, so you can just push of upload. [20:53] _oggy, but sometimes you need to. I push the branch to a neutral location, and have the document root be a checkout of the branch. Then I update and commit as needed. [20:55] <_oggy> rockstar: perhaps i didn't explain very clearly. the PHP script is on my box, so it's not "live" in a "deployment" sense, rather "live" in the sense of "i can see the effects of changes i make" [20:56] <_oggy> however i'd like to make it a part of a (mostly non-PHP) repo which lives outside of DocumentRoot, so i can share it with other people [20:56] _oggy, symlinks. [20:57] <_oggy> rockstar: doesn't bzr then just track the symlink, instead of file contents? [20:58] _oggy, put the symlink in your documentroot, have it pointing to the file in your branch. [20:58] Sorry for the ambiguity. [20:59] Why would you want it to be part of something that [I assume, from it being elsewhere] isn't part of the same project? [20:59] <_oggy> rockstar: yeah, but i have to set up PHP (or Apache? forgot which) to allow execution outside the DocumentRoot [21:00] <_oggy> rockstar: not that it wouldn't work, i was just hoping for something more elegant :) [21:00] _oggy, just set up up to follow symlinks. [21:01] As long as it knows to follow the symlink, you shouldn't have any problems with where the file actually is. Apache won't differentiate between an actual file in DocumentRoot and a symlink to a file outside DocumentRoot. [21:01] <_oggy> fullermd: it is a part of the project, but the project is mostly non-PHP, so it doesn't make sense to put it inside of DocumentRoot [21:02] <_oggy> rockstar: yeah, i know. thanks. i was just hoping there was a way to tell bazar to track the symlink directory content instead of tracking the symlink itself [21:04] Well, I always just use Makefiles to deploy into docroots. But that's deployment, for dev I always just have symlinks into the working branch anyway. 's simpler. [21:05] <_oggy> fullermd: yeah, it probably makes more sense that way anyhow === ja1 is now known as jam [21:16] hi all [21:16] hi asabil [21:16] hey pygi [21:16] how are you doing enemy? [21:17] enemy ? [21:18] that's a joke [21:19] :) [21:22] is there some way to extract all changes to a branch as a patch? [21:26] jave: bzr diff -r ancestor:../my-pappa [21:27] the ancestor is corrupt [21:27] jave: You need to know the revision it was branched from them [21:27] bzr diff -r n.. # where n is the revision [21:28] the branch was merged several times from upstream [21:28] jave: It'll be the last merged revision then [21:28] jave: Assuming you didn't cherrypick [21:29] no cherrypicking [21:30] is it really "bzr diff -r n.." ? cant find that syntax in the manual? [21:32] bzr help diff ; bzr help revisionspec [21:32] Thanks [21:33] Hmm, I could be wrong about the range part [21:33] how can I ask bzr from a shell script whether my working tree is clean? [21:35] anyone aware that the bzr nightly packages are not installable on hardy? [21:35] mgedmin: bzr status ? [21:35] it returns the same exit code in both cases [21:36] they depends on python-central >= 0.6.7 and 0.6.5 is available in hardy [21:36] I could play with grep, but I'm afraid of misundestandings [21:36] Well, depending on exactly what you mean by 'clean', it should have NO output at all. [21:37] good idea [21:37] I probably want to stop if there are unversioned files [21:37] An alternative would be using version-info [21:40] bzr version-info --check-clean is what I was looking for, thanks! [21:48] is there a restricted shell like thing to install as shell for an user, so that he can only do bzr+ssh? or maybe something similar to mercurial-server [21:49] jelmer: is there anyway to instruct bzr-svn to not try and figure out the tags/branches layout of an svn repo? [21:54] zsquareplusc: bzr shell from plugin "bzrtools" [21:55] garyvdm: thanks. now that's a name that is easy to search in google ;-) heh [21:56] moin [21:57] hm. but bzr shell -> ls shows all files on the disk. not really "restricted" [22:01] rocky: why would you want to do that? [22:01] jelmer: because this particular svn repo i'm dealing with doesn't have tags/branches folders and blocks access further up which means bzr-svn barfs with 403 [22:04] bzr shell isn't anything restricted, it's just a shortcut for running commands. [22:04] You can limit what commands can be run with various ssh keys somehow... [22:06] rocky: I'd argue that bzr-svn sould handle the 403 [22:06] rocky: you can also specify a manual repository layout [22:06] well i'm not really arguing anything, but i do think it's a little odd that bzr-svn depends on finding a svn layout [22:09] rocky: what's odd about that? [22:09] rocky: the alternative is requiring users to specify a repository layout manually always [22:09] i guess [22:10] jelmer: how do i do it manually btw? [22:11] jam: could I bother you for https://code.edge.launchpad.net/~lifeless/bzr/bug-395556/+merge/8857 again please [22:30] lifeless: you are doing "from copy import deepcopy" but it doesn't look like you are using it [22:30] lifeless: and you update the comment, but again, it isn't accurate now [22:32] lifeless: weird, the code review page you linked doesn't actually give me the ability to review it.... [22:32] maybe because of a text conflict? [22:33] or maybe the ui just changed [22:33] since it still has the "review or comment" link, I guess [22:34] poolie, ping? [22:43] jam: oh doh, thanks for the catch on th ecomment [22:43] and import [22:43] lifeless: I've got a bit more [22:43] sending it as a real review [22:43] thanks [22:43] this at least passes all commit tests [22:43] the other win shoved a different test out [22:43] s/win/one [22:44] lifeless: review sent [22:44] you also have ".decode('utf')" in the new tracing code [22:44] rather than 'utf8' [22:44] etc [22:44] blah, thats shoddy of me [22:44] and a code comment that says "we update an iterator" when you are popping an entry out of the list [22:44] I don't see anything done to an iterator [22:45] jam: you have seen my lazy-import aware pyflakes? [22:46] mwhudson: other than hearing a while back that it existed, I haven't really done anything with it [22:46] jam: just because you said [22:46] As near as I can tell, you don't use deepcopy anymore so you don't need to import it [22:46] +from copy import deepcopy [22:47] mwhudson: :) but does it work on patches I read via HTTP? [22:47] jam: ah, no [22:48] you could probably write a thing that automatically reported flakes on proposed reviews using the api... [22:49] This is a bit of an odd question, but I'm finding bzr st to be pretty slow on my system (cygwin on WinXP). I do have a lot of files in this depot however, so I'm not sure if there's much that can be done, but I'd be interested to hear if there's any 'tricks' to speed it up? [22:49] KhaZ: don't use cygwin [22:49] use the win32 port directly [22:49] KhaZ: did you compare with a native python + bzr? [22:49] last I checked it was ~2x faster [22:50] cygwin adds a *lot* of per-path overhead [22:50] Huh, OK. I'd like to try that. Would it make a difference if I call the native binary from within cygwin? [22:50] and status has to hit every path in your tree [22:50] KhaZ: I do it all the time [22:50] Ah, I see. So perhaps even running within cygwin would be slow. [22:50] no [22:50] native win32 [22:50] Really? but running the native app within cygwin; wouldn't the same pathing routines be called? Well, maybe not now that I think about it. [22:50] doesn't have to ask the cygwin.dll to translate the path [22:51] I guess it calls win32 api's directly rather than cygwin's emu layer. [22:51] yep [22:51] Right. OK, I'll see about switching. I don't need to re-init my depot, do I? [22:51] nope [22:51] Alright. I'll just wait for this crazy slow commit to finish. [22:51] the only thing that might effect you is if you were using symlinks or executable bits [22:51] Nope. this is a windows app, so I'm "lucky" that way. [22:52] KhaZ: "time /bin/python bzr st" on my machine is 1.5s, "time bzr st" (native) is 0.421s [22:52] Not perfectly apples-to-apples [22:52] but > 2x [22:56] hello emmajane, hello jam [22:56] poolie, hey :) [22:56] poolie, have you got a minute or two for a PM? [22:57] sure [22:57] cool [23:01] Oh, neat. And I don't need a native version of bzr, but a native version of python? Is that right? [23:03] KhaZ: there are a lot of ways to do it, but if you have the native python executable you can run from there [23:03] jam: how much longer are you around? [23:03] however, it also sounds like you might not be running with the compiled extensions [23:03] which is another big win [23:03] lifeless: just about to leave [23:03] If you want, we can talk via phone [23:05] jam: I am hoping to land this patch is all [23:05] jam: I've replied to the review [23:06] I need about 5 minutes to make the last tweak I realised that would make it better [23:28] What would you call the different methods of talking to remote bzr depots? 'transports'? (I'm talking about things like bzr+ssh, etc). [23:28] I'm trying to look up the different tyeps to pick the best one for my sitaution. [23:28] Man, my typing is swill today. [23:30] bzr help urlsepec [23:30] bzr help urlspec [23:30] Ah; thanks. [23:31] lifeless: BTW, I got a few minutes to try fiddling with libcpuinfo build... [23:32] I had to make some tweaks I don't entirely understand to configure.ac to get it as far as running configure. [23:33] fullermd: thanks [23:33] How do I test the language bindings? [23:34] * fullermd doesn't see a counterpart to the bin/p_count [23:35] lifeless: http://paste.ubuntu.com/220120/ [23:36] (LT_* just got passed straight through as text, which blew up when running ./configure. automake got cranky without the AC_PROG) [23:36] what version of libtool and autoconf do you have? [23:37] Looks like it would be using ac 2.62, am 1.10.1, lt 1.5.26 [23:38] I think it needs lt 2* for the new syntax [23:38] which builds a lot faster [23:39] Mmm. Not even a port for lt 2. [23:39] ?! [23:39] seriously? its up to 2.2.x these days [23:39] Nyet, only 15. [23:40] feel like some yak shaving? [23:41] Whoops, afk, I have to clean my hair and rearrange my underwear drawer. [23:41] lol, ciao [23:59] morning [23:59] Alright, can anyone recommend the easiest urlspec to use with Windows users who prefer stuff to 'just work'? I'm thinking of something like samba shares and just file://.... Is that rife with problems?