[00:06] jelmer: no luck on figuring out my os x issues. i'm going to work on it and when i have it working i'll report back. i gg for now. [00:06] ttyl. [00:07] ok [00:07] bye [00:11] jelmer: I've filed a bug [00:14] lifeless: k [00:14] jelmer: the item_keys_introduced_by function is the current failing thing [00:15] jelmer: I have a working diff panel in bzrk, but I'm not happy with it and I've been too busy to fix it. [00:15] ToyKeeper: ah, ok [00:15] jelmer: If you want it, it's at lp:~toykeeper/bzr-gtk/bzr-vis-enhancements [00:16] ToyKeeper: I'll wait until you're happy with it [00:16] jelmer, lol, I was just about to send the same patch to the list (minus the tortoise bits that sneaked into your patch) [00:17] I probably need to fix some things in DiffWidget. It doesn't like to have its contents changed after it gets displayed. [00:17] hello all [00:17] Also, is there any existing way to save preferences, or should I make something up? [00:19] ToyKeeper: We generally just use the bazaar configuration infrastructure [00:22] mornin' mbp_ (poolie-in-disguise) [00:22] hi mbp_ [00:26] hi Martin [00:26] lifeless: I'm a bit confused about the use of iter_lines_added_or_present_in_keys() [00:27] jelmer: ignore that, look at the top of the frame [00:27] lifeless: would it be valid to just retrieve those keys' contents and yield their lines one by one? [00:27] top-frame [00:27] ahh [00:31] jelmer: :) [00:39] bug 243998 [00:39] Launchpad bug 243998 in bzr "BzrDir.has_workingtree() raises NotLocalUrl" [Undecided,New] https://launchpad.net/bugs/243998 [00:39] jelmer: this is by design; perhaps you could enlarge on why it affects you? [00:48] lifeless: I've got a plugin that registers a post-push hook [00:49] that hook will push a index.html page (with a quick description of how to check out the branch, and its history) if there is no remote working tree === `6og is now known as Birthday_Kaiser [01:01] jelmer: nice; you should catch NotLocalUrl [01:02] lifeless: that's what I'm doing at the moment [01:03] it does seem like something that the API could handle for me though [01:03] since it does have enough data to return a proper value [01:04] jelmer: it sounds like you want 'has_working_tree' or something; thats really a Look-before-you-leap style method though; I'd question its value [01:04] lifeless: that's what we're talking about here though [01:04] this function *is* called has_working_tree() [01:04] it's not open_working_tree() I'm referring to [01:05] hmm [01:05] I think it's perfectly sensible for *open_workingtree()* to raise NotLocalUrl if it's a remote URL [01:12] Hi, I am trying to run a smart server via inetd with this line «4155 stream tcp nowait baco /usr/bin/bzr /usr/bin/bzr serve --inet --directory=/srv/bzr/» and when I do telnet to the port I get «bzr: ERROR: unknown command "--inet"» [01:13] where is the problem? [01:16] lifeless: have you looked at the btrees in the zodb? [01:16] (i sort of doubt they're suitable, but probabyl worth a look) [01:16] mwhudson: I found something that looked like it was that; it uses marshall [01:16] mwhudson: / pickle [01:17] there's a string/string version isn't there? [01:17] mwhudson: and wants to update - its a disk hash table rather than anything else [01:17] yeah, the write-once stuff isn't part of its world [01:18] anyway, just a thought [01:18] * mwhudson wanders off for a bit [01:19] mwhudson: http://pypi.python.org/pypi/zc.dict/1.2.1 is what I looked at [01:19] and http://pypi.python.org/pypi/zope.bforest/1.2 [01:20] ah, i think i was thinking about bforest and had forgotten a lot of details [01:21] there is a ZODB.BTrees apparently [01:21] but I'm having trouble finding it :) [01:22] (in pypi that is) [01:23] also there isn't SSBTree, only I or O [01:24] (as far as I can tell to date) [01:26] * lifeless considers running bzr search over zope, so he can find this damn code [01:27] davidstrauss: how did you go with loggerhead? [01:28] lifeless: haven't tried installing it yet [01:28] lifeless: i'll probably try tomorrow [01:28] lifeless: but thanks for asking [01:28] baco: that's weird, it's like it isn't seeing the 'serve' part of the command line [01:29] davidstrauss: no probs; I think most people run loggerhead from source, but I may be wrong [01:29] spiv: I bet is the inetd server, I am changing it now [01:32] spiv: yeah, I was right, is wried anyways, but do not install inetutils-inetd, openbsd-inetd is the one that works [01:35] mwhudson: yeah, zodb.btrees is not suitable; two reasons - it pickles. and it pickles. [01:35] mwhudson: oh, and it is mutable, and complex. [01:36] * spiv buys lifeless a Pickle-Me-Elmo [01:36] ewww [03:42] * igc lunch [04:08] lifeless: Continuing from -devel, this is the worrying output: [04:12] Conflict adding files to libmokoui. Created directory. [04:12] Conflict because libmokoui is not versioned, but has versioned children. Versioned directory. [04:12] Conflict adding file libmokoui. Moved existing file to libmokoui.moved. [04:12] (libmokoui is a directory, so 'Conflict adding file' is worrysome [04:12] StevenK: you add files to directories [04:13] StevenK: can you create a new branch of the one you were merging into [04:13] StevenK: and then repeat the merge from the one you were merging from [04:13] StevenK: (I want to eliminate the chance of local edits causing issues) [04:15] lifeless: There were no local edits, same behavior from a fresh branch [04:16] StevenK: ok, please file a bug [04:17] StevenK: 'adding files' could be clearer I guess, but something is almost certainly wrong if two well formed branches can't merge in that manner without the error about being unversioned [04:17] lifeless: I suspect the branches haven't seen each other before, but bzr should be able to merge them [04:18] StevenK: if they don't have a common parent it would error [04:19] Can I teach it the common parent? I don't see why it's adding files, either, file lists are the same. [04:19] StevenK: if they have a common parent, then they've seen each other before :). directories added to both sides should (and appear to have) cause a simple conflict - the 'Conflict because libmokoui is not versioned, but has versioned children. Versioned directory.' is what is spurious and seems to have propogated [04:19] StevenK: does it say 'branches have no common parent cannot merge' ? [04:19] StevenK: or words to that effect? [04:19] Branches have no common ancestor, and no merge base revision was specified. [04:19] I suspect I "branched" this using cp [04:20] StevenK: ok. that says bzr thinks these are entirely separate projects. [04:20] StevenK: using 'cp' is fine, unless you then bzr init and add and give everything brand new identity [04:20] I may well have done that, I'm not certain. [04:21] StevenK: so. you know bzr has an inode concept right? files and directories have identity separate from path. [04:21] StevenK: 'bzr add' assigns identity to a file/directory [04:21] StevenK: bzr merge when two files/directories share a path but don't share identity -> conflict [04:23] Hm. Drat. [04:23] StevenK: so, every file that is in common between these two separate projects will conflict. This is appropriate - consider two separate projects with different COPYING contents. [04:23] StevenK: or even the same, but then one changes its mind; we shouldn't consider them to be the same file. [04:24] StevenK: there is a genuine bug here - the 'Conflict because libmokoui is not versioned, but has versioned children. Versioned directory.' error is spurious AFAICT [04:24] StevenK: but you've also, almost certainly, made your life harder by doing 'bzr init' rather than 'bzr branch' at some point in the past. [04:24] Can I fix that? [04:25] StevenK: in some senses yes. Essentially, for every common path you need to pick one file id and choose it. That file id will keep its history, the other will show up as deleted at this point [04:25] StevenK: if there is an upstream/downstream relationship here, you should take the upstreams file ids. [04:28] lifeless: Okay, so how I pick/change the file ids? [04:29] StevenK: bzr st *should* show you foo and foo.moved for every conflicting path [04:29] StevenK: before we go further, can you file a bug with: [04:29] the two branches [04:30] the output of 'bzr version-info' in each branch [04:30] and the output of the merge; I'll clean it up into an actual bug report on the thing I think is going wrong [04:35] lifeless: Submitted, bug 244115 [04:35] Launchpad bug 244115 in bzr "merge between two branches fails" [Undecided,New] https://launchpad.net/bugs/244115 [04:42] StevenK: thanks [04:42] StevenK: so [04:43] StevenK: in your tree right after the merge [04:43] StevenK: if you do 'bzr diff -r branch:THINGYOUMERGEDFROM' [04:43] StevenK: we want to keep adjusting your working tree until that diff looks reasonable [04:43] StevenK: with no delete+add pairs etc [04:43] StevenK: (assuming the branch you merged from is your 'upstream'.) [04:44] StevenK: if you are the upstream, we'll use 'bzr diff' to do this test [04:57] StevenK: ping me when you are back [05:06] lifeless: I'm back [05:07] lifeless: I've adjusted the working tree so that the diff looks good already [05:07] StevenK: right, so does the above make sense? [05:07] StevenK: against -r branch:, or your local branch? [05:07] Local [05:07] StevenK: and which branch has more history ? [05:08] % bzr di -r branch:../trunk | diffstat | tail -n 1 [05:08] 40 files changed, 5141 insertions(+), 4244 deletions(-) [05:08] Ah ha [05:09] lifeless: trunk [05:09] lifeless: The only changes in the ubuntu branch are under debian/ [05:09] StevenK: try bzr st -r branch:../trunk [05:09] (trunk has no debian/) [05:10] lifeless: It has two headings: removed: and added: and both list every file [05:10] StevenK: right, you've resolve in the wrong direction :) [05:11] StevenK: can I ask, as you trying to do 'uupdate via merge' ? [05:12] lifeless: Basically, yes [05:12] StevenK: so, this is why james_w is working on mass conversions and history joining [05:14] StevenK: lets get you unblocked - bzr diff -r x..y ../trunk | bzr patch, is likely better [05:14] x..y being what? [05:15] Revision numbers, of course, but which? [05:16] StevenK: well whatever you passed the merge command to make it do something === retupmoca` is now known as retupmoca [05:17] lifeless: I essentially have that on my local branch as it is [05:26] StevenK: does 'st' show a pending merge ? [05:31] bzr: ERROR: Revision {('vcs-imports@canonical.com-20080410144539-rrh49m2mt78576ft',)} not present in "". [05:31] StevenK: I'd bzr revert and do 'bzr diff -r x..y ../trunk | bzr patch' TBH [05:32] lifeless: I did [05:32] StevenK: merging across separate imports is not easy [05:32] StevenK: if you reverted, then you shouldn't be getting an error [05:32] lifeless: It was a new branch [05:34] StevenK: what was it [05:34] lifeless: Sorry? [05:35] StevenK: I have no idea what you're talking about anymore, read up and imagine you have only what you've told me to work off :) [05:36] lifeless: Okay, so I started with a fresh branch using 'bzr branch', and then ran 'bzr di ... | bzr patch'. 'bzr st -r branch:../trunk' gave that error I pasted above. [05:36] StevenK: ok. [05:36] StevenK: just 'bzr st' [05:36] no -r here, because we're not trying to produce a related branch [05:36] Two files modified [05:36] Which are the two files changed [05:36] StevenK: any pending merges ? [05:37] Nope. [05:37] StevenK: commit and move on :) [05:37] lifeless: But when trunk moves on, I can't just merge, I'll have this pain again? [05:38] StevenK: yes. [05:38] Can I make the pain stop? :-) [05:38] StevenK: yes, build from upstream rather than having an unrelated branch [05:38] 'bzr branch upstream; do stuff' [05:38] beuno: are you here/awake ? [05:44] lifeless: Well, actually, if I could smush the two branches together, it would be ideal. ubuntu for everything under debian/ and trunk for everything else. [05:46] StevenK: so [05:46] StevenK: I described above what you need to do to sync up correctly [05:46] StevenK: but we have to do this on 13K branches, doing it adhoc is really not that useful - james_w will be doing toolchain support for this [05:47] lifeless: I've done bzr branch upstream, I'm just not sure what I can do to get the files from the existing ubuntu branch into the new one while preserving history [05:48] StevenK: bzr merge -r 0..-1 ../ubuntu/debian [05:48] StevenK: you did say that no changes were outside ./debian right ? [05:50] lifeless: Right [05:51] lifeless: -1 == HEAD isn't so intituive, either [05:51] StevenK: -0 is hard to represent [05:52] lifeless: The code can't have a constant set for HEAD? [05:52] probably can :) [05:52] Even if HEAD is a CVS-ism [05:54] Grumble. bzr log doesn't show history [05:56] StevenK: have you committed the merge? [05:57] lifeless: Yes. [05:57] StevenK: then it should [05:58] lifeless: bzr merge .... ; bzr ci -m "" [05:58] StevenK: bzr log --show-ids -r -1 [05:59] StevenK: does it have one or two parents? [06:02] lifeless: It has one parent [06:03] StevenK: so, let me introduce you to 'bzr st' [06:03] its a great way of seeing what a commit will do [06:04] :) [06:04] lifeless: uncommit and then st shows added files, not a pending merge [06:05] StevenK: of course; do a revert [06:05] StevenK: then the merge again and see if st shows a pending merge [06:05] lifeless: No, just added files [06:06] abentley: is there some other way to join separate imports than 'merge -r 0..-1'? its not adding a pending parent for StevenK . [06:07] lifeless: I can't think of one. [06:07] abentley: I am sure it used to, I think this is a merge regression - do you agree? [06:07] lifeless: Also, the only reason it wouldn't add a pending parent is if one had already been set. [06:08] ie the merge had been done in the past. [06:08] abentley: in that case though, merge wouldn't need a -r at all ;) [06:08] abentley: I think its still considering it a cherry pick [06:08] in that case, the merge should be a no-op. [06:09] My code certainly didn't do that. [06:10] abentley: yah, like I say I think its a regression [06:10] I tried a merge -r 0..-1 and it behaved as expected. [06:10] abentley: oh, no I know [06:10] abentley: I know whats going on and why :) [06:10] Was a file specified in the merge? [06:11] StevenK: ok, heres what to do [06:11] abentley: yes [06:11] StevenK: revert / uncommit etc until you have whats in trunk [06:11] StevenK: then: [06:11] bzr merge -r 0..-1 ../ubuntu; bzr revert . ; bzr merge -r 0..-1 ../ubuntu/debian; bzr st [06:13] lifeless: There is "join", of course. That's less general than you asked about. [06:13] Okay, bzr st now shows a pending merge, but there was a bunch of errors from the other 3 commands. [06:13] StevenK: thats ok [06:13] lifeless: also the merge-into plugin. [06:13] And that's impressively counter-initutive :-) [06:13] StevenK: it should ahve your ubuntu files etc; and you can just commit now [06:14] abentley: yes, doing join and deleting and rearranging is probably the preferred ui [06:14] I wonder if I can remove the 'submit' branch shown in bzr info [06:14] StevenK: like I say, you're doing something that there is not much toolchain support for yet, and you can only do because you have the special case of no overlapping files [06:15] Ah. We're trying to outsmart bzr a little too, I suspect? [06:17] * StevenK blinks. The merge works, but debian/ doesn't exist? [06:18] StevenK: its not listed in 'bzr st' ? [06:18] bzr st doesn't show anything. I've commited. [06:18] StevenK: log -v -r -1 ? [06:19] It shows the merge, and it that it added every file [06:19] s/and it/and/ [06:21] StevenK: 'every file'? [06:22] lifeless: Well, added every file, such as AUTHORS, NEWS, README, etc [06:22] lifeless: I can pastebin the output, if you wish? [06:23] StevenK: sure [06:24] lifeless: http://paste.ubuntu.com/23876/ [06:25] StevenK: looks fine to me [06:25] StevenK: lines 16 through 18 [06:25] StevenK: etc [06:25] StevenK: what about 'bzr st -r -2..-1' ? [06:26] lifeless: No output [06:27] StevenK: ok, I think the last merge didn't quite do what we wanted [06:27] StevenK: uncommit :) [06:27] StevenK: repeat the 15:11 < lifeless> bzr merge -r 0..-1 ../ubuntu; bzr revert . ; bzr merge -r 0..-1 ../ubuntu/debian; bzr st [06:27] step [06:27] and make sure debian is present and everything ok before you commit [06:27] lifeless: bzr st still shows a pending merge [06:27] revert too [06:27] lifeless: Or revert and redo? [06:28] Done. And: [06:28] ls: cannot access debian: No such file or directory [06:29] uhm [06:29] bzr st [06:29] does it list debian etc? [06:29] It just shows a pending merge [06:29] % bzr st [06:29] pending merges: [06:29] Steve Kowalik 2008-04-19 Add missing X[BS]-Python-Version fields. [06:29] ... [06:29] bzr merge -r 0..-1 ../ubuntu/debian --force ; bzr st [06:30] bzr: ERROR: Revision {('',)} not present in "". [06:30] argh [06:30] bzr revert [06:30] Okay [06:30] bzr branch ../ubuntu ./tempdir [06:30] bzr join tempdir [06:30] bzr mv tempdir/debian debian [06:31] bzr rm --remove tempdir [06:31] bzr st [06:32] bzr: ERROR: Can't join trees because KnitPackRepository('file:///home/steven/canonical/moko/libmokoui2/ubuntu/.bzr/repository/') doesn't support rich root data. [06:32] You can use bzr upgrade on the repository. [06:32] ugh [06:33] StevenK: that Revision {('',)} not present in "" is a bug [06:33] StevenK: what version of bzr do you have? [06:33] Woo, another one [06:33] lifeless: 1.4 [06:33] StevenK: try 1.5 [06:33] bzr merge -r 0..-1 ../ubuntu; bzr revert . ; bzr merge -r 0..-1 ../ubuntu/debian --force ; bzr st [06:34] Try that with 1.5? [06:34] yes [06:35] * StevenK digs for the bzr PPA [06:42] lifeless: 1.5 still gives bzr: ERROR: Revision {('',)} not present in "". [06:45] StevenK: ok, file a bug I guess [06:45] or try 1.3 [06:51] lifeless: 1.3.1 gives the same error [06:54] bleep [06:54] bugger a file for sure [07:09] lifeless: Not sure what the bug is. :-) [07:09] getting that error [07:18] "My husband comes from a family where the men are always in charge. He was very nice to me when we were dating and after we got married he changed like he thinks he is my master. I feel like a slave sometimes and if I don't do what I am supposed to he yells and curses at me and he even spanks me. He doesnt usually hit me too bad but I am thinking that if we have a baby maybe he would be nicer with a child in the house. What do you peo [07:18] ple think I should do." [07:18] lol, stupid women [07:23] Suigintou: thats really not on topic for this channel [07:23] Suigintou: not to mention being offensive [08:04] mbp_: I have some initial figures on the B+Tree index approach [08:05] mbp_: looks like 2 IO's for up to 250K keys [08:05] mbp_: and 3 for up to 125M keys [08:07] wrong channel, in fact, wrong network altogether, really sorry [08:59] * igc dinner [10:15] hi, how is bzr with handling (bigger) binary files, e.g. movies [10:17] i tried to add (by mistake) some rendered files (*.ac3, +.m2v, *.mpg) where *.mpg is ~220MB and darcs was on knees using 1GB of memory + 1GB of swap :-/ [10:18] it's my old video-project and i'll definitely migrate it from darcs [10:18] gour, yeah, not so good. It uses about 3x the amount of memory of the file's size [10:18] if you hace enough ram, you can pull it off, but, in general, it's probably not the best idea [10:18] bzr? [10:18] yeah, bzr [10:19] gour: its improvable [10:19] gour: and sounds like better than darcs :) [10:19] hmm, 3x is till better than 2GBs for ~220MB file [10:19] *still [10:19] hopefully, it does not try to keep them all at once in memory [10:20] lifeless: good. let me burn & print DVD first, then i'll check how bzr does [10:20] lifeless, what's improvable? [10:20] during that attempt my machine become totally non-responsible :-/ [10:21] beuno: memory use [10:22] lifeless, the estimate is still 3x the file's size though, right? [10:22] it's not very common use, but when doing video-editing it might be useful to be able to store files [10:22] beuno: we can do better [10:22] beuno: we don't today, but we can [10:26] lifeless, right, that reminds me of some bug where the user asked if we could warn them before adding a file that would probably run out of memory while committing. Is that too difficult to do today? [10:26] beuno: its tricky [10:26] beuno: some people have 8GB RAM [10:27] beuno: some ave 8GB VM and 2GB ram [10:27] beuno: at what point is 'out of memory' is it thrashing? is it hitting swap? etc [10:27] using a non refcounting python would help too [10:27] hm, yeah, may be worth working on the actual problem then [10:28] * gour has 1GB only :-( [10:29] gour, well, 1GB should be enough for 220mb files [10:30] darcs used 1GB + 1GB swap to add 15M + 180M + 222M [10:30] and machine was down [10:30] * gour --> copy-shop to print DVD cover. bbl === gour is now known as gour|afk === gour|afk is now known as gour [11:37] gour: For large files like that, you might find rsnapshot more appropriate... at least, if you just want to be able to retrieve old versions. [11:38] Or, perhaps rdiff-backup, if you make small changes to big files (like changing the ID3 tag in a mp3)... could be more space-efficient. [11:41] ToyKeeper: well, when i work with cinelerra i keep its project (xml) files and some graphic files under vcs, so it was mistake to add those rendered files and interesting (darcs) result. now, when i finish with burning, i'll check how will bzr react [12:39] ERROR: Repository KnitPackRepository('file:///home/mkanat/projects/mw/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://control.trusthosting.net/var/www/html/everythingsolved.com/bzr/mingleware/.bzr/) ? [12:44] Is that telling me that I can't use bzr+ssh with a rich-root-pack repo?? [12:44] mkanat: its telling you that one of repositories is rich root and one isn't [12:45] mkanat: really shoukld make the error clearer [12:45] lifeless: Hmm, I thought I made them both rich-root. [12:45] lifeless: They're both rich-root-pack, I just checked. [12:47] lifeless: At least, that's what .bzr/repository/format says. [12:51] What's the difference between .bzr/branch-format and .bzr/branch/format ? [12:54] Hmm, guess I need a newer bzr on the server side, that's my guess. [12:58] mkanat: possibly; what version is it? [12:58] It's 1.3 on the server, 1.5 on the client. [12:58] .bzr/branch-format is the control dir format [12:58] Ah, okay. [13:00] (before 0.8 we didn't have split out repository/branch/checkout objects) [13:00] so its named whackily, but backwards compatible [13:00] Ahh. :-) [13:00] Hmm, upgrading the server didn't help. [13:01] sftp checkout works fine, bzr+ssh doesn't. [13:02] mkanat: file a bug please [13:02] lifeless: Okay, will do. [13:03] Ah, it's already filed as bug 205579. [13:03] Launchpad bug 205579 in bzr "bzr checkout doesn't work with rich-root-pack" [High,Confirmed] https://launchpad.net/bugs/205579 [13:04] mkanat: you sure its the same? [13:05] lifeless: Yep, identical problem. [13:56] I dunno if there are any other Xcoders in here but if there are then this may interest you: http://www.mcubedsw.com/blog/index.php?/site/comments/build_numbers_from_bazaar/ [14:24] Pilky, nice [14:29] after a branch merge, do you just delete the branch? [14:31] Tsmith, a little more information may be needed to answer that question :) [14:31] you where working in a branch separate from the mainline [14:31] and you merged that into, let's say trunk? === Birthday_Kaiser is now known as Kamping_Kaiser [15:22] abentley: hi! I wrote several posts on support issue 00002413 [15:22] guilhembi: Hi there. I saw them. [15:22] abentley: even the latest one? [15:23] "I missed your comment?" [15:23] I did see that. [15:24] abentley: ok, thanks [15:24] Right now, I'm looking into this tests directory conflict. [15:24] abentley: uber-great! [15:24] abentley: mysterious how mysys/tests/Makefile.am wasn't imported... [15:25] If mysys/tests *was* deleted, possibly Makefile.am was deleted at the same time. But I can't say whether that happened yet. [15:28] abentley: and I don't know either if it was deleted. Looking for creation history when the file exists, is easy, but for deletion history when it's missing, is not, and it's not specific to bzr. [15:28] Yeah. I can do it, it'll just take a bit. [15:30] abentley: after doing some grep somewhere, it looks like it was never deleted and never existed in 6.0-ndb [15:33] So far, I've determined that the file was created in mysql-5.1-telco-6.2-merge revno 2555.13.2 [15:38] abentley: is that the same as sp1r-mtaylor@solace.(none)-20080425063223-04764 ? [15:38] guilhembi: Yes. === mw|out is now known as mw === guilhembi is now known as guilhembi|bbl [15:43] guilhembi: So it looks like my results match yours; 'tomas.ulin@sun.com-20080619094326-n15bh5klhd3yt83j' is not a descendant of 'sp1r-mtaylor@solace.(none)-20080425063223-04764' === guilhembi|bbl is now known as guilhembi [15:43] abentley: uh, did I say that... [15:44] Therefore the first didn't delete the directory created by the second. [15:45] It doesn't have the directory because it never had the opportunity to get it. [15:45] that I agree === lamont` is now known as lamont [15:46] So now I have to find out why bzr thought it did. === guilhembi is now known as guilhembi|bbl === prateeksaxena is now known as prtk === prtk is now known as prk === prk is now known as prtk [16:43] heh, finally i found time to test how bzr handles binary files...i tried to add the same 3 binaries which put darcs on the knees (15M, 180M and 222M) and bzr handled them OK [16:44] sure, there is room for improvement for the memory usage, but it was workable, while with darcs my machine almost stopped responding using all of 1GB RAM as well as 1GB of swap [17:19] so I'm doing a "push" to a remote (windows) filesystem. [17:19] slooow. :p [17:19] (The connection is just slow & laggy) [17:20] I imagine a pull would go much more quickly... but I'm not sure if I have rights to install bzr on that end. >.< === thekorn_ is now known as thekorn [17:37] can I "clean out" a shared repo? can I get rid of the revision stored there that no longer have branches? [17:39] bpeterson: I believe there is a plugin for it (bzr-remove-revisions), but there isn't a core garbage collection command [17:40] what does bzr pack do? [17:40] bpeterson: combines small packs into larger ones [17:40] oh [17:40] thanks [17:42] are there plans to add some garbage collection type thing? === guilhembi|bbl is now known as guilhembi [18:35] abentley: ping, a question on the _merge_names logic [18:36]