[00:02] ChrisMorgan: this is caused by bzr probing for the smart server [00:03] ? [00:03] That went over my head :-) [00:03] Just agree that it didn't work :P [00:09] ChrisMorgan: when bzr sees a http:// URL, it'll first try POST to $url/.bzr/smart with a smart server request. jelmer is saying that for some reason this probe is preventing bzr-svn from being able to do its own probe and take over. [00:10] Shall I put that in my bug report or let you two comment it? [00:10] ChrisMorgan: (maybe the server is rejecting the bzr smart server probe with a slightly unusual HTTP response code, or something like that) [00:10] ChrisMorgan: well, please file a bug if you haven't already [00:11] ChrisMorgan: we've have a few along these lines before, no need to paste my generic explanation into the bug :) [00:12] https://bugs.launchpad.net/bzr-svn/+bug/506196 [00:12] Launchpad bug 506196 in bzr-svn "SVN checkout failing with empty authentication details" [Undecided,New] [00:13] ChrisMorgan: you may be able to workaround it by prefixing svn+ to the URL? [00:14] Works. [00:14] (Or perhaps by prefixing nosmart+ come to think of it...) [00:16] I'll leave you to comment that addition then. I've already posted mine. [00:16] Nevertheless, it's still a bug :-) [00:16] If it works with svn it should work with bzr :-) [00:17] Thanks though, I really wanted all the information so I can revert to Django 1.1 if I needed to while off-line [00:17] Thanks for reporting the bug :) [00:18] SVN is slow... now I've made it to revision 500/7768... [00:19] Yeah, it's not really designed to send you the complete history :) [00:25] For some things I'd just want a lightweight checkout, this time I do really want it all. [00:28] I thought someone already maintained a django bzr collection of branches [00:31] Over 2000... [00:31] I have heard of it... I dunno [00:31] It's been used for benchmarks [00:35] morning [01:39] ChrisMorgan: it might help if you attach the log from running [01:39] bzr co log+http:/otauhaotnhu [01:39] if you haven't already [02:04] jelmer: have you had a chance to look at that new bzr-svn exception I'm hitting? [02:13] * igc lunch [03:58] is there a better way to change a commit message than uncommit + commit? [04:01] There's not a simpler way for simple cases (that I know of) [04:01] Any 'better' way would be functionally equivalent in the end, anyway. [04:01] I guess I mean "easier" ;P [04:01] anyhow, no big deal [04:03] idnar: easier in what way? Open an editor with the old commit message I guess? [04:04] something like that [04:04] It'd be nice to have something like that, maybe commit --redo or something. [04:04] uncommit's useful for more than just changing the commit message, of course. [04:04] or even just avoid the risk of including uncommited changes or whatever [04:05] ironically, darcs has a command (amend-record) that lets you include additional changes but doesn't let you change the patch name [04:36] poolie: I like the new "always report if it came from a user-defined source" version [04:40] thanks, sent [04:40] jam, i think our patch-landing latency is improving for developers as well as new contributors since mooloolaba [04:40] which is good [04:40] no room for complacency though [04:50] can someone help me work out where to write a test for bug 456077? [04:50] Launchpad bug 456077 in bzr "MYSQL/BZR P3: bzr doesn't explain it's doing a slow cross-format fetch" [Medium,In progress] https://launchpad.net/bugs/456077 [04:50] or maybe it doesn't really need one [04:50] poolie: sure [04:51] so what do we want, a ui.note when getting a stream with a different format? [04:51] i guess in per_interrepository [04:51] yes [04:51] well, [04:51] more broadly, when the fetch is going to be noticeably slow [04:52] so the stream interface is tested on repository, not interrepo [04:52] and thats where the code would live, so I'd write the test there. [04:53] as for 'when it will be slow' - there isn't a guaranteed metric for that. [04:53] and will all fetches go through the stream interface? [04:53] so to me that means writing per-case tests. [04:53] poolie: all the bzr <-> bzr ones do now [04:54] it was one of the major achievements spiv and I had last year [04:55] concretely we expect getting a revision-delta style stream to be painful on non-CHK repositories [04:56] ok, so you could possibly override InterRepository, but that's not actually expected to be done [04:56] svn/git/hg fetches do that [04:56] they provide specific optimisers at the moment I believe. [04:57] i wonder if a warning is useful there [04:57] they could move to using the streaming interface at some future point. [04:57] probably not [04:57] possibly it is, but it won't help mysql:) [04:57] and the place to put it would be in the SVN or whatever InterRepo class anyhow, I think. [04:58] well, i was thinking of putting it in the base interrepo class [04:58] but, as you point out, that is no longer where the variation is [04:59] fetch.py does this [04:59] : [04:59] source = self.from_repository._get_source( [04:59] self.to_repository._format) [04:59] yes i see [04:59] but its the repo _get_source that will actually know its going to be slow. [05:01] so we have a StreamSource or RemoteStreamSource locally [05:01] specifically [05:01] in repository.py [05:01] and i guess that can give the warning... [05:01] _get_inventory_stream [05:01] there is a bunch of logic that may call into [05:01] ah yes [05:01] self._get_convertable_inventory_stream [05:01] that *that* function is the one that does the hard work. [05:02] and that's not overridden in the remote case [05:02] note that with fetch from bzr+ssh, this code block will execute on the smart server. [05:02] but you can use the current 'stderr shows on the client' 'feature' to let users see the warning anyway, for now. [05:03] hm [05:03] poolie: right, nothing is overridden in the remote case; the entire object is proxied [05:07] the comment on get_convertable... says "the source is using CHKs" but this actually seems to cover all different-format cases? [05:07] yes [05:08] thanks very much [05:08] np [05:08] do you recall if the deprecation warning patch landed already? [05:08] sorry no [05:12] i guess this won't work over bzr+http or tcp until we have a way to remote ui operations [05:13] if you were willing to bump the stream format [05:13] you could do a step towards the progress-in-streams stuff I've speculated on [05:13] and include a substream of type 'warning' [05:14] mm [05:14] on push operations the RemoteStreamSink would see that and show it locally, on pull operations the StreamSink would get it from the network and show it. [05:14] alternatively we could make sure the logic runs on the client [05:14] but that seems a bit messy [05:14] you'd have to duplicate it - cause it to run twice [05:15] right [05:15] and you wouldn't know about config or environment on the server, so you'd be guessing [05:15] so [05:15] i guess we could make the client give this warning if it receives a stream of inventory-delta? [05:15] regardless of why the server decided to send that? [05:15] yes [05:16] specifically you'd want to make the Sink do that, if its not running inside a server, and RemoteSink to do it if it observes it going past. [05:16] its a little crude, but it will do [05:18] do you think that's better? [05:18] it seems possibly better to me [05:18] I think it will work now, as a stderr output would. It would work in tcp and http as you noted, so thats better [05:18] OTOH deltas can be very fast chk<->chk so perhaps there will be some false positives in the future. [05:22] i'd kind of rather deal with the false positive [05:22] s [05:22] then do that :) [05:22] if there are are any [05:26] Isn't there some bug about dirstate when you upgrade to a rich-root format? [05:26] Should I...do something, or is it fine? [05:26] Peng: nada [05:27] it's fine? [05:27] jelmer: ping [05:29] so, u [05:29] um [05:29] fetching from 2a into 1.14-rr does seem to use InterDifferingSerializer [05:29] which does not seem to use streams [05:30] or, not in a straightforward way [05:30] * poolie looks [05:32] oh, locally? [05:32] I'd check with spiv at this point. [05:32] spiv: ^ [05:32] I was fairly sure that even that remnant had been dropped, but apparently not. [05:32] Hmm. [05:33] It's only used for local fetches. [05:33] See InterDifferingSerializer.is_compatible, it returns False if either side has a URL starting with file:/// [05:34] (And only if the serializers differ, etc.) [05:35] Somewhere, possibly just a mailing list thread, there's a list of things we need to fix to be able to drop IDS completely. [05:35] IIRC it was progress indication and worse speed/memory for local fetches (although the speed/memory was partially addressed?). [05:40] erk, now I can't unping him. === arjenAU2 is now known as arjenAU [05:51] spiv actually it's false if either of them is not local [05:51] but iswym [05:51] so it seems that we need a warning in both ids and streaming [05:53] Yeah. [05:54] IDS is duplication, after all. [05:54] so [05:54] i'd like to add blackbox tests to make sure i'm actually covering the right things [06:22] poolie: well, I'd really be inclined to write tests close to the code [06:22] poolie: but I know we have differing opinions on this ;) [06:23] to me the risk here is not so much that my call to warning is wrong [06:23] but that the code is not reached at all [06:23] as it was not in my/our first attempt [06:23] therefore i want an integration test that checks that [06:29] spiv, i'm going to merge 2.0 back to trunk, which will carry some of your cleanup changes [06:29] just so you know [06:30] i'm having some trouble threading bazaar when gtk is running... without the threading bzr works but locks up gtk, but with threading bzr hits Branch.open(remote_branch_url) and doesn't do anything afterwards in that thread. [06:30] doesn't even end. [06:30] poolie: sure [06:30] poolie: I think you'll find that the cmd_annotate change from 2.0 can be discarded, but that the test that is added ought to be kept. [06:30] oh ok [06:30] that conflicted [06:31] why should it be discarded? [06:31] The command_cleanup branch included the cmd_annotate fix, but using add_cleanup rather than try/finally. [06:31] it looks like an improvement, trunk still does it without cleanups [06:31] The change in trunk was the try/finally for the tree lock IIRC. [06:31] but we want to end up with it using cleanups in trunk, don't we? [06:32] poolie: right; I mean discard the 2.0 version and keep it as it is in trunk :) [06:32] doctormo: hmm [06:33] doctormo: I doubt most of bzrlib is threadsafe [06:33] spiv: AWOS: don't use threads it won't work? [06:33] doctormo: so your gtk program can use threads, but you should take care to only call bzrlib from a single thread. [06:34] oh i see [06:34] spiv: OK, I think I may be able to wrangle the mental image, I think it's changing the ui outside the thread. [06:35] spiv: our own server is multithreaded [06:35] lifeless: yeah [06:35] doctormo: bzrlib should be pretty safe as long as you only use a given object from the same thread. [06:36] doctormo: so you can use two threads, or N, but don't pass a (say) Branch opened from one thread to another thread. [06:36] lifeless: but we don't share objects between threads... [06:36] lifeless: it's simpler just to say "don't use multiple threads" :P [06:36] lifeless: but you're right. [06:36] spiv: yes, I'm trying to rephrase what you said in a slightly less restrictive way ;) [06:37] lifeless: Don't use threads unless you know how to control leaks. [06:37] doctormo: uh, I think thats a very different statement ;) [06:37] for all that it may be wise [06:39] lifeless: I can't land things in bzr-loom. [06:39] Peng: aren't you in ~bzr yet? [06:39] lifeless: No. [06:39] lifeless: About once a month you suggest it, but then none of us (including me) follow up. :) [06:40] you can now [06:40] lifeless: Cool, thanks. I'll land it. [06:41] and you're now in ~bzr. welcome to the firehose [06:41] :D [06:42] Peng: Are you the same Peng that hangs around in #linode, too? :-) [06:43] StevenK: Yes. [06:44] bbl [06:54] i want to check out from a bzr branch, but I don't want the new working copy to be a bzr repo - just a working copy. [06:54] I think there's a command for this... [06:54] but I can't find it [06:55] chrispitzer: I think you want a lightweight checkout then. [06:55] chrispitzer: You don't want a local copy of the history? You're looking for "bzr checkout --lightweight" or "bzr branch --stacked", depending on whether you want a checkout or branch. [06:55] bzr co --lightweight [06:55] thanks [07:00] chrispitzer: note that this will be very slow over the internet [07:07] hi all [07:08] lifeless: but only for things like log, annotate, etc. Diff shouldn't take longer, commit will take just as long. That's right isn't it? [07:10] ChrisMorgan: no [07:10] diff will take longer [07:10] commit will take longer [07:11] For a checkout? [07:11] a lightweight one, yes [07:11] diff on a heavyweight one shouldn't be affected [07:11] Particularly though, why will diff take longer? Doesn't a lightweight checkout still have the latest revision? What would need to be looked at in the network? [07:11] ChrisMorgan: a lightweight checkout doesn't have its own copy of the original version to compare to [07:12] commit on a heavyweight one will be slightly affected [07:12] ChrisMorgan: it has to fetch that from the repository, so diff will be slower if the repository is not local. [07:12] ChrisMorgan: say your round trip time is 100ms [07:12] So it's not like an SVN checkout. [07:12] ChrisMorgan: rigth [07:12] right, rather [07:12] I thought lightweight made it that way. [07:12] OK. [07:12] stacked branch is the same then I presume? [07:12] Well, it's like SVN only more extreme :) [07:12] ChrisMorgan: diff on a lightweight checkout will open the branch ~(600ms) and repository ~(400ms) before doing anything locally [07:13] ChrisMorgan: so thats about a second of overhead, before you consider the cost of getting out basis files where a difference is detected [07:13] Stacking will at least keep some of the repo locally. [07:13] And why, oh, /why/ do you have "lightweight" checkouts and "stacked" branches if it's the same thing? [07:13] ChrisMorgan: lightweight makes it roughly like CVS checkouts [07:13] But stacking isn't really designed for this case (yet). [07:13] I'm not really familiar with CVS... I tried it once for some Drupal work and haven't got over the shock yet. [07:13] ChrisMorgan: it'd be nice to collapse them, but at the moment they serve different needs [07:13] ChrisMorgan: stacked branches can diverge [07:14] ChrisMorgan: there's a huge thread on the mailing list on (broadly) this topic atm :) [07:14] ChrisMorgan: checkouts can't(*), so they aren't really the same thing at all. [07:14] Yeah, but is the only difference between a checkout and a branch that the first is bound? [07:14] the only difference between 'bzr checkout oo' and 'bzr branch oo' is that the former binds to the source whereas the latter sets the parent to the source [07:15] checkout --lightweight doesn't create a local repo at all and replaces the local branch object with a branch reference pointing at the source [07:30] hi vila? [07:30] poolie: hey ! [07:30] vila, i think we're meant to talk [07:31] poolie: yup, I started the day with a crashed desktop (and was lucky enough to reboot the host only after suspending the guest...) but things seem to be ok now [09:11] hello all [09:14] win 38 [09:14] hi bialix [09:15] hey lifeless, what's 38? [09:16] hi bialix! [09:16] * igc dinner [09:16] hi Ian [09:16] bialix: the number of the irssi window he failed to switch to (he meant to type /win 38) [09:16] btw, igc, I've update explorer translation template [09:22] I'm still having odd problems with threading, could a kind person look over the code quickly and see if they spot any dumb mistakes? [09:23] http://bazaar.launchpad.net/~doctormo/groundcontrol/trunk/annotate/head%3A/nautilus-groundcontrol.py from line 162 to 175 [09:23] and http://bazaar.launchpad.net/~doctormo/groundcontrol/trunk/annotate/head%3A/GroundControl/bazaar.py the entire file is probably of interest. === spiv_ is now known as spiv [09:29] bzr's launchpad plugin doesn't, currently, help with the creation of new projects, and I'm looking at hacking on it so that it does so. Was this left out for a reason? [09:36] aquarius: no, and we'd welcome improvements to the plugin [09:37] aquarius: (originally it was because Launchpad didn't have launchpadlib when the plugin was created, just a couple of XML-RPC methods) [09:37] ah, cool. [09:38] atm, all my small projects live in my svn server, because setting up a launchpad project is a pain by comparison with typing four svn commands :) [09:39] but typing "bzr lp-new-project projectname description" in a folder to make it an LP project would get over that hump quite nicely [09:40] aquarius: this may involve hacking on lp [09:41] lifeless, really? launchpadlib lets me create projects, I think? [09:41] dunno [09:41] coverage of exposed apis can be pretty hit and miss [09:41] should do. if it doesn't I shall whine mightily at leonardr :) [09:42] if I've got a plugin in the system plugins folder and a plugin with the same name in my local plugins folder, the local one will override the system one, yes? [09:43] mtaylor: you really should release a new pandora build if you're talking on it. [09:43] mtaylor: the version I packaged in debian is way old now [09:45] aquarius: ywa [09:58] bialix: Hi! I have a quick question about scmproj... [09:59] heya jszakmeister! sure [09:59] How do you work on a local branch and merge the result back in? [10:00] merge locally and then push [10:00] maybe I misunderstood your question? [10:00] Let's say I have a trunk of library that's in the workspace created by scmproj... [10:01] I want to create a branch of trunk for that library, make the change, and get it reviewed by the team. Does scmproj support that sort of workflow? [10:02] Usually we're creating new alt for this, and put new branch under that alt [10:02] then merging 2 alts when ready [10:02] but alts is half way to deprecation [10:03] That's what I thought. :-) [10:03] Do you envision some other way of doing this? [10:03] instead of alts you may want to use just new branch of project config [10:03] but today alts are still supported [10:03] and sometimes they are much easier [10:04] I'll remove alts once I will have new layout format with snapshots ready [10:04] I had that thought as well. But the one project I'd like to use it for is massive. [10:04] I'd rather not have a whole second tree, if I can avoid it. [10:04] new branch of project config is much closer to what nested trees should be [10:05] jszakmeister: in the past I've tried to create something like bzr-colo now [10:05] today I'd suggest using bzr-colo plugin [10:05] I saw that on the list... looks interesting! [10:05] I've played with it yesterday and it really in good shape [10:05] despite version 0.0.1 [10:06] I'm not sure yet I will want to provide tight integration with colo in scmproj [10:07] jszakmeister: if you have only branch for one component then I'd use alts today, publish your branch on the server for review, then merge alts [10:07] to merge alt from server you need: bzr pcmd "merge {BRANCH_URL}" --alt XXX -i your_library [10:08] there --alt XXX will be your alt (corresponding to your new branch) [10:08] Yeah, but I don't want to head down a path thats going to be deprecated. [10:08] look at http://bialix.com/scmproj/docs/howto.html [10:09] http://bialix.com/scmproj/docs/tips-n-tricks.html [10:09] I'd rather say "we can't do that right now" instead. [10:09] hmm, it's so strong for me [10:09] s/so/too/ [10:10] :-) [10:10] The backend is actually in Subversion, so they have other choices. [10:10] you're underestimate the power of pcmd [10:10] oh [10:11] I don't see the full picture of yours [10:11] They have everything in a Subversion backend, and have been using externals to manage the tree. [10:12] But it's a PITA. [10:12] Plus, the backend is old (before SVN had merge tracking)... [10:12] I'm going to bed now, thanks for the help before, although the problems remain I'm sure it's a simple fix. [10:12] bzr-externals? [10:12] It'd be nice to switch them to Bazaar and bzr-svn, but we don't *have* to [10:13] That was the next one on my list to examine. :-) [10:13] The nice thing about scmproj is pcmd [10:13] and the fact that you can run operations on everything. [10:15] So, bzr-colo... works for more than just trying to get colocated branch support for one "project"? [10:17] I thought, from the name, it was really just trying to handle multiple branches of the same project. [10:19] bzr-colo provides git-style workflow [10:19] multiple [feature] branches of the same project [10:20] Yeah, that's what I thought... which is very nice! [10:20] I just need something more along the lines of scmproj for the other projects though. [10:20] along the lines? [10:21] Sorry... I should use better English: "something like scmproj" [10:21] no, that's me [10:23] well, scmproj is nice when you have set of loosely related components [10:24] or when you have common library for several projects [10:24] That's exactly our case. [10:24] I have no experience with svn:externals though [10:24] Be happy that you don't. :-) [10:24] just read the docs [10:24] :-) [10:24] lol [10:24] but I mean maybe I'm lack some knowledge [10:25] the good thing about small company/startup is that you can choose any vcs you want [10:25] but you have to admin it yourself too [10:25] :-) [10:27] jszakmeister: I'm planning to add some tips about merge in scmproj [10:28] or maybe I should finally implement it as separate command [10:28] That would be great (either one!) [10:28] there is enough special cases user have to care [10:28] I completely missed the merge docs the first time around [10:29] your position re alts is very strong, I did not expect people can get it this way [10:29] thanks for feedback! [10:29] You're welcome! [10:30] if you have any suggestions or more question: I'll be happy to hear them [10:31] today my own experience drives the development of scmproj, but I can miss some other POV [10:32] I'm actually trying to write a few things down, but I believe I will have some suggestions for scmproj. [10:35] testr failiing doesn't seem to be implemented despite being mentioned in README.txt [10:35] Of course that the one I was interested in :D [10:35] vila: failing to fail is still a failure, right? ;) [10:37] spiv: yes, I'm whining about failing to sucessfully fail :) [10:37] err, wrong channel for my remark about testr >-) [10:38] well, it will get my attention :P [10:38] #testrepository if you want the 'right channel' [10:53] hi vila [10:53] hi bialix [11:14] supposing bzr+ssh://remote-a and bzr+ssh://remote-b are two different branches which share 99.9% of their revision history. [11:14] and they're large enough that they're slow to branch afresh. [11:14] and I already have a local branch of remote-a [11:14] what's the quickest way to get a local branch of remote-b? [11:15] Is your local branch of remote-a in a shared repo? [11:15] quicksilver: Have remote-a branched in a shared-repository (initialised with “bzr init-repo”) and then branch remote-b into the same repo. [11:15] fullermd: no, but if that's the right answer then in future I will arrange for it to be so :) [11:16] I'm pretty sure you can reconfigure remote-a to be in a shared repository. [11:16] Well, you could fudge without it. But you'd be wasting near double the space, from 2 copies of the history. [11:16] Yes, you can. init-repo a repo around it, and use 'reconfigure' to move its history into it. [11:16] * fullermd sprinkles a few more pronouns into that sentence just for kicks. [11:16] Metasyntactic variables FTW! [11:18] fullermd: cool. [11:22] does 'bzr info' show when you've done it right, I.e. when it is using the shared-repo properly? [11:22] It does. [11:27] OK. I bzr init-repo . to create my first shared repo. [11:28] then I bzr branch bzr+ssh://remote-a remote-a to populate it with the first branch [11:28] and it freezes only a second or so in, saying: [11:28] [#########| ] 103KB 100KB/s | Fetching revisions:Get stream sourc [11:28] Well, you already have the first branch locally, don't you? [11:28] oh, it's unfrozen [11:28] was a good 60 seconds though [11:29] fullermd: yes, I do. I was faking a clean start to (a) make sure I understood the process and (b) as a basis for explaning it to colleagues [11:29] I've been trying to fake a clean start for years, but I haven't managed to burn all copies of the.... [11:30] Uh... [11:30] Nevermind. Didn't say anything. [11:30] :) [11:37] I think some kind of insect is trapped inside the bzr process now. chk:chk it's going. [11:37] perhaps a baby bird. [11:37] That's the buzzer. Hence the name. [11:39] chk:chk means there's a small sliver of paper stuck between the hammer and the bell. You probably need to empty out the bit bucket. [11:41] OK, the results are in. [11:41] a clean branch of one of these branches took 4m30 [11:41] the first branch into a shared-repo took 13m56 [11:42] but then a subsequent branch (a similar but different branch) took 45 seconds [11:42] definitely better [11:43] that's quite apart from the disk space savings, which were pretty close to the 'ideal' 50% [11:43] but to be honest disk space isn't what I care about [11:43] it's branch time. [11:43]