[00:30] morning [01:05] Good morning. [01:07] morning spiv [01:29] spiv: feeling better ? [01:30] lifeless: yes, thankfully. [01:31] I can't guarantee I won't brainfade in the afternoon again... but so far so good, and without cold&flu pills! [01:37] ugh [01:39] I just did a merge of two trees of the same codebase that have no revision ancestry. There are very little differences between the two trees but bzr conflicts on all the files because the year in the copyright statement at the top of the files were all updated. [01:41] will trying a different merge method help or bzr just won't be able to figure this out on its own? [01:43] you could write/adapt/improve jams copyright plugin [01:43] spiv: would like to talk gil stuff with you at some point [01:43] ok, really popping out for these chores/lunch [01:44] lifeless: ok === joerg_ is now known as joerg [03:07] We're starting to get on top of the review backlog from the sprint :) [03:07] \o/ [03:18] losa ping [03:19] yo [03:19] can you check balleny's bzr 2.1 branch [03:19] lifeless: sure, in what sense check tho? [03:19] I think the xmlrpc server fell down went boom just as pqm went to do the 2nd-phase push [03:19] ahh. right. [03:19] so there will be another commit in that branch vs lp [03:20] manually push the sucker? [03:21] lifeless: https://pastebin.canonical.com/32485/ so yeah, looks to me like '42 missed [03:21] please sir may I have another [03:22] lifeless: Pushed up to revision 4842. [03:23] thanks a lot [03:23] np [03:23] now I can do -> bzr.dev [03:23] :) [03:24] heh [03:33] garh, bzr-search not-quite-fixified. [03:38] spiv: does bzr merge --weave still call NEWS helper ? [03:43] ugh [03:43] lets say I have two branches [03:43] the second branch is a branch of the first branch [03:44] in the second branch, I've moved files using bzr move [03:44] * lifeless waits for launchpad [03:45] 6 ppm [03:45] :< [03:45] why is that if I make modifications to those files I moved under the original name in the first branch that when I merge the first branch into the second branch I get a text conflict for the original filenames? [03:45] lifeless: I don't recall, I *think* so [03:46] cody-somerville: you shouldn't [03:46] cody-somerville: please file a bug [03:46] cody-somerville: in the situation you just described, you shouldn't. Either there's a bug, or the situation isn't as you described. [03:46] lifeless, I can only assume that maybe I didn't use bzr move when I thought I did? [03:47] You can look at the file-ids [03:47] have a look at bzr log filename [03:47] how do I do? [03:47] in branch2 [03:47] e.g. "bzr file-id FILENAME" [03:47] with -v [03:47] if it shows the rename, you used bzr mv [03:49] sighs [03:49] wasn't moved [03:50] because I merged the first branch into another branch to initial create the 'second branch' and that was a bzr-git import and it shows the files were deleted and then added with new name. [03:50] *initially [03:51] Any way I can give bzr the extra meta-data? [03:52] no, this is a hole. [03:53] * cody-somerville sobs. [03:54] or rather, not trivially. [03:54] you can probably rebase, if you hit things hard enough [03:54] there is a file id mapping feature in that plugin [03:54] damned if I know how to use it though :() [03:54] I'm trying to manage two series of a codebase [03:55] but upstream decided to create a new git branch (or w/e its called in git) for the new series. === tchan1 is now known as tchan [04:35] jam: bzr in C ? I've got a few libraries you might want [04:35] jam: that are slowly building up towards that [04:35] e.g. libvfs === timchen1` is now known as nasloc__ [04:44] anyone want to keep CHK1/CHK2 formats around? [04:44] I wouldn't think so [04:45] There are always old releases if someone does. [04:48] bleh [04:48] Ran 24411 tests in 1013.377s [04:48] FAILED (failures=1, errors=72, known_failure_count=47) [04:53] hello, I got error "Invalid url supplied to transport" when doing bzr checkout svn+http://url [04:54] what's the problem? [04:54] thanks [04:54] echo-area: do you have the bzr-svn plugin installed? (check the output of 'bzr plugins') === Toksyury1l is now known as Toksyuryel [04:55] spiv: yes, if I do bzr checkout svn+ssh://other-url, I am prompted to input the password. But I can't, since the subversion repository is not accessible by ssh for me [04:56] echo-area: odd. pastebin the entire error? [04:56] ok === davidstrauss_ is now known as davidstrauss === lifeless_ is now known as lifeless === FryGuy_ is now known as FryGuy- [05:02] spiv: http://pastebin.com/khtwepfF [05:34] back soon [07:14] does somebody have an explaination to my bzr-svn problem? [07:17] echo-area: I don't, sorry [07:21] spiv: no problem, thank you [07:22] does bzr-svn require pycurl? I found it mentioned here: https://answers.launchpad.net/bzr-svn/+question/11299 [07:22] bzr bzr plugins [07:22] sorry [07:22] check the output of 'bzr plugins' [07:22] I suspect its not loading, and the error will be in bzr.log [07:22] (to support svn+http) [07:23] echo-area: It's not *required* AFAIK, but used if available [07:23] lifeless: http://pastebin.com/khtwepfF <-- output of bzr plugins is pasted here [07:24] vila: bzr-svn uses the svn http core, can't use anything else [07:24] echo-area: and is svn in the list ? [07:24] lifeless: the current run on pqm says (lifeless) Merge 2.1 into 2.0, you meant 2.0 into 2.1 right ? [07:24] blah 2.1 to trunk [07:24] lifeless: yes, it is "16.svn 1.0.2" [07:25] ok [07:25] check your .bzr.log just in case there is an error there [07:25] lifeless: it still uses any available bzr client for some operations (can't remember which but at least OPTION is involved and jelmer asked me to support that directly far too long ago) [07:26] sure [07:28] " blah 2.1 to trunk" cool ! [07:29] I've updated the pastebin content. An exception is thrown when the plugin tries to connect the server [07:29] http://pastebin.com/xsj7q0Ca [07:30] it's here [07:33] I guess the problem is in subvertpy, let me check [07:37] echo-area: try using 'bzr plugins -v' the paths used will displayed and may help you detect a problem in your setup, and as lifeless mentioned, check your .bzr.log ('bzr version' will tell you where it is located)) [07:41] vila: done; the content of .bzr.log reflected the error has been pasted. Btw, when bzr-svn calls subvertpy functions, is the "svn+" part of url stripped off? I.e., at line 249 of transport.py of bzr-svn, does the url parameter begin with "http://" or "svn+http://"? [07:42] I'd expect stripped. [07:42] But ICBW. [07:53] I don't have experience using python before, and I want to change subvertpy's code, so I need help: in this expression _ra.RemoteAccess(url, *args, **kwargs), which field of the definition in the C code of _ra.RemoteAccess is the function gets called? [07:55] echo-area: before modifying code, have you tried using -Dtransport as an additional parameter to the command ? [07:55] it should output more debug stuff to .bzr.log [07:56] vila: no, let me try now. Do you mean bzr co -Dtransport svn+http://...? [07:56] yup, it may give you what you are after with this code modification with a bit of luck [07:59] vila: sadly there's no more output I've not seen. [08:06] echo-area: that Python expression will invoke ra_new in subvertpy/_ra.c (via a little bit of indirection) === radoe_ is now known as radoe [08:09] spiv: yes, and I've located the PyTypeObject "_ra.RemoteAccess" in _ra.c, but that definition does not give me any clue which function to look further [08:11] echo-area: see around line 2071, PyTypeObject RemoteAccess_Type = { [08:12] echo-area: which defines various builtin operations that can be done with a Type object, and also defines the methods and members of that type. [08:12] echo-area: specifically, the constructor for that type roughly corresponds to the tp_new slot (right at the bottom of that struct definition) [08:13] echo-area: and arrays like ra_methods defines the methods instances of that type will have [08:14] echo-area: so _ra.RemoteAccess(...) is calling the _ra.RemoteAccess constructor, which as I said before will mean the ra_new function in that file. [08:15] echo-area: does that help? [08:15] spiv: yes, that's enough knowledge for me to dig deeper. Thank you! [08:16] echo-area: great :) [08:42] echo-area: any luck? [09:56] spiv: no, I was interrupted and am doing other things now. I expect myself solving this problem before the weekend [09:56] s/solving/explaining/ === mrevell is now known as mrevell-lunch [12:59] Hi. If I have a directory hierarchy with several branches under it, synchronizable across machines easily with multi-pull or repo-push, is there any way to easily synchronize changes to the actual hierarchy layout? [12:59] Before nested trees are production quality, that is. === dcoles_ is now known as dcoles === joerg is now known as Guest86 === mrevell-lunch is now known as mrevell === Guest86 is now known as joerg [14:11] Also, why must the shared repository of a branch always be located in a parent directory? [14:11] Seems like it wouldn't be very complicated to simply record the location of the repository in branch.conf [14:39] Hi. Is there some way to colorize bzr diff output? (similar to what git and hg offer) [14:49] jjann: look at cdiff command from bzrtools [14:49] bialix: that's perfect, thanks === tchan1 is now known as tchan [15:55] jelmer_: vila: ping [15:57] I have a bzr-gtk branch that implements collapsing with which I am quite happy now [15:58] should I do a merge request through launchpad? [15:58] or a bzr send to the ml? [15:58] or something else? === deryck is now known as deryck[lunch] [16:01] guijemont: a merge request with a cover lettter explaining if and how you share code with qbzr would be the best [16:02] guijemont: did you tested it with a mysql or emacs branch ? [16:02] vila: my branch still uses ye olde linegraph() [16:02] hmm, i didn't, good idea [16:02] I tested it with itself, and with lp:elisa [16:05] trying with bigger branches may help unless you're into adding automated tests (which are painfully lacking so far) [16:10] I think it will make sense to add some automated tests when the code is refactored to use the qbzr graph generation stuff [16:12] guijemont: hehe, TDD is about doing it the other way around i.e. write tests first :-) [16:12] guijemont: but it's harder to do TDD with an existing code base and no tests [16:13] vila: yeah, and with a code base that doesn't separate things well [16:13] Oh, no, it's much easier. Your changes never break tests :p [16:14] fullermd: you're on the right path young jedi, the next step is to realize that the only that should be written is one that fix a test :) [16:15] s/only/& code/ mandatory typo... [16:15] when i access a svn repo with bzr can it track renames? [16:15] as it seems to stop displaying history for a file at the point at which it was renamed [16:15] Ergo, bzr-gtk is already perfect. QED :) [16:16] haaaaa, that's why it's so hard to ehance code without tests, I should have think about that sooner :) === IslandUsurper is now known as IslandUsurperAFK [16:26] wow, time travel again... I see files created in the future... (5mins and 1.5hours) [16:27] Maybe you're just slow :p [16:27] the really weeird thing is that 'date' displayed value seems correct [16:28] reminds me of today's smbc [16:28] (or was it yesterday?) [16:28] nope, all on the *same* system, no mounted fs involved (that would be too easy :) [16:28] yeah, today [16:29] http://www.smbc-comics.com/comics/20100520.gif [16:29] arf, no samba there :) [16:29] guijemont: :) === davidstrauss_ is now known as davidstrauss [16:52] hmm, I have a few "maximum recursion depth exceeded" [16:52] the code looked good when using recursion :/ [16:52] guijemont: what do you recurse on? [16:53] don't remember [16:53] I might do that in more than one place [16:54] I'll have a look at the backtraces in more detail === deryck[lunch] is now known as deryck [16:55] hmm, actually, the place where I get this is weird [16:56] i think i need a break before plunging into that [16:59] Hi bialix [16:59] Just landed stable scroll for qannotate \o/ [17:00] GaryvdM: Really ? Is it really what I think it is ? [17:01] Hi vila, I think it is what you think it is. [17:01] GaryvdM: that's awesome ! [17:01] GaryvdM: you rock :) [17:01] But is it what I think you think he thinks it is? === Chex_ is now known as Chex [17:01] lol [17:03] * GaryvdM thinks about landing lp:~garyvdm/qbzr/annotate_find. Does it really matter if the ui is inconsistent for a while? [17:03] GaryvdM: doesn't matter to me :) [17:03] mgz: I think I see what you mean... [17:03] boom, maximum recursion depth exceeded in discussion [17:04] GaryvdM: what matters though, is that some bindings should be defined there :-P [17:05] vila: I don't understand [17:06] return should be bound to next by default [17:07] hi vila and GaryvdM [17:07] Is there a recommended way to put multiple branches under a single working directory? [17:07] (With the intention that the working directory is used to switch between the branches) [17:07] when I enter text the 'Find:' field, I'd like 'return' to give me the next match without touching my mouse [17:07] vila: ok [17:08] vila: You and Craig both gave me some feed back. I will go through that first. [17:14] Lor: I don't use that setup myself, but AIUI, lightweight checkouts and the switch command OR the bzr-colo plugin are different ways to achive that today [17:15] Ah, didn't know about bzr-colo. [17:15] Is it some sort of a hack to simulate nested trees until they are fully supported by the core? [17:16] Ah, no. [17:16] Right. [17:19] Lor: Not nested trees. Rather collocated branches. [17:19] Lor: Like git [17:19] Right, I'm reading the docs now. [17:19] It's just an alternative directory layout convention for lightweight checkouts? [17:20] Does it work with bzr-pipeline? === beuno is now known as beuno-lunch [17:24] Going out for a bit. bbl [17:29] jelmer_: are you there? === IslandUsurperAFK is now known as IslandUsurper [17:41] Is there really a performance overhead for storing multiple unrelated projects in the same shared repository? [17:50] cbz: hi [18:00] jelmer_: does bzr-svn track renames? it appears that it's history of files i renmamed stops at the point i renamed them [18:03] Lor: "bzr init-repo --no-trees project; cd project; bzr init branch1; bzr co --lightweight branch1 work [18:03] Lor: from there you can do: 'bzr branch --switch ../branch1 ../branch2" [18:03] or [18:03] "bzr switch -b branch2" [18:04] I was asking about how to put branches under a _working directory_. [18:04] bzr-colo seems to provide a sensible convention and tools to make its usage easier [18:05] Lor: well, you can do: [18:05] touch work [18:05] cd work [18:05] bzr init-repo --no-trees . [18:05] bzr init _a_branch [18:05] bzr co --lightweight _a_branch . [18:05] It is a bit weird to put the branches in the same dir as the working tree [18:06] so aside from that, bzr-colo [18:06] Yes, that's one convention. [18:06] But it's a bit funny to have the branch directly under the root of the working directory, since there's then nothing to immediately distinguish between a branch directory and a workingtree subdirectory. [18:06] .bzr/branches seems like a more sensible place to put the branches [18:07] It also seems to work ok with bzr-pipeline. [18:07] So I'm all good. [18:10] Actually, pipeline+colo=loom? === oubiwann_ is now known as oubiwann [18:17] cbz: yes, it can track renames [18:18] cbz: but it won't infer renames from copy + delete in svn [18:18] cbz: so it will only work for revisions pushed from bzr into svn [18:18] okay [18:18] can't it use whatever information svn uses to work out what has been renamed? [18:23] SVN doesn't store renames. [18:23] SVN stores a revision that deletes a file, but adds a new file by copying history from the old one. [18:23] That isn't quite a "rename" [18:26] ugh, setuptools makes me feel unclean === beuno-lunch is now known as beuno [18:30] but it stores enough meta information for tortoisesvn to work out that a rename/copy has taken place [18:35] the mismatch is that bzr doesn't support copies [18:37] oh [18:46] Suppose I have a network connection available only for a limited while. I want to get new revisions from upstream, but my working directory is currently a mess so I don't want to merge right away. What's the best way to do this? [18:46] The obvious solution is just to branch upstream into a local copy and then merge that local copy into my working branch later on. [18:47] But I'm wondering if there is a way that doesn't require creation of a temporary local branch. [18:56] Lor: not that I can think of [18:57] Well, in principle it's possible to do a merge, then revert before committing. This does bring in all the revisions into the local repository. But after the revert there is just pointer to them so it's not trivial to redo the merge. [18:57] just _no_ pointer to them [18:58] But a branch is a cheap thing. [18:59] Actually, one of the reasons why the colocated branch convention is good is that you always get a shared repository so branches are always cheap. [19:05] Incidentally, could someone explain the point of shelves? [19:06] It seems kind of silly that when we have full version control available, a separate system is used to store temporary changes. [19:06] Lor: back out a part of the uncommitted changes in the working directory [19:06] to make it possible to to more focused commits [19:06] e.g., with simple commit messages [19:07] If you want to back out some changes that you want to later bring back, why not commit, then revert those changes, then do what you want, then merge rest of the stuff from the commit? [19:07] Because I don't want them in the "public" history yet [19:07] "public"? [19:07] It's your own branch! [19:07] but I'm going to push it somewhere public [19:08] e.g., if I'm evaluating a patch which supplies both a testcase and a fix [19:08] That seems like a problem with your workflow. [19:08] I apply the patch, shelve the fix, and ensure that the testcase fails [19:08] (note I haven't committed anything) [19:08] then unshelve the fix and commit both together [19:09] or if I have made "janitorial" changes to one part of a file while making substantive changes to another part [19:09] I forgot: after the commit, uncommit back to the previous revision but revert the working tree only partly (those parts you don't want to shelve). [19:09] I want to commit the two parts separately [19:09] bzr-pipeline seems like the right tool for that. [19:09] (or loom) [19:10] no, those are too complex [19:10] Only if you think that a branch is a big thing. [19:10] no [19:10] I'm done trying to explain how I use it -- I don't need to defend it [19:13] I'm not saying there's necessarily anything wrong with shelves, they just seem orthogonal and redundant. [19:13] aborting commit write group: OSError(24, 'open: Too many open files') [19:13] bzr: ERROR: [Errno 24] open: Too many open files: '.' [19:13] seriously? [19:16] Sorry, _un_-orthogonal. [19:17] elmo: On what os? [19:17] GaryvdM: Ubuntu, Lucid [19:18] elmo: I've only seen that when using bzr-svn [19:18] the code that actually reads the content does have a try/finally:f.close() [19:18] so we shouldn't be leaking from there [19:19] jam: this is straight bzr, managing /etc [19:19] root@carpobrotus:/etc# bzr st | tr -d @ | grep -v "^[a-z]" | grep -v " postgresql/8" | grep -v /hook | awk '{print $1}'| wc -l [19:19] 1268 [19:19] ^-- that's the number of files I'm trying to commit [19:19] I'm basically doing bzr ci -m "commit message" $() [19:19] (without the wc, obviously) [19:20] elmo: hmm... I still haven't seen us have a problem with that, but we can certainly try to investigate [19:20] I assume it is perfectly reproducible for you? [19:20] and 'bzr --version' is? [19:20] jam: yes, reproducible [19:20] jam: 2.1.1 [19:21] 2.1.1-1 to be precise [19:21] I suspect I can reproduce with a dumb testcase and that the trigger is listing files on the command line [19:21] I'm sure I've commited trees with more changes before but I don't often specify the files on the command line [19:21] but I'm guessing [19:24] yeah [19:25] I'll file a bug, it's got a trivial test case [19:27] elmo: thanks, I'm trying to reproduce now [19:27] jam: http://paste.ubuntu.com/436872/ [19:29] elmo: so, I can reproduce something weird with "bzr st `cat big_list.txt`" [19:30] reported as https://bugs.launchpad.net/bzr/+bug/583468 [19:30] Launchpad bug 583468 in Bazaar "bzr commit will break when given too many files as arguments (affected: 1, heat: 0)" [Undecided,New] [19:30] jamnice [19:30] jam: nice - even [19:31] jam: that looks like a related/similar problem [19:31] elmo: seems like it is actually a problem with the command line being too long [19:31] and that is getting masked somehow [19:32] jam: I don't think so? [19:32] 'ls *' works, for example [19:32] so 'bzr st *' should too [19:33] elmo: now i'm seeing "permission denied"... [19:43] elmo: so I'm pretty sure it isn't the commit code, but actually the "what has changed" code that is at fault, still investigating [19:43] jam: ok, thanks for looking. FWIW, it's not urgent though I do appreciate you looking into it [19:43] elmo: Yeah, if you "mv _readdir_pyx.so _readdir_pyx_old.so" it works [19:43] the issue is something in there is opening file descriptors and not closing them [19:44] I know we do "open(directory)" so we can do "chdir(old_dir_id)" but we seem to properly (close(old_dir_id)) [19:44] elmo: any chance you can test on something other than lucid? [19:44] jam: like what? [19:44] something newer? [19:45] or older [19:45] something different [19:45] sure, I can test hardy trivially [19:45] in case it is something like OS not actually releasing handles on open(directory) or a problem with opendir()/closedir() etc [19:45] thanks [19:45] I've only got a Lucid VM here [19:46] so you don't need commit, 'bzr st *' should trigger it just fine [19:46] but it probably has to be a bunch of files and not their containing dirs [19:46] because the code filters (if you supply dir/ and dir/foo, we only use dir/) [19:47] jam: hardy with 2.0.4 exhibits the same behaviour [19:47] elmo: thx [19:49] elmo: submitting a bug, hopefully I can track it down [19:51] bug #583486 [19:51] Launchpad bug 583486 in Bazaar "_readdir_pyx.so leaks file descriptors (affected: 1, heat: 0)" [High,Confirmed] https://launchpad.net/bugs/583486 [19:54] jam: ah, I guess I should dupe my bug into that then? [19:54] jam: (done) [20:22] is there a way to either revert to a tag or determine the revision corresponding to a tag? [20:34] launchpad-bugs-owner@lists.canonical.com "Your message was rejected" huh? [20:35] that's surely not expected behaviour from submitting a merge proposal, sending me email complaining about it. === khmarbaise_ is now known as khmarbaise [21:17] Wait, what? Are plugins allowed to store data into bazaar.conf? [21:20] Lor: yes [21:21] Then it's not really a configuration file? [21:21] cr3: bzr tags ? [21:21] jpds: yep [21:21] (In the unix sense, meaning: managed only by the user, can be set read-only) [21:21] cr3: Err, that was the answer to the latter part of your question. [21:22] Lor: What plugin are you looking at ? [21:22] bzr-bookmark [21:22] Lor: Well, the user *configures* their bookmarks [21:23] Arguably, yes. [21:23] bzr itself modifies bazaar.conf [21:24] I'm not saying this is wrong, but it is confusing not to have a clear idea exactly where bzr will touch, and where the user is in control. [21:24] I think providing UI for configuration files is nothing special [21:27] hm, when I do bzr co bm:foo, the bound_location gets the _expanded_ bookmark location, instead of just bm:foo [21:28] I was hoping to use bookmarks as a layer of indirection so that if the upstream location moves someplace else, I just need to do a single reconfiguration and everything will keep on working. [21:29] moin [21:31] (Basically I'm wondering whether I should use bookmark locations as part of something I'm doing, or cook my own thing, even though it would be slightly similar) [21:35] bazaar.conf doesn't support include directives? [21:36] I'd like to use the same configuration on multiple machines, except for some site-specific bits. === SimonK_ is now known as SimonK [22:15] elmo: found the bug [22:15] when you pass in a path [22:16] we open() the current directory so that we can chdir() back to it [22:16] but if it is a file and the 'chdir(path)' fails, we were not closing the descriptor [22:16] simple one-line fix [22:16] grah [22:16] +1 [22:16] jam: awesome, ta [22:16] lifeless: do you want me to clean up the code a bit, I get some warnings under pyrex. Otherwise I can just do the minimal one-line fix [22:16] jam: we want to land in 2.0 [22:16] lifeless: sure [22:16] I'll start small :) [22:17] jam: so - one liner, for SRU niceness. Cleanup in trunk after mergnig forward. === blueyed_ is now known as blueyed [22:22] elmo, lifeless: Theres the one-line fix [22:22] http://paste.ubuntu.com/436938/ [22:22] yeah, doit [22:26] it would be great if I could say bzr push $parent [22:26] except without the $parent part [22:26] I mean - if it was something good and not $parent [22:26] * mtaylor is babbling [22:27] bzr push `bzr info | grep parent | awk '{print $3}'` [22:27] is what I'm trying to say [22:28] mtaylor: bzr push :parent ? [22:28] jam: wow. is that a thing? [22:28] mtaylor: yes [22:28] jam: see... you anticipate my needs before I even know them :) [22:29] mtaylor: bzr help location-alias lists 6 shortcuts [22:29] borrowing guido's time machine, are we? [22:29] woot [22:50] Bazaar for dapper in the PPA doesn't install "bzr: Depends: python-configobj but it is not installable" [22:50] (yes, dapper. I need Bazaar there to get *off* of that system, heh) [22:54] So should I... install Bazaar manually? [22:55] AfC: uhm [22:55] jelmer_: that's what I said :) [22:55] AfC: Or perhaps just run it unpacked from your home directory? [22:55] jelmer_: as in from tarball? [22:55]