[00:15] lifeless: can tribunal already handle subunit? [00:19] * poolie just branches lp:tribunal [00:19] tribunal runs a python test suite [00:19] if that uses a SubProcessTestSuite, its transparent to tribunal [00:19] igc: how are those reviews going [00:20] starting now [00:20] (been reading the threads with abentley's and spiv's comments) [00:21] the one I pointed you at is much simpler [00:21] *ones* [00:51] New bug: #208039 in bzrtools (main) "Feature Freeze Exception: bzr 1.3" [Undecided,New] https://launchpad.net/bugs/208039 [01:12] markh: that document is pretty interesting [01:12] poolie: thanks! [01:13] * poolie avoids getting sucked into reading the whole Old new thing [01:14] heh - its a very intersting blog for windows developers [01:15] I'm going to dig deeper into the tsvn cache etc [01:15] and decided to get sidetracked by pulling their svn tree via bzr ;) [01:15] * beuno pokes poolie and lifeless about the debconf bzr talk deadline [01:16] beuno: hi [01:16] thanks [01:16] hey poolie :) [01:16] so what did we work out about that? that lifeless would propose a talk and james_w might go too, iirc? [01:17] yeap, he was willing to go === kiko is now known as kiko-zzz [01:18] and jelmer and LarstiQ are interested in going too, they where going to apply for sponsorship by debian [01:18] and with me and Verterok, we might be a pretty big bzr possy [01:19] might even be worth organizing a sprint :) [01:21] oh, and dato might come too, right dato? [01:22] 'evening markh [01:22] markh: great to see you taking on TortoiseBzr ! [01:22] hi jelmer - thanks! [01:23] key to its success will be these "external apps" which we call to do the grunt work. I haven't really looked at them yet [01:23] I don't have pygtk locally [01:23] but the cool thing is we can fix them later, and independently of the shell itself [01:23] I think it would make sense to call out to qbzr from tortoisebzr rather than bzr-gtk [01:24] qbzr is easier to install than bzr-gtk and looks more native on windows [01:24] there is an existing impl for a couple of "commands" in the tbzr tree [01:25] I *think* they are gtk, but I've really only noticed they exist, not what they do :) [01:25] yeah, that's all gtk [01:25] so I'm up for nuking them, or whatever everyone agrees [01:25] jelmer, hey :) I haven't had _any_ free time at all these past weeks, but I do have a few hours now. Is the bzr-gtk release missing anything other than the disable-through-nautilus bit? [01:25] we initially created tortoisebzr as a fork of bzr-gtk [01:25] but no1 focus should be the shell IMO [01:25] beuno: yep, that's the only bit missing [01:26] beuno: hi :-) [01:26] right, I need a topic I think [01:26] lifeless: "sock puppets" ? [01:26] how about xul? ;) [01:26] * markh ducks [01:26] jelmer, alright, I'm on it. I'll try and get that done tonight [01:26] beuno: that'd be awesome [01:26] xul! that would be interesting! [01:27] beuno: if those people don't get sponsorship from debian talk to me [01:28] markh: i don't have any particular comments, but it looks like a good start [01:29] markh: I think nuking them wouldn't be a problem - they're also in bzr-gtk anyway [01:29] lifeless: your deprecation of get_graph_with_ghosts appears to also affect get_graph [01:29] markh: i guess i would be inclined not to have a separate cache process other than the xmlrpc server, at least at first, just to reduce the number of moving parts [01:29] jelmer: hello. [01:29] luislavena: hi [01:29] also, maybe you could expand in a future post on what kind of debug/trace _is_ needed? [01:30] poolie, sure, I'll follow it closely. jelmer, LarstiQ, keep your agendas open got august ;) [01:30] jelmer: is there a way I can branch/svn-cache 16K svn revisions without hit the memory error? [01:30] :-D [01:30] beuno: will do, thanks :-) [01:30] poolie: it we move to pure C++ for the shell, I'm a little concerned the xmlrpc requirement will complicate what should be fairly simple [01:30] luislavena: use a version of python-subversion with the memory leaks fixed [01:30] and slower and less secure if implemented via sockets on windows :) [01:31] hm [01:31] what would be better? [01:31] abentley: thats 'index.get_graph' which is on a private attribute of knits - knit._index.get_graph. [01:31] i guess you could make a dcom server in python? [01:31] luislavena: mmm, that will need me to swtich to ubuntu and put that on a pendrive :-D [01:31] luislavena: or you can use "bzr init dir"; bzr pull -r1000; bzr pull -r2000; bzr pull -r3000.. etc [01:31] would that be easier to talk to? [01:31] markh, you'd also be able to get XML straigh out of bzr, just like with the current xmloutput plugin [01:31] the cache process is likely to need to create a hidden window to receive shell notifications from explorer when a user deletes files, for example, and maybe register for asynch NT filechange notifications to even handle the command-line changing the file-system [01:31] jelmer: pull directly instead of branch? [01:32] luislavena: yes, pull 1000 revisions each time [01:32] markh, i guess i don't understand what you mean by "the xmlrpc requirement will complicate what should be [01:32] fairly simple" [01:32] poolie: dcom might work, yeah - but a few simple commands over a named pipe is really quite trivial [01:32] jelmer: great, thank you for the pointer. [01:32] lifeless: acceptable breakage. [01:33] xmlrpc imples a few C++ libraries I'm not familiar with [01:33] DCE/RPC \o/ [01:33] and we want this as thin as possible, as it gets dragged into many processes [01:34] markh: another option is to talk the bzr network protocol [01:34] the encoding for it would be pretty trivial to write in c++ [01:34] some of the commands you need may not exist [01:34] this will possibly be smaller or simpler than xmlrpc [01:35] probably more new code though [01:35] lifeless: looks like abentley and I just reviewed that patch for you. One was approve and the other was resubmit (though my review was borderline tweak) [01:36] Would all the gui apps be written to use this xmlrpc server? [01:36] markh, that's the plan, GUI and IDEs [01:37] lifeless: please to be running the test suite before submitting your patch. [01:37] snap [01:37] But isn't it more moving parts for a GUI app that has direct access to bzrlib? I do see the benfit for IDEs etc, but not so much for gui apps that are "part of" bzr [01:37] but thats fine :) [01:38] I don't need to be convinced ;) [01:38] i didn't think guis would but i might be out of date [01:38] markh, well, if you can access python directly, then it makes sense, yes [01:38] IIRC, there where some use cases for GUIs that couldn't interact with python [01:39] so - that would make the shell code the only known consumer of this server on windows today. Its not written yet, it adds complexity and offers a much richer API than we actually need :) [01:40] hence I'm still on the "simple" side of the fence :) [01:40] abentley: igc: both of you reviewed the superseded, broken, version of it [01:41] abentley: I do run the test suite usually :) [01:41] Should BB have noticed that it was superseded? [01:41] markh, after a whole sprint of "windows support is extremely important", and nobody willing to do anything about it, I guess you should go down whatever path you want, and we can just help :) [01:42] I'm obviously happy to go with whatever is decided - but in the meantime I must take off to the shops for lunch. bb in an hour. thanks for the info about the server thinking! [01:42] beuno: thx - its still obviously open for discussion! [01:43] I'm pretty sure BB didn't notice that it was superseded, because I voted using BB. [01:43] oh hmm === mw is now known as mw|out [01:43] lifeless: sorry about that. I don't seem to have a more recent one in my email though and BB didn't list another with a similar name? [01:45] hmm [01:45] oh, *I* was confused [01:54] is there an advantage to having a shared repo on a bzr server other than saving space? [01:56] LaserJock, nope, and that just applies if the branches have common revisions [01:57] jelmer, we agreed on setting the nautilus disable flag in "~/.bazaar/bazaar.conf", right? [01:59] Well, You save a lot of traffic... [02:00] LaserJock: Yes, it also saves time. [02:02] I guess my question is, is there a difference if the user creates a shared repo or if it's already a shared repo on the server? [02:02] not sure if I was clear the first time [02:03] LaserJock: no different really; but lp doesn't support or use shared repos's. if thats what you were thinking :> [02:03] LaserJock, my attempts to use shared repos for _many_ unrelated branches led to some weird results [02:03] lifeless: yeah it was [02:04] lifeless: does LP support rich-root-pack ? [02:04] yes [02:04] LaserJock, LP has the latest version of bzr, so whatever you push to it will work [02:05] so just getting some LP bzr admin type to convert our dirstate-with-subtree branches to rich-root-pack should speed things up and allow us to make shared repos, correct? [02:06] that's my bottom line I guess :-) [02:06] LaserJock, you shouldn't need an admin if you have access to the branch [02:06] you can just "upgrade --format=" [02:06] heh [02:07] but I can't really push it back up [02:07] if it takes pushing the whole branch [02:07] LaserJock, no, you can do bzr upgrade --format bzr+ssh://laserjock@baza.... [02:08] well [02:08] beuno: But upgrade doesn't work over bzr+ssh, right? [02:08] you can't beuno [02:08] oh? sftp then? [02:09] That works, or should. [02:10] LaserJock, right, sftp instead of bzr+ssh [02:10] so would the LP server then do the conversion? [02:10] yeap [02:10] * LaserJock struggles to wrap his brain around this stuff [02:11] Well, no. Your local bzr client does the conversion over sftp. [02:11] So this can be _sloooooooow_. [02:11] so when I did it locally it took 40 min [02:11] of course, I'm not sure what wil happen when pushing/pulling from other local formats. You'd probably want to upgrade all current branches [02:11] when we first pushed this branch it took about 5 days [02:11] so roughly how long do you think it'd take? [02:12] LaserJock, I'd say run it and go to sleep :) [02:13] I'd have to do it for 4 branches [02:13] and I only have 2 locally [02:14] LaserJock, many times it's faster to re-branch [02:14] what do you mean by re-branch? [02:14] upgrade in LP, and re-branch to your box [02:14] ah [02:14] much cheaper in big repos [02:15] if we could get that done before Intrepid get's really going I think it'd be a big advantage for new contributors [02:16] beuno: upgrade over sftp copies all the data twice [02:16] beuno: over the wire [02:16] LaserJock, if it's that big of a deal, then it might be faster to get a LP admin to do it. Maybe abentley? [02:17] lifeless, ah, so it should be cheaper to upgrade locally and fully re-upload? [02:17] beuno: yeah, I just sent an email to the team to start a discussion about shared repos and getting the format upgraded [02:17] we'll see how it goes, but I'm sure everybody will like the improvement [02:18] how old of a bzr version will handle rich-root-pack? 1.0 ? [02:19] LaserJock, I think from 0.92 [02:19] or 0.91 even [02:19] so 1.0 should be a safe bet [02:19] k, just wondered about gutsy users [02:20] They were introduced in 1.0, according to NEWS. [02:20] abentley, wasn't it introduced with packs itself? [02:20] no [02:21] * beuno is awfully wrong today [02:21] * beuno alt+tabs into vim [02:26] beuno: at least that's one thing right. [02:27] jdong, :p [02:27] jdong: I thought it was just typo ;-) [02:28] *just a [02:40] igc, btw, thanks for redirecting all the IDE people to be, I've got a pretty good list of people working on stuff. I'll put up a wiki page with it soon [02:41] beuno: excellent. I almost did exactly that yesterday but didn't get to it [02:41] I want a page called EditorsAndIDEs (say) that lists all of them together with software and/or contact points [02:42] exactly what I had in mind :) [02:42] we can also use that to direct people to the team you've set up [02:43] igc, yeap, sounds great. Seems the news from the sprint got many people excited about it [02:44] igc: there were two patches ... [02:45] lifeless: didn't abentley approve the seocnd one? === bigdo1 is now known as bigdog [02:49] *blush* [02:49] ok [02:59] * igc lunch & doctor visit [03:41] abentley: cool patch; I don't think I'll get to review it myself today [03:42] abentley: but it sounds excellent (though I'm not 100% sure about validating against different formats automagically) [03:42] abentley: spiv: duplication reduction ping [03:42] lifeless: Well, that's only on conversion. And it's only if the obvious choice fails. [03:43] so, I've reduced about half of the duplicate sites to use helpers; the rest are not actually all the same [03:44] the knit and versionedfile ones don't filter nulls and so on [03:44] Otherwise, I would have to fail to convert. [03:45] well, my thoughts were that if its wrong, its wrong and failure is expected. [03:45] I'll sleep on it [03:45] So that means that if we convert something from format 5 into 6, we can't convert it to 8 [03:45] And similarly for 7 -> 5 [03:45] sorry, 7->6 [03:46] the way I looked at it, reading the old inventory will fail [03:46] so this is a job for reconcile, which is allowed to be slower and more complex than just pull [03:46] lifeless: yeah, in the patch I saw I think there were two variants. [03:47] spiv: do you want to see the new diff; I think its about as reduced as I'm comfortable with [03:47] or an incremental diff? [03:47] or [03:48] lifeless: But then you're generating format 5 serializations with differing inventory_sha1s for the same revision. [03:48] lifeless: an incremental diff would do [03:48] abentley: huh? whatever rich-root is today - yes. And it can happy today trivially. [03:49] abentley: all you have to do to get different inventory sha 1s today is to do a bzr baz-import into a rich root repo, and also a bzr baz-import into a pack-0.92 which you then upgrade. [03:49] The 5, 6 and 7 serializers all use format 5 for their serialization. [03:49] of revisions. [03:50] and ditto with bzr-hg/hg-import etc - all the deterministic importers will create this [03:50] spiv: mailed you [03:50] lifeless: ta [03:51] lifeless: That's just them not being completely deterministic. [03:51] jelmer, sent the patch :) I suppose I have to add the stuff I ahve done up to now in NEWS, but I'll wait until it gets approved to send that in [03:51] abentley: they would have to generate a format 5 inventory, grab its sha, and then reserialise to format 7 inventory [03:52] abentley: I think they are being completely deterministic; its *our* bug on upgrade that makes any problems exist; which is what your patch is about fixing. [03:52] They're not deterministic. They don't force the root revision_id to always be updated, AFAIK [03:52] which is the non-rich-root behavior. [03:53] abentley: mmm, possibly; [03:53] i.e. what you'd get if you converted something from baz into knit, then rich-root. [03:53] lifeless: +1 [03:56] thanks [03:57] poolie, if you want some help with bzr packaging for ubuntu, just upload the current branches to LP and I'll pitch in to get 1.3 into PPA [03:57] beuno: I need a topic suggestion; looms would be ideal but they aren't really polished yet :( [03:58] lifeless, how about generically going for "managing your packages with bzr"? [03:58] and then see how polished they are by august :) [04:16] is there a simple way to have bzr show the traceback when it can't load a plugin? [04:17] markh: the traceback is written to the .bzr.log [04:17] ah - thanks! [04:17] markh: it might be good if there were a -Dplugin debug flag, perhaps. [04:28] markh: i would think -Derror should do that but i guess it does not? [04:31] heh - the log is in "my documents" :) [04:42] so - .bzr.log is misplaced IMO on windows. What is the best place to discuss that? Open a launchpad bug or just email the list? The patch is trivial, but agreement on the correct place might not be ;) [04:43] markh: see the archive first please [04:43] markh: its not accidental where it is :> [04:45] bugger - so it is to help the user find the log? [04:46] it may be that there is a better place [04:46] bzr --version shows where the log is going [04:47] so please google a bit, and if you decide that it should be moved:- send a [MERGE] in :) [04:48] well - making it easy to explain to a user where to find the log is very true and I don't want to start a bikeshed discussion - but I think its safe to say I'm very glad that no other apps take the approach of dumping their logs where I store my documents ;) [04:49] markh: which is why I am acking that there may be a better place; but asking you to check the history a bit first, and rather than openning a bikeshed discussion, send in a patch that does the right thing [04:52] fair enough - tho me even bringing it up is kinda bikeshedding :) [04:55] I don't think its bikeshedding to say 'here is a way to do things better'. bikeshedding is arguing about trivialities. [04:55] "I want my shed to be pink, and called 'My Documents'" ;) [04:57] I did assume the location was "accidental" - but given it was explicitly decided, the location of the log file is almost a triviality at this stage of the game - much bigger fish to fry! [04:58] eg, how we bend py2exe to allow plugins to work OK in binary releases. For now I'll just switch to a source version of bzr instead though... [05:18] tchau [05:18] bye lifeless [06:28] Is jam up? Guess not. [06:29] AfC: he's on holidays for the next week and a bit [06:29] poolie: ah! Nice. Thanks [06:33] i've forwarded your expenses [06:33] btw [06:35] poolie: thanks [06:35] ! [06:35] poolie: So it's probably a rear guard action at this point, [06:36] but I'm trying to [automate] set up [of] bzr-svn branches for GNOME projects for people to use. [06:36] I'm happy to publish a selection of the resultant branches on our R&D server, but [06:37] I was wondering if the launchpad guys are {likely, in progress} doing that themselves [06:37] i'd like them to move to doing it through bzr-svn rather than cscvs [06:37] (versus bzr-vcs-import, which is unfortunately no good for projects that are not migrating but still using Subversion as their main) [06:37] for a few reasons including the result being more useful, ... well you can imagine [06:38] but that is not on their plate at present [06:38] um [06:38] i have heard there is interest in having those imports though [06:38] poolie: ok. Just thought I'd ask before writing a bunch of scripts and kicking them off. [06:38] sure [06:38] can you mail the list when you do it? [06:38] i'd like to at least mirror them to launchpad [06:38] poolie: yeah, I sorta heard that murmour in the back of the room in London; I also now understand some of the things the Launchpad team are up against. [06:39] :) [06:39] poolie: yeah, for sure. [06:39] we had an interesting thread about downtime recently [06:39] it's actually above 99% but whether that's good or not depends on your point of view [06:40] anyhow i should finish rebuilds [06:40] Not bzr-svn's fault, but I had to do the 100 revisions at a time trick to try and do the 19,000 revision repo. I didn't have a server handy with the patched Subversion, and the machine I was on (ie, my laptop) was in an environment that was VERY intermittent. [06:40] It took 9 days to do the import. [06:40] Needless to say, I'm not going to tell anyone else that :) [06:40] well [06:41] this is one reason it would be good to get it running on proper infrastructure [06:41] poolie: [99%.... for most people, that's pretty good. The one I usually look for is planned vs unplanned] [06:41] AfC: jelmer says bzr-svn 0.4.9 is much faster, btw [06:41] spiv: I was just going to grab it... I know it has the changes that you and he made a couple weeks back [06:42] AfC: so if the dependencies aren't too horrible, it'd be worth trying the upgrade [06:42] spiv: should be ok... I just had to jump through lots of stupid hoops to get Subversion to co-operate. [06:42] Anyway, it's on my list of things to contribute in April. === doko_ is now known as doko [07:59] night all - have a good weekend === cprov-out is now known as cprov === weigon__ is now known as weigon [09:24] thanks jdong [09:26] hi james_w [09:26] hi poolie [09:26] how are you? [09:26] very good [09:27] i should sign off though... [09:27] have a good weekend [10:16] G'day all [10:17] Hi Lo-lan-do [10:17] I'm reading about the new dpkg source formats, including one called "3.0 (bzr)". [10:17] (Basically, replace orig.tar.gz+diff.gz with a single tarball containing a bzr branch) [10:18] That sounds interesting to me, but converting my main package (gforge) to it would make the source package grow from ~10MB to ~60MB, because of the full history included. [10:18] So I was wondering whether the history horizon/shallow branches feature is still being worked on... [10:19] i expect any package will have that problem too :| [10:20] Not every package has thousands of revisions, but yeah. [10:20] It would be nice to be able to only keep like the last year of revisions. [10:21] some preparatory work is happening but it is still over the horizon [10:22] I see. [10:23] um [10:23] but you can use lightweight checkouts in many places, i presume [10:23] and then they will not be so large [10:23] anyhow, really going now [10:24] I know about lightweight checkouts, but that's not the use case I'm talking about. [10:27] poolie: nice pun :-) [10:27] heh, so I wasn't the only one =) [10:27] hi dato [10:28] hello james_w [10:28] Lo-lan-do: I haven't looked in to those formats to understand them yet. [10:32] james_w: They sound promising to me, but I won't switch quite yet, because of the size problem. [10:32] yeah, I think that's reasonable. [10:33] it seems to me like they may be more of a stepping stone to get to a proper VCS based workflow [12:20] Moin moin. === mrevell_ is now known as mrevell-lunch [13:05] Just making sure, when I work with a remote repo, I do a "bzr commit" and after that a "bzr push", right? [13:06] So that my changes get immediatly applied to the remote repository? [13:06] Yes, unless you're in a checkout (bound branch) [13:06] by repo you mean a branch created by 'bzr branch'? [13:07] luks: not hundred percent. By repo I mean a svn+https:// url that I have created via bzr svn-push. [13:07] andreas@andi-lap:~/lookery/lookery_memberfind> bzr merge svn+https://lookery_andreas@lookery.unfuddle.com/svn/lookery_process/trunk/logs/lookery-memberfind [13:07] bzr: ERROR: Repository KnitPackRepository('file:///home/andreas/lookery/lookery_memberfind/.bzr/repository/') is not compatible with repository SvnRepository('svn+https://lookery_andreas@lookery.unfuddle.com/svn/lookery_process') [13:07] oh, no idea about bzr-svn [13:07] Isn't that peachy? [13:08] this looks like a incompatible shared repository format [13:08] yacc: you created ~/lookery/lookery_memberfind with bzr-svn? [13:08] and I think it's explained in bzr-svn's FAQ [13:09] No, lookery/lookery_memberfind was the initial directory where the project started, so it was created by bzr init. [13:09] the project originated in bzr, then was branched to svn? [13:09] bob2: yeah. [13:09] the bzr branch has to have a compatible repository format [13:10] Yeah, but upgrade --rich-root-pack breaks too. [13:10] 'bzr upgrade --rich-root-pack' (ideally after making a backupof it) [13:10] ah, suck [13:10] bob2: well, I did already svn-push from this directory. [13:10] the push will be fine [13:11] pull/merge won't, tho [13:12] some missing revision error from bzr upgrade? [13:12] yacc: what's the error on upgrade? [13:12] Yeah, but it complains about diverged branches and asks me to merge. Which is curious, as there have been no commits to the directory in the mean time. [13:12] bob2: it complains that some version does not exist in the repo. [13:12] james_w: bzr: ERROR: Revision {('andreas@andi-lap-20080318163204-v6cbndpdo3k2hneq',)} not present in "". [13:13] suck [13:13] yeah, I don't know if there is a workaround for that problem yet, sorry [13:13] what about 'bzr missing' - does it show revisions missing on both sides? [13:13] abentley: hi, are you around? [13:13] james_w: yeah, I'm getting this sick feeling that despite jelmer's efforts bzr-svn is not a viable svn client solution ;( [13:13] 'bzr reconcile' might 'fix' it for now [13:13] bob2: I already run reconcile [13:13] james_w: hi [13:14] abentley: hi, is there a workaround known for yacc's error above? [13:14] yacc: the issue is with the conversion, as far as I know - if you'd started with rich-root-pack (or branched from svn), pretty sure it would be fine [13:14] That's curious, branching the svn repo freshly, commit the single again, and pushing it worked fine. [13:14] bob2: yeah, I have a feeling that the "start a svn repo with bzr" is not exactly a typical usecase. [13:14] yeah, you get the right local repository format that way, the problem is with the upgrade [13:15] yacc: maybe branching the original bzr branch into a rich-root-pack repo would work, too [13:15] What was the original format? dirstate-tags? [13:16] bob2: well, I'll try to start my new egg with svn mkdir && bzr branch for a change. [13:16] abentley: the format before was pack-0.92. [13:16] abentley: KnitPackRepository [13:16] abentley: But svn-pushing worked before, ... [13:16] yacc: yeah, it's not the typical use case. [13:16] yacc: pushing wiwll work, it's the pulling of data from svn that is the issue, afaik [13:16] yacc: You were using bzr-svn 0.3? [13:17] abentley: nope :) [13:18] bob2: yeah, but it complained about diverging branches, so pulling was needed too. [13:18] bob2: despite that nobody has commited anything to the directory on svn. [13:18] yacc: does 'bzr missing' explain that? [13:18] yacc: AIUI, bzr-svn 0.4 requires a rich-root format. So I don't know how you got that. [13:19] bob2: nope, I already managed to push it via a fresh branch. [13:20] abentley: which makes me wonder how the revisions in lookery-memberfind ended up in the svn repo in the first case? [13:21] Ok, I've got an idea what can be out of whack. [13:21] bzr missing complains that I'm missing the initial revision the directory is based on, that I did via "svn mkdir" if I remember right. [13:21] yacc: Could you run this in the root of your branch please? [13:21] python -c "from bzrlib import workingtree; wt = workingtree.WorkingTree.open('.'); wt.lock_read(); print wt.inventory.root; wt.unlock()" [13:22] abentley: nope, the branch had a portion of tender-love-care from rm -Rf ;( [13:22] yacc: So you didn't originate this bzr-svn conversion? [13:23] I did orginate yet again, but I solved it by branching the svn url freshly, applying my change and pushing it. Everything worked fine then. [13:24] yacc: did you just start with bzr init, made some commits, and then did bzr svn-push? [13:24] james_w: yes. [13:24] Alright, I guess there's nothing for me to see here. [13:24] thanks abentley [13:25] james_w: To somewhat answer your question, there are two fixable causes of that error. [13:25] One is the sort of data inconsistencies that reconcile will fix, so that's fixable. [13:26] And the second one? [13:26] The other is that the non-rich -> rich converter assumes non-rich trees have TREE_ROOT as their tree root. That hasn't been addressed yet, but I'm planning to do it as part of my pack-1.4 work. [13:28] hey guys -- any news on nested branches? [13:28] abentley: great, thanks. [13:29] schierbeck: I think LarstiQ had almost all tests passing in London, so hopefully we will get the first bits to review at some point. [13:29] awesome! === mrevell-lunch is now known as mrevell [13:56] bzr+http woohoo!!! [13:56] finally got the basics running [13:57] not if only I could figure out how to use the update the working tree remotely or an alternate work flow that will server multiple developers [13:58] I have bzr+http with write enabled working with mod_authz_ldap [13:58] anybody here to share my joy :-) [13:58] "yay!" [13:58] Yaaay. [13:59] dato: Lo-lan-do: thanks [13:59]