[00:02] well an idea for core dev... dmg installer for Mac OS X 10.4 [00:02] spiv: ping; can we chat? if you're not deep in the flow; I have a proposal for 'what revisions I need to push detection' [00:03] keithy_: I'll mail the list for you if you like [00:03] keithy_: the dmg is done by community members :) [00:03] k [00:05] I'v been waiting for python to finish building for ages, does it take long? [00:05] that's the stupid problem with macports [00:05] It compiles EVERYTHING [00:06] it might as well compile an alternate kernel too for pete's sake [00:06] I don't use it. [00:06] ./configure && make are easy to use. [00:06] I think I have python on this mc 4 times now [00:07] what would it take to get easy_install on your mac ? [00:07] skip macports [00:08] if you have easy_install then it's just one line [00:08] to get the latest bzr [00:08] sudo easy_install -U paramiko pycrypto bzr [00:08] OS X comes with Python - you shouldn't have to be compiling Python. [00:09] http://peak.telecommunity.com/DevCenter/EasyInstall [00:11] OS X's python is crippled pretty hard last time (10.3 days) I looked. [00:11] lifeless: is there a dmg yet? I thought there were people still working on it [00:11] maybe we should add easy_install instructions to the Download page [00:18] igc: easy_install doesn't provide a patched python-subversion [00:19] someone could make an easy_installable python-subversion, though, probably. [00:20] that would be nice [00:20] Error: The following dependencies failed to build: py25-paramiko py25-zlib [00:21] there have been quite a few people here trying to patch and build it [00:23] that reminds me, I need to get that memory leak fix into hardy... [00:23] because of the way the memory pool stuff works in apr, it's also a major performance improvement [00:29] so macports is hosed [00:29] I cant even find a skip option [00:29] Yeah I stopped using fink and macports years ago [00:29] same reason I stopped using gentoo [00:30] you are guaranteed to get pissed one day when the whole build system breaks down when you need it. [00:30] yeah I use knoppix for linux because I detest these installation issues [00:30] has everything preinstalled [00:30] debian and debian variants - accept no substitutes [00:30] but I cant beleive I have found a mac os x programme that is offering me no options [00:33] have you tried easy_install (or are you more inclined to the not_easy_install_hair_pulling method) ? [00:33] http://peak.telecommunity.com/DevCenter/setuptools#installing-setuptools [00:34] er better http://peak.telecommunity.com/DevCenter/EasyInstall#installation-instructions [00:35] try this [00:35] cd /tmp ; curl -O http://peak.telecommunity.com/dist/ez_setup.py ; python ./ez_setup.py [00:36] sheesh I am not even a python person :/ Help me out guys. [00:38] jelmer: I thought there was a 10.5 one [00:38] There is but you don't need it [00:38] easy_install -U does the same thing [00:38] It just looks prettier [00:38] and has docs [00:38] lifeless: Ah, it just doesn't include the python-subversion stuff then yet [00:39] (It = dmg) [00:39] I am updating the python-subversion instructions again on the wiki in the next 30 min [00:39] (for OS X) [00:39] It's better than my yesterday edit. [00:48] abentley: ping [00:49] lol I finally got time to install subversion (trunk) 1.5 and now it says svn: Unrecognized URL scheme for 'http://macromates.com/svn/Bundles/trunk' [00:49] abentley: I am looking at adding a 'current_search' parameter to get_parent_map; this will allow get_parent_map on the smart server to avoid sending duplicate data back [00:49] wtf? [00:51] svn+ssh works but it's not recognizing the http [00:51] grr [00:52] error: Download error for http://www.lag.net/paramiko/download/paramiko-1.7.1.zip: (61, 'Connection refused') [00:53] I give up [00:53] keithy_: you only need paramiko for sftp [00:53] keithy_: to just use bzr; if you have *a* python (2.4 or newer) just do this: [00:53] - grab the bzr tarball [00:53] - untar it [00:53] - add that directory to your path [00:53] * DONE * [01:08] it worked! [01:11] what is main feature of bzr-1.1? [01:11] version control [01:11] * dysinger ducks [01:11] erm .. it doesnt install on Mac os x 10.4 [01:11] ;-) [01:19] max os X is awkward [01:20] its really geared for binary installs, but the vast chunk of unix programmes are not supplied as binaries by apple [01:24] spiv: the eagle has landed [01:24] lifeless: sweet [01:25] hsn - ditto. It'd be nice to see the web-page announce 1.1 in the news and give some hint as to what is new (even if it's just "here's a faster, more stable bzr"). [01:27] there is a changelog I thought [01:27] Talden: http://bazaar-vcs.org/ [01:28] Talden: says "The main changes in this release are: improved diff, merge, annotate and reconfigure commands; more efficient ordering inside pack repositories; better http authentication, and various other bugs fixed. (full changelog) [01:28] " [01:28] Talden: and links to the full changelog. [01:35] lifeless: but the "News" section doesn't say anything [01:35] foom: see martins post about website maintenance [01:36] * igc lunch [01:47] Hmm [01:47] the improved Inventory.repr() is nice, but it causes very large backtraces in some cases [01:48] I just got a single-line 700k error from bzr [02:37] jelmer: grats [02:38] lifeless: hi [02:38] lifeless, grats? [02:38] on 700K bt [02:38] bt? [02:39] (backtrace) [02:39] lifeless: ah, congrats? [02:39] jelmer: yes [02:41] you had me wondering there for a moment why that word wasn't in my 500-page en<->nl dictionary ;-) [02:45] WoW slang [02:47] well, with so many Australian bzr developers, I'm glad the main language isn't strine :-P [02:47] does bzr not have an en_AU translation yet? [02:49] There is no localization yet [02:50] and both english and american spelling appear to be used [02:50] bob2: so what's different in en_AU from en_UK? [02:51] jelmer: very few things. [02:55] I can't seem to find any difference in the .mo files [02:56] it seems that plugin email works only on client side, when I commit any code to server but email is not sent on server [02:56] anybody has idea? [02:56] * jelmer suddenly realizes he's up at 4 AM searching for differences between Australian and British language files for evolution and decides to get some sleep [02:56] ntnhan: It doesn't send email from the server side [02:57] jelmer: yes, that's what I don't want :( [02:58] ntnhan, is the server running the bzr smart server? [02:59] beuno: no, it's just bzr installed [03:00] ntnhan, I'm not sure how you can make the server send off emails if it's not actually running bzr when you commit [03:02] (smart server would solve it in that case, as you can hook into it) [03:02] bueno: how do we configure bzr running on server each time client commits? [03:02] ntnhan, using the smart server :D [03:02] bueno: haha, thx, I didn't know it :), will give a try now [03:03] ntnhan, then you can just hook into bzr, maybe even the current plugin will send off emails. jelmer? [03:04] I don't think the smart server can send emails when a revision is pushed to it [03:04] but it's been a while since I've looked at it [03:04] it being bzr-email [03:04] lifeless is the bzr-email maintainer so he's probably in a better position to comment [03:05] ntnhan, maybe take a peek at http://bazaar-vcs.org/SmartServer/RemoteObjectHacking [03:05] and of course, lifeless would be *the* man :D [03:05] beuno: ok, i'll try it [03:06] ntnhan: hi [03:06] lifeless: hi [03:06] ntnhan: the bzr-email plugin fires on Branch.post_commit which is not currently invoked in the server process; as discussed above you will have to bzr using bzr:// (or bzr+ssh etc) for it to work /in principal/ [03:06] but we have to make it work in fact too:) [03:07] there is a cron based solution folk have created which sends an email when a new commit is detected on the branch and works with any transport (rysnc, bzr, sftp, etc) [03:07] there has to be someway to do it, Launchpad does it :p [03:07] beuno: launchpad uses the cron based solution [03:08] beuno: not the exact same code but that logic path [03:08] seems fairly trivial, just scan through the dir, save the last revid sent by email, and fire off [03:09] (of course, almost anything seems trivial in irc :P) === jamesh_ is now known as jamesh [03:09] beuno: well code exists; kthxbye :) [03:09] beuno: yes, but everybody wants to save time, need a ready cake [03:10] :) [03:10] ntnhan, that's how plugins get started :D [03:10] (or specs pushed into the trunk) [03:10] file a bug [03:10] requesting it [03:11] the "let's get the aount of open bugs" fever in the upcoming sprint should take care of the rest! [03:11] s/aount/amount [03:23] jelmer sorry to bother you again. So I have subversion 1.5 trunk all compiled into /usr/local with neon and all is good. I can do all the subversion functions with it - it works. Then I try to use bzr 1.1 w/ bzr-svn stable and get bzr: ERROR: Not a branch: "https://.... for every single svn url I try. [03:23] This worked fine in subversion 1.4.6 [03:24] dysinger: Try 'svn+https://...'. [03:24] * Odd_Bloke can't remember if that works or not. [03:24] yeah not working either [03:24] already tried that [03:25] Well, jelmer will probably save the day. [03:25] He normally does. :p [03:25] I am trying to get closer and closer to his setup [03:25] svn+https blows up with a stack trace [03:25] dysinger: Do you have libneon built with SSL support? [03:26] regular https:// is acting like it's looking at as a bzr branch [03:26] dysinger: its jelmer's 4am :- I think you'll get little now :) [03:26] hah! [03:26] have you looked in ~/.bzr.log ? [03:26] He's up! [03:26] ah ok two good suggestions. [03:26] I wager its not loading the plugin [03:26] 1st svn ls https:// works and yes svn --version shows https [03:27] let me look at the log [03:27] dysinger: the svn executable from the location you just installed to and with the same DYLD_LIBRARY_PATH set? [03:27] FAQ! [03:27] one sec maybe my bad [03:29] I managed to install it in /usr/local/bin but svn --version reports 1.4.4 (version that comes with mac). ??? [03:29] This is kicking my ass. [03:30] I am setting DYLD and PYTHONPATH too [03:30] PATH has /usr/local first [03:31] ok I have more work to do [03:31] my neon didn't install right. [03:31] * dysinger goes back to the salt mines [03:33] spiv: how do you get remote server backtraces ? [03:47] hello, i've read a little bit about the differences between bundles and regular patches, but i'm not sure i fully understand. can anyone explain the advantages of a bundle vs. pushing up a regular patch (or set of patches) as a revision? [03:48] bundles and pushing revisions are roughly equivalent [03:48] think of it as a transport change [03:48] transport change? [03:49] however 'regular patches' means GNU patch output, which does not include: commit messages, mode changes, renames, deletes-as-deletes [03:49] j1mc, basically, bundles have bzr metadata about the commit(s), and a regular patch just has the diff for the changes to the code [03:50] spiv: ping [03:50] lifeless: deletes-as-deletes? [03:50] beuno: thanks. (and thanks to you, too, lifeless). what kind of bzr metadata might be included in the bundle? [03:51] minghua: 'foo is deleted' is different to 'foo has a patch that removes ' [03:52] ah, ok. [03:53] minghua: its particularly different in terms of the conflicts you can give the user; and also how do you represent 'trunc() this file' if a delete is shown as deleting all the contents ;)). [03:56] lifeless: Ah, I see. Thanks. [04:04] moin === Verterok-laptop is now known as Verterok [04:05] lifeless: http://rafb.net/p/JoRYz534.html [04:06] spiv: bb:approve [04:06] poolie, lifeless: I have a dmg for OS X 10.4 ready for a ride :) [04:06] Verterok, yay [04:06] lifeless: ta [04:06] Verterok, can you upload it to launchpad? [04:06] btw i spoke to them about the size limit [04:06] it's ppc only [04:06] Verterok: sweet [04:06] is 60MB ok? [04:06] keithy_: ^ [04:07] poolie: 6MB [04:08] there might be something wrong 6MB vs 60MB [04:09] this dmg only contains bzr+pycrypto+paramiko [04:10] aha, all the plugins missing :P [04:11] I'm going to add Rebase and bzrtools to it, but I don't have QT installed in OS X so no Qbzr :( === bigdo1 is now known as bogdog === bogdog is now known as bigdo1 [04:26] poolie: I misunderstood the question about the size (is too late here :P) === mw is now known as mw|out [04:40] Verterok: l) [04:46] I have a dmg with bzr(pycrypto+paramiko) + bzrtools + bzr-rebase :) [04:46] care to add bzr-email [04:47] ok [04:48] lifeless: trunk? [04:49] yup [04:51] trunk has not been published yet [04:52] http://bazaar.launchpad.net/~bzr/bzr-email/trunk/ [04:52] dunno what you mean by not published yet [04:52] is what launchpad say :) [04:53] https://code.launchpad.net/~lifeless/bzr-email/trunk [04:53] url ? [04:53] ~bzr [04:53] not ~lifeless [04:53] ok, sorry [04:54] thumper: https://code.edge.launchpad.net/~bzr/bzr-email/trunk <- [04:55] thumper: I didn't get any notification about that merge request [04:55] thumper: so I didn't know it exists [05:03] poolie: I'm going to upload it to: https://launchpad.net/bzr/1.1/1.1 it's ok? [05:04] yes, thanks [05:09] spiv: down to 100 seconds in get_parents_map calls [05:22] spiv: thats down from 237 [05:23] lifeless: very nice [05:23] lifeless: that's for branching bzr.dev from London? [05:26] yeah [05:26] 115 seconds on my current test [05:26] I'm done for the day; [05:26] I'll commit and push [05:27] if you re interested [05:27] http://people.ubuntu.com/~robertc/baz2.0/search-results [05:27] rev 3198 pushing now [05:29] 15 seconds from startup to starting the stream in my 'last 100' test [05:29] thats another 100% saving over my report earlier in the week [05:30] your patch when it lands will help debug [05:30] it seems to be falling into a 'one at a time' pathological mode [05:31] it should be walking minimum-depth-at-a-time, and it may be that there are places where the search collapses; but I don't expect that. [05:31] lifeless, have a tolerable trip :) [05:31] so this needs some good analysis and reporting to figure out what is going wrong; the hg recursive approach may be something to reintroduce [05:31] I don't anticipategetting any hacking on this branch done next week [05:32] but I'm quite happy with where it is getting to :) [05:33] thats poolie [05:34] poolie: oh you might like to mail me anything you want (other than the baz package stuff) for discussion with the distro. [05:34] ciao. [05:37] lifeless: yeah, damn eh [05:37] lifeless: a bug report would be good :-) [05:46] is it possible to modify the commit message for a revision? [05:46] Manfre, uncommit then commit again [05:47] is there anyway to modify a revision that is not the head? [06:10] lifeless: The idea sounds fine. I've never considered anything below Graph to be a stable interface. It's Graphs that repos are required to provide. [06:10] Whatever way is most efficient for them. [06:40] New bug: #183948 in bzr "can't PUSH over an sshfs fuse file share" [Undecided,New] https://launchpad.net/bugs/183948 [06:41] * spiv goes for a swim [06:51] abentley: man, when do you sleep? [07:20] * Verterok leaves, only two hours for sleep. seeya! [07:21] f [07:39] how long as 1.1 been out? === brilliantnu1 is now known as brilliantnut [08:02] AnMaster: a few days [08:10] ok [08:10] poolie: ping [08:17] AnMaster: "Bazaar 1.1 was released on the 15th of January, 2008." <---- Very first sentence on http://bazaar-vcs.org/ [08:21] right === brilliantnu1 is now known as brilliantnut [09:17] jelmer: because I see python packages b-depending on python-all-dev *everywhere*, and it's not needed at all [09:28] jelmer: omg, I don't know if you saw my question yesterday about making the svn cp from bzr-svn itself, but I tried it and it works... [09:28] jelmer: so my bug has much less priority now, thanks to bzr-svn rocking ;) [10:34] hi, how does bzr merge handle a move or delete on one branch and an edit on the other (since they were branched)? === asak_ is now known as asak [10:42] aha... just found the docs... looks like this case is handled [10:45] is there an easy way (short hand) to export a series of commits as one-patch-per-commit? === Gwaihir_ is now known as Gwaihir [11:09] hey all, is there a way to remove binary files including their history from a bzr archive? [11:09] s/archive/branch/ [11:10] I found that tracking jsmath-fonts is a big pain in the ass, with all its 20 000 odd files [11:11] maybe I can check out before their inclusion, and apply all the patches that happened after their inclusion [11:11] asak_: diff -r x..+1 in a loop perhaps ? [11:12] hrm, bugger, those files were there since revision 1 [11:20] * dato hands lifeless diff -c ;) [11:32] did an experiment now, and seems like you can remove all traces of a binary file from a branch by doing 'bzr remove'. Why is that even possible? Shouldn't you be able to revert to any point in history? [11:33] stefanv: no, remove does not remove all traces [11:34] dato: hrm, interesting: because I had 88Mb's worth of binary files, and now the repo in total is only 18Mb [11:37] ... _is_ there a way to purge all evidence of something from a branch history & repo? [11:38] I mean, in purist terms you'd never need to, but there are pragmatic reasons (material committed illegally, security sensitive or privacy sensitive information at risk of being divulged, etc) [11:38] AfC: well, I just made sure: when I remove those binary files, and do 'bzr uncommit', they don't come back [11:38] so it definately permanently erases them [11:39] Assumint the [11:39] revision hasn't leaked anywhere... but the revision itself it's still in the repository. I think you could fetch it if you knew it's revid [11:40] yes, if you knew which binary files to bring back (i.e. you still have the filename information) [11:40] AFAIK in an SVN repository, the binary data itself is also stored [11:40] hence my original question :) [11:41] no, you can't remove anything from the repository permanently without rewriting it completely [11:42] AfC: I would very much like to know the answer to your question above, as well. sometimes, copyrighted code is checked into open source repos, which causes problems. === cfbolz_ is now known as cfbolz [11:42] I guess the size difference is because you count the working tree size [11:42] luks: you cannot bring back those binary files, they are gone. [11:42] you can [11:42] bzr remove doesn't actually remove them from the history [11:42] well, since my repo is now only 3.3Mb large, I'd like to know where it stores those 88Mb worth of files :) [11:43] luks: no, sure, they *filename* info is still there... but the actual bytes are gone [11:43] nope [11:43] so, 88Mb in 3.3Mb, eh? [11:43] if you just did bzr remove and bzr commit, all the bytes are still there [11:44] the only thing I could imagine is that you haven't committed 'bzr add' of those files [11:44] sounds like it [11:44] they *were* tracked: [11:45] === removed file 'sanum/static/javascript/jsMath/fonts/cmbx10/plain/85/char73.png' [11:45] let me just recheck the original repo [11:45] bzr cat -r REVISION_IN_WHICH_THE_FILE_WAS_ADDED sanum/static/javascript/jsMath/fonts/cmbx10/plain/85/char73.png [11:46] ok, so it's head-in-the-sand time then? [11:47] hrm, but wait [11:47] if I do bzr log sanum/static/.... I should see something [11:48] yeap, I don't think those files were tracked. why don't they show up in bzr status then? [11:49] ok, erase my previous 4 sentences [11:49] the files *was* tracked from revision 1 [11:49] the bzr cat -r 1 command shows its contents [11:50] which explains why bzr status doesn't explain it [11:50] s/explain/show/ [11:50] luks: are you sure the bzr behaviour you describe above is correct? [11:51] yes [11:52] you can never ever permanently remove anything from the repository [11:52] it would break integrity of the repository [11:52] something very strange going on. I can confirm the behaviour you describe with a new repo, but not with my other one. [11:52] the only way to remove them would be to "rewrite" the repository without those file [11:55] luks: ok, figured out what was going on [11:55] luks: the binary files are indeed tracked [11:56] luks: but they are *much* smaller when they aren't physically written to disk [11:56] 'physically written to disk' means in the working tree? [11:56] luks: about 20000 odd files, each taking up a minimum space determined by the file-system configuration [11:56] luks: yes, so if they are all stored in one big file, they are much much smaller [11:57] 88MB vs. 3MB still seems too big difference [11:57] 20000 files at 4k blog size would be 78mb [11:58] well, the files are tiny, and an inode needs a min of 4 or 8K right? === asac_ is now known as asac [11:58] 20000 ~150 byte files make 3mb [11:58] hm, makes sense [11:58] so, it's possible [11:59] my apologies for not believing that bzr could compress 90Mb into 3Mb :) [11:59] :) [12:00] now, I also know better than to try and rsync that repo [12:19] When I try to bzr push, I get an error about how the branches have diverged. bzr merge then pulls these new changes. There are no conflicts (the changes don't effect the same files). What do I do after I've done that merge to allow me to push? [12:20] commit [12:20] every merge needs a commit [12:20] Ah, so I commit the differences from somebody else's branch to my one? [12:20] * rjek sees. Ta. [12:20] yes [12:20] As a convention, what do people tend to use as their commit messages for such merges? [12:21] I usually use "Merge " or "Merge " [12:21] Right. [12:21] but some people prefer more descriptive messages [12:21] That seems fine. [12:22] * Ng would be very happy if a post-merge commit that hadn't changed anything other than the merge would do that automagically, I never have anything to add to the logs from the merged branch :) [12:23] Ng: auto-merge is not always right [12:23] even if there are no textual conflicts, you can't be sure the merge is right [12:23] luks: indeed. I only use bzr in very small and simple ways, so I appreciate that me wanting it to be easier isn't suitable for all ;) [12:25] :) [12:34] lifeless: thanks ... didn't know about the +1 notation ;) [12:34] guessing a patch-filename from comment would be nice to have automated though [12:37] asac: I don't think that notation exists. you want diff -c [12:42] dato: ok ... -c is even better :) [12:43] btw, the foreach (ezbzr) branch isn't hosted at the place named on BzrPlugins page anymore. maybe remove it or contact the author. [12:45] naybe the bazaar-cvs.org page should start to auto-mirror branches of plugins where license permits it? [13:00] thumper: Evidently, I slept just then. [13:00] and I'm just about to [13:16] (Geez, Thumper, when do you sleep?) [13:17] Sleep? I heard of that once, I think... [13:17] * fullermd checks google. [13:18] I find merge commits the perfect place for NEWS-style descriptions. At the least, I use those commits alone to generate the release announcement. [13:18] I also put ticket numbers in the commits for merges. [13:19] and describe the change in high-level [13:19] that works fine if you have a mainline and only merge feature branches [13:20] but it's not that useful when you randomly sync with a few developers [13:20] yeah. why would I do that random thing when I could do an organized thing? :) [13:20] dunno, the "decentralized" thing :) [13:21] my development is perfectly distributed. [13:21] * radix goes to get breakfast [13:21] that doesn't mean decentralized === mrevell is now known as mrevell-luncheon === mw|out is now known as mw [13:36] jelmer: I don't plan to ever work on trac-bzr again. [13:36] abentley: oh, ok [13:38] abentley: I didn't follow the rest of the thread -- is trac-bzr maintained at all? [13:38] stefanv: I have the impression that other people have been working on it. [13:40] abentley: that's good news -- many projects simply won't switch if there isn't a supported trac backend available [13:42] Oh my. `meld` is amazing. [13:42] I wonder if we can find a way to feed it from bzr-gtk [13:43] * luks never really got any of those gui merge programs [13:44] I'm guilty of still merging with emacs [13:45] AfC: We've been discussing that, but the main problem at the moment is that there's no sane API that allows you to use it yet [13:47] jelmer: fair enough [13:47] Of course, we could just fix meld but nobody has done that yet... [13:47] jelmer: (I just had a conflict and so for the heck of it tried [13:48] `meld DemoWindowRunner.java.OTHER DemoWindowRunner.java.THIS` [13:48] and it was glorious) [13:48] yeah, it works and looks quite well [13:48] luks: I haven't tried it as a merging program, but to show the diff it was really slick [13:49] AfC: I don't think you need to even specify filenames, it can figure out bzr conflicts itself [13:50] speaking of meld, I'd love to use it with bzr but bzr diff doesn't have a --diff-cmd parameter [13:51] (just for the diff viewing, of course. the merging would obviously require more work) [13:52] Whoa. So for merging / conflict resolution you just click on the arrows... [13:52] radix: not sure if it works with meld, but there is `bzr diff --using` [13:53] if meld takes file1 file2 as arguments then --using will work. [13:53] that must only be in bzr.dev or something... [13:53] 1.1 I think [13:53] 1.1 [13:53] ah, cool [13:54] * radix clicks the little explodey down-arrow [13:58] looks like it's not packaged yet, or something. guess I'll have to wait a couple day s:) [13:59] 'night === bigdo1 is now known as bigdog [14:00] radix: it's in ppa [14:03] missing postfix [14:03] bzr: ERROR: unknown kind 'missing' [14:03]