[00:00] lifeless: anyway, thanks for the comments. I'll give it some thought [00:01] kk [00:01] jelmer: on another topic, what's your timeline for subvertpy 0.7 being released? [00:02] igc: Nothing in particular at the moment; if it would be useful for you I could do a release right now [00:02] jlemer: I'm not reconsidering where best you new fast-import script lives [00:02] s/not/now/ [00:02] jelmer: my worry is that 0.6.9 is in karmic [00:03] jelmer: does subvertpy end up in our PPA? [00:05] igc: there is a separate subverpty PPA but it doesn't have very recent versions at the moment [00:05] igc: that's fixable though [00:06] jelmer: maybe my wrapper script - fast-export-from-svn - ought to look for your script and use it if found [00:06] otherwise, fall back to the current one [00:06] your script could live in subvertpy [00:07] and be called something like "subvertpy-fast-export" ... [00:07] or subversion-fast-export even [00:07] jelmer: ^^^ [00:07] igc: that'd be fine with me [00:08] jelmer: ok, let's do that [00:08] ok [00:08] jelmer: so the next step is for you to release 0.7.0 with that script included and point me to a PPA [00:09] I'll them tweak fast-export-from-svn to go looking for it [00:09] then [00:09] igc: ok [00:10] jelmer: cool [00:22] * igc out for medical stuff - bbl === MarkAtw2 is now known as MarkAtwood [00:44] igc: I've uploaded 0.7.0 [01:26] lifeless: so, there are two implementations that should be distinct imho: the ignore file implementation and the working tree implementation, the two aren't necessarily coupled [01:26] thanks jelmer [01:26] lifeless: I'd rather see them in separate source files as we for clarity's sake [01:27] jelmer: we don't really have a private module concept though [01:27] from the working tree's pov it shouldn't matter what format ignore file is used [01:27] and it is odd to have a module thats all private [01:28] jelmer: actually it matters a lot [01:28] jelmer: wt4 on all bzr versions that support wt4 should be able to process the ignores [01:28] lifeless: I haven't mentioned privateness anywhere [01:30] lifeless: is that really necessary? That would imply .gitignore support in bzrlib or no support for .gitignore in bzr working trees at all [01:30] jelmer: bzr checkout foo; cd foo; (build); bzr st [01:30] should be clean [01:30] if the authors have made it clean using ignores [01:31] shouldn't it? [01:33] lifeless: yes [01:33] lifeless: but would it be ok if that required bzr-git if the original branch was imported from git? [01:34] lifeless: I agree it's not ideal but I don't see anything significantly better without storing ignores as tree metadata rather than inside the tree [01:34] jelmer: igc has a 'needed plugins' concept that is worth exploring more [01:36] Personally, I'd hesitate to add this indirection to existing tree formats [01:37] but I only say hesitate because clearly all imports can't work today, so its not really a regression [01:42] lifeless: what's the problem with adding this to existing formats compared to adding it to new formats? [01:44] none of the existing bzr versions - e.g. 2.0.0 - know how to handle it [01:54] lifeless: I do see your point, though it's hard to come up with anything else that allows the use of foreign ignores in the short-o to mid-term [01:56] jelmer: we have 5 months before the next stable release [01:57] jelmer: and as I say, *I* would hesitate, thats not to say it shouldn't be done. [01:57] I would worry that it will confuse folk on 2.0.0 to have someone say 'wow x works' and not have it work for them. [01:57] particularly with e.g. NFS home dirs [02:01] mwhudson: so, did you capture any other tarballs? What was the command you ran? [02:05] whoa [02:05] I think I've found a serious bug. [02:05] or there's something very weird going on. [02:05] I removed a file I am certain is under version control from a checkout, and bzr st is reporting nothing [02:06] I change that file from the base, and bzr st reports nothing. [02:06] And I moved aside .bzrignore [02:06] I'm scared :| [02:06] .bzrignore won't affect files that are already versioned. [02:07] is it shown by 'bzr inventory'? [02:07] will loggerhead work with the new 2.0 formats? [02:07] bjp: yes, although you probably need a recent version. [02:07] i'm pretty sure i have the latest [02:08] just wanted to make sure before converting my repos [02:08] yes, bzr inventory shows the file [02:08] spiv: just bzr get lp:~ubuntu-core-doc/gnome-user-docs/ubuntu-karmic [02:08] spiv: but i access the copy of the branch in the hosted area [02:08] jfroy|work: details [02:09] what do you need to know? [02:09] jfroy|work: is the file in 'bzr inventory -r -1' [02:09] spiv: let me faff for a moment [02:09] or if inventory barfs on that, can you do 'bzr cat -r -1 PATH' [02:09] lifeless: yes [02:10] and you have deleted it now [02:10] but 'bzr st' doesn't reflect that? [02:11] one sec, more weirdness [02:11] tes [02:11] *yes [02:12] is the file in 'bzr inventory' [02:12] it is [02:13] this is very odd [02:13] so, if its in bzr inventory its not 'removed' but it could be missing [02:13] its odd for 'bzr st' not to show it [02:13] what bzr version? [02:14] 2.0.1 [02:14] there's more going on here [02:14] I think my system has gone nuts :p [02:14] strange, mkdir in lftp always fails against codehosting [02:15] AH! [02:15] yes, codehosting isn't quite sftp anymore [02:15] * jfroy|work hides in shame [02:15] mwhudson: maybe it tries to emulate 'mkdir -p' but gets confused about the topmost directories not actually existing? [02:15] pwd != pwd ? [02:15] I was operating on a different directory in the GUI than the shell [02:16] spiv: hm, maybe [02:17] I apologize. [02:19] Guuuh. Stupid stat begging for WT... [02:23] jfroy|work: no worries [02:27] mwhudson: how goes the faff? [02:27] mwhudson: that branch command worked for me, btw [02:27] spiv: progress, i think [02:27] spiv: i'm not entirely surprised [02:27] * spiv nods [02:29] spiv: try bzr get lp:~spiv/+junk/u-k [02:29] mwhudson: curiously, my fetch retrieved an identical number of revisions, inventories and texts as your tarball [02:29] heh [02:30] That reminds me I should make some noise on the bug for 'should not be able to make random stuff owned (and thus implicitly attributed to) people w/o their permission' [02:31] spiv: i can only do that because i'm a bazaar-expert [02:31] Ah, that's good. [02:31] spiv: a copy of the branch made with lftp's [02:31] 'mirror' command is at https://devpad.canonical.com/~mwh/mirror.tgz [02:31] * spiv encoffees [02:44] mwhudson: that reproduces, thank you! [02:45] spiv: yay [02:52] Hmm, I should probably grab a mirror of the stacked-on branch too, just in case. [02:55] yes i guess so [02:57] if nothing else, being able to reproduce without consuming my adsl bandwidth would be plus :) [02:58] heh yes [03:39] mwhudson: I have some sort-of good news for you [03:39] mwhudson: it's almost certainly a client-side bug, which means no cherrypick when I do fix it ;) [03:39] spiv: yay [03:42] mwhudson: re bug 441125 ... [03:42] Launchpad bug 441125 in bzr "bzr: ERROR: exceptions.KeyError: ('makefile.am-20080508221105-rbs9wugi1qq76gcs-2', 'scott@netsplit.com-20090702173125-4nayj8jp8h4f8jnq')" [High,In progress] https://launchpad.net/bugs/441125 [03:42] I used lftp to grab the branch [03:42] but it doesn't report being a branch once I grab it [03:43] should I use 'mirror' instead? [03:43] igc: how did you grab it? [03:43] mwhudson: or maybe it was just lftp user error on my side? [03:43] igc: also if it's stacked, the stacked on branch will be relative [03:43] igc: so you'll need to fix that [03:44] hmm [03:44] * igc looks [03:47] mwhudson: I don''t think it's stacked looking through the .bzr directory [03:47] mwhuson: bzr info -v reports it as being an unshared repository, even though .bzr/branch and all the files seem to be there [03:47] igc: what is in .bzr/branch/branch.conf ? [03:48] ah, me wrong ... [03:48] parent_location = lp-hosted:///%7Escott/upstart/trunk/ [03:48] stacked_on_location = /~scott/upstart/trunk [03:48] that's all [03:48] * mwhudson gets out his "practical bzr debugging" badge [05:38] spiv: ping [05:39] spiv: any chance you could be second reviewer on some simple patches in the queue? [05:39] https://code.edge.launchpad.net/~mathepic/bzr/mkdir-recursive/+merge/13380 [05:39] https://code.edge.launchpad.net/~joke/bzr/bugfix353370/+merge/13404 [05:39] https://code.edge.launchpad.net/~mathepic/bzr/remove-tree-multi/+merge/13451 [05:40] spiv: all are just a few lines long and pretty straight forward imo [05:43] igc: ok [05:44] spiv: also, is https://code.edge.launchpad.net/~jameinel/bzr/2.1-static-tuple-chk-map/+merge/13082 ready to land? [05:44] for some reason, I'm not allow to change it to "Approved' [05:45] spiv: maybe because you claimed the reivew? [05:48] igc: because the target is not a branch you have rights to [05:49] spiv: ah - fair enough [05:49] igc: this is the downside to the way jam found to get LP reviews to do incremental diffs [05:49] spiv: right [06:08] * igc pick up kids - bbiab [06:31] back === oubiwann_ is now known as oubiwann [08:19] hello all [08:33] hi garyvdm, thanks for such detailed mails. [08:34] Hi bialix - Sure - Sorry I did not do it earlier. [08:34] yep [08:35] I suppose your i-net and/or free time is problematic. no problem. [08:37] Yes - I hope to get that sorted out soon. [08:38] will be nice [08:38] I'm glad you're back on board :-) [08:50] hi! i am trying out bazaar and i am trying to settle on a workflow for using it with django. anybody have any tips? [09:08] hi bialix, garyvdm [09:08] Hi Igc [09:09] * igc dinner [09:11] hi igc === davidstrauss_ is now known as davidstrauss [10:20] Hi vila [10:21] vila: I want to make a test that requires user interaction. For this reason, I'm not going to incude it in the test suit. [10:22] vila: I'm trying to work out the easiest way to do this. [10:23] Can you give me any pointer. [10:23] garyvdm: phone call [10:23] Ok [11:18] garyvdm: ping.... if you read logs somewhere... [11:19] garyvdm: automated tests assumes no user is there. If a user is required, that's not automated anymore, so I'd like to understand better why you want to write such a test... [11:43] vila: perhaps because writing automated tests for PyQt4 is a hard job [11:43] garyvdm: I think custom launcher for non-automated tests should be enough? [11:43] GUI automated tests are always hard, but you have to start somewhere... [11:44] Hi vila, bialix. [11:44] garyvdm: hi [11:44] garyvdm: automated tests assumes no user is there. If a user is required, that's not automated anymore, so I'd like to understand better why you want to write such a test... [11:44] hi Gary (again) [11:44] I was disconnected for a while. It seems I missed some dicussion. I'll take a look in the logs. [11:45] garyvdm: you don't miss anything yet [11:45] vila just repeated his question to you [11:45] Ok [11:45] This is what I started on: http://pastebin.ubuntu.com/297350/ [11:46] vila, bialix: That should give you a good Idea of what I want to do. [11:46] My problem is getting a TestCase to run, that is not apart of the test suite. [11:47] hmmm [11:48] garyvdm: oh, ok, so while I still think that's not the right way to go :-) What you want is a test loader and a test runner [11:49] garyvdm: look into bzrlib.tests.TestUtil.py [11:49] vila: Thanks - That is what I was looking for. [11:50] hmm, only the loader is defined here, let me see for the runner [11:50] the runner in bzr;lib/tests/__init__.py [11:51] garyvdm: hmm, for the runner it's more controversial, but you can use .. yeah like bialix said [11:51] garyvdm: any reason why you want to use unittest-like interface? [11:52] To be able to reuse assertRaises [11:52] then you have to write custom TestRunner [11:52] IMO [11:53] I'm about to go crash [11:53] but if you were to mail the list with a broad "i want to achieve x' I'd be delighted to reply tomorrow [11:56] lifeless: Ok - I'll do that. === mrevell is now known as mrevell-lunch [12:19] hi === mrevell-lunch is now known as mrevell [12:19] Hi jml [12:19] there's a bug with a branch at https://bugs.edge.launchpad.net/bzr/+bug/84659 that has been approved [12:19] Launchpad bug 84659 in bzr ""serve --allow-writes" allows more than you might think" [Medium,In progress] === weigon_ is now known as weigon [14:23] morning all [14:27] I'm being sent to a 404 (http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#bug-tracker-settings) from http://doc.bazaar-vcs.org/latest/en/user-guide/bug_trackers.html [14:27] Can anyone tell me where the proper bug tracker settings page can be found please? [14:28] Is there a bzr documentation project or should I just post a bug in bzr? [14:39] hello jam [14:40] jam: we discussed with garyvdm qbzr versions re bzr versions, perhaps you saw that thread in qbzr ml. resume: 0.14.4 is for bzr 2.0.1, 0.15 for bzr 2.1.0b1 [14:41] morning bialix [14:41] Meths: bug in bzr is fine [14:41] :-D [14:41] bialix: sure [14:41] jam: okay. [14:42] is there a way to cache my svn credentials with bzr-svn? [14:42] Tak: IIRC you can use svn to cache the credentials, and then bzr-svn will use the cached values [14:42] but it doesn't have a way to cache them itself [14:43] alternatively, I think you can set up authentication.conf, but I'm not sure how to set that up w/ svn [14:44] * Tak try that [14:46] hah - svn co doesn't ask me, but bzr pull from an existing branch does [14:47] Tak: what versions are you using? [14:48] morning jam [14:48] bzr 2.0.1, svn 1.6.5, bzr-svn 1.0.0 [14:49] wow @ bazaar-vcs.org makeover [14:53] btw, I just found a bug with a branch at https://bugs.edge.launchpad.net/bzr/+bug/84659 that has been approved but not merged. [14:53] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/84659/+text) [14:55] aha - if I set up authentication.conf, I can get: http://paste2.org/p/476652 [15:09] Is there an ETA for 2.0.1 .exes? [15:21] Meths: approximately today, it just depends on how many hiccups I run into while trying to build them [15:23] jam: cool, thanks. Do they always cause lots of headaches compared to the other packages? [15:26] Meths: yeah, generally. It is the only place where we bundle everything in one package [15:26] so skew means rebuilding the whole thnig [15:26] thing [15:26] so you need the right version of bzr-svn, bzr-rewrite, qbzr, tortoisebzr, ... [15:27] by contrast on Linux, each of those is a separate package, so if there is a problem *that* package gets updated [15:27] also, by there are some bad designs in the windows packaging [15:27] namely, the code that defines plugin dependencies is *in* bzr's setup.py [15:27] which means that plugins have to match bzr, which is a bit wonky [15:29] aha, bug 452121 [15:29] Launchpad bug 452121 in bzr-svn "Putting svn password in authentication.conf doesn't work" [Undecided,New] https://launchpad.net/bugs/452121 [15:31] Meths: also, the shared machine we use to make the windows builds is 'remote', and has a bug with DNS so you have to manually add hosts to the 'hosts' file. Which generally is ok, but can be annoying [15:31] being hosted in AU doesn't help *my* ping times, though :) [15:32] jam: there is desire to factor out plugins dependencies from bzr's setup.py [15:32] bialix: absolutely, but we need people to actually... do it [15:32] which is non trivial [15:32] yep [15:32] and since *I'm* the one that pays the primary burden, I would be the one to fix it [15:32] I don't think it's non trivial [15:32] but I'm also the one working on new features, etc. [15:33] it's just need some time [15:33] bialix: you think it would be a trivial change? [15:33] I mean I understand the way where we should go to achieve this [15:33] but it require lot of work [15:34] I have proof of concept of moving such data to plugin's setup.py [15:34] you said in the past that this is almost impossible [15:34] I have proof of concept that it very possible [15:34] but then you did not answer [15:35] I suppose you have distracted by other more important things [15:35] and vila too [15:35] so, it's not "trivial" as 5-minutes fix [15:36] bialix: so I see it as possible, but getting 10 plugins to all switch to the format, and getting bzr's setup.py cleaned up is at least a couple of days to a weeks worth of work [15:36] but it's not "non-trivial" as you need many weeks to experiment first before writing actual code [15:36] to a week [15:36] here I'm agreed [15:36] couple of days [15:37] and push all these improvements back to each component upstream [15:38] IIUC there is only 2 components affected: tbzr and qbzr [15:39] bialix: and bzr-svn [15:40] I think, not positive [15:40] * bialix looks [15:40] but certainly tbzr is the one that has caused the most dependency problems [15:40] bzr-svn has caused the most 'rebuild a new installer' problems [15:41] you as core dev can voluntary working on transferring dependency codes [15:42] I'd like to have clear agreement about approach first [15:42] at my job we always writing mini specs first before coding [15:43] for bzr-svn the dependency is simple, but indeed present [15:43] def get_svn_py2exe_info(includes, excludes, packages): [15:43] packages.append('subvertpy') [15:45] jam: while I'm here. This is my proof of concept to load required data from plugin's setup.py lp:~bialix/+junk/plugins-setups [15:46] jam: to really start working on it somebody should extend plugins API definition as in http://doc.bazaar-vcs.org/bzr.dev/developers/plugin-api.html#plugin-metadata-before-installation [15:46] for me this is 2 mandatory dependencies [15:46] \o/ finally the build completed... now to get people to poke at it :) [15:46] cool [15:47] I probably can't build 2.1.0b1 yet, because bzr-svn at least needs updating [15:47] but at least 2.0.1 will be done [15:48] all hail jam! [15:48] bialix: thanks for the encouragement [15:48] * jam does not like doing the installers, but seems to be the only one doing it... [15:51] building tbzr is still the corner of entire installer process [15:51] because of full MSVC 2008 required [15:51] bialix: yeah, supposedly naoki had it working without the full compiler [15:51] using specific versions of SDKs, etc [15:51] I haven't seen his setup, yet [15:52] but he mentioned not needing it for his work [15:52] I'm not sure [15:52] bialix: just to check, we should be using qzbr 0.14.4 and bzr-explorer 0.8.3, right? [15:52] bialix: he mentioned it in the bug about tbzr not compiling with the lite version [15:53] I don't have it off-hand [15:53] and IIRC, he didn't give specific steps to reproduce [15:53] qbzr 0.14.4 and explorer 0.8.3, correct [15:56] vila: how is babune looking lately? [15:57] pfff [15:57] bialix: also at some point we'll want to start bundling svn 1.6.* [15:58] leopard is back, I had to fight with tiger to avoid a log file filling my boot disk (which is quite painful as it's the host for the guest I'm using for IRC and mail riht now :-/) [15:58] so OSX suffers from a latent bug related to leaking tests but the bug stop manifesting itself on leopard [15:59] and tiger failed this morning but without filling my OSX / [16:00] jam: which more or less confirms that I'm right about the cause of the bug, but gives no idea on where to start to fix it... (I have some ideas but none are trivial so I let them mature a bit) [16:00] vila: sounds like about as much fun as I've been having with the installers :) [16:01] jam: so I'm back working on resolve --interactive.... and realizes there are many conflicts than need more love, to the point I may want to define a new format :-/ [16:01] jam: yeah ! Lots of fun ! :-D [16:01] well many is too strong, but at least 3 or 4 :-/ [16:01] vila: yeah for conflicts we sort of have the 'minimal set' right now. We could use clearer definitions for 'directory already exists' versus 'parent directory deleted' etc. [16:02] Which I had looked at a while back [16:02] when we were debugging what was going on w/ mysql [16:02] there is also the fact that sometimes we create several conflicts and I'm not sure we really need that... [16:03] So my basic concern is about how to change conflicts definition with regard to compatibility, [16:03] can we consider that upgrading while having conflicts in a tree is rare enough that we can say: [16:03] vila: do it in 2.1.0* and don't overly concern yourself :) [16:03] Oh, no luck, I can't read your conflicts anymore, please redo your merge [16:04] vila: I would say, if it is a problem, refuse to upgrade if there are conflicts [16:04] so let them sort it out how they want [16:04] revert, resolve, whatever [16:05] hmm, no the code has to be changed, so the data and the code should stay in sync :-/ [16:07] so when working on old format working trees, I think you need to interpret the conflicts file the same as old clients [16:07] there are people that share workingtrees across NFS [16:07] (which I don't recommend in any fashion, but it happens) [16:08] jam: right, so I need to address the backward compatibility issue at least :-/. [16:09] jam: and since I don't want to do that right now, I think I will restrict implementing --interactive for some conflicts only instead [16:09] that way I will move forward instead of backward at each step :-/ [16:11] vila: usually a preferred direction :) [16:11] :) [16:16] vila: so I'd like to check the current memory status on 64-bit python. Would it be okay if I bring down a copy of the launchpad code base onto 'saw' ? [16:17] I think it is ~100-200MB of data [16:17] hmm, what size ? [16:17] ok, be aware you're on an SSD, so don't burn it too fast :) [16:18] jam: if you need HDD instead I can create some dir somewhere you can symlink from your home [16:18] but up to 1GB, go for the SSD [16:19] vila: I certainly don't need to use the SSD, but if it means you don't have to do more work, I'm happy to use it :) [16:19] jam: still 33GB free there, as long as the tmp files for selftest are not on it, SSD ftw ! [16:22] vila: I'm shocked, I'm only getting 16kB/s downloading launchpad's code from lp [16:22] I wonder what is going on... [16:22] maybe codehosting is overloaded? [16:23] going via http, I'm peaking at around 2MB/s [16:23] though it is pretty choppy [16:23] jam: don't know what you tried, I get 2MB/s right now [16:24] oh, you too [16:24] vila: first attempt was 'bzr branch lp:launchpad' which would go via bzr+ssh [16:24] And I'm wondering if that wasn't slow because of the bzr:// server side [16:24] for example, if codehosting is thrashing into swap [16:25] jam: my observations so far are that the rate is highly variable (and different from what a perfmeter will report) [16:26] but the difference is due to our processing so not worth fixing IMHO [16:26] vila: well we could do better on the filtering [16:26] such as using "a = a + b*cur" [16:26] (first order filter) [16:26] rather than just "a = cur / time" [16:27] jam: well we can't satisfy everybody, I think the actual figures are quite representative, if people want more detailed bandwith usage, that's outside bzr (still IMHO :) [16:28] right now you're using between 0 and 1MB/s, what did bzr report ? [16:28] vila: I think we tend to under-report [16:29] because a long download followed by a quick short one [16:29] will get overrwritten [16:29] jam: nope, I've seen both under and over reports [16:29] that's why I didn't report myself :-D [16:29] vila: right now it reports ~.5M [16:29] so sure [16:29] my point is that it is unstable because we mix big reads with short reads [16:30] and don't average across them [16:30] from the perfmeter that's quite correct, you had peaks at 2MB/s [16:30] jam: well, I'd prefer we fix the code so that we always max the bandwith :) [16:30] you're flag now [16:30] for the last 30 secs [16:30] s/flag/flat/ [16:31] yeah, it is on the 'missing keys' portion [16:31] so almost done [16:31] peak at 2 [16:31] flat [16:34] * vila cries [16:34] what on earth is an 'overwrite' conflict ! [16:34] The thing that conceals an underwrite conflict. [16:35] * vila send some anti-bits on fullermd disks just so he too can have his share of fun :)] [16:35] Anti-bits take up negative space, so it's like getting larger disks for free! [16:36] fullermd: you wish ! [16:36] It seems logical. [16:36] no, anti-bits erase real bits and disapear, the net result can be smaller sectors for example [16:37] so you have your regular 512 bytes sectors and then some at 511 or 510 see [16:38] Actually, I *encountered* such behavior in real life... at leasts it looked like that, we found part of files that had shrinked [16:38] Man, how prejudiced can you be? anti-bits are just as 'real' as regular bits. Don't be such a baryogenetic racist. [16:38] shrinked in the *middle* of fixed size records... [16:39] ..in the end it was an hardware bug, but boy did we wonder... [16:39] That's why I run ZFS :p [16:40] jam: BTW, can you weigh in on the DWIM "looks like a revno but isn't" fallthru thingy? It's kinda mixed... [16:46] jelmer: btw, subvertpy 0.7.0 breaks the build... [16:46] subvertpy\repos.c:24:21: apr_md5.h [16:46] No such file or directory [16:46] perhaps this is a svn 1.6ism? [16:47] That's part of APR, actually. [16:48] jam: I've just merged a fix for that [16:49] jam: will update bzr-windows-installer [16:49] fullermd: sure it is apr, but my assumption was that subvertpy was using something from a newer apr which is bundled with a newer svn [16:49] jelmer: so a subvertpy 0.7.1 ? [16:50] Oh. I didn't know svn bundled APR. [16:50] jam: there was an incorrect include path in setup.py that for some reason wasn't a problem before now [16:50] fullermd: so... the revspec dwim is basically someone doing "bzr branch -r 1.2.3" and there isn't a revno 1.2.3 but there is a *tag* 1.2.3 [16:50] fullermd: well, it depends on it, and exposes the pools etc as part of svn's pai [16:50]