[00:16] poolie: hi [00:21] jml, hi [00:22] Moin. [00:22] poolie: I was thinking about branches last night. [00:22] Odd_Bloke: g'day [00:22] jml, btw i'm on leave today [00:22] poolie: oh. [00:22] i will be around a bit [00:22] poolie: in that case I'll talk to you about branches tomorrow :) [00:22] :) [00:22] i am going to check on my stacking merge for a bit though [00:23] there are still some test failures in the top of robert's loom [00:23] * jml nods sagely [00:23] unless he somehow fixed them [00:23] mm [00:23] i wish it was done [00:25] jml: Hey. :) How's it going? [00:25] Odd_Bloke: well, actually. [00:26] Odd_Bloke: I'm experimenting to see if rememberthemilk is better than emacs for my nefarious purposes. === edcrypt is now known as edcrypt_ [01:26] poolie: When you're next free, I'd like to have a chat. :) [01:27] Odd_Bloke: how about this time tomorrow? [01:28] poolie: Sure, that should be fine. [02:03] with bzr-loom, is it possible to merge the changes in the upper thread down? when i use combine-thread it just tosses my changes [02:03] tro: you could do "bzr merge -rthread:THREAD-NAME" [02:03] ah [02:04] i'll try that. what does bzr record do? [02:05] It saves the state of the loom (i.e. the current threads and what revisions they are at). [02:05] when would i use it? after commits? or only when i move from one thread to another? [02:05] bzr merge -rthread:initial [02:05] bzr: ERROR: No location specified or remembered [02:05] Just before pushing, basically. [02:06] ah ok [02:07] the same error occurs when i do just "bzr merge -r thread:" [02:07] Oh, [02:07] "bzr merge -rthread:initial ." [02:07] Merge needs a location, not just a revisionspec. [02:08] I just tested, and that does work. [02:08] indeed. thanks [02:09] loom comes in useful, when working with source inside an environment, which is tedious to set up [02:09] The idea with record is that eventually it'll facilitate merging looms; i.e. if someone branches off your loom, and makes changes including adding/combining threads, you'll be able to merge their loom state back into yours nicely. [02:09] o neat [02:09] I don't think that's fully ready yet, but looms are already very useful :) [02:10] is there a reason why creating a new thread and then merging it back into the original results in the revision number having not one but two more decimal points? [02:11] ie. rev 1 -> rev 2 -> rev 2.1.1 > rev 3 [02:11] 2 is the branch point [02:11] tro: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#understanding-revision-numbers [02:11] ok thanks [02:12] It's not specific to looms, that's how bzr revision numbering works in general. [02:48] please help http://pastebin.org/49528 what am i doing wrong? [02:50] ozzloy: You're merging from the wrong directory. [02:50] so i am [02:50] bzr push sftp://ozzloy@ozzloy.lifeafterking.org/~/public_html/avk/itms ... Merging from remembered location sftp://ozzloy@ozzloy.lifeafterking.org/~/public_html/itms/ [02:51] ozzloy: as RAOF says, there's a missing "avk/" in the remembered location. Do "bzr merge --remember sftp://ozzloy.lifeafterking.org/~/public_html/avk/itms" [02:53] hooray! [02:53] that was a tad slow, but yay! [02:53] something to work on tomorrow. thank you! === Linnk is now known as Tank|Away [03:17] Probably tedious licencing question: does Bazaar really regard its logo as GPL? There have been uploads to Wikimedia on that basis: http://commons.wikimedia.org/wiki/Image:Bzr.jpg http://commons.wikimedia.org/wiki/Image:Bzr_icon_64.png [03:18] The logo files no longer seem to be in the source tarballs and the bazaar-vcs.org website seems to be all rights reserved. [03:22] hypatia: Why do you ask? === FBI is now known as Suiseiseki === Suiseiseki is now known as Suigintou [03:24] Odd_Bloke: A couple of reasons, all related to Wikimedia Commons. If those files aren't Free, they can't be on Commons, that's one reason. The other is that if the logo is GPLed, Commons should use the SVG version. [03:26] The current justification for them being on Commons is that, apparently, as of the beginning of 2008 they were included in the tarball of Bazaar itself, which has a LICENCE file saying it's GPL. The logo files are no longer in the repo that I can see. [03:26] If they ever were, I have not searched the history yet. [03:29] hypatia: FWIW, I don't see a logo in the bzr-1.1 tarball, which was released mid-Jan 2008. [03:29] hmm, would be nice to have some clarification about that [03:29] spiv: I am currently running bzr log on your laptop, so we'll see. [03:29] bzr-gtk still ships them [03:29] Heh. [03:30] Unfortunately poolie isn't around today. [03:30] If they aren't free, they should be. [03:30] Odd_Bloke: yeah [03:30] They are not in Ubuntu's .deb of bzr. [03:30] Else Debian'll have to package bzr as IceMarket. [03:31] any nested tree gurus around? [03:31] Odd_Bloke: heh [03:31] The serializer appears to forbid reference_revision to be None, but other parts of the code seem to assume that's a valid value [03:31] LarstiQ_: pingz0rz? [03:38] Is packages.ubuntu.com being unresponsive for anyone else? [03:40] yes [03:41] OK, I just found an Ubuntu mirror and looked at the diff.gz, which saved time. :p [05:06] moin [05:06] hi lifeless [05:21] Looks like the bzr repo has never contained the logo. [05:25] how can you do a non-destructive revert after adding a file you don't want versioned? [05:26] bzr rm --keep FILE [05:27] --keep might be a nice flag for bzr revert [05:27] but thanks, that worked like a charm [05:27] Although bzr rm will not delete the file if bzr thinks there might be uncommitted changes to it. [05:28] hi lifeless [05:28] will bzr revert? [05:28] that would be unfortunate default behavior, but it was what the help indicated would happen [05:28] =/ [05:29] bzr revert won't delete an uncommitted file either (You can test for yourself with "bzr init foo; cd foo; echo hello > hello.txt; bzr add; bzr revert") [05:30] ahh [05:30] the basic "bzr help revert" didn't indicate that behavior clearly to me [05:30] but good to know! =] that's what i wanted it to do, and I had done it once, and the output seemed to indicate it was deleting files, so I was concerned [05:31] The help text talks a bit about how it will make a backup of the file "if appropriate", which sort of hints that it's careful not to destroy your work. [05:31] But yeah, it could be clearer. [05:32] yea, i read the creating a backup to mean it *would* destructively modify the file, which is why it needed a backup [05:33] and in this case, i added a *very* large directory, so going through and renaming stuff would have been... messy... ;] [05:37] spiv: ping [05:37] lifeless: pong [05:37] you're about to get mail ;) [05:41] spiv: RAOF: thanks, btw [05:41] spiv: its queued [05:41] abentley: Am I right in thinking that you had some work on merge directive support in PQM somewhere? [05:41] ozzloy: not a problem [05:51] spiv: mail should have reached you:) [06:13] If someone could add me to the list of people allowed to post to bazaar-commits, it'd be appreciated. === arjenAU2 is now known as arjenAU [07:34] poolie: ping === doko__ is now known as doko [08:40] what provides bzrlib.knit.* stuff? [08:40] chandlerc: how do you mean 'provides' ? [08:40] i'm getting an ImportError [08:41] i have bzr 1.6b2 installed.. wondering if i need some additional libraries [08:41] chandlerc: you probably have a 1.6b3 version of some plugin [08:41] hrm [08:42] annoying... trying to follow a release branch of bzr-svn, but don't really want to be quite so bleeding edge with bzr itself [08:45] highly annoying as the released version doesn't work with 1.6b2 and contains a couple of bugs fixed in the release branch [08:51] That reminds me... I've been meaning to fix my dual bzr/bzr.dev install setup so it doesn't try to use the wrong version of plugins. [08:52] IIRC there was an article on an easy way to do that, if I can find it. :) [08:54] jelmer: ^ see chandlerc's comment :P [08:54] ToyKeeper: basically, don't use ~/.bazar/pluings for ones that hace trouble, instad link them to bzrlib/plugins/ in the version you want them for [08:54] ToyKeeper: our export a bZR_PLUGINS_PATH [08:58] jelmer: pongzorz [09:06] Odd_Bloke: ping [09:06] poolie: piong [09:09] lifeless: Pong. [09:10] poolie is on leave today, so probably isn't around. [09:15] mwhudson, check out bug #237914 [09:15] Launchpad bug 237914 in loggerhead "please provide downloadable and applicable diffs" [Medium,Confirmed] https://launchpad.net/bugs/237914 [09:15] :) [09:18] Odd_Bloke: how'd you go with that PHP snippet? [09:19] AfC: I looked at it, thought "I'll do this later" and haven't got around to doing it yet. :p [09:20] Odd_Bloke: your review requests titled 'The Diff' are context-free. I'm told if you don't set a title a sensible one is chosen [09:20] Odd_Bloke: most of it is actually about creating a listing of repositories, branches, and/or empty directories as you'd expect in a normal server generated index page. The "There's a branch here" part was pretty easy". [09:23] lifeless: I've been adding "The diff" via "Add a comment/review" just before using the "Request a review" button. I'll use the "Request a review" whiteboard for the diff in future. [09:23] lifeless: Apologies. [09:23] Odd_Bloke: the problem is the tmail topic [09:23] Odd_Bloke: thumper says not to use the whiteboard [09:24] thumper says you are setting a subject; don't do that. [09:24] its a bug that there isa field there IMO [09:25] I took my prompting for adding the diff from https://code.launchpad.net/~thumper/pqm/test-bzr-home/+merge/296 [09:25] But in future I'll leave the subject empty. [09:30] Odd_Bloke: oh, I just realized that without the Apache config the .php I sent you is probably totally lacking in context. So, http://rafb.net/p/WihwmF64.html [09:31] Odd_Bloke: thumper agrees that it is all his fault, and he sucks [09:42] Odd_Bloke: Here's my last work: http://code.aaronbentley.com/bzr/pqm [10:14] Hi! What is considered to be a good web interface for bzr repositories? I found "bzrweb" (http://mccormick.cx/dev/bzrweb/index.py/repositories) and webserve (https://launchpad.net/bzr-webserve). [10:15] ChristopheT, Loggerhead is probably the most complete one [10:15] https://launchpad.net/loggerhead [10:15] or launchpad itself! [10:16] hey beuno [10:17] morning james_w [10:17] are you in the office? [10:18] james_w, yeap, got here a while ago [10:18] are you here too? [10:19] yeah, I'm hiding away in the back corner. [10:19] ah, you sneaked in! I got here 9am-ish, and I'm right by the door [10:28] lifeless: Hurrah! [10:28] abentley: Thanks. :) [10:35] Odd_Bloke: ? [10:35] 08:31:19 < lifeless> Odd_Bloke: thumper agrees that it is all his fault, and he sucks [10:35] right === Tank|Away is now known as Linnk [10:40] hey all - quick question... given a revision id, is there a _sensilble_ way to find out the tags applied to the tree _after_ that revision? [10:40] jelmer: ping [10:42] like, if we tag releases and want to be able to determine if a particular patch went in to a particular release... [10:42] mthaddon: log can show tags I believe [10:42] meh mtaylor I mean [10:43] lifeless: yes... it can [10:43] lifeless: but that makes the process ... bzr log | less ... find commit, scroll back in output looking for tags... [10:44] mtaylor: I suggest you fle a bug wishlist wise :) [10:44] hehe [10:44] ok [10:44] :) [10:44] mtaylor: would 'bzr log -rrevid:foo.. | grep "tags: " | cut -d" " -f2' be considered sensible? [10:45] mtaylor: but I agree that it would be a good thing to have [10:45] hi lifeless [10:59] james_w: well, I've just come across another snag... [11:00] james_w: if I later merge from a different tree (in this case, say I'm in the 6.2 release branch and I occasionally merge up changes from the 6.1 branch) [11:00] then I see those 6.1 tags in my bzr log output in the 6.2 ... which would lead me to believe that the fix is "in" 6.1.11 [11:00] this is silly [11:01] mtaylor: true [11:02] are you mainly interested in a single tag when you do this, or are you looking for all tags? [11:03] doing it for one tag (or a list of them) is easy enough. [11:03] I think if I could pass a revspec to bzr tags, this would be cake [11:03] like [11:04] bzr tags -r2512.78.7.. [11:04] asking "what tags is this revision an ancestor of?" is probably straightforward as well, I'm not familiar enough with the branch.tags interface though. [11:05] I'm not sure about adding that to tags, as it would seem to be to be "list all tags that are in this revision range", not "list all tags that have the start of this range as an ancestor", which means I would expect it to return the same as the grep expression. [11:29] mtaylor: http://pastebin.com/f3b0c221d [11:30] try putting that as ~/.bazaar/plugins/which_tags.py and then run "bzr which-tags -rrevid:foo" [11:31] hello, is there any example of post_change_branch_tip for doing anything on the repository server when a new commit arrives through a push? [11:32] it works when i commit locally, but when i push nothing happens. i have also tried using bzr serve to no avail [11:32] (commit locally on the server that is) [11:34] james_w: awesome... trying now [11:34] perhaps it is related to the message "This transport does not update the working tree of" - i get that with both bzr+ssh://, sftp:// and bzr:// (what transport am i supposed to use?) [11:35] traduffe: your repository on the server should probably be created with --no-trees [11:36] traduffe: remote transports won't do that for you. [11:36] traduffe: your hook doesn't do what you want, or it isn't exectued at all? [11:37] james_w: it is not executed at all [11:37] mtaylor: I still think a wishlist bug would be valuable, as I think this should be done right, and done in the core. [11:38] james_w: cool. I'll file one if I get a chance today [11:38] traduffe: I'm not familiar with hooks, so I'm not sure what to look at, sorry. [11:38] traduffe: what version are you using? [11:38] traduffe: server and client? [11:38] mtaylor: great, thanks [11:39] james_w: version 1.5 [11:39] at both sides (from the ppa launchpad repo) [11:41] traduffe: I don't know what to say, sorry. Hopefully someone with a clue will pipe up. [11:41] ok! [11:55] Jc2k: ping [12:03] lifeless: pong [12:18] Jc2k: wondering if we can et your procmail recipe [12:18] eh, its not procmail [12:19] or whatever it is :) [12:19] wget http://bzr-mirror.gnome.org:8080/vcs-mirror/trunk/download/6/mirror.py-20080624200612-su5368kmi8ua94bd-5/mirror.py?file_id=mirror.py-20080624200612-su5368kmi8ua94bd-5 [12:20] * Jc2k blinks at the url :) [12:21] see the actions/ folder for how the {svn,bzr,git} mirrors are created/updated [12:22] Jc2k: thanks! [12:22] yuck [12:23] Jc2k: we're looking at making an in-conference mirror [12:23] Jc2k: what do you think? [12:23] lifeless, ping [12:23] (at the url, it's too late to be clicking things) [12:23] pygi: hi [12:23] lifeless, tell gnome people to stop being ignorant, and mentioning gitorious only in git context [12:24] pygi: right, clearly its portable to bzr :) [12:24] lifeless, also tell them that if needed, gitorious can fully support bzr in a two-weeks timeframe [12:24] and it will, as I mentioned in my blog post, through rvcs [12:24] somebody just gotta get me the reason to do it [12:25] lifeless, what me and Jc2k mentioned is far more important ... coming up with the plan on how to do all things needed for the migration [12:25] pygi: well, I'm doing the things [12:25] lifeless: an onsite mirror? if we can get the bandwidth for an initial pull [12:25] onsite branching, with bzr-avahi [12:25] shit the bed. [12:25] Jc2k: shipping a firewire drive from london [12:26] Jc2k: just need a machine to plug the thing into [12:26] lifeless: i'm bouncing up and down like a giddy goat [12:26] Jc2k: ok, cool [12:26] lifeless, anyway, just wanted to mention that =) [12:26] if they have any problems, direct them to me xD [12:26] pygi: thanks! will do [12:27] * pygi goes back to hacking... [12:32] james_w, let me know when you're hungry :) [12:32] beuno: are you still in england? [12:33] lifeless, yeah, I got sidetracked into working on other stuff :) [12:33] so I'm here til saturday [12:34] dang [12:34] I arive sunday [12:34] yeah, all the fun starts when I leave [12:34] that *always* happens :p [12:34] beuno: I was just thinking the same thing. What is there to do for food around here? [12:35] james_w, there's pizza express, the cafe that's mostly for takeaways, or other pubs that I'm always unable to find [12:35] lifeless, how's Guadec? === acuster is now known as avc_afk [12:35] good; intense [12:35] are you giving any bzr talks? [12:42] yes, in 40 minutes [12:47] lifeless, good luck [12:47] I'm off to lunch! [12:47] thanks! [12:50] Jc2k: hi [12:50] Jc2k: you moved a module to svn recently, for use with i10n right ? [12:52] did i? [12:52] * Jc2k blinks [12:52] or maybe it was someone else.. [13:08] Jc2k: it was gnome-specimen [13:09] uws: ping [13:11] http://uwstopia.nl/blog/2008/06/gnome-specimen-now-in-gnome-svn [13:11] ^ - so , danilo is looking at making this work straight out of i10n === avc_afk is now known as acuster [13:42] hi! i get a traceback when running 'bzr annotate file.OTHER' while merging, if file is removed locally and modified in the other branch [13:42] i can reproduce it with this: http://pastebin.com/m3837d47e [13:43] using bzr 1.5 [13:44] and also 1.6b3 [13:47] <_paneb> i created a branch locally, added some code, and pushed it to a remote repository. when i ssh into the remote machine, the remote branch has no working tree - is this normal? [13:47] sven: please file a bug [13:47] lifeless, ok [13:48] _paneb: yes, totally normaly - other people can branch from this [13:55] <_paneb> ok [13:57] <_paneb> ok now i have my local mirror of the remote (trunk). i want to create a new branch for a new feature. i do bzr branch trunk feature-X locally against my mirror branch. when i do bzr log in feature-X, the branch nick is still 'trunk' [13:58] yes, because the commits were created in that branch [13:58] the nick affects future commits [13:58] 'bzr nick' will show you what it will be recorded as [13:59] <_paneb> ah [13:59] <_paneb> ok, thanks [13:59] I just wondered, is there a way to have a single working tree switch between different branches? [13:59] MvG: bzr switch [13:59] Use case: large compiled project and I'm working on multiple features. [13:59] yes, with the 'bzr switch' command [13:59] MvG: which is useful in exactly that usecase, yes :) [13:59] * MvG is reading switch help [14:01] Ah, so I create a lightweight checkot initially, and then use switch to change the branch. Nice. Thanks! [14:05] abentley: hello! could you please post an update in support issue 2413? A colleague hit a criss-cross merge where the merge3-per-file bzr version gives seemingly bad content conflicts, as we had already observed, and which is a problem you were working on. [14:06] lifeless, ok, i filed https://bugs.launchpad.net/bzr/+bug/246573 [14:06] Launchpad bug 246573 in bzr "'bzr annotate file.OTHER' during contents conflict gives traceback" [Undecided,New] [14:08] jelmer: Are there any news in bzr-svn regarding fetching history explicitely for the given branch, as opposed to implicitely for each history request not contained in the cache? [14:08] abentley: the colleague is Sven who is on this channel, by the way. [14:09] sven: tanks! [14:09] abentley: he used the "bzr merge --mysql" plugin to kill those conflicts, [14:09] <_paneb> and finally, how do i create a release (export) from the remote trunk, given that it has no working tree? [14:09] MvG: not particularly [14:09] abentley: but this feels a bit anxious, as one cannot be sure that all of them were incorrect. So we're looking forward to the full solution. [14:09] MvG, I've kept my svn-1.5 branch up to date with the 0.4 branch and started looking into the logic behind all this and then got distracted [14:11] hi guilhembi and lifeless! yes, would be very nice to have a solution to this! the merge --mysql thing is good, but i have to go through all the content conflict files and check the result... [14:11] jelmer: Understandable. As long as it isn't forgotten completely, that should be all right. [14:12] jelmer: Especially as current 0.4 branch seems to work with svn-1.5 as well, there is not that much of a hurry. [14:12] _paneb: normally you'd use your local version of it, but bzr export takes a branch argument [14:13] <_paneb> bob2, ok, i'll use the local branch, but i did pass the branch to export [14:13] _paneb: and what happened? [14:14] <_paneb> bob2, i inverted the branch name and archive names :P [14:25] jelmer: you pinged me for something? [14:25] LarstiQ_, yeah, nested tree support [14:25] LarstiQ_, What's the status ? :-) [14:25] jelmer: the same as in London afaik [14:25] LarstiQ_, Also, do you know whether it's possible to nest another branch [14:25] without specifying a revision in that branch === LarstiQ_ is now known as LarstiQ [14:26] or, to word it differently, is it possible to nest the tip of another branch rather than a specific revision [14:26] jelmer: as in, always pull the latest version? [14:26] yeah [14:27] jelmer: I don't think so [14:27] crap, that makes nested trees unusable for svn:externals :-/ [14:27] you think? [14:27] jelmer: ime svn:externals are mostly pinned at a specific revision. [14:28] It is possible to pin them, but almost nobody uses the pinning [14:28] still would like to update once in a while of course [14:28] jelmer: hmmm, our experiences conflict :) [14:28] in particular because the revision an external is pinned to is annoying to update [14:28] you have to update the external [14:29] propedit it? [14:29] yeah [14:31] well, at least that makes it easy to decide whether to wait for nested trees before I introduce that new mapping format... [14:33] ok, let met dig through the code a bit. [14:34] jelmer: Hello, was that log informative at all for the bindings? [14:40] awilkins, yeah, I just haven't had much time to look into them yet :-/ [14:41] though some may be fixed now because of the move away from fs access === tale is now known as tethridge [14:46] awilkins, Yeah, any chance you can run it again? [14:46] the number of errors should've gone done quite a bit [14:46] jelmer: fs access? [14:46] LarstiQ: Rather than using a working copy to create revisions for testing [14:46] we now talk directly to the database [14:47] jelmer: ok, I'm severely lacking context [14:47] LarstiQ: this is in bzr-svn [14:47] jelmer: that I understood :) [14:47] LarstiQ: using a working copy to build revisions is quite slow [14:47] (an actual directory in the file system we modify and then commit in) [14:48] mainly because svn sleeps in between operations to avoid funny timestamp business [14:48] instead, we now just talk to the Subversion repository directly without using a working copy === Christop` is now known as ChristopheT [14:48] jelmer: an svn working copy? [14:49] LarstiQ: yes [14:49] Bazaar doesn't have working copies, only working trees :-P [14:50] jelmer: I'll run it later, this isn't my build machine [14:50] jelmer: oh feh terminology ;P [14:51] jelmer: Current bzr.dev and bzr-svn 0.4 repeatedly fail to branch the inkscape repo for me: http://rafb.net/p/fvOeJD27.html [14:52] Looks like the server became impatient and dropped the connection, but I would expect bzr-svn to reestablish connection at least once before giving up. [14:53] MvG: Reconnecting would be a job of the svn client library imho [14:53] MvG: The problem is that we don't have a good way to determine why an operation fails [14:54] the same error code is returned for everything that fails when using the webdav transport [14:54] jelmer: We could examine the error message, serach for "connection.*closed" or some such. [14:54] Ugly, I know. [14:54] The error message is useless since that can be localized [14:54] :-( [14:55] Still a dropped connection would differ from most other errors in that retrying the exactly same operation again would succeed. [14:56] Yeah, but that would mean adding fallback code everywhere and that seems too much for a workaround like this [14:56] So how would you suggest I proceed? Try to implement reconnects, fall back to using svn without bzr, or bug the subversion lib devs trying to get reconnects and/or sensible error messages there? [14:56] well, simplest solution would just be to run the command again and let bzr-svn continue where it stopped [14:57] but in the end the subversion lib should be fixed first [14:57] jelmer: any clue on using the 0.4 bzr-svn branch with bzr 1.6b2? [14:57] Which I did before I wrote about "repeatedly failing" up there. [14:57] chandlerc: You need a newer version of bzr than 1.6b2 [14:58] =/ [14:58] MvG: Try the command again as a user I mean [14:59] jelmer: where would i get it from? i'd rather not run bzr right off the tip of development [14:59] (if i can even do that) [14:59] jelmer: I already deleted the branch directory and restarted the branch command from the command line. As the shared repository was still in place I had hoped it would continue there, but it seems that wasn't enough. [14:59] chandlerc: You would need bzr.dev for the 0.4 branch at the moment [15:00] MvG: If the shared repo is still there, it should be continuing [15:00] MvG: Does "bzr info" in the repo say those revisions are there? [15:03] jelmer: 0 revisions. The last message from bzr-svn was "determining changes". No status message afterwards yet, seems to be still working. Not much network traffic either. [15:04] MvG: it may've saved the cache though [15:05] jelmer: Yes, the cache should be complete. Command just died again. Next time around I guess I'll wireshark things. [15:09] Woo, I have merge-directives working in PQM. [15:09] In a 'has worked once for me' type of way, before anyone gets too excited. :p [15:09] Odd_Bloke: W00t! Congrats :-) === mw|out is now known as mw [15:10] Almost entirely Aaron's work. [15:13] jelmer: is running bzr.dev viable? ie, is it stable enough to use day to day? [15:14] jelmer: i would gladly run the released bzr-svn and avoid all of this, but there are bugs fixed since then that I depend on. ;] [15:14] chandlerc: yeah, I've been doing so for the last two and a half years without any problems whatsoever [15:14] Odd_Bloke: Still, this is nice to finally have [15:15] jelmer: Yeah. :) [15:21] jelmer: OK, the network is busy all the time with PROPFIND requests. Not much of throughput, so it didn't show up on my network usage docklet. I got a gdb stack trace somewhere in between, and it lists ra_get_dir as the function called from python, but as the error message indicates _fetch_switch instead, I'd rather assume the issue to occur in the switching code. Can you reproduce the issue? [15:23] MvG, what's the url exactly? [15:24] jelmer: http://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk is the branch, http://rafb.net/p/fvOeJD27.html my error command line and error message. [15:27] MvG: You know about -Dtransport? [15:28] jelmer: In theory yes. Should I try to get a log for this? [15:29] MvG: I suspect this is just the server being a pain [15:29] so far everything is working smoothly here though [15:31] jelmer: Do you have any idea what bzr-svn is doing all the time here? It prints a progress bar about determining what revisions to fetch, that bar vanishes about halfway through, and afterwards I see nothing and the code calls those get_dir things and issues PROFIND requests for various dirs. SHouldn't all that information be available form the log? [15:31] MvG: It's figuring out what revisions are present in Subversion and which ones are missing in bzr [15:32] MvG, it needs to look at the file properties of a path to figure out what its revision id is [15:33] So basically it's asking the server for each and every dir in the tree to tell it what files are present and what revisions IDs they have? I thought revision IDs were a bzr thing. [15:34] MvG: It's only looking at the file properties of the branch itself [15:34] so /trunk usually [15:34] MvG: But revision ids have to be preserved when pushing revisions into Subversion [15:34] jelmer: My wireshark capture says otherwise. [15:34] and they're stored in file ids [15:34] s/file ids/file properties/ [15:35] I see. Still looks like something was going wrong here. [15:35] MvG: It's doing requests for get_dir() on things other than branch paths? [15:35] Was just debugging why PQM wasn't accessing remote source locations when using merge directives. I hadn't actually created the remote branch. >.< [15:36] It's difficult to match network traffic to function calls, or trace the lib calls in some sensible way, but I think so. [15:37] As it was running get_dir at some arbitrary point during all those PREOFIND requests, I'd assume get_dir to be the source of at least most of those. And as I'd assume get_dir to only issue a handful of such requests, I think there is either a bug in get_dir or it's being called repeatedly. [15:37] MvG: get_dir() is being called repeatedly [15:38] MvG: It's probably called awfully often but hopefully only doing a single request each time [15:38] jelmer: I have the -Dtransport log ready. Opening RA connection to repo root, then a long break, then a list of unsupported properties immediately followed by the traceback. [15:38] isn't that worse than doing more requests less often? [15:39] LarstiQ: There is no way you can get multiple results out of get_dir() [15:40]