[00:02] <keithy_> well an idea for core dev... dmg installer for Mac OS X 10.4
[00:02] <lifeless> 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] <lifeless> keithy_: I'll mail the list for you if you like
[00:03] <lifeless> keithy_: the dmg is done by community members :)
[00:03] <keithy_> k
[00:05] <keithy_> I'v been waiting for python to finish building for ages, does it take long?
[00:05] <dysinger> that's the stupid problem with macports
[00:05] <dysinger> It compiles EVERYTHING
[00:06] <dysinger> it might as well compile an alternate kernel too for pete's sake
[00:06] <dysinger> I don't use it.
[00:06] <dysinger> ./configure && make are easy to use.
[00:06] <keithy_> I think I have python on this mc 4 times now
[00:07] <dysinger> what would it take to get easy_install on your mac ?
[00:07] <dysinger> skip macports
[00:08] <dysinger> if you have easy_install then it's just one line
[00:08] <dysinger> to get the latest bzr
[00:08] <dysinger> sudo easy_install -U paramiko pycrypto bzr
[00:08] <dysinger> OS X comes with Python - you shouldn't have to be compiling Python.
[00:09] <dysinger> http://peak.telecommunity.com/DevCenter/EasyInstall
[00:11] <minghua> OS X's python is crippled pretty hard last time (10.3 days) I looked.
[00:11] <jelmer> lifeless: is there a dmg yet? I thought there were people still working on it
[00:11] <igc> maybe we should add easy_install instructions to the Download page
[00:18] <jelmer> igc: easy_install doesn't provide a patched python-subversion
[00:19] <foom> someone could make an easy_installable python-subversion, though, probably.
[00:20] <jelmer> that would be nice
[00:20] <keithy_> Error: The following dependencies failed to build: py25-paramiko py25-zlib
[00:21] <jelmer> there have been quite a few people here trying to patch and build it
[00:23] <jelmer> that reminds me, I need to get that memory leak fix into hardy...
[00:23] <jelmer> because of the way the memory pool stuff works in apr, it's also a major performance improvement
[00:29] <keithy_> so macports is hosed
[00:29] <keithy_> I cant even find a skip option
[00:29] <dysinger> Yeah I stopped using fink and macports years ago
[00:29] <dysinger> same reason I stopped using gentoo
[00:30] <dysinger> you are guaranteed to get pissed one day when the whole build system breaks down when you need it.
[00:30] <keithy_> yeah I use knoppix for linux because I detest these installation issues
[00:30] <keithy_> has everything preinstalled
[00:30] <dysinger> debian and debian variants - accept no substitutes
[00:30] <keithy_> but I cant beleive I have found a mac os x programme that is offering me no options
[00:33] <dysinger> have you tried easy_install (or are you more inclined to the not_easy_install_hair_pulling method) ?
[00:33] <dysinger> http://peak.telecommunity.com/DevCenter/setuptools#installing-setuptools
[00:34] <dysinger> er better http://peak.telecommunity.com/DevCenter/EasyInstall#installation-instructions
[00:35] <dysinger> try this
[00:35] <dysinger> cd /tmp ; curl -O http://peak.telecommunity.com/dist/ez_setup.py ; python ./ez_setup.py
[00:36] <dysinger> sheesh I am not even a python person :/  Help me out guys.
[00:38] <lifeless> jelmer: I thought there was a 10.5 one
[00:38] <dysinger> There is but you don't need it
[00:38] <dysinger> easy_install -U does the same thing
[00:38] <dysinger> It just looks prettier
[00:38] <dysinger> and has docs
[00:38] <jelmer> lifeless: Ah, it just doesn't include the python-subversion stuff then yet
[00:39] <dysinger> (It = dmg)
[00:39] <dysinger> I am updating the python-subversion instructions again on the wiki in the next 30 min
[00:39] <dysinger> (for OS X)
[00:39] <dysinger> It's better than my yesterday edit.
[00:48] <lifeless> abentley: ping
[00:49] <dysinger> 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] <lifeless> 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] <dysinger> wtf?
[00:51] <dysinger> svn+ssh works but it's not recognizing the http
[00:51] <dysinger> grr
[00:52] <keithy_> error: Download error for http://www.lag.net/paramiko/download/paramiko-1.7.1.zip: (61, 'Connection refused')
[00:53] <keithy_> I give up
[00:53] <lifeless> keithy_: you only need paramiko for sftp
[00:53] <lifeless> keithy_: to just use bzr; if you have *a* python (2.4 or newer) just do this:
[00:53] <lifeless>  - grab the bzr tarball
[00:53] <lifeless>  - untar it
[00:53] <lifeless>  - add that directory to your path
[00:53] <lifeless>  * DONE *
[01:08] <keithy_> it worked!
[01:11] <hsn_> what is main feature of bzr-1.1?
[01:11] <dysinger> version control
[01:11]  * dysinger ducks
[01:11] <keithy_> erm .. it doesnt install on Mac os  x 10.4
[01:11] <keithy_> ;-)
[01:19] <lifeless> max os X is awkward
[01:20] <lifeless> its really geared for binary installs, but the vast chunk of unix programmes are not supplied as binaries by apple
[01:24] <lifeless> spiv: the eagle has landed
[01:24] <spiv> lifeless: sweet
[01:25] <Talden> 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] <lifeless> there is a changelog I thought
[01:27] <lifeless> Talden: http://bazaar-vcs.org/
[01:28] <lifeless> 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] <lifeless> "
[01:28] <lifeless> Talden: and links to the full changelog.
[01:35] <foom> lifeless: but the "News" section doesn't say anything
[01:35] <lifeless> foom: see martins post about website maintenance
[01:36]  * igc lunch
[01:47] <jelmer> Hmm
[01:47] <jelmer> the improved Inventory.repr() is nice, but it causes very large backtraces in some cases
[01:48] <jelmer> I just got a single-line 700k error from bzr
[02:37] <lifeless> jelmer: grats
[02:38] <jelmer> lifeless: hi
[02:38] <jelmer> lifeless, grats?
[02:38] <lifeless> on 700K bt
[02:38] <poolie> bt?
[02:39] <bob2> (backtrace)
[02:39] <jelmer> lifeless: ah, congrats?
[02:39] <lifeless> jelmer: yes
[02:41] <jelmer> you had me wondering there for a moment why that word wasn't in my 500-page en<->nl dictionary ;-)
[02:45] <lifeless> WoW slang
[02:47] <jelmer> well, with so many Australian bzr developers, I'm glad the main language isn't strine :-P
[02:47] <bob2> does bzr not have an en_AU translation yet?
[02:49] <jelmer> There is no localization yet
[02:50] <jelmer> and both english and american spelling appear to be used
[02:50] <jelmer> bob2: so what's different in en_AU from en_UK?
[02:51] <jml> jelmer: very few things.
[02:55] <jelmer> I can't seem to find any difference in the .mo files
[02:56] <ntnhan> 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] <ntnhan> 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] <jelmer> ntnhan: It doesn't send email from the server side
[02:57] <ntnhan> jelmer: yes, that's what I don't want :(
[02:58] <beuno> ntnhan, is the server running the bzr smart server?
[02:59] <ntnhan> beuno: no, it's just bzr installed
[03:00] <beuno> 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] <beuno> (smart server would solve it in that case, as you can hook into it)
[03:02] <ntnhan> bueno: how do we configure bzr running on server each time client commits?
[03:02] <beuno> ntnhan, using the smart server  :D
[03:02] <ntnhan> bueno: haha, thx, I didn't know it :), will give a try now
[03:03] <beuno> ntnhan, then you can just hook into bzr, maybe even the current plugin will send off emails. jelmer?
[03:04] <jelmer> I don't think the smart server can send emails when a revision is pushed to it
[03:04] <jelmer> but it's been a while since I've looked at it
[03:04] <jelmer> it being bzr-email
[03:04] <jelmer> lifeless is the bzr-email maintainer so he's probably in a better position to comment
[03:05] <beuno> ntnhan, maybe take a peek at http://bazaar-vcs.org/SmartServer/RemoteObjectHacking
[03:05] <beuno> and of course, lifeless would be *the* man  :D
[03:05] <ntnhan> beuno: ok, i'll try it
[03:06] <lifeless> ntnhan: hi
[03:06] <ntnhan> lifeless: hi
[03:06] <lifeless> 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] <lifeless> but we have to make it work in fact too:)
[03:07] <lifeless> 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] <beuno> there has to be someway to do it, Launchpad does it  :p
[03:07] <lifeless> beuno: launchpad uses the cron based solution
[03:08] <lifeless> beuno: not the exact same code but that logic path
[03:08] <beuno> seems fairly trivial, just scan through the dir, save the last revid sent by email, and fire off
[03:09] <beuno> (of course, almost anything seems trivial in irc  :P)
[03:09] <lifeless> beuno: well code exists; kthxbye :)
[03:09] <ntnhan> beuno: yes, but everybody wants to save time, need a ready cake
[03:10] <ntnhan> :)
[03:10] <beuno> ntnhan, that's how plugins get started  :D
[03:10] <beuno> (or specs pushed into the trunk)
[03:10] <beuno> file a bug
[03:10] <beuno> requesting it
[03:11] <beuno> the "let's get the aount of open bugs" fever in the upcoming sprint should take care of the rest!
[03:11] <beuno> s/aount/amount
[03:23] <dysinger> 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] <dysinger> This worked fine in subversion 1.4.6
[03:24] <Odd_Bloke> dysinger: Try 'svn+https://...'.
[03:24]  * Odd_Bloke can't remember if that works or not.
[03:24] <dysinger> yeah not working either
[03:24] <dysinger> already tried that
[03:25] <Odd_Bloke> Well, jelmer will probably save the day.
[03:25] <Odd_Bloke> He normally does. :p
[03:25] <dysinger> I am trying to get closer and closer to his setup
[03:25] <dysinger> svn+https blows up with a stack trace
[03:25] <jelmer> dysinger: Do you have libneon built with SSL support?
[03:26] <dysinger> regular https:// is acting like it's looking at as a bzr branch
[03:26] <lifeless> dysinger: its jelmer's 4am :- I think you'll get little now :)
[03:26] <dysinger> hah!
[03:26] <lifeless> have you looked in ~/.bzr.log ?
[03:26] <dysinger> He's up!
[03:26] <dysinger> ah ok two good suggestions.
[03:26] <lifeless> I wager its not loading the plugin
[03:26] <dysinger> 1st svn ls https:// works and yes svn --version shows https
[03:27] <dysinger> let me look at the log
[03:27] <jelmer> dysinger: the svn executable from the location you just installed to and with the same DYLD_LIBRARY_PATH set?
[03:27] <dysinger> FAQ!
[03:27] <dysinger> one sec maybe my bad
[03:29] <dysinger> I managed to install it in /usr/local/bin but svn --version reports 1.4.4 (version that comes with mac).  ???
[03:29] <dysinger> This is kicking my ass.
[03:30] <dysinger> I am setting DYLD and PYTHONPATH too
[03:30] <dysinger> PATH has /usr/local first
[03:31] <dysinger> ok I have more work to do
[03:31] <dysinger> my neon didn't install right.
[03:31]  * dysinger goes back to the salt mines
[03:33] <lifeless> spiv: how do you get remote server backtraces ?
[03:47] <j1mc> 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] <lifeless> bundles and pushing revisions are roughly equivalent
[03:48] <lifeless> think of it as a transport change
[03:48] <j1mc> transport change?
[03:49] <lifeless> however 'regular patches' means GNU patch output, which does not include: commit messages, mode changes, renames, deletes-as-deletes
[03:49] <beuno> 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] <lifeless> spiv: ping
[03:50] <minghua> lifeless: deletes-as-deletes?
[03:50] <j1mc> beuno: thanks.  (and thanks to you, too, lifeless).  what kind of bzr metadata might be included in the bundle?
[03:51] <lifeless> minghua: 'foo is deleted' is different to 'foo has a patch that removes <entire list of old lines>'
[03:52] <j1mc> ah, ok.
[03:53] <lifeless> 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] <minghua> lifeless: Ah, I see.  Thanks.
[04:04] <Verterok-laptop> moin
[04:05] <spiv> lifeless: http://rafb.net/p/JoRYz534.html
[04:06] <lifeless> spiv: bb:approve
[04:06] <Verterok> poolie, lifeless: I have a dmg for OS X 10.4 ready for a ride :)
[04:06] <poolie> Verterok, yay
[04:06] <spiv> lifeless: ta
[04:06] <poolie> Verterok, can you upload it to launchpad?
[04:06] <poolie> btw i spoke to them about the size limit
[04:06] <Verterok> it's ppc only
[04:06] <lifeless> Verterok: sweet
[04:06] <poolie> is 60MB ok?
[04:06] <lifeless> keithy_: ^
[04:07] <Verterok> poolie: 6MB
[04:08] <Verterok> there might be something wrong 6MB vs 60MB
[04:09] <Verterok> this dmg only contains bzr+pycrypto+paramiko
[04:10] <Verterok> aha, all the plugins missing :P
[04:11] <Verterok> I'm going to add Rebase and bzrtools to it, but I don't have QT installed in OS X so no Qbzr :(
[04:26] <Verterok> poolie: I misunderstood the question about the size (is too late here :P)
[04:40] <lifeless> Verterok: l)
[04:46] <Verterok> I have a dmg with bzr(pycrypto+paramiko) + bzrtools + bzr-rebase :)
[04:46] <lifeless> care to add bzr-email
[04:47] <Verterok> ok
[04:48] <Verterok> lifeless: trunk?
[04:49] <lifeless> yup
[04:51] <Verterok> trunk has not been published yet
[04:52] <lifeless> http://bazaar.launchpad.net/~bzr/bzr-email/trunk/
[04:52] <lifeless> dunno what you mean by not published yet
[04:52] <Verterok> is what launchpad say :)
[04:53] <Verterok> https://code.launchpad.net/~lifeless/bzr-email/trunk
[04:53] <lifeless> url ?
[04:53] <lifeless> ~bzr
[04:53] <lifeless> not ~lifeless
[04:53] <Verterok> ok, sorry
[04:54] <lifeless> thumper: https://code.edge.launchpad.net/~bzr/bzr-email/trunk <-
[04:55] <lifeless> thumper: I didn't get any notification about that merge request
[04:55] <lifeless> thumper: so I didn't know it exists
[05:03] <Verterok> poolie: I'm going to upload it to: https://launchpad.net/bzr/1.1/1.1 it's ok?
[05:04] <poolie> yes, thanks
[05:09] <lifeless> spiv: down to 100 seconds in get_parents_map calls
[05:22] <lifeless> spiv: thats down from 237
[05:23] <spiv> lifeless: very nice
[05:23] <spiv> lifeless: that's for branching bzr.dev from London?
[05:26] <lifeless> yeah
[05:26] <lifeless> 115 seconds on my current test
[05:26] <lifeless> I'm done for the day;
[05:26] <lifeless> I'll commit and push
[05:27] <lifeless> if you re interested
[05:27] <lifeless> http://people.ubuntu.com/~robertc/baz2.0/search-results
[05:27] <lifeless> rev 3198 pushing now
[05:29] <lifeless> 15 seconds from startup to starting the stream in my 'last 100' test
[05:29] <lifeless> thats another 100% saving over my report earlier in the week
[05:30] <lifeless> your patch when it lands will help debug
[05:30] <lifeless> it seems to be falling into a 'one at a time' pathological mode
[05:31] <lifeless> 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] <poolie> lifeless, have a tolerable trip :)
[05:31] <lifeless> 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] <lifeless> I don't anticipategetting any hacking on this branch done next week
[05:32] <lifeless> but I'm quite happy with where it is getting to :)
[05:33] <lifeless> thats poolie
[05:34] <lifeless> poolie: oh you might like to mail me anything you want (other than the baz package stuff) for discussion with the distro.
[05:34] <lifeless> ciao.
[05:37] <thumper> lifeless: yeah, damn eh
[05:37] <thumper> lifeless: a bug report would be good :-)
[05:46] <Manfre> is it possible to modify the commit message for a revision?
[05:46] <poolie> Manfre, uncommit then commit again
[05:47] <Manfre> is there anyway to modify a revision that is not the head?
[06:10] <abentley> 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] <abentley> Whatever way is most efficient for them.
[06:40] <ubotu> 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] <thumper> abentley: man, when do you sleep?
[07:20]  * Verterok leaves, only two hours for sleep. seeya!
[07:21] <caelum_> f
[07:39] <AnMaster> how long as 1.1 been out?
[08:02] <AfC> AnMaster: a few days
[08:10] <AnMaster> ok
[08:10] <sabdfl> poolie: ping
[08:17] <soren> AnMaster: "Bazaar 1.1 was released on the 15th of January, 2008."  <---- Very first sentence on http://bazaar-vcs.org/
[08:21] <AnMaster> right
[09:17] <dato> jelmer: because I see python packages b-depending on python-all-dev *everywhere*, and it's not needed at all
[09:28] <dato> 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] <dato> jelmer: so my bug has much less priority now, thanks to bzr-svn rocking ;)
[10:34] <ntoll> hi, how does bzr merge handle a move or delete on one branch and an edit on the other (since they were branched)?
[10:42] <ntoll> aha... just found the docs... looks like this case is handled
[10:45] <asac> is there an easy way (short hand) to export a series of commits as one-patch-per-commit?
[11:09] <stefanv> hey all, is there a way to remove binary files including their history from a bzr archive?
[11:09] <stefanv> s/archive/branch/
[11:10] <stefanv> I found that tracking jsmath-fonts is a big pain in the ass, with all its 20 000 odd files
[11:11] <stefanv> maybe I can check out before their inclusion, and apply all the patches that happened after their inclusion
[11:11] <lifeless> asak_: diff -r x..+1 in a loop perhaps ?
[11:12] <stefanv> hrm, bugger, those files were there since revision 1
[11:20]  * dato hands lifeless diff -c ;)
[11:32] <stefanv> 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] <dato> stefanv: no, remove does not remove all traces
[11:34] <stefanv> dato: hrm, interesting: because I had 88Mb's worth of binary files, and now the repo in total is only 18Mb
[11:37] <AfC> ... _is_ there a way to purge all evidence of something from a branch history & repo?
[11:38] <AfC> 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] <stefanv> AfC: well, I just made sure: when I remove those binary files, and do 'bzr uncommit', they don't come back
[11:38] <stefanv> so it definately permanently erases them
[11:39] <AfC> Assumint the
[11:39] <AfC> 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] <stefanv> yes, if you knew which binary files to bring back (i.e. you still have the filename information)
[11:40] <stefanv> AFAIK in an SVN repository, the binary data itself is also stored
[11:40] <stefanv> hence my original question :)
[11:41] <luks> no, you can't remove anything from the repository permanently without rewriting it completely
[11:42] <stefanv> 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.
[11:42] <luks> I guess the size difference is because you count the working tree size
[11:42] <stefanv> luks: you cannot bring back those binary files, they are gone.
[11:42] <luks> you can
[11:42] <luks> bzr remove doesn't actually remove them from the history
[11:42] <stefanv> 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] <stefanv> luks: no, sure, they *filename* info is still there... but the actual bytes are gone
[11:43] <luks> nope
[11:43] <stefanv> so, 88Mb in 3.3Mb, eh?
[11:43] <luks> if you just did bzr remove and bzr commit, all the bytes are still there
[11:44] <luks> the only thing I could imagine is that you haven't committed 'bzr add' of those files
[11:44] <dato> sounds like it
[11:44] <stefanv> they *were* tracked:
[11:45] <stefanv> [11:45] <stefanv> let me just recheck the original repo
[11:45] <luks> bzr cat -r REVISION_IN_WHICH_THE_FILE_WAS_ADDED sanum/static/javascript/jsMath/fonts/cmbx10/plain/85/char73.png
[11:46] <stefanv> ok, so it's head-in-the-sand time then?
[11:47] <stefanv> hrm, but wait
[11:47] <stefanv> if I do bzr log sanum/static/.... I should see something
[11:48] <stefanv> yeap, I don't think those files were tracked.  why don't they show up in bzr status then?
[11:49] <stefanv> ok, erase my previous 4 sentences
[11:49] <stefanv> the files *was* tracked from revision 1
[11:49] <stefanv> the bzr cat -r 1 command shows its contents
[11:50] <stefanv> which explains why bzr status doesn't explain it
[11:50] <stefanv> s/explain/show/
[11:50] <stefanv> luks: are you sure the bzr behaviour you  describe above is correct?
[11:51] <luks> yes
[11:52] <luks> you can never ever permanently remove anything from the repository
[11:52] <luks> it would break integrity of the repository
[11:52] <stefanv> something very strange going on.  I can confirm the behaviour you describe with a new repo, but not with my other one.
[11:52] <luks> the only way to remove them would be to "rewrite" the repository without those file
[11:55] <stefanv> luks: ok, figured out what was going on
[11:55] <stefanv> luks: the binary files are indeed tracked
[11:56] <stefanv> luks: but they are *much* smaller when they aren't physically written to disk
[11:56] <luks> 'physically written to disk' means in the working tree?
[11:56] <stefanv> luks: about 20000 odd files, each taking up a minimum space determined by the file-system configuration
[11:56] <stefanv> luks: yes, so if they are all stored in one big file, they are much much smaller
[11:57] <luks> 88MB vs. 3MB still seems too big difference
[11:57] <dato> 20000 files at 4k blog size would be 78mb
[11:58] <stefanv> well, the files are tiny, and an inode needs a min of 4 or 8K right?
[11:58] <dato> 20000 ~150 byte files make 3mb
[11:58] <luks> hm, makes sense
[11:58] <dato> so, it's possible
[11:59] <stefanv> my apologies for not believing that bzr could compress 90Mb into 3Mb :)
[11:59] <luks> :)
[12:00] <stefanv> now, I also know better than to try and rsync that repo
[12:19] <rjek> 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] <luks> commit
[12:20] <luks> every merge needs a commit
[12:20] <rjek> Ah, so I commit the differences from somebody else's branch to my one?
[12:20]  * rjek sees.  Ta.
[12:20] <luks> yes
[12:20] <rjek> As a convention, what do people tend to use as their commit messages for such merges?
[12:21] <luks> I usually use "Merge <URL>" or "Merge <branch name>"
[12:21] <rjek> Right.
[12:21] <luks> but some people prefer more descriptive messages
[12:21] <rjek> 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] <luks> Ng: auto-merge is not always right
[12:23] <luks> even if there are no textual conflicts, you can't be sure the merge is right
[12:23] <Ng> 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] <rjek> :)
[12:34] <asac> lifeless: thanks ... didn't know about the +1 notation ;)
[12:34] <asac> guessing a patch-filename from comment would be nice to have automated though
[12:37] <dato> asac: I don't think that notation exists. you want diff -c
[12:42] <asac> dato: ok ... -c is even better :)
[12:43] <asac> 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] <asac> naybe the bazaar-cvs.org page should start to auto-mirror branches of plugins where license permits it?
[13:00] <abentley> thumper: Evidently, I slept just then.
[13:00] <thumper> and I'm just about to
[13:16] <abentley> (Geez, Thumper, when do you sleep?)
[13:17] <fullermd> Sleep?  I heard of that once, I think...
[13:17]  * fullermd checks google.
[13:18] <radix> 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] <radix> I also put ticket numbers in the commits for merges.
[13:19] <radix> and describe the change in high-level
[13:19] <luks> that works fine if you have a mainline and only merge feature branches
[13:20] <luks> but it's not that useful when you randomly sync with a few developers
[13:20] <radix> yeah. why would I do that random thing when I could do an organized thing? :)
[13:20] <luks> dunno, the "decentralized" thing :)
[13:21] <radix> my development is perfectly distributed.
[13:21]  * radix goes to get breakfast
[13:21] <luks> that doesn't mean decentralized
[13:36] <abentley> jelmer: I don't plan to ever work on trac-bzr again.
[13:36] <jelmer> abentley: oh, ok
[13:38] <stefanv> abentley: I didn't follow the rest of the thread -- is trac-bzr maintained at all?
[13:38] <abentley> stefanv: I have the impression that other people have been working on it.
[13:40] <stefanv> abentley: that's good news -- many projects simply won't switch if there isn't a supported trac backend available
[13:42] <AfC> Oh my. `meld` is amazing.
[13:42] <AfC> 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] <stefanv> I'm guilty of still merging with emacs
[13:45] <jelmer> 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] <AfC> jelmer: fair enough
[13:47] <jelmer> Of course, we could just fix meld but nobody has done that yet...
[13:47] <AfC> jelmer: (I just had a conflict and so for the heck of it tried
[13:48] <AfC> `meld DemoWindowRunner.java.OTHER DemoWindowRunner.java.THIS`
[13:48] <AfC> and it was glorious)
[13:48] <jelmer> yeah, it works and looks quite well
[13:48] <AfC> luks: I haven't tried it as a merging program, but to show the diff it was really slick
[13:49] <luks> AfC: I don't think you need to even specify filenames, it can figure out bzr conflicts itself
[13:50] <radix> speaking of meld, I'd love to use it with bzr but bzr diff doesn't have a --diff-cmd parameter
[13:51] <radix> (just for the diff viewing, of course. the merging would obviously require more work)
[13:52] <AfC> Whoa. So for merging / conflict resolution you just click on the arrows...
[13:52] <luks> radix: not sure if it works with meld, but there is `bzr diff --using`
[13:53] <brilliantnut> if meld takes file1 file2 as arguments then --using will work.
[13:53] <radix> that must only be in bzr.dev or something...
[13:53] <luks> 1.1 I think
[13:53] <brilliantnut> 1.1
[13:53] <radix> ah, cool
[13:54]  * radix clicks the little explodey down-arrow
[13:58] <radix> looks like it's not packaged yet, or something. guess I'll have to wait a couple day s:)
[13:59] <AfC> 'night
[14:00] <luks> radix: it's in ppa
[14:03] <elmo> missing postfix
[14:03] <elmo> bzr: ERROR: unknown kind 'missing'
[14:03] <elmo> ^-- halp?
[14:05] <lamont> elmo: bzr version maybe?
[14:05] <elmo> it's 1.0
[14:34] <mikl> how do I fix conflicts? The docs talk about conflict markers, whatever that is...
[14:34] <rjek> Manually, usually.
[14:34] <mikl> ensuring that .BASE, .THIS and .OTHER files are identical wont allow me to resolve it
[14:34] <mikl> nor will deleting them do the trick
[14:35] <dato> mikl: edit the conflicting file to make sure it's resolved, and then `bzr resolve FILE`
[15:02] <bac> mikl: using a tool like kdiff3 or meld makes it pretty easy
[15:03] <bac> i use the extmerge plugin which you may want to have a look at
[15:03] <mikl> bac: ok, thank you :)
[15:44] <rjek> So, what are people's suggestions for web-based bzr branch/repository browsers that don't require a big fat framework?
[15:59] <beuno> rjek, I've been working on a php-based solution
[15:59] <beuno> but it's not releaseable
[16:00] <TFKyle> beuno: implemented a lot of bzr in php?
[16:02] <rjek> Eugh.  I'm not sure I'd want to run a php-based one.
[16:02] <rjek> Especially given that we've banned PHP from our co-lo boxes.
[16:02] <beuno> TFKyle, yeap, quite a lot
[16:03] <rjek> Something that could do what bzr vis does would be extra lovely.
[16:08] <rjek> Additionally, are their C bindings to bzr so I can use it as a library from C and other languages?
[16:09] <corporate_cookie> im calling BZR from cron on a RHEL4 system with a parallel install of python2.3 and 2.4. Cron reports this error: /bin/sh: bzr: command not found. However bzr works otherwise
[16:09] <corporate_cookie> any ideas ? : )
[16:10] <rjek> What does "which bzr" say?
[16:10] <rjek> It may not be in the PATH of the environment that runs the cronjob.
[16:10] <corporate_cookie> rjek: it says /usr/bin/bzr
[16:11] <rjek> Try changing your cronjob to use /usr/bin/bzr rather than just bzr.  If that doesn't work, it may not be able to find any Python.
[16:11] <corporate_cookie> the job runs as root ...whos path is -bash: /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin
[16:11] <abadger1999> Does anyone know the plan regarding bzr versions and stability?  (ie: will there be a 1.0.x branch?  Will 1.x have API backwards compatibility? Business as usual?  Other?)
[16:12] <rjek> The environment that your cron runs in need not be the same as the one you get if you log in as root.
[16:12] <corporate_cookie> how do I determine what environment cron runs in
[16:13] <corporate_cookie> (my linux foo is weak)
[16:13] <rjek> corporate_cookie: Write a cronjob that just runs "env" - it'll email you with the environment :)
[16:14] <corporate_cookie> good thinking! :" )
[16:15] <rjek> I know nothing of Red Hat.  I've not used it in years.  I know less about Python, so if this doesn't reveal the answer obviously, I'm out of ideas :)
[16:18] <jam> abadger1999: generally business as usuall. We've already released 1.1, and 1.2 is on the way
[16:19] <abadger1999> jam: Thanks.  I guess I'll be updating for Fedora but holding at 1.0 for Red Hat/CentOS then.
[16:20] <jam> rjek: as for C bindings, you can embed the python interpreter in your C program
[16:20] <jam> rjek: then you would be working in terms of PyObjects, etc
[16:21] <rjek> jam: Eugh.  I'd rather avoid having to speak Python.  And embedding Python into Lua in order to query stuff nicely sounds like a hack :)
[16:21] <dato> abadger1999: I think cron resets PATH to something unuseable, you'll want to give PATH a value
[16:21] <jam> understandable, I don't think our data objects are terribly hard, but it would seem silly to reimplement everything
[16:22] <rjek> For example. subversion has a nice library you can link to directly from C.
[16:22] <jam> rjek: sure, but it was *written* in C
[16:22] <rjek> jam: Well, you can bind C functions to Python.  Is it not simple to bind Python functions to C?
[16:22] <rjek> Lua makes this pretty trivial.
[16:23] <rjek> I have no idea what Python's C interface is like, of course.
[16:23] <jam> It's interface is pretty decent
[16:23] <jam> IMO
[16:23] <jam> of course, it is up to you whether you would rather embed python
[16:24] <jam> or spawn a process and parse text
[16:24] <jam> bzrlib is a rather rich api
[16:24] <rjek> I'd rather use a C API, as that's then trivially used from pretty much everything.
[16:24] <jam> and 'bzr' is more focused on clients than scripters
[16:24] <rjek> Be it C, C++, Lua, or Perl.  Or whatever you fancy.
[16:24] <jam> except then you are stuck with the C data model, etc.
[16:25] <jam> and string processing and memory management is horribly painful at the C level
[16:25] <rjek> For a slight inconvience you gain a lot of flexibility, though.
[16:25] <jam> anyway, /me => away for a while
[16:25]  * rjek shrugs, libsvn's API's pretty elegant.
[17:53] <beuno> hmmm, I just upgrade a 3GB branch to packs, and now, the repository is twice it's size. repository/obsolete_packs/ seems to be the same size as repository/packs/.  Is this an expected behaviour?  (bzr 1.0)
[17:54] <jam> beuno: you can nuke obsolete_packs/*, bzr will clean it up eventually, we only keep it around to avoid race conditions with when the OS writes out new files versus deleting old ones
[17:55] <beuno> jam, great, thanks. Shouldn't there be a command that you cleans it for you?
[17:57] <jam> At the moment, it will be done at the next "autopack"
[17:57] <jam> which will be approximately 10 commits from now
[17:57] <jam> I've posted to the list about having "bzr pack" do it automatically
[17:58] <jam> we could add a new command, but it seems better suited to just add it into bzr pack
[17:58] <beuno> yes, bzr pack seems like the most intuitive (in fact, I ran it before to see if it would solve it)
[18:00] <ubotu> New bug: #184097 in bzr "[1.0.0] Should not die on error if cannot open .bzr.log" [Undecided,New] https://launchpad.net/bugs/184097
[18:36] <_flx> hi
[18:37] <_flx> is there any way when commiting with the command line to add endline in the commit message so separate two elements
[18:37] <_flx> ?
[18:38] <brilliantnut> _flx: is there a problem with opening the editor for entering your commit message?
[18:38] <_flx> brilliantnut, no the I would like to do it with the "-m" option
[18:39] <_flx> s/the/but
[18:43] <BasicOSX> Is there a way to get a remote bzr repository without all of the history? I just want a working copy of the bzr tree, to us, and save the disk space by not having the history
[18:47] <james_w> BasicOSX: I'm afraid you can't do that currently.
[18:48] <LarstiQ> lightweight checkout?
[18:50] <LeoNerd> bzr co --lightweight URL
[18:51] <brilliantnut> _flx: if you're on linux, then most shells will let you add a \ at the end of your line to escape the new line
[18:51] <LarstiQ> BasicOSX: for just a copy of the working tree, that works. But for any other bzr functionality it will have to hit the network.
[18:52] <_flx> brilliantnut, thx you
[18:53] <mtaylor> statik: I sent in the patch we were talking about
[19:05] <jelmer> what's the proper way to get the per-file ancestry these days?
[19:06] <ekimus_> hi, is check_signatures and create_signatures some magic thing? I just can't figure out how to specify the key, or do I have to explicitely set gpg_signing_command in the corresponding locations.conf section?
[19:08] <ekimus_> hmm or ist the signature stuff just used for email submissions?
[19:10] <Qhestion> anyone know where i can get paramiko (for sftp)? looks like the homepage is down :/
[19:10] <Qhestion> ahh wait... nevermind
[19:10] <Qhestion> its on launchpad :)
[19:12] <james_w> It's obviously been to long, I can't believe I got that wrong.
[19:12] <james_w> Hi LarstiQ, how are you?
[19:13] <LarstiQ> james_w: improving, thank you. How about you?
[19:13] <james_w> I'm well thanks.
[19:13] <james_w> Do you think you'll go to the sprint?
[19:13] <LarstiQ> james_w: not decided yet
[19:15] <james_w> LarstiQ: it would be great if you were there so we have a chance to meet.
[19:16] <LarstiQ> james_w: you're going?
[19:17] <james_w> LarstiQ: hopefully, but probably only for the last couple of days.
[19:18] <james_w> jelmer: will you be going?
[19:18] <LarstiQ> james_w: cool, that's certainly something I have to keep in mind then.
[19:20] <jelmer> james_w: Yep, I'll be there
[19:20] <james_w> great.
[19:26] <cr3> is bzr quicker or slower with some protocols? for example, is sftp known to be slow?
[19:28] <mtaylor> cr3: yes
[19:28] <mtaylor> cr3: sftp is _way_ slower than bzr+ssh
[19:28] <mtaylor> cr3: of course, there are some situations in which you still want to use sftp
[19:29] <mtaylor> cr3: such as when the server you are dealing with doesn't have bzr installed or has an old version installed
[20:12] <deepjoy> if I want to use bzr as a server for the central repos with authentication with a relatively slow connection between the repos and the developers what format should I be using? i.e. bzr+ssh bzr+http sftp etc.
[20:13] <beuno> deepjoy, bzr+ssh or bzr+sftp is fine
[20:14] <deepjoy> also is are the repository format considerations I should be aware of
[20:14] <deepjoy> I'm converting my repos from CVS using cvsps plugin
[20:15] <deepjoy> is the default repos storage format that bzr 1.1 converts to the latest?
[20:15] <deepjoy> or is there some other repos format that is not the default but may be different (not necesarily better) in it's performance
[20:15] <beuno> deepjoy, yeap, packs, which is the format to use
[20:17] <deepjoy> so I gather bzr+http is still in it's nacency and using apache for ldap auth using mod_ldap is not stable yet?
[20:17] <deepjoy> so pack is the default on 1.1?
[20:20] <beuno> deepjoy, bzr+ssh is the fastest method, bzr+http isn't ready for pushing yet AFAIK
[20:20] <beuno> and yes, packs has been the default format since <0.92
[20:20] <beuno> it has a lot of performance work done on it
[20:21] <beuno> so using 1.1 and bzr+ssh seems like the way to go
[20:21] <fullermd> No, it's existed since 0.92.  Didn't get switched to default 'till 1.0, I think.
[20:21] <beuno> ah, could be true
[20:21] <beuno> 1.0 and on for sure
[20:25] <deepjoy> thanks
[20:25] <beuno> np  :D
[20:25] <deepjoy> I was trying to get bzr+http working some time back on 1.0 and spiv pointed out how to get it working for push
[20:26] <deepjoy> it does do push
[20:26] <deepjoy> the perf  is not too good yet
[20:27] <deepjoy> I believe there is a verb addition task in launch pad for that
[20:27] <beuno> ah, I haven't tried that out in a while
[20:27] <beuno> good to know though
[21:17] <pfharlock> I have a rather dumb question, if you delete a branch from a shared repository using the os filesystem commands, is there a way to get that branch back out of the repository?
[21:18] <james_w> pfharlock: yes.
[21:18] <james_w> pfharlock: the easiest way is to install the 'heads' plugin.
[21:19] <pfharlock> ahhh, ok, so there isn't a built in way to do it.
[21:19] <dato> I think I'd be amused by the output of `heads` in my repositories, where I do zillions of `uncommits`
[21:19] <james_w> then run that (with an option that I forget, something like --dead), and find the one that you want, and then you should be able to 'bzr branch -rrevid:whatever another_branch new'
[21:59] <fullermd> Hm.  Today's bzr.dev seems to not like talking to 1.0 over bzr+ssh...
[21:59] <fullermd> r3191 works; 3192 fails.
[22:00] <dato> fullermd: there's a msg from lifeless on list about that
[22:01] <dato> fullermd: subject.*api break
[22:01] <fullermd> No, that's bzr.dev <-> older bzr.dev, not bzr.dev <-> 1.0
[22:01] <dato> ah
[22:01] <dato> indeed, misread
[22:02] <fullermd> Forgot about that mail, though.
[22:02]  * fullermd wanders off to post a followup.
[23:01] <dysinger> So I am going to keep playing with OS X bzr-svn but I have to comment that it's a PITA and not ready for the masses
[23:01] <dysinger> Git-svn is orders of magnitude faster and smaller on disk.
[23:02] <dysinger> But that is not a criticism - it's just is what it is :)
[23:03] <dysinger> s/it\'s/it
[23:03] <foom> the actual program git-svn is smaller on disk?
[23:03] <dysinger> My repository on Git is 181MB - with bzr-svn it's twice that.
[23:04] <jelmer> dysinger: Are you using packs?
[23:04] <dysinger> --rich-root-packs y
[23:04] <dysinger> Let me get the actual numbers
[23:04] <fullermd> That's probably more git/bzr than git-svn/bzr-svn.
[23:05] <dysinger> y
[23:05] <dysinger> You guys totally win in the UI
[23:05] <dysinger> I like it better
[23:05] <foom> maybe bzr should just be a UI for git. :p
[23:06] <dysinger> no
[23:06] <dysinger> that would not work.
[23:06] <jelmer> dysinger: Afaik the last comparisons actually showed that bzr's on disk format was in the same order of size as gits
[23:06] <TFKyle> foom: that would kind of suck, you'd loose decent support for windows
[23:06] <dysinger> hmm let me check myself.
[23:06] <fullermd> I doubt that.  Maybe an un-repack'd git...
[23:07] <dysinger> Yeah I just packed and pruned and GC git
[23:07] <dysinger> but it's the entire trunk and 2 branches thats' 181MB
[23:07] <jelmer> dysinger: Did you garbage collect for bzr ?
[23:07] <dysinger> no
[23:07] <dysinger> enlighten me
[23:08] <fullermd> In some quick testing I happened to do the other month, bzr in packs won by a little bit (5% or so) against a straight git import, but repacked git was half the size or something.
[23:08] <jelmer> "bzr pack" should do the packing I think
[23:08] <jelmer> but I'm not sure if that's all you can do to make storage more efficient
[23:08] <jelmer> fullermd: Did you try repacking the bzr packs?
[23:08] <jelmer> lifeless: ^
[23:09] <lifeless> jelmer: no we haven't
[23:09] <lifeless> fullermd: yes thats known; its even in my email from tuesday or so about what we need to do for large projects
[23:10] <lifeless> fullermd: '50% storage reduction' - we have multiple answers that give better compression; just have to choose one and implement
[23:10] <lifeless> fullermd: and I know john is hoping to get onto that in th enext week or so
[23:10] <fullermd> Oh, I know.  I wasn't _surprised_ by it.
[23:10] <jelmer> lifeless: thanks
[23:11] <jelmer> dysinger: out of curiosity - what's the speed difference between bzr-svn and git-svn like?
[23:12] <dysinger> Well i can compare both packed and make some commits and updates with "time"
[23:14] <dysinger> both repos with trunk and 2 branches :  git packed is 187M vs bzr packed is 347M
[23:14] <fullermd> Really, my biggest current grump that's semi-storage-related is the inability to log multiple files at once (of which 'recursive log' is just a special case).  Smaller is good, but I'm not really hurting on size anywhere important.
[23:14] <elmo> hey, can I whine about my bzr commit breakage again?
[23:15] <dysinger> so 150MB is nothing to sneeze at
[23:15] <elmo> bzr: ERROR: unknown kind 'missing'
[23:15] <elmo> with 1.0; I couldn't find any bugs about it; before I go trying to boil it down to a reprdoucable test case, does anyone have any ideas?
[23:16] <lifeless> elmo: file bugs always
[23:16] <lifeless> elmo: knowing it happened is a useful data point; reproducability is great but not as important as knowing it exists (and always include the .bzr.log snippet for the error)
[23:17] <lifeless> dysinger: we'll be fixing that by 1.4 I think.
[23:17] <elmo> lifeless: sure, but I'm leary about how much info I can include in the commit msg
[23:17] <elmo> err
[23:17] <elmo> brain hard
[23:18] <elmo> s/commit msg/bug/
[23:18] <lifeless> elmo: nothing in the .bzr.log will have content, so unless you are naming files with your passwords :))
[23:18] <lifeless> elmo: anyhow, sed FTW
[23:30] <dysinger> So Jelmer my latest attempt to use a clean build of Subversion 1.5 trunk has failed too.  Everything works, I can use svn and all the transports (http/s, svn, ssh) but on bzr-svn I cannot use https without it blowing up.  I can use http etc no problem.
[23:32] <dysinger> I get this -> Assertion failed: (g->gc.gc_refs != _PyGC_REFS_UNTRACKED), function instancemethod_dealloc, file Objects/classobject.c, line 2285.
[23:32] <dysinger> Abort trap
[23:32] <dysinger> :/
[23:32] <dysinger> but only on https svn repos
[23:33] <dysinger> svn ls, co, info etc all work with 1.5 and ssl
[23:33] <lifeless> fullermd: you know the drill; bug or list discussion kthzbye
[23:34] <fullermd> Eh?  For what?
[23:45] <lifeless> fullermd: log N files
[23:46] <ubotu> New bug: #184196 in bzr "BzrError: unknown kind 'missing'" [Undecided,New] https://launchpad.net/bugs/184196
[23:46] <fullermd> Oh.  I'm pretty sure there's already at least one bug on that.  And besides, everybody knows it, and I thought handling that better was one of the points of the in-progress inventory work anyway.
[23:47] <lifeless> fullermd: it can be supported to day; speed is orthogonal to functionality
[23:50] <fullermd> bug 97715 at least
[23:50] <ubotu> Launchpad bug 97715 in bzr "bzr log DIR should show changes under dir" [Undecided,New] https://launchpad.net/bugs/97715
[23:54] <elmo> is anyone working on bzr support for reviewboard?
[23:56] <lifeless> elmo: yes
[23:56] <lifeless> elmo: statik's friends
[23:57] <elmo> k
[23:57] <elmo> git's interface is apparently only 150 lines or so is all
[23:57] <elmo> anyway