[00:07] hello all [00:15] lifeless: hi, i was thinking about having a stab at either bug 385826 or bug 393677 today... [00:15] Launchpad bug 385826 in bzr "push and pull with different formats extremely slow on network" [Critical,Triaged] https://launchpad.net/bugs/385826 [00:15] Launchpad bug 393677 in bzr "pushing a 1.9 branch stacked on a 2a branch causes problems" [High,Confirmed] https://launchpad.net/bugs/393677 [00:15] 38826 is what spiv is working on [00:16] 393677 doesn't conflict with anyone [00:16] so I'd suggest 393677 [00:24] hm i meant the one with InterDifferingSerializer [00:24] but at any rate it's related to what he's doing [00:24] i was hoping it would be complementary [00:24] i wonder if he sent his patch... [00:25] poolie: so there are three things that need to lang all roughly at the same time [00:25] 1) streaming inv deltas [00:25] 2) fixup the streaming rich root conversion [00:26] 3) disable IDS for non-local operations [00:26] my hunch is that its better to have one person do all three, as I expect test interactions [00:29] poolie: still working on that patch... currently fixing differences in behaviour between the streaming path and InterDifferingSerializer that the tests found. [00:30] spiv: the rich root conversion path? [00:30] lifeless: right [00:30] great [00:30] Which I guess is your 2) from above. [00:30] yes [00:30] there are three separate bugs for 1,2 and 3 [00:30] I'm basically taking the logic from IDS and transplanting it. [00:30] you'll probably want to close them all :) [00:31] Sure, the more bugs closed the merrier :) [00:32] FWIW, I have the bulk of 1) done, although I haven't finished exhaustively testing or polishing because of 2). [00:33] the reason for 2 is that without 3, which needed 1, I'd have had to write awkward tests for 2 rather than the simpler generic tests [00:33] and as it wasn't being used that seemed counterproductive [00:35] hHi [00:35] I upgraded to 1.16 on Windows and I keep getting now "bzr: ERROR: Unable to look up default port for ssh". [00:35] Any ideas why? [00:35] GungaJin: Someone else had that error the other day, but I don't recall the cause :/ [00:36] Which version did you upgrade from? [00:37] 1.14 [00:37] Hmm, I wouldn't expect there to be any changes since 1.14 that would cause that. [00:38] But that's what I'm getting on Windows [00:38] I wonder if something odd changed in the build process for the Windows installer since 1.14? [00:38] It sounds like a system misconfiguration issue, but I don't know why 1.16 would expose it if 1.14 didn't. [00:39] GungaJin: can you run the command with -Derror added to the commandline, and pastebin the traceback? [00:40] sure [00:41] Hmm. That error string isn't part of bzrlib, so maybe it's one of the bundled plugins that's causing it... [00:41] http://pastebin.com/m6d892fee [00:42] Ah-hah, and I was right. [00:42] It seems to be due to the bzr-svn plugin. [00:42] please file a bug on bzr-svn [00:43] Probably you can work around it by using --no-plugins or explicitly giving the port number in your URLs (i.e. bzr+ssh://hostname:22/...) [00:43] But please do file a bug. [00:44] How can you tell it's in bzr-svn? [00:44] I *think* this bug is already fixed in bzr-svn trunk, looking at the code. [00:45] I think so too.. I just found a similar post in launchpad. [00:45] (it now mutters that message to the log and returns cleanly, rather than raising an error) [00:45] https://answers.launchpad.net/bzr/+question/73528 [00:45] GungaJin: I can tell because the last part of the traceback is in plugins\svn\auth.py [00:46] i c [00:46] (sorry.. I don't really know python..) [00:46] Sure, that's ok. [00:46] That's what we're here for :) [00:48] igc, you should blog about the bzr-explorer release with pretty pictures [00:51] poolie: shall do [00:53] is there a recommended way to convert from svn to bzr? i used just "branch" (with bzr-svn installed) and it seems to do the expected (creating a native bzr branch) [00:53] jelmer: with what should I replace "svnversion" in a Makefile in order to get something sensible from a bzr-svn working copy? [00:59] zsquareplusc: Yeah, that's about it. [01:00] SamB: GNOME Do uses 'bzr version-info --custom --template="bzr {branch_nick} r{revno}"' [01:00] fine [01:00] and is there a history editing tool. i.e i have an private branch that i'd like to clean up before publishing [01:01] zsquareplusc: 'uncommit' is about all there is [01:01] zsquareplusc: Not really. You _can_ effectivly re-structure history by judicious merging, though. [01:01] RAOF: I meant, a way to extract just the nearest ancestral SVN revision number [01:01] with maybe some indication of how far away it was [01:01] zsquareplusc: in general, there's not much reason to clean up history in a branch [01:02] igc, it does look like links to the group blog posts are broken on planet bazaar [01:02] since it doesn't show up in the normal log of mainline [01:02] the feed looks ok to me so i'll file an rt I guess === abentley1 is now known as abentley [01:02] poolie: but clicking on things from the feed, does that work? [01:03] yep [01:03] zsquareplusc: If you've got a branch with lots of experimental commits, and you'd like to tie them into feature-commits, you can bzr merge -rA..B ../experimental branch, possibly fix stuff, then commit. Follow with bzr merge -rB..C ../experimental, rince and repeat. [01:03] how about for you? http://bazaarvcs.wordpress.com/feed/ [01:03] How do I uninstall the svn plugin? [01:03] dash: because i ran that project privately it may contain comments not intended for others eyes. or think of passwords in old changsets [01:05] RAOF: ah ok. so i could create a new history with a few important points relatively easy. [01:05] zsquareplusc: I don't _think_ there's much support for that yet, although it's an acknowledged need. Someone more knowledgable might have a better idea. IIRC I've seen lifeless talk about this before? [01:06] zsquareplusc: what RAOF described doesn't erase history [01:06] the alternative is i just import the head w/o any history. but that is kind of sad for all the time i took to write the commit comments :-) [01:06] Yeah. What I sugested merely clusters history into potentialy more useful groups. [01:07] GungaJin: if you've used the executable installer you can't [01:07] GungaJin: because its bundled in the same exe === abentley1 is now known as abentley [01:07] filing an rt for the feed links... [01:09] GungaJin: I think we'll need to fix the 1.16.1 installer with a new bzr-svn [01:10] i could start with an empty branch and go through the revisions of the original, copying the files to my branch for each step. would some work. :/ [01:11] zsquareplusc: _do_ you have passwords in your revision history? [01:12] lifeless - probably, but I don't feel like writing --no-plugins all the time... and I don't use this plugin anyway. [01:12] there is a plugin named 'bzr-rebase', it might be of help [01:12] dash: probably not :-) but it is a history over a few years, who knows what i did back then ;-) [01:13] an other issue i have is with bzr-gtk. everytime i start one of its commands like bzr vis i get a traceback (DBusException) on the 1st run. the 2nd time it is working. [01:14] mm. with 1.13.1 (jaunty) [01:14] GungaJin: I think there may be another way around it [01:15] I'll be glad to hear it. [01:15] GungaJin: you might be able to avoid that error by adding an entry for ssh to your windows\system32\drivers\etc\services directory [01:15] s/directory/file// [01:16] ? [01:18] GungaJin: I haven't used Windows in a pretty long time, so I might be wrong, but I think that file is used to lookup port numbers when a program calls the getservbyname winsock function. [01:19] GungaJin: you can probably just add a line like "ssh 22/tcp" to that file to avoid that bzr-svn bug [01:19] hmmmm... could be. [01:19] but I'm just using the default port... [01:19] spiv: why does guessing that have anything to do with using windows? [01:19] (that bzr-svn bug is triggered when getservbyname fails to look up a port for a scheme like 'ssh') [01:19] oh, because you can't remember if there is a file like that? [01:20] SamB: I'm pretty sure there used to be a file like that in roughly that location in older versions of Windows. [01:20] SamB: I could be wrong about the details, current Windows might do something completely different, etc :) [01:20] well, if there is already a file there, you can be pretty sure that it's for that [01:21] I think I'm mostly right, or wouldn't be wasting GungaJin's time, but I figure I should be clear when I'm not totally sure about my advice :) [01:21] a quick google indicates that they're apparantly still there in vista [01:29] lifeless: sorry to bug you, but any plans of what to do about my bzr check failing bug? [01:29] lifeless: I have a lot of users that would like some faster performance, and we can't upgrade because check fails [01:29] maybe there is someone else who could help? [01:30] kingos: what's the bug number? [01:31] bug 356028 [01:31] Launchpad bug 356028 in bzr "bzr check fails with KeyError" [Undecided,New] https://launchpad.net/bugs/356028 [01:35] kingos: hi. I'll look into it this afternoon. === obstriege is now known as obst [01:49] lifeless: thanks [02:45] jhello [02:46] 2 collaborators, no server [02:46] how do I set up something like this [02:49] no server at all, or could you run a ssh/sftp server? [02:50] emet, if you have email you can just use bzr send [02:50] then merge or pulll from the bundles [02:50] zsquareplusc: please explain your question a little more [02:52] davidstrauss: that was directed to emet. i like that you can push and pull a bzr branch to a server with just an ssh account there. so no special SW on server [02:57] okay bzr send might be a solution, SSH seems like a more secure solution [02:59] emet: bzr send is plenty secure if you review the diffs [03:00] well, send is as secure as your email setup [03:00] send with gpg and smtp tls and it's about as secure as ssh imo [03:02] Grr, pycurl test hangs are annoying. At least you can strace to find out the fd it is polling then use gdb to close the fd to unhang it (and fail the test). [03:07] popping out for a walk; going to think about how best to fit in the iterchanges changes for dirstate [03:14] Still, everything other test is passing, so that's good. [03:15] Now to fix the duplicated code... [03:53] * igc lunch [04:04] spiv, can you push it before you go out? === spm_ is now known as spm [05:21] I wish pyrex could be run straight from python [05:21] it would be awesome [05:22] Like what, import a .pyx and it would be automagically sorted out? [05:22] Doesn't Cython have a feature like that? [05:23] lifeless: http://docs.cython.org/docs/tutorial.html#pyximport-cython-compilation-the-easy-way [05:30] Peng_: no, I mean run in emulation [05:30] Peng_: to allow debugging with pdb etc while fixing shit [05:30] then set it free with C after that [05:31] Oooooh. [05:31] Peng_: do you do stuff with GnomeDo? [05:31] lifeless: Never heard of it. [05:32] I saw a reference to Peng in the release blog post for it yesterday [05:32] was wonding if Peng == Peng_ [05:33] I really should've gone with a more unique handle... [05:44] Peng__? [05:53] lifeless: Too many other people use Peng. [05:54] Uin? [05:54] Yeah. :\ [05:54] (pronounced 'win') [05:54] * Peng_ is terrible at coming up with names. [05:54] I'm suggesting it for a name for you [05:54] God forbid I ever have children... :D [05:54] Oh. [05:54] Not taken. Does Freenode allow 3-lettern icks? [05:54] err, s/n / n/ [05:54] try it... :) [05:54] I suggested Peng__ too, but you seemed to miss the joke :) [05:55] lifeless: Oh. Yes, I did. [05:55] Someone on one network is annoyed by the single _. Two would probably kill him. :D [05:55] "joke" :) === BasicPRO is now known as BasicOSX [06:35] \o/ dirstate pyx passing the first test [06:35] its polish from here on it [06:35] *in* [06:39] that's good [06:39] still got some careful thinking to do [06:39] but also surprising to me [06:39] about ways we could still generate bad inv deltas [06:39] poolie: whats surprising? [06:45] python passes; CHKInv next [07:13] hi all [07:16] hello vila! [07:41] vila, lifeless, any thoughts on my recent comments at the bottom of bug 340347? [07:41] Launchpad bug 340347 in bzr "log+ transport apparently breaks readv iterator" [High,In progress] https://launchpad.net/bugs/340347 [07:41] poolie: listifying is permitted by the contract [07:42] poolie: in particular, the http transports all buffer a full copy AIUI (because of the underlying behaviour) [07:42] hm [07:42] i doubt access to packs over http would work in that case [07:42] and it does seem to [07:43] lifeless: meeep, only pycurl does that [07:43] if it doesn't turn them back into a generator it will probably give a similar failure [07:43] it might... [07:43] * vila checking [07:44] poolie: so what failure do you get? MemoryError? [07:45] lifeless: http does buffer a lot of stuff potentially but does eventually yield it out of readv, as a generator [07:45] bzr: ERROR: exceptions.AttributeError: 'list' object has no attribute 'next' [07:45] oh [07:45] typical failure for something that wanted a generator and got a list of course [07:45] the iterator probably wants to return iter() of what its returning at the moment [07:45] s/iterator/generator/ [07:46] poolie, lifeless : confirmed, pycurl buffers as much as 4M, while urllib-based goes to great lengths to *not* buffer at all [07:46] -or- the calling code should iter() what it gets [07:46] vila: hyopthetical [07:46] lifeless: ?? [07:46] lifeless: itym s/iterator/decorator/? [07:46] vila: what happens if you ask for 10000000-10000999, 15-20, and the server gives a 200 [07:46] as i say, i'm actually wondering if we should do both of those [07:47] poolie: yes, yes, I do [07:47] poolie: and I think both would be sensible [07:48] lifeless: as in 'squid is involved' ? :-P Seriously, pycurl will certainly raise MemoryError, urllib should just seek() the unwanted bits (I don remember exactly if we allow unsorted ranges) [07:49] vila: any server is allowed to do this [07:49] lifeless: I know, but some proxies abuse it (still joking ;-) [07:50] vila: squid doesn't do this in fact; it generates ranges from its local cache [07:50] vila: if we _permitted_ it to cache it would do better [07:54] lifeless: hmm, I didn't thought about that... From https://bugs.edge.launchpad.net/bzr/+bug/120697/comments/7 , my conclusions at that point was that we don't want squid to download a whole xxGB pack files for answering requests that will at most represent yyyMB, am I wrong ? [07:54] Ubuntu bug 120697 in bzr "bzr shouldn't bypass http caches" [Unknown,Fix released] [07:55] Is it time to talk about Squid in this channel, too? :-) [07:55] vila: we don't, but on the other hand if we're going to read all the pack file eventually anyway, cache hits would be good [07:56] lifeless: ok [07:58] poolie: I implemented readv as http://paste.ubuntu.com/207353/ in my transportstats plugin, AFAIK the tests are still passing [07:58] poolie: i.e. just do for item in whatever-the-decorated-returns: yield item [07:59] yeah [07:59] log+ folds the whole thing into a list [07:59] this may be inferior [07:59] in several ways, but it does mean we can print the whole size [08:00] yup, that's a problem transportstats has to address at a different level (and theres is still that big FIXME) [08:00] let's merge it sometime... [08:01] at least the feature if not the code [08:01] getting a total count at the end of -Dhpss is good... [08:01] yeah, there is a huge TODO in that plugin :-/ [08:06] ciao [08:06] lifeless: g'night [08:06] cheerio [08:19] lifeless, how about moving ReadVFile from pack.py into transport? [08:19] it seems totally generic [08:19] i guess it can wait though. [08:40] is there a bzr service like bitbucket [08:41] launchpad.net === abentley1 is now known as abentley [09:35] * igc1 dinner [09:47] Hi, I have a problem with bzr-svn - I branched a repo and then branched from that for my working copy. Later, I had to bzr svn-upgrade the svn repo due to the format changing in bzr-svn. Now I can't merge my working copy back into the svn one since the ids are different, nor can I bzr svn-upgrade the working copy since the parent is not a foreign repository. === spetrunia is now known as spetrunia|bbl === jelmer is now known as Guest78562 === Guest78562 is now known as jelmer [11:49] Should 2a always be smaller than the equivalent 1.14-rich-root repository? [11:51] awilkins: http://bazaarvcs.wordpress.com/2009/06/30/scability-benchmarking/ [11:53] I'm just repacking it [11:53] It was 711M to start with now it's 904 [11:53] Don't forget obsolete_packs. [11:53] Deleted those [11:53] And I'm only sizing "/packs" [11:54] hi all [11:54] a small stupid question, how can I cherry pick the last 3 commits from a release branch into trunk ? [11:55] bzr merge -r -3.. ../series/0.2 doesn't produce the expected result for me [12:02] asabil, what's unexpected exactly? [12:03] I would like it to apply the 3 last commits as patches into the current working tree [12:04] at least that what I would expect since bzr doesn't track cherry picks === kkubasik_ is now known as kkubasik [12:04] asabil, but what does bzr merge -r3... do that you don't expect? [12:04] it just applies the last commit as a patch [12:04] asabil, ah, sorry [12:04] asabil, if you mean the *last* three patches, try -r-3 [12:05] -r-3 will only apply the 3rd to the last patch according to the bzr user guide [12:08] LarstiQ: After a repack it's now 651MB so a little smaller :) [12:09] awilkins: ok [12:13] bzr.dev r4494 ("(Jelmer) Pass create_prefix paremeter to BzrDir.push_branch.") doesn't actually introduce any changes... [12:13] asabil, I mean -r-3.. [12:14] jelmer: doesn't work, it tries to delete all the files [12:29] Having 'bzr shelve'd some changes, can I show the stored diff somehow; like bzr shelf1 show ? === cprov1 is now known as cprov [13:04] * asabil thinks that bzr needs something like bitbucket or github === mrevell is now known as mrevell-lunch [13:23] Hi. [13:23] I'm receiving the following error when trying to `bzr branch`: http://pastebin.ubuntu.com/207499/ Is there anything I can do to resolve it? [13:36] gmb: there are bugs filed that look like that. Offhand you could try reconcile [13:37] LarstiQ: Okay, I'll give that a shot and do some digging. Thanks. === mrevell-lunch is now known as mrevell === maxb__ is now known as maxb [14:50] Goood morning jam ! [14:50] morning vila [15:02] meh - is there a way to resolve "AssertionError: Tried registering as parent while None already was parent" on a bzr-svn pull? [15:06] Tak, what version of bzr-svn? [15:13] whatever comes with the bzr1.16 winstaller [15:14] Tak, you may be able to fix it by removing the cache directory and letting it regenerate that [15:14] where is the cache directory? [15:15] somewhere under the directory with local settings for your user account [15:15] %appdata%\bazaar\2.0\svn-cache [15:16] Yegods, our network is reaching new lows today [15:17] success! [15:28] hello bzr! [15:29] jam, vila: I have fix for bug 307554 [15:29] Launchpad bug 307554 in qbzr "`bzr branch URL .` refuses to create new branch in empty directory" [Medium,In progress] https://launchpad.net/bugs/307554 [15:29] can somebody review it? please [15:29] http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch21ldm%248pt%241%40ger.gmane.org%3E [15:34] wow, I was convinced you managed to addresed the problem in qbzr only and din't need a fix bzr 8-/ I realized you updated the bug on lp correctly but I misread things between the greyed 'undecided' and the double affectation bzr/qbzr :-/ [15:35] vila: no, the fix for bzr core is still required [15:35] bialix: I see that [15:35] ok [15:36] I've followed lifeless suggestions [15:37] bialix: sounds correct at first read, I'll install it and review [15:38] I know, I've missed NEWS entry [15:39] bialix: an Ukrainian and French to write NEWS entry in English :-) Help ! [15:39] can I help? ;) [15:39] Dutch to rescue ! Hurrah ! [15:40] it was joke, I knew [15:40] :-) [15:41] bialix, LarstiQ : Joke aside if alex can pastebin a proposed NEWS entry and wouter can review it, I'll submit the result :) [15:41] ouch! [15:42] branch now accepts a --use-existing-dir parameter (Alexander Alexander Belchenko, #307554) [15:43] Is that correct and complete enough ? [15:45] no, you wrote my name twice [15:46] bialix: :) [15:46] one sec [15:46] bialix: your got the code from cmd_checkout ? [15:46] cmd_push [15:47] vila, larstiq: http://pastebin.com/m160586c6 [15:47] LarstiQ: ^ [15:47] ok? [15:48] god for me [15:48] good for me [15:48] LarstiQ: you have to approve it [15:48] pleeeease! [15:49] heh [15:49] he's ran away? [15:50] vila: it seems so [15:54] vila: what is your verdict? [15:55] approve, I'm fixing a few typos and I'll submit [15:55] ok, many thanks [15:57] jelmer: should I file a bug about that? I'm not sure how to reproduce... [15:57] (bzr-svn issue from hours ago...) [16:00] Tak, It works now? [16:00] Tak, I'm suspecting it's a bug in bzr-svn that was fixed earlier but caused issues in the cache [16:09] ok [16:09] yeah, it seems to be working [16:17] jelmer: what was it that needed to happen before bzr-svn supports ignoring files based on that SVN property? [16:18] jelmer: and more immediately useful, do you know of any tools to convert that property into the form used in .bzrignore files? [16:19] SamB: bzr needs to support a generic API for handling ignores rather than relying on the fact that a versioned file named ".bzrignore" exists [16:20] jelmer: oh, that has to be versioned? [16:20] SamB, there's some functions in bzr-svn for handling svn:ignore data, which is used for svn:ignore in working copies [16:20] that sounds kind of sick [16:20] SamB, .bzrignore doesn't have to be versioned atm [16:20] ah good [16:20] that's as it should be, I think [16:20] ... how else is a soul supposed to test changes? [16:22] so ... can bzr-svn access the svn revprops when in a bzr-format working copy for a bzr-format branch? [16:27] SamB, only svn:author, svn:log and svn:date (which are mapped to their bzr equivalents) [16:27] SamB, if you think there's a reason to support others, please file a bug :-) [16:28] I was just hoping to add a command to to generate ignore rules in the form required by ".bzrignore" [16:29] so it would have to get the property from somewhere ... [16:29] SamB, svn:ignore is not a revision property but a file property [16:29] oh, file property [16:30] right [16:30] file properties aren't stored anywhere either (bzr doesn't have "free-form" file properties, only specific ones) [16:30] * SamB doesn't know why he said revprop above [16:32] well, would it be reasonable to write a command that takes an SVN url (perhaps defaulting to bound or parent URL?) and perhaps SVN revision number and outputs .bzrignore rules ? [16:33] * SamB wonders where svn:ignore is documented ... tries googling [16:37] SamB, yeah, that'd be reasonable [16:44] is there a URL for the latest released svnbook ...? [16:49] jelmer: so where is this code dealing with svn:ignore? [16:51] SamB, workingtree.py [16:52] and would I be able to use this even if I don't have an SVN working tree? [16:53] hmm, the main bit seems to be a method on SvnWorkingTree, so I'm thinking "not without refactoring" === thekorn_ is now known as thekorn === thekorn_ is now known as thekorn === weltende is now known as welterde === kartik_rustagi is now known as join === join is now known as kartik_rustagi [18:11] jelmer: how do you test bzr-svn? [18:12] I mean, I don't really want to run all of the bzr self tests for bzr+all-installed-plugins === mario_ is now known as pygi [19:05] hi, how to get a list of changed files since X rev? [19:07] backz, bzr log -v -r X [19:08] beuno: ok, but I need only list of files [19:08] I'm creating a rsync.txt === mario_ is now known as pygi [19:09] backz, not sure if there's a command that will give you that exact output [19:10] ok, no prob, I'll parse log -v output in vim [19:10] thanks! [19:20] ffs, how do you show the branch uri(s) in git? [19:21] Wrong channel? [19:23] it's relevant, because I'm trying to refind the uri for an existing git branch so I can rebranch it with bzr-git :-P [19:24] then the voices will stop shouting === Kissaki^0ff is now known as Kissaki [19:54] just had a cool idea; wondering if there already exists a plugin that does this [19:54] would be nice if i could put in a comment some keyword that would block a checkin with that file [19:55] wouldn't be hard to have a plugin that checked incoming checkin for that keyword and bailed if it was found [19:55] something like # DONT-CHECK-ME-IN \n print($SECRET_VALUE) [20:49] phinze: first note that you have to store secret values in the source tree of your deployment, you need a better configuration system. [20:50] phinze: then, the common way to deal with this use case is with "bzr ignore" [20:50] since involuntary commit is usually a consequence of runnig "bzr add" and not checking the result. [20:50] ddaa: right, i was just using a simple example [20:51] i'm just picturing a sanity-check that allows a dev to, for example, insert debugging code and make sure she doesn't forget about it before commit [20:52] whereas bzr ignore is file-wise [20:53] oh, that's a much better use case :) [20:53] i looked at a few other pre-commit plugins; and it should be pretty simple to whip up. i'll post to the room if/when i do that [20:53] I sometimes put "NOCOMMIT" comments in my code. But what I usually mean is "do not merge that into trunk", not "do not commit that in my development brancH" [20:54] so, I guess it would be useful to have an option that says in essence "bzr commit --with-the-nocommit-crap-too" [20:56] You know, bzr developers have this strange habits of doing multiple commits on development branches before merging on mainline, while other dvcs have crappy log commands that cause this behaviour to be regarded as "commit log pollution" [20:56] So they write strange tools to avoid doing commits, such as hg queues, and they claim they are really cool, while they are half-assed solutions to the wrong problem. [20:57] Oops, sorry, I ranted on hg queues again. [20:57] ddaa: You should try hg queues; they totally solve that problem. They're really cool. [20:58] * ddaa hits fullermd with a large nail-studded stick [20:59] fullermd: don;t take offense. that's ddaa's customary mating ritual. [21:00] mneptok: I do not remember hitting any female with a nail-studded stick at our former common employer's meetings. [21:02] I guess it was against company etiquette, unlike, say, filling a female's belly button with sugar. [21:02] Are you mad? Think of the calories! [21:10] hi [21:10] does bzr have an equivalent to svn export? [21:10] export? [21:11] Tak: i just realized that. the syntax was a little weird to me :) [21:11] moldy: what about 'bzr export'? [21:11] ddaa: yep, thank you [21:12] i got irritated by the fact that it takes the destination as first and the source as second argument [21:12] the common use case is to run this command from within the source [21:13] yep, i happen to have another use case :) [21:41] jelmer: hello [21:42] mwhudson, hey [21:44] jelmer: thinking about using bzr-svn for launchpad again [21:44] horray [21:44] mwhudson, \o/ [21:44] jelmer: have you made any releases subvertpy of bzr-svn since the last time i talked to you about this? [21:45] jelmer: does bzr-svn have anything like the git.db file? [21:46] mwhudson, that depends on what the last time was that we talked about this :-) [21:46] jelmer: it has something in ~/.bazaar/svn-cache, right? not in the repo [21:46] mwhudson, bzr-svn basically has a companion release for every bzr major release [21:46] jelmer: :) [21:46]