[00:41] <lifeless> poolie: pulls of lp down to 49s
[00:41] <johnny> from?
[00:41] <lifeless> poolie: sneaking up on it, 8 seconds wasted on _ensure_real bs
[00:41] <spiv> johnny: approx 2-3 minutes
[00:41] <johnny> yes.. wwe sure are ensuring real bs :)
[00:41] <spiv> johnny: it's not a very scientific test.
[00:41] <johnny> hehe jk
[00:42] <lifeless> spiv: you have the same disk format right - knits at both ends ?
[00:42] <spiv> johnny: because I'm not pulling the same revisions each time, I'm just doing updates occasionally.
[00:42] <spiv> lifeless: I think so, I'll double-check
[00:42] <poolie> spiv, reviewed
[00:42] <johnny> if you had a quote bot in here.. that'd totally be in there :)
[00:42] <poolie> lifeless, what bs is that?
[00:42] <johnny> not that i think you should have one..
[00:42] <johnny> but still
[00:42] <spiv> poolie: thanks!
[00:43] <johnny> so, do you guys participate in that vcs mailing list?
[00:43] <lifeless> poolie: its being tracked down still
[00:43] <johnny> revctrl ?
[00:43] <lifeless> poolie: I'm guessing tags or something like that
[00:43] <spiv> lifeless: yes, both ends knits
[00:43] <johnny> crazy people ...
[00:43] <johnny> too smart for their own good :)
[00:43] <lifeless> johnny: yes, I do
[00:43] <johnny> i know the monotone folks are involved
[00:44] <johnny> that's what i use with other projects
[00:44] <lifeless> johnny: theres a strange mix of noise and signal
[00:44] <johnny> monotone is great... but it's written in C++, and has not so good tools :(
[00:45] <johnny> and git is insane... fast, but insane
[00:45] <johnny> now i'm looking into hg as well, which i had never even previously considered
[00:46] <johnny> lots of amazing projects are using all of these systems
[00:46] <johnny> makes it hard to choose..
[00:48] <lifeless> poolie: I'd like a quick call if thats ok
[00:48] <poolie> 1m
[00:48] <lifeless> I think you forgot a ^V[[; there
[00:49] <lifeless> meh, ^[[;
[00:49] <poolie> heh
[00:49] <poolie> are you controllable by ansi sequences?
[00:49] <lifeless> not anymore, I got upgraded
[00:50] <poolie> css? :)
[00:54] <lifeless> so - quick call or not ?
[00:54] <poolie> go on then
[01:03] <lifeless> thank god for noise cancelling headphones
[01:03] <lifeless> my house phone needs a mini-rca jack
[01:05] <Peng> Hmm, revctrl list? I'm in the channel, but it's almost dead.
[01:05] <Peng> What type of noise cancelling headphones?
[01:06] <Peng> Also, crapcrapcrap. I have a Python installation with no bzip2 support, and now bzr requires it.
[01:09] <poolie> Peng, on what kind of machine?
[01:09] <poolie> hm i wonder if we really need it or not?
[01:09] <poolie> Spads, so is that review ok?
[01:09] <poolie> i mean spiv
[01:10] <Peng> poolie: It's a Debian shared web host. They suck at Python (2.3.5 and 2.4.1 installed), so I've compiled 2.5.1 in my homedir, but it winds up without bzip2 (or readline) support.
[01:10] <Peng> Humm.
[01:11] <lifeless> Peng: 2.4.1 should work fine for bzr
[01:11] <lifeless> poolie: yes, we do - see the thread where I asked first :)
[01:11] <lifeless> Peng: actually bzr has required it for some time
[01:12] <mwhudson> Peng: i guess the bzip2 headers aren't on the host
[01:12] <lifeless> Peng: just now needs it in another area
[01:12] <spiv> poolie: yep
[01:12] <lifeless> Peng: Sennheiser 350's
[01:12] <lifeless> Peng: they make the construction going on upstairs nearly entire go away
[01:13] <spiv> lifeless: ooh, nice
[01:13] <Peng> mwhudson: Yeah, that's probably the case.
[01:14] <Peng> lifeless: Yeah, but I want 2.5. And even if bzr already used bzip2, I'd so far avoided that part of the code.
[01:15] <Peng> lifeless: That sounds good. I have a pair of Sonys that mostly make my loud computer fan tolerable . .
[01:19] <lifeless> Peng: what do you want 2.5 for ?
[01:23] <c1|freaky> hi all. umm, if i allready have set up a svn repository - should i use svn as repository? ... i just started reading the user guide ... well, if i dont use svn ...  is there any advantage or disadvantage?
[01:23] <lifeless> the best way to use bzr is bzr-all-the-way
[01:24] <Peng> lifeless: Just for stuff I screw around with, not bzr. Hmm, I could probably switch bzr to the system 2.4.
[01:24] <lifeless> the stuff about svn is because many users we get have been using svn and have a number of systems to migrate
[01:24] <lifeless> so its easiest for them to migrate incrementally
[01:24] <lifeless> and some users have to work with other folk that use svn, and who won't change, but our users still want to use bzr because its nice :)
[01:26] <c1|freaky> ok so, is it hard to migrate svn repos to bzr ones?
[01:27] <lifeless> not at all
[01:27] <lifeless> install bzr, bzr-svn and do a bzr svn-import
[01:28] <c1|freaky> do i need to install bzr on the server?
[01:28] <lifeless> it depends how you configure it - and that depends on what you want. Bzr can run over sftp which requires no special server side support, or over ssh which does want a copy of bzr on the server
[01:30] <c1|freaky> can bzr have its own authentication mechanism like with svn and http?
[01:31] <lifeless> bzr uses your authentication; you can have it be authenticated by apache, - if what you mean is 'does bzr have to use my passwd database' the answer is no.
[01:31] <lifeless> in fact someone has recently done a ssh server for bzr with its own auth, but I've not tested that myself.
[01:31] <c1|freaky> i dont want to give anyone shell access - sftp also uses ssh authentication
[01:32] <c1|freaky> PAM
[01:32] <c1|freaky> or whatever
[01:32] <c1|freaky> i need an own authentication mechanism for bzr repos
[01:32] <lifeless> sure, that ssh server I mention will do that
[01:32] <c1|freaky> maybe i should read the admin guide if there is any for bzr
[01:32] <lifeless> it doesn't use pam
[01:33] <lifeless> and you can do restricted ssh keys by the way - that prevents anyone having shell access (you can have /bin/false as the shell too for extra security)
[01:33] <lifeless> docs.bazaar-vcs.org IIRC
[01:35] <c1|freaky> ok thank you
[02:10] <c1|freaky> umm, does the trac-bazaar plugin work and is it as good as the subversion one?
[02:13] <lifeless> abentley: shaved about 100ms off of 5.5 seconds user time for indexes so far - using checkout ---lightweight of a treeless branch as my test
[02:14] <lifeless> abentley: still mainly refactoring to make it amenable to overhauling
[02:14] <lifeless> c1|freaky: sorry, I don't use trac, can't really comment
[02:14] <c1|freaky> ok bo
[02:14] <c1|freaky> ^^
[02:14] <c1|freaky> np
[02:15] <mwhudson> it seems bzr.dev push hasn't received the same love as bzr.dev pull yet?
[02:16]  * mwhudson watches revisions.kndx trickle upstream
[02:19] <spiv> mwhudson: not yet
[02:19] <spiv> mwhudson: although packs make it better
[02:20] <mwhudson> i'm sure
[02:20] <mwhudson> i guess i should convert my devpad repo over to packs
[02:21] <abentley> lifeless: Wow, I can't get such steady timings on that workload to see 100 ms go away.
[02:22] <abentley> Still, it sounds like movement, so that can't be bad.
[02:24] <Peng> Ha! I got it to work with Python 2.4 and virtual-python.
[02:28] <lifeless> abentley: the userspace timing is pretty consistent for me
[02:28] <lifeless> abentley: the wall clock is pretty jumpy
[02:28] <abentley> Ah.
[02:28] <lifeless> I found while optimising commit to just ignore wall clock
[02:28] <lifeless> and run it several times
[02:29] <lifeless> that or close everything down
[03:12] <pattern> i just did a "bzr add foo" and "bzr add bar", but changed my mind about adding these file before doing a commit
[03:12] <pattern> how can i tell bzr not to version these files after all ?
[03:12] <lifeless> bzr remove --keep
[03:13] <pattern> thank you
[03:13] <pattern> what about "bzr remove --new" ?
[03:14] <pattern> how is that different from --keep ?
[03:16] <poolie> remove --new automatically selects the files just added
[03:16] <poolie> so i think you want --keep --new
[03:17] <poolie> i'm going to look into the pqm failure i got the other day, merging some already-approved branches
[03:17] <lifeless> --new is not needed
[03:17] <poolie> if he names the files it's not needed
[03:17] <lifeless> unless you want bzr to scan
[03:18] <poolie> spiv, ping me when you've merged your thing, please
[03:18] <spiv> poolie: ok
[03:18] <poolie> lifeless, random comment
[03:19] <poolie> i find pqm is disruptive to my concentration because it makes me open my mail client, which is the mind-killer
[03:19] <poolie> i should probably procmail them into a special box and look at only that
[03:19] <lifeless> poolie: fear!
[03:19] <lifeless> poolie: but thats a good comment
[03:20] <lifeless> poolie: pqm should blog or something
[03:20] <poolie> yeah
[03:20] <lifeless> theres an open bug for showing recent results in the status page
[03:20]  * fullermd doesn't wanna let pqm pass thru him.
[03:20] <poolie> or even dump them in an indexed web directory
[03:20] <poolie> i realized this is more than half of my unhappiness about its asynchronicity
[03:20] <pattern> thanks for your help, guys
[03:21] <c1|freaky> after a few hours of reading i still dont know if i should switch to bzr from svn or not ... what do you say?
[03:21] <lifeless> switch
[03:22] <lifeless> you'll love it
[03:25] <rolly> just try it out, it's very easy to make the transition
[03:25] <c1|freaky> my only problem, at the moment is
[03:25] <abentley> c1|freaky: And you can go back if you want to.
[03:25] <c1|freaky> how can i have people to easily authenticate for submit
[03:25] <rolly> I hit that snag too. I use bzr+ssh://
[03:26] <c1|freaky> in a way without PAM authentication
[03:26] <c1|freaky> i dont want to give everyone shell access who should be able to access a repository
[03:26] <lifeless> c1|freaky: there was a post on the list a few days ago about a plugin that implements its own ssh server
[03:26] <lifeless> c1|freaky: *also* you can "Use PAM but not give everyone shell access"
[03:27] <rolly> there are myrisad ways to restrict ssh
[03:27] <c1|freaky> they'd still have ftp access and a home directory
[03:27] <c1|freaky> that sucks
[03:27] <rolly> *myriad
[03:27] <abentley> c1|freaky: Your system requires all users to have FTP access?
[03:27] <c1|freaky> no
[03:28] <rolly> http://tadek.pietraszek.org/blog/2006/10/18/restricted-shell-account-ssh-and-subversion/
[03:28] <rolly> adapt to bzr.
[03:28] <c1|freaky> thx
[03:29] <c1|freaky> im still not sure
[03:29] <c1|freaky> ill have a rest now
[03:29] <c1|freaky> and continue later
[03:30] <c1|freaky> 20 minutes or so
[03:38] <poolie> oh i see, having times in the trace log makes it a bit harder to test, foo
[03:41] <Aloha> Anyone know anything about Bug #189478?
[03:41] <ubotu> Launchpad bug 189478 in bzr "man page has errors when typing "man bzr"" [Undecided,New] https://launchpad.net/bugs/189478
[03:42] <johnny> c1|freaky, the issue is never between bzr and subversion.. bzr always beats subversion :)
[03:42] <c1|freaky> i installed bzr manually because the ubuntu version still is 1.0.0
[03:42] <johnny> its' between bzr,mercurial,git,and monotone
[03:42] <c1|freaky> with subversion i can do http authentication
[03:43] <c1|freaky> i want protected repositories where the user don't have ssh shells
[03:43] <c1|freaky> an own authentication system
[03:43] <johnny> the rest of svn won't make that worth it
[03:43] <johnny> monotone has it's own
[03:43] <johnny> based on public keys
[03:43] <johnny> git can use http iirc
[03:44] <bob2> on the downside, the openssh people are almost certainly better at writing authentication systems than anyone else
[03:45] <johnny> the new monotone uses ssh agent for local keys which is nice
[03:45]  * johnny doesn't like having system accounts either
[03:46] <Aloha> how do i merge a patch into parent branch?
[03:46] <c1|freaky> im using trac and i just want to provide some friends with repositories, and with the best possibilities
[03:47] <johnny> trac will always work best with subversion, cuz they designed it badly
[03:47] <johnny> it wasn't abstracted enough
[03:47] <johnny> so.. for 0.12 it should work nicer with distributed vcs
[03:47] <johnny> there is a bzr plugin
[03:47] <johnny> as well as git and mtn ones
[03:47] <bob2> Aloha: merge parent into your branch, then push to the parent
[03:47] <bob2> Aloha: or checkout parent, merge your branch into it, then push
[03:48] <Aloha> bob2, the patch is from someone else. how do i merge their patch?
[03:48] <bob2> Aloha: is it really a patch, or is it a bzr branch or bundle?
[03:49] <Aloha> bob2, its a bzr -o send patch
[03:50] <spiv> Aloha: "bzr merge patch", where patch is the file generated by "bzr send -o"
[03:50] <bob2> Aloha: "bzr merge patch_file"
[03:50] <Aloha> spiv, bob2, thnx
[03:50] <Aloha> so merge that into my branch and then push, yeah?
[03:51] <bob2> yup (don't forget to commit after merge)
[03:51] <spiv> Aloha: a merge is like any other change to your working tree, you need to commit it.
[03:51] <spiv> Aloha: but otherwise yes.
[03:52] <Aloha> bob2, doesn't bzr -o send create a patch based off of parent?
[03:52] <Aloha> so does that mean my local branch has to be synced with parent?
[03:53] <bob2> it has to be at or ahead of it, but you'd need that before you could push to it anyway
[03:53] <lifeless> Aloha: no it doesn't have to be synced
[03:53] <lifeless> Aloha: it uses the revision graph to generate a good diff
[03:54] <Aloha> lifeless, thats freaking cool
[03:54]  * Aloha loves bzr
[03:54] <bob2> lifeless: it'll automaticaly fetch needed revisions?
[03:55] <lifeless> bob2: if the other branch is ahead, there is nothing to fetch; if the other branch is behind the new revisions are in the local branch
[03:57] <c1|freaky> hey guys, ill migrate from svn to bzr but i need some help. i have a 3 svn repositories on my server. i now want to "convert" them to bzr. how to do that? (i have one of them checked out)
[03:58] <c1|freaky> (i just reinstalled kubuntu on my laptop that's why i dont have them all yet
[03:58] <johnny> read the docs
[03:58] <johnny> there's a migration section
[03:58] <c1|freaky> in which documentation?
[03:59] <johnny> onthe main site
[03:59] <johnny> for bazaar
[03:59] <c1|freaky> user guide?
[04:00] <johnny> no
[04:00] <johnny> it's right on the site
[04:00] <igc> http://bazaar-vcs.org/BzrMigration
[04:00] <rolly> does the pre-commit hook allow for modification of a versioned file, or addition of an unversioned file?
[04:00] <c1|freaky> oh ok found it
[04:00] <c1|freaky> :d
[04:00] <c1|freaky> thank you
[04:01] <igc> rolly: no, I don't think so
[04:01] <johnny> modifying versioned files [04:01] <johnny> BAD!!!!!!
[04:01] <rolly> haha
[04:01] <johnny> this isn't CVS
[04:01] <igc> rolly: we're looking at a start-commit hook for things like that
[04:01] <rolly> it's not ALWAYS bad
[04:01] <johnny> keywords will never be expanded
[04:01] <rolly> igc: that would be so awesome
[04:01] <rolly> it would make my dreams of versioning my database come true
[04:02] <igc> jelmer recently raised a bug on lp for that
[04:02]  * igc looks
[04:03] <lifeless> rolly: not currently; we will add one soon
[04:03]  * johnny tries to think of a way you could modify a versioned file that was already committed 
[04:03] <rolly> lifeless: cool! Yet one more step ahead of SVN
[04:03] <johnny> as that sounds like it would invalidate it
[04:04] <igc> bug 186422
[04:04] <ubotu> Launchpad bug 186422 in bzr "Ability to modify the tree from a pre-commit hook" [Wishlist,Triaged] https://launchpad.net/bugs/186422
[04:04] <johnny> oh.. pre commit would be fine, but you'd have to be super careful :)
[04:05] <johnny> i idled in #monotone in otfc for awhile, those guys were always talking versioning theory
[04:05] <johnny> pretty intense stuff
[04:05] <rolly> wait, so I _can_ modify with pre-commit?
[04:05]  * rolly reads
[04:05] <johnny> i never rode the svn train
[04:05] <johnny> i knew it was a lame idea
[04:06] <lifeless> johnny: you can't alter history
[04:06] <lifeless> johnny: but versioned file refers a file that is managed by bzr in general
[04:06] <lifeless> johnny: so altering a versioned file in a working tree is what you do with emacs/vim etc all day
[04:07] <rolly> Maybe I can get by with a little hack to bzr.bat
[04:09] <lifeless> about 150ms down stably now
[04:20] <c1|freaky> when i checked out the svn repositories to a local place ... now i'd have to create the bzr repos on the server, right? but before that, i need an authentication mechanism and i still dont know which i could use
[04:20] <c1|freaky> :((
[04:20] <c1|freaky> i dont want ssh or any other PAM authentication
[04:22] <fullermd> It sounds like an excellent solution to me.  I mean, that's the whole point of PAM...
[04:23] <c1|freaky> i dont want to give everyone ssh access
[04:23] <c1|freaky> :((
[04:23] <fullermd> You don't have to.  You can just give them bzr+ssh access.
[04:25] <c1|freaky> how to do that?
[04:25] <c1|freaky> and where should i create the repos? should i create a user called "bazaar"
[04:25] <c1|freaky> and in that directory create the repository
[04:25] <c1|freaky> for the different projects?
[04:25] <lifeless> 200ms now
[04:25] <lifeless> c1|freaky: I suggest you read the users guide and play with bzr *before* migrationg
[04:26] <lifeless> c1|freaky: start with it on your workstation and get a feel for how it works. This will help you a lot when you start thinking about group setups
[04:26] <c1|freaky> :(
[04:26] <c1|freaky> i have no project im starting right now i just want to migrate
[04:26] <c1|freaky> hmm
[04:26] <fullermd> You can use PAM to authenticate against a database or another file or something other than the system password file.  You can set allowable commands for the users via ssh.  They don't have to have home directories or real shells.
[04:27] <lifeless> c1|freaky: then just do 'bzr branch svn://urlhere local-disk-path'
[04:27] <lifeless> c1|freaky: and you'll have your existing projects to play with
[04:27] <c1|freaky> ok cool
[04:27] <c1|freaky> :D
[04:27] <c1|freaky> ill try that, thank you
[04:27] <lifeless> c1|freaky: I suggest that you learn the basic tool first because otherwise you are going to be learning new concepts in several directions all at once.
[04:28] <c1|freaky> i've allready read the whole user guide
[04:28] <lifeless> c1|freaky: and thats tough; we have much more facility than svn, but we *different* - you don't /need/ a "repository" for instance. (You can have one, but its not needed)
[04:28] <c1|freaky> ok ill remove my svn checkouts
[04:28] <c1|freaky> and use the bzr branch dirs then
[04:28] <c1|freaky> instead
[04:28] <c1|freaky> and later when i created the repos on the server
[04:29] <c1|freaky> ill use the bzr repos and commit them
[04:29] <lifeless> yes
[04:30] <lifeless> abentley: still around?
[04:30] <abentley> lifeless: Yup.
[04:30] <c1|freaky> Bazaar has encountered an internal error :\
[04:30] <abentley> ubotu: paste
[04:30] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[04:30] <c1|freaky> PROPFIND request failed
[04:31] <lifeless> abentley: total time for bzr.dev's lightweight checkouts - of that what fraction is index from memory?
[04:31] <lifeless> abentley: (I'm not using your branch yet)
[04:31] <lifeless> I've shaved 5% off basically at this point
[04:31] <c1|freaky> http://paste.ubuntu-nl.org/55055/
[04:31] <abentley> On my branch, it's 50%.
[04:31] <lifeless> c1|freaky: what url did you us ?
[04:31] <abentley> Total index.
[04:31] <lifeless> abentley: right, I'm asking bzr.dev :)
[04:31] <lifeless> abentley: IDK is fine
[04:32] <c1|freaky> i used: http://code-1.de/svn/freaky-tcl/
[04:32] <lifeless> c1|freaky: try svn+http://
[04:32] <c1|freaky> k
[04:32] <lifeless> c1|freaky: I hear that that may work better
[04:32] <lifeless> failing that, jelmer ^^
[04:32] <abentley> lifeless: I use dev as my sample data :-)
[04:33] <lifeless> abentley: yes, but bzr.dev's _code_
[04:33] <c1|freaky> lifeless: still the same
[04:33] <lifeless> c1|freaky: do you have write access to the branch?
[04:33] <lifeless> c1|freaky: if so what url do you use ?
[04:33] <c1|freaky> i use http://code-1.de/svn/freaky-tcl/ i _have_ write access but it doesnt ask for login information? oO
[04:33] <c1|freaky> still anyone can read
[04:33] <lifeless> oh interesting
[04:34] <abentley> I understood,  was explaining my dumbness.
[04:34] <c1|freaky> so i dont really need login information
[04:34] <lifeless> abentley: ok, I don't understand and am confused :)
[04:34] <lifeless> c1|freaky: its not that, I was hoping for a different url. We'll need some help from the bzr-svn author at this point I think
[04:34] <spiv> c1|freaky: that SVN repo has many projects in it.
[04:34] <abentley> dev spends 53.43% in bisect_multi_bytes.
[04:34] <lifeless> abentley: thanks
[04:35] <c1|freaky> spiv: i just put them all together as one projects - my tcl scripts
[04:35] <c1|freaky> -s
[04:35] <lifeless> c1|freaky: https://answers.edge.launchpad.net/bzr-svn
[04:35] <lifeless> I suggest asking a question there, and looking in the bug tracker too
[04:35] <abentley> (The percentages are similar for dev and my code because I also eliminated some lookups)
[04:35] <abentley> At least, I assumed so.
[04:36] <abentley> If it's cached, maybe there's another reason.
[04:36] <spiv> c1|freaky: hmm, so there's no trunk/ or branches/ or tags/?  Just one branch at the root of the repo?
[04:36] <c1|freaky> spiv: yea
[04:36] <lifeless> abentley: if bzr.dev spends agreater fraction in the index layer, its more efficient at the other things
[04:36] <c1|freaky> it's just TCL
[04:36] <lifeless> abentley: unless the extra index use is disproportionately slow
[04:36] <lifeless> abentley: anyhow, my problem for now, and I guess 10% improvement in that region
[04:37] <lifeless> if I assume 2.5 seconds in index, I'm down to 2.3
[04:40] <abentley> The percentage bisect_multi_bytes for my branch is 50.76, I think.  Getting some contradictory output.
[04:41] <abentley> Iter_entries time for dev is 57%, for mine, 51%.
[04:42] <abentley> But recall that I'm batching my index queries.
[04:42] <abentley> So that may help on the initial bisect.
[04:46] <lifeless> batched queries are a huge win
[04:48] <lifeless> I want! http://awaregeek.com/funny-stuff/usb-panic-button/
[05:20] <abentley> lifeless: Would there be a performance win if indexes calculated build-dependencies all in one go?
[05:21] <lifeless> abentley: possibly; its been my intent to put some tasteful graph query support into the index layer
[05:22] <poolie> jml, my car is going to be ready in a bit, so i'll walk up and get it
[05:22] <c1|freaky> i got another question: say 2 people want to code ona  project together, and they want to use a server, do you have to create a user account for every project your users make together, in addition to their normal user accounts just for the projects - because they both need access to the repository which can only be on a account on the server to which they both have access
[05:22] <lifeless> the only possible win though is slightly fewer round trips in extreme cases
[05:22] <poolie> you're welcome to stay here
[05:22] <c1|freaky> or can u do that using groups?
[05:23] <lifeless> abentley: we could in fact choose to not resolve references to merges but only to the actual trees.
[05:23] <lifeless> needs this refactoring finished and tweaked further I think.
[05:24] <lifeless> abentley: what would be a good result - (key, selected_reference, value) in an iterator?
[05:25] <c1|freaky> and
[05:25] <c1|freaky> how can i fix this: Unable to load 'bzr-gtk-0.93.0' in '/home/uwe/.bazaar/plugins' as a plugin because file path isn't a valid module name; try renaming it to 'bzr_gtk_0_93_0'.
[05:25] <spiv> Wow, PQM is taking an hour and a half to run tests for a single merge.
[05:26] <abentley> Possibly.  Is selected_reference for accelerating future queries?
[05:26] <spiv> c1|freaky: do what it says: rename the bzr-gtk-0.93.0 directory in plugins so that it doesn't have dots or hyphens.
[05:28] <c1|freaky> i removed it
[05:28] <c1|freaky> i installed it as root
[05:28] <c1|freaky> did that in the wrong direcotry
[05:28] <c1|freaky> thank you
[05:29] <c1|freaky> and where do i install that PQM thingy? on the server? what does it compile? do i have to create testing-config files i mean, how to compile programs etc. or are there default ones which just work?
[05:29] <c1|freaky> that's all so much work for a private thing
[05:29] <c1|freaky> but i want something neat for coders on my server
[05:29] <lifeless> c1|freaky: in fact you should name that directory 'gtk' :)
[05:30] <mtaylor> c1|freaky: I use group permissions for shared repos on my server
[05:30] <mtaylor> works great
[05:30] <c1|freaky> mtaylor: and where do you put the directories for the shared repos?
[05:30] <fullermd> Blasphemously enough, I've got some in /home/cvs/bzr/[...]
[05:31] <mtaylor> c1|freaky:  I made a /var/lib/bzr
[05:31] <mtaylor> c1|freaky: then every time I add a new repository,  I go there and do chgrp -R src repos_name
[05:31] <mtaylor> and then chmod -R g+s repos_name
[05:31] <c1|freaky> ok, so i can put several projects on there, one repository (/var/lib/bzr) and in there the different projects on which different users could work on. and for every project i would have to create a group on the system
[05:31] <mtaylor> and then I never think about it again
[05:32] <mtaylor> c1|freaky: I make a new repos for each unrelated project myself
[05:33] <mtaylor> c1|freaky: and if you really wanted to restrict access to project to a different set of people, then yeah, each one would want its own group
[05:35] <mtaylor> any chance that "InvalidRevisionNumber: Invalid revision number 5946" means something other than what it says?
[05:36] <c1|freaky> ok
[05:36] <c1|freaky> now i need to create a repo on the server
[05:37] <c1|freaky> how do you do that? do you first create the repo on the server itself?
[05:37] <bob2> yes, the same as you would with svnadmin
[05:37] <mtaylor> c1|freaky: you can do it multiple ways, but I usually just go to /var/lib/bzr and do bzr init-repo --no-trees repo_name
[05:38] <spiv> poolie: at this rate, PQM should have merged my fix at about 6pm.
[05:38] <c1|freaky> what does no-trees do btw, i didnt udnerstand it yet
[05:38] <poolie> spiv, +1 my pqm speedup patch then :)
[05:39] <bob2> c1|freaky: doesn't include a checkout-out copy of the source code in the repository
[05:40] <lifeless> poolie: I've got about 10% so far
[05:40] <c1|freaky> mtaylor: and when that repo is created, how to you put content on it?
[05:40] <lifeless> poolie: I'm calling it a day at this point
[05:40] <lifeless> poolie: I should have the refactoring finished tomorrow
[05:41] <mtaylor> c1|freaky: then you can just push a branch there from somewhere eles.
[05:41] <c1|freaky> i have a branch on my pc
[05:41] <lifeless> abentley: its my index.range_map if you want to give it a whirl
[05:41] <mtaylor> c1|freaky: so if you do cd /var/lib/bzr ; bzr init-repo --no-trees foo on your server
[05:41] <spiv> Hmm, SyPy tonight.
[05:41] <c1|freaky> but the server cant access my pc
[05:41] <mtaylor> c1|freaky: doesn't need to
[05:41] <abentley> lifeless: Where?
[05:41] <mtaylor> c1|freaky: go to your pc, and go into your branch
[05:42] <mtaylor> c1|freaky: and do bzr push bzr+ssh://yoursever/var/lib/bzr/foo/branch_name
[05:42] <lifeless> abentley: https://code.launchpad.net/~lifeless/bzr/index.range_map
[05:42] <lifeless> abentley: since I fixed register_branch I register them all :)
[05:42] <lifeless> abentley: alternatively, because 6 hour mirroring is bog
[05:42] <lifeless> *bong*
[05:42] <lifeless> you'll want the external url http://people.ubuntu.com/~robertc/baz2.0/index.range_map
[05:42] <c1|freaky> push is always like svn commit right?
[05:42] <lifeless> c1|freaky: no, commit is like commit
[05:43] <c1|freaky> but if im not bound to the repo
[05:43] <c1|freaky> i can do commit and it wont commit to the server?
[05:43] <mtaylor> c1|freaky: right.
[05:43] <abentley> Oh, do I have one of those?
[05:43] <c1|freaky> so what is push then?
[05:43] <lifeless> mtaylor: except for history pivots
[05:43] <lifeless> abentley: try logging into rookery
[05:44] <mtaylor> c1|freaky: push is how publish your local commits to your shared branch
[05:44] <lifeless> c1|freaky: push is used to mirror your local work to a remote repository
[05:44] <lifeless> c1|freaky: mtaylor: the difference between commit and push is this: commit preserves the mainline history *always*, push does not.
[05:45] <mtaylor> yes
[05:45] <abentley> lifeless, yep.
[05:45] <lifeless> abentley: then yes, yes you do
[05:45]  * lifeless waves
[05:46] <c1|freaky> ok ... i dont know what a mainline history is exactly. that's more like, the final part of the program after the rivisions from the branches have been put together?
[05:47] <c1|freaky> SHIT!!!!
[05:47] <c1|freaky> one moment need to revert a backup
[05:47] <c1|freaky> oh no i dont have a backup of that directory
[05:47] <c1|freaky> one moment
[05:47] <abentley> lifeless: Merging your index stuff, I get 4.9 seconds.
[05:50] <abentley> lifeless: no significant difference in the lsprof data for iter_entries
[05:56] <lifeless> abentley: what did you get before? 4.9 still ?
[05:56] <abentley> Roughly.
[05:56] <lifeless> yeah
[05:56] <lifeless> well at least I haven't borked it
[05:56] <lifeless> I'll finish the refactoring up and then get into serious tuning
[05:58] <abentley> best of 4, mine: 4.7.  Best of 4, yours: 4.8
[05:58] <abentley> that is yours+mine
[05:59] <c1|freaky> i can't get that push to work it tells me:
[05:59] <c1|freaky> ValueError: I/O operation on closed file
[05:59] <c1|freaky> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[06:03] <rolly> Is there an easy way to "squash" a series of revisions into just one? The use case is that I've a bunch of little revisions that make up a single feature.
[06:04] <c1|freaky> it works
[06:04] <c1|freaky> forgot the write permissions
[06:21] <mtaylor> rolly: I've got a plugin for that
[06:21] <mtaylor> rolly: I haven't gotten around to releasing it yet... :)
[06:21] <rolly> :O
[06:21] <bob2> that's basically what merge does
[06:22] <mtaylor> right, but the use case here is that you want to collapse into one revision before pushing
[06:22] <rolly> exactly
[06:23] <rolly> I could always merge, then uncommit, then pull. But screw that :p
[06:23] <mtaylor> right
[06:23] <rolly> plus, sometimes you want to squash even if you're not pushing anything
[06:24] <mtaylor> yup
[06:24] <mtaylor> I should add squash as an alias. I like that
[06:24] <bob2> hm, do you want to lose the individual revisions entirely or just contain them within one "implement all of FOO" one?
[06:24] <rolly> mtaylor: stole it from the git-rebase docs
[06:24] <mtaylor> hehe
[06:25] <rolly> mtaylor: does your plugin operate on ranges?
[06:25] <mtaylor> yeah
[06:25] <mtaylor> (I think... lemme double check - but I'm pretty sure it does)
[06:25] <rolly> even if one of the ranges isn't the tip of the branch?
[06:25] <rolly> that would be so sweet
[06:26] <mtaylor> hm... now _that_ I don't think I've got
[06:26] <mtaylor> because it's essentially using uncommit
[06:26] <mtaylor> under the covers
[06:26] <rolly> Gotcha :)
[06:26] <rolly> that's still really useful. I hope you release it someday
[06:27] <mtaylor> thanks for reminding me.
[06:27] <mtaylor> we're using it at work... I just haven't gotten around to bundling it up sensibly
[06:28] <c1|freaky> is anyone using the bzr plugin for trac?
[06:29] <mtaylor> nope.
[06:29]  * mtaylor uses launchpad for everything
[06:30] <Debolaz> Apples and oranges. :)
[06:30] <mtaylor> of course
[06:31] <Debolaz> That being said, I stay far away from trac usually.
[06:31] <mtaylor> ah... I dunno... oranges and tangerines perhaps
[06:31] <rolly> I set trac up once, it was quite laborious
[06:31] <Debolaz> It's not that it's bad, it just doesn't seem to fit anything I do. It either does too much or too little.
[06:32] <Debolaz> For a small project, I don't want to go through all the trouble of setting up trac, but for a larger project its features just aren't enough.
[06:34] <c1|freaky> rolly: yea u need to experiment a lot but in the end i got it set up and running: http://scm.code-1.de
[06:39] <c1|freaky> is the publish bot put on the server or on the client?
[06:49] <Peng> Uh-oh.
[06:49] <Peng> Unable to delete pending-deletion.
[06:50] <Peng> Ah, NFS garbage file.
[06:52] <Peng> Gah, limbo too.
[06:52] <Peng> Except, limbo is empty.
[06:52] <Peng> Ok, third try's the charm.
[07:06] <spiv> poolie: I was right, it landed at 6pm, almost exactly :)
[07:16] <c1|freaky> what is a good pqm bot?
[07:19] <c1|freaky> what is bazaar-ng?
[07:19] <Peng> Huh, a pack repo will autopack even if it just spews a "these branches have diverged" error (at least over bzr+ssh).
[07:19] <Peng> c1|freaky: Bazaar.
[07:20] <Peng> c1|freaky: Bazaar (baz) was originally a fork of Arch. Then they invented Bazaar-NG (bzr), a whole new VCS. Later, Bazaar was renamed to Baz and Bazaar-NG was renamed to just Bazaar.
[07:20] <Peng> c1|freaky: So, now they're interchangeable.
[07:20] <c1|freaky> oh ok, thank you :)
[07:21] <rolly> ng = next generation?
[07:21] <Peng> Probably.
[07:21] <rolly> where no repo has gone before
[07:22] <fullermd> No, totally not like that.  In this case the NG version is _better_ than the original.
[07:22] <rolly> No one said it's not, unless I'm missing something
[07:23] <fullermd> Well, you started in with the Trek references...
[07:23] <rolly> Ahhh...
[07:24] <rolly> haha.
[08:35] <ubotu> New bug: #189841 in trac-bzr "plugin doesn't load?" [Undecided,New] https://launchpad.net/bugs/189841
[08:41] <c1|freaky> :D that was me :o)
[08:42] <mtaylor> so the collapse thing I was talking about earlier...
[08:43] <mtaylor> should I submit that to bzr.dev as a new builtin? or perhaps bzrtools? it seems sort of small to be its own plugin...
[08:44] <lifeless> mtaylor: what sort of collapse thing?
[08:44] <rolly> I would like to see it as a plugin mysql
[08:44] <fullermd> Would it make sense to roll it in as part of rebase?
[08:44] <rolly> *myself
[08:44] <lifeless> Peng: it's done a fetch of data in that scenario where it autopacks
[08:44] <mtaylor> fullermd: ah, perhaps...
[08:45] <rolly> are you talking about the 'squash' thing?
[08:45] <mtaylor> lifeless: it's a command that essentially does an uncommit all the way back to the last thing you've pushed
[08:45] <mtaylor> yeah
[08:45] <fullermd> Just because it's crammed in that package in git doesn't necessarily mean it should be here, but when you're collapsing the middle of a range, you'd have to rebase the later stuff anyway...
[08:45] <mtaylor> collapse/squash
[08:45] <lifeless> mtaylor: so you do this when you know noone will look at your branch? :)
[08:46] <lifeless> mtaylor: (merging past that -> pain)
[08:46] <mtaylor> lifeless: yeah - it more like to clean up the thing you're going to send, to get rid of the 12 revisions you did that were all "fixed small typo" and "crap, fixed another small typo"
[08:47] <mtaylor> lifeless: I don't personally use it all that much, but it seems that it's a life-or-death thing for the folks who are in to it
[08:47]  * mtaylor knows he's gonna have to write a test for it if he sends it to bzr.dev though... :)
[08:48] <johnny> who uses that?
[08:48] <johnny> what system supports bringing revs together like that?
[08:48] <rolly> I guess your code could be useful in rebase, if --interactive is ever implemented
[08:48] <mtaylor> bk
[08:48] <johnny> aha.. bk
[08:49] <johnny> but only the kernel and mysql folks use that :)
[08:49] <mtaylor> hehe
[08:49] <johnny> we were the 3rd biggest user
[08:49] <johnny> but nobody ever did that
[08:49] <johnny> before we switched to monotone
[08:49] <mtaylor> johnny: who's we?
[08:49] <johnny> xaraya
[08:50] <johnny> web app framework/cms thingie
[08:50] <mtaylor> the bk folks I know (really large bk user that I'm trying not to name atm) use it alot
[08:50] <mtaylor> mainly so that they can bundle up a set of things that are logically one change and re-submit them for a sensible code review
[08:50] <mtaylor> I think things like bundlebuggy already handle this problem from a different perspective though
[08:51] <mtaylor> given that I can submit a merge again and it'll effectively collapse it in the display
[08:52] <mtaylor> hrm. yeah. I don't really want to submit it to bzr.dev
[08:53] <spiv> mtaylor: right, getting a useful diff for code review is a completely orthogonal issue
[08:53] <mtaylor> yup
[08:53] <spiv> mtaylor: you don't need to throw away history for that :)
[08:53] <johnny> i use monotone for that, but trying to use bzr for a seperate project
[08:55] <lostylost> is bzr very well tested on windows machines?
[08:58] <spiv> Yeah, it we have quite a few people actively testing on windows.
[08:58] <spiv> More testing never hurts, of course ;)
[08:59] <lostylost> I keep getting errors commiting to a remote repo, that works fine on four other osx, linux boxes
[08:59] <lostylost> it just stalls out half way through at the status bar point
[08:59] <lostylost> before that I was having some wierd, pending-deletion errors
[09:00] <ubotu> New bug: #189845 in bzr "hg-import:  ImportError: No module named hgimport.importer" [Undecided,New] https://launchpad.net/bugs/189845
[09:01] <spiv> lostylost: hmm, that's no good.  Please file bugs.
[09:02] <spiv> lostylost: you're welcome to pastebin the errors and talk about them here too, of course.
[09:02] <lostylost> yeah, one of the other guys did re: the pending-deletion errors
[09:02] <spiv> (Unfortunately I'm about to have dinner, so I can't be much help right now)
[09:02] <lostylost> spiv, Thanks.    I think I will come back some time, I am starting to getcranky
[09:02] <lostylost> enjoy your dinner
[09:03] <spiv> lostylost: thanks.  Put all the relevant details somewhere (ideally a bug report, probably), and someone should be able to help you with it.
[09:03]  * spiv -> gone
[09:10] <ubotu> New bug: #189848 in bzr "hg plugin crashes" [Undecided,New] https://launchpad.net/bugs/189848
[09:17] <lostylost> would it be unwize in the extreme to use cygwin bzr along with native windows bzr at the same time?
[09:17] <lostylost> it *shouldnt* matter but would it?
[09:18] <johnny> if you can make it error that way, i'm sure folks would be interested :)
[09:19] <johnny> why does cygwin bzr exist anyways?
[09:20] <lostylost> I am not sure, some people just like an integrated environment and don't want to leave cygwin/bash. I can't see the advantage
[09:21] <lostylost> It's weird native bzr keeps stalling out on a commit so I am trying cygwin bzr. It says that I have changed every file in the branch though...
[09:21] <lostylost> very od
[09:22] <c1|freaky> what pqm are u using with bzr?
[09:22] <lostylost> what do you mean pqm sorry?
[09:22] <lostylost> if you are addressing me
[09:24] <c1|freaky> i mean everyone
[09:24] <c1|freaky> i mean that thing which tries to compiles commits etc. and then puts it into the mainline
[09:25] <spiv> c1|freaky: we use https://launchpad.net/pqm for committing to bzr.dev
[09:29] <c1|freaky> thx
[09:30] <c1|freaky> do u always ude dots for branches?
[09:30] <c1|freaky> *use
[09:30] <johnny> i prolly would.. but that's an old habit
[09:30] <c1|freaky> should i install that pqm as root?
[09:30] <johnny> org.xaraya.core.stable
[09:30] <c1|freaky> ok ill remember that
[09:30] <johnny> for example
[09:32] <fullermd> Darn mtn'ers   :P
[09:32] <speakman> hi ppl...
[09:35] <speakman> I currently got the same file under "removed:" and "added:" under "bzr status". How come?
[09:35] <Odd_Bloke> speakman: Is it in the same location?
[09:36] <speakman> Fixed it by making a copy of "new" file and then removed it and did a revert from last revision. And finally 'cat' new contents into the "old" file and then it was printed under "modified:" instead.
[09:36] <speakman> exactly the same location.
[09:36] <speakman> identical path
[09:36] <spiv> speakman: those are different files to bzr
[09:37] <speakman> how come? what's the "identifier" for bzr then, if it isn't filename?
[09:37] <spiv> speakman: note also that you do "bzr revert FILe"
[09:37] <spiv> speakman: file-id
[09:38] <spiv> speakman: there's a hidden command, "bzr file-id FILE" if you're interested.
[09:38] <spiv> So that bzr can track renames.
[09:38]  * spiv -> dinner
[09:38] <speakman> I did need to do a revert. Actually, the "strange" file was made out of a copy from a backup file with a 'cp', so there sure are some good explainations.
[09:40] <speakman> how these strange "hosts" on ppl? ubuntu/not/ubotu and such?
[09:40] <speakman> (O/T, sorry)
[09:41] <Odd_Bloke> ubotu is a bot, which does helpful things (such as linking to the pages of bugs, and keeping people updated as to new bugs).
[09:42] <c1|freaky> ok i still don't understand how to use a pqm
[09:52] <c1|freaky> how do i install the bazaar smart server?
[09:55] <c1|freaky> that bazaar quickstartcard is cool i just printed it :D
[09:57] <speakman> c1|freaky: use inetd
[09:57] <speakman> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#inetd
[09:59] <lifeless> speakman: the strange hosts are an IRC feature
[09:59] <lifeless> for registered users
[09:59] <speakman> oh, i see
[09:59] <speakman> thanks
[10:00] <c1|freaky> damn why can't we download the launchpad software :(
[10:00] <Odd_Bloke> c1|freaky: Because it's not Free Software.
[10:00] <Odd_Bloke> Even if you could, you wouldn't really want to, I suspect.
[10:00] <c1|freaky> that's a pitty
[10:00] <c1|freaky> :D
[10:01] <c1|freaky> speakman: thank you
[10:04] <Peng> I've read that the reason Launchpad is closed-source is because the point of it is to bring projects together (like how you can link bugs from one project to another), so having multiple LPs isn't so useful.
[10:04] <Peng> s/isn't so useful/counterproductive/
[10:09] <Odd_Bloke> That's what I've heard.
[10:10] <Odd_Bloke> The intent is also, I believe, to Free it once there's a mechanism to share between multiple Launchpad instances, so that problem can be overcome.
[11:00] <joabr> Does any bzr plugin have something similar to this -> http://en.wikipedia.org/wiki/Image:Hgk.png ?
[11:01] <joabr> graph ancestry does some similar graphing, but not the textual extra info.
[11:02] <joabr> i'm trying to sell bazaar to my boss :-)
[11:04] <Odd_Bloke> joabr: Look at bzr-gtk.
[11:09] <Kinnison> yep, bzr-gtk has 'bzr visualise'
[11:09] <Kinnison> which does exactly that
[11:11] <Odd_Bloke> QBzr might also have something, though I've never used it myself.
[11:12] <joabr> ah, ok. Thanks alot.
[11:17] <ubotu> New bug: #189874 in bzr "hg-import Can parse file names with spaces" [Undecided,New] https://launchpad.net/bugs/189874
[11:22] <lifeless> joabr: bzr viz; in fact gitview is based on bzr-gtk's visualise
[11:25] <joabr> lifeless: sweet
[11:35] <ubotu> New bug: #189886 in trac-bzr "Tracebacks when viewing log of a specified range of changesets" [Undecided,New] https://launchpad.net/bugs/189886
[12:09] <elmo> so, i know you bzr guys like to argue about this
[12:09] <elmo> if I have two runs of a script: old machine takes 95 minutes, new one takes 56 minutes
[12:10] <elmo> is that 1.7x faster and 40% faster? or how do you do that 'n times faster / n% faster' math?
[12:18] <jblack> 1 - 56/95 = 41.1% faster
[12:29] <elmo> jblack: thanks
[12:34] <jelmer> c1|freaky: don't use the 0.4 branch but use the released version of bzr-svn
[12:36] <dato> jelmer: is that general advice?
[12:39] <c1|freaky> jelmer: i soon wont need it anymore. ill just checkout, delete the .svn dirs and put it under bzrs vc :D
[12:39] <c1|freaky> as soon as i get the trac-bzr plugin to work
[12:40] <c1|freaky> i printed out the bazaar quick start card
[12:40] <c1|freaky> really nice useful thing
[12:51] <joabr>  do bzr have a svn equivalent to 'svn log --stop-on-copy'?
[12:56] <mtaylor> joabr: what does stop-on-copy do?
[12:57] <ddaa> it does not traverse copies
[12:57] <ddaa> such as branch points or renames
[12:57] <ddaa> bzr does not have explicit branch points
[12:58] <ddaa> it _could_ stop logs on renames, but it's not clear that's what joabr wants
[12:58] <ddaa> and I do not believe the feature is implemented already
[13:00] <joabr> ddaa: the idea is to see revisions only for a given branch.
[13:01] <ddaa> I'm afraid this request is a bit ill defined in bzr, you'll need to frame your problem a bit differently.
[13:01] <ddaa> One way to look at bzr is that every commit is a branch point.
[13:02] <ddaa> I could use my hard won skills at divining user desires to wrangle it out of you, but I do not really feel like it today.
[13:03] <ddaa> for example, you could say "exclude from the log every revision that is in the ancestry of that other branch, defaulting to the parent"
[13:03] <ddaa> which might do what you want
[13:03] <joabr> okay, how?
[13:05] <ddaa> a common approximation for what you seem to request is something like "bzr log last:1..ancestor:../other-branch"
[13:06] <ddaa> "bzr help revisionspec" for help
[13:07] <ddaa> you might also want to use "bzr missing"
[13:08] <ddaa> that's usually enough to make bzr folks happy
[13:11] <joabr> i'll take a look. Thanks for the info so far :-)
[13:26] <jelmer> dato: not really
[13:27] <jelmer> dato: There is a regression in the http support in the 0.4 branch at the moment that causes exceptions
[13:27] <jelmer> however, this is not caught by the testsuite at the moment (since that would require setting up apache, etc)
[13:30] <badrunner> Hi all, im having problems trying to push to an https branch, i get an " ERROR: Cannot lock LockDir ..etc" message
[13:31] <badrunner> I also just get "Bazaar has encountered an internal error" when doing a pull or merge, but branch works fine
[13:35] <luks> you can't push over http(s)
[13:38] <badrunner> luks: ok, what are people doing for having multiple users commit access to the same repository? I cant seem to find any info on this, i keep windind up at the shared-repository page, which means something different
[13:38] <badrunner> luks: oh, and this is without the ability to add system users, so thats why i was hoping https with a .htpasswd would work here for me
[13:38] <luks> badrunner: you can use any writable method with multiple users
[13:38] <luks> but HTTP is not writable
[13:39] <badrunner> is there a list of methods anywhere?
[13:39] <luks> you could setup the smart server over HTTP and use the web server to limit access
[13:40] <luks> and then use bzr+http:// instead of http://
[13:40] <badrunner> luks: that sounds like a good plan, i'll look into that thanks
[13:41] <mtaylor> bzr+http works?
[13:41] <mtaylor> crazy
[13:50] <elmo> the bzr 1.1 PPA dapper source packages are broken - are they the official source of things these days - and if, so should I file a bug about it?
[13:54] <Lunkwill> hi, I'm currently in the process of testing bzr - I've converted an SVN repository with several branches into bzr, using svn2bzr
[13:56] <Lunkwill> I'm trying to merge one of these branches onto the main development branch (trunk)
[13:57] <Lunkwill> on this branch, though, there are about 3 merge revisions, which contain the contents of several changesets taken from the trunk
[13:58] <Lunkwill> of course that won't register properly in the bzr history
[13:59] <Lunkwill> what is the best strategy to merge this branch with trunk, excluding those few merge-revisions that came from the subversion trunk?
[14:01] <ubotu> New bug: #189915 in bzr "bzr 1.1 dapper PPA debs FTBFS" [Undecided,New] https://launchpad.net/bugs/189915
[14:05] <Lunkwill> I've gotten the contents of the two branches merged properly by performing three merge operations, the first one starting from the branches' common ancestor.  the bzr history will only reflect the first merge as two branches merging, the two other merge operations appears as two single revisions
[14:11] <Lunkwill> anyone know how to hack this so the branch revisions will look like they've been properly merged with the trunk, or do I have to live with this history problem because of our subversion heritage?  any answers will be greatly appreciated :)
[14:12] <Lunkwill> k, I'll shut up now ;)
[14:19] <LeoNerd> "merge" makes a single revision that contains all the composite changes
[14:19] <LeoNerd> If you want to see them all as individual commits, you have a problem. History diverged. It is no longer a single stream timeline
[14:19] <LeoNerd> You can't just "merge" those divergant streams and have it appear as a single consistent historic timeline
[14:21] <LeoNerd> What you could do, if you were so inclined, would be to "rebase" the branch to the current head-of-trunk, then "pull" all the trunk revisions in, making them appear as new commits. But this can only work if the rebase operation succeeds; i.e. if there's no conflicts anywhere
[14:32] <Lunkwill> LeoNerd: how about merging the subversion merge revisions, and "resolve" the conflicts by reverting all the changes in that revision, then commit?
[15:07] <fbond> Hi, I think bzr is doing something weird with timestamps that is messing up an autotools build setup... does that sound familiar?
[17:11] <tallo> Anyone tried using the svn plugin on osx?  I need to use http basic auth, which seems to be broken, yet I don't see any bugs open for it...
[17:12] <tallo> i.e. the two perl lines removing auth in http://bazaar-vcs.org/BzrForeignBranches/Subversion
[17:13] <tallo> or is this https://bugs.launchpad.net/subversion/+bug/71266 ?
[17:13] <ubotu> Launchpad bug 71266 in subversion "Problems getting things to work on Mac OS X" [Undecided,New]
[17:14] <muszek> hi... what do you guys use to be notified about revisions made to branches on remote servers?
[17:15] <jelmer> tallo: Are you running 1.5?
[17:16] <tallo> should be, having followed the directions on the page (locally installed in ~/.bazaar/svn)
[17:16] <tallo> actually looks more like 1.6.0...
[17:17] <jelmer> tallo: Subversion 1.5, I mean
[17:17] <tallo> yup
[17:17] <tallo> ~/.bazaar/svn/bin/svn --version returns 1.6.0
[17:18] <tallo> craps out with "Assertion failed: (g->gc.gc_refs != _PyGC_REFS_UNTRACKED), function instancemethod_dealloc, file Objects/classobject.c, line 2285." at the console
[17:19] <tallo> OSX 10.5.1, intel core2duo iMac...
[17:19] <jelmer> tallo: Those two lines you commented out disable password prompting
[17:20] <tallo> I should clarify: when I comment out those two lines, bzr just fails to access the svn repo. :)
[17:20] <jelmer> sorry, that's what I mean
[17:20] <tallo> But that's working-as-written
[17:20] <tallo> When I leave them be, that's when things crash :)
[17:21] <jelmer> those two lines hook in the password prompting
[17:21] <tallo> which I need :(
[17:21] <jelmer> apparently them crashing is a bug in the python subversion bindings
[17:23] <jelmer> there's an alternative way to authenticate though, see the FAQ for details
[17:24] <tallo> Yup, it's fairly obvious from the stack trace.  Hehe, even found a message from Brian de Alwis to you, with a (nearly?) identical trace
[17:25] <tallo> Hm.  Tried "svn info <url>", it doesn't prompt and properly returns data.
[17:26] <tallo> Tried "bzr branch svn+<url> mybranch", and it fails with Permission denied
[17:31] <jelmer> It may be some OS-X specific thing
[17:31] <tallo> Sounds like it, from Brian's post.
[17:32] <jelmer> Can you try adding the following line:
[17:33] <jelmer> svn.client.get_keychain_simple_provider(pool),
[17:33] <jelmer> in transport.py:54
[17:35] <tallo> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'get_keychain_simple_provider'
[17:35] <tallo> perhaps I've got an older python-svn module?
[17:36] <jelmer> this function is MacOSX-specific
[17:36] <jelmer> there probably just isn't a python binding for it (yet)
[17:36] <tallo> ah
[17:37] <tallo> and yeah, I see the entries in Keychain that it would use
[17:37] <jelmer> are you on Mac OS X 10.2 or later?
[17:37] <tallo> 10.5.1
[17:42] <jelmer> hmm, I don't actually see anything that could cause it to not generate python bindings for that function
[17:43] <tallo> :(
[17:45] <jelmer> maybe it's the ifdefs in the header file that confuse it
[17:46] <jelmer> I can add the required bits to bzr-svn, but I can't figure out how to fix the python-subversion bits
[17:46] <jelmer> since I don't have Mac OS X here
[17:47] <tallo> hm
[17:47] <tallo> Can you point me to the general location where it should be generated?
[17:48] <jelmer> subversion/bindings/swig in the subversion source
[17:51] <tallo> ok, thanks so much!
[17:51] <jelmer> it's probably a matter of specifying -DDARWIN= or something to SWIG
[17:52] <tallo> heh
[17:59] <jelmer> the required bits should now be in bzr-svn
[18:00] <tallo> cool, thanks :)
[18:03] <abentley> fbond: Are you checking in built files?
[18:04] <fbond> abentley: yes; I've traced my problem to an unrelated cause...
[18:04] <abentley> Okay, nm.
[18:04] <fbond> although I have seen the recent thread on the ML
[18:04] <fbond> (that may also be an issue for me .... )
[18:05] <abentley> Okay.  So you know your built file may end up newer than its source.
[18:05] <fbond> Yes.
[18:05] <abentley> or older
[18:05] <fbond> Right...
[18:05] <abentley> Cool.
[18:05] <fbond> Will that be addressed soon?
[18:12] <abentley> fbond: Hard to say.  I'm rather busy in RL, but that area is usually left to me.
[18:25] <bobbo> What is the bazaar equivalent of ViewVC?
[18:26] <mwhudson> loggerhead
[18:27] <bobbo> thanks mwhudson
[18:28] <mwhudson> this branch is the most up-to-date: https://code.edge.launchpad.net/~mwhudson/loggerhead/production
[18:30] <bobbo> mwhudson: what dependencies do i need for loggerhead?
[18:30] <mwhudson> bobbo: turbogears
[18:30] <mwhudson> (unfortunately :/)
[18:32]  * abentley sticks his tongue out at mwhudson
[18:34] <mwhudson> abentley: it causes more problems than it solves for loggerhead, it's the wrong tool for the job
[18:50] <fbond> mwhudson: (my curiosity) what would've been the right tool for the job?
[18:53] <mwhudson> fbond: good question, but something that didn't use cherrypy as it's http layer would be a good start
[18:55] <fbond> mwhudson: don't mean to pry, but I'm wondering why?
[18:55] <fbond> I've never used cherrypy
[18:55] <fbond> (also didn't mean to rhyme there ;)
[18:58] <skvidal> fbond: do the rest in iambic pentameter
[18:58] <skvidal> I was wondering if there was an easy way of going from bzr log > changelog-format
[18:58] <skvidal> ?
[18:58] <skvidal> sorry, hit enter too soon, there
[18:59] <mwhudson> fbond: maybe it's just the way loggerhead uses it, but it has some annoying features
[19:00] <mwhudson> (totally unhelpful behaviour if there's an exception during url traversal, completely un-workaroundable url mangling)
[19:05] <fbond> mwhudson: so you just don't like cherrypy in general?  None of this sounds remarkably loggerhead-specific...
[19:07] <mwhudson> fbond: from what i've read cherrypy3 is quite nice
[19:07] <mwhudson> fbond: but no, i don't like cherrypy2, and that's what loggerhead is stuck with
[19:07] <fbond> mwhudson: interesting.  thanks!
[19:10] <fbond> mwhudson: have you used Django at all?
[19:10] <mwhudson> fbond: no
[19:10] <c1|freaky> is anyone using trac with bzr?
[19:11] <mwhudson> fbond: but the real complaint about loggerhead using tg is that it's just not helpful
[19:11] <mwhudson> loggerhead isn't a database-backed webapp in any sense
[19:11] <thatch> c1|freaky: yeah, do you have a question about it?
[19:11] <mwhudson> it and on-demand generated bunch of static web pages in some sense
[19:13] <fbond> mwhudson: but CherryPy is just an HTTP framework, and loggerhead uses HTTP, right?
[19:14] <fbond> mwhudson: I guess you think it's just not worth the overhead?
[19:14] <c1|freaky> thatch: yea, are u using it with trac11b1?
[19:14] <c1|freaky> thatch: look here: https://bugs.launchpad.net/trac-bzr/+bug/189841
[19:14] <ubotu> Launchpad bug 189841 in trac-bzr "plugin doesn't load?" [Undecided,New]
[19:15] <c1|freaky> i submitted that bug
[19:15] <c1|freaky> did you have the same problem am i missing some step?
[19:15] <thatch> c1|freaky: actually still on r6306... but yes I got that problem initially
[19:15] <c1|freaky> and how did you fix it?
[19:16] <thatch> c1|freaky: let's continue in pm, it's not directly bzr related
[19:16] <c1|freaky> ok :)
[19:18] <aadis> is there a way to send an automated mail on a bzr push?
[19:18] <aadis> ie, server-side from the host being pushed to
[19:31] <ubotu> New bug: #64658 in trac-bzr "[PATCH] Use trac to_unicode function when passing the revision message to trac" [High,Fix released] https://launchpad.net/bugs/64658
[19:58] <nessy> I am trying to install bzr 1.0 or 1.1 on a Mac OS X 10.4 (Tiger) machine
[19:58] <nessy> is there a package?
[19:58] <nessy> http://bazaar-vcs.org/Download?highlight=%28Mac%29%7C%281.0%29%7C%28OS%29%7C%2810.4%29%7C%28X%29%7C%28bzr%29 only lists ppc
[19:59] <nessy> and my bzr-py25 in fink lists as 0.18-1
[20:00] <nessy> I don't have MacPorts installed - get along well with finnk
[20:03] <nessy> is my only option to install from src ?
[20:03] <aadis> nessy: installing from source is pretty simple as it is
[20:05] <nessy> am in the middle of it - but still wondered if there was a more adequate release :)
[20:13] <nessy> hmm - need to instally pycrypto and paramiko and make sure my default python is 2.5 :(
[20:13] <nessy> might as well upgrade to leopard!
[20:18] <tallo> nessy: according to the first line of http://bazaar-vcs.org/BzrForeignBranches/Subversion (which I've been working from)
[20:18] <tallo> sudo easy_install -U paramiko pycrypto bzr
[20:18] <tallo> claims that it should work for tiger and leopard
[20:18] <tallo> except some stuff about xcode 2.5 and libtool...
[20:19] <nessy> easy_install : command not found :)
[20:19] <nessy> I don't have xcode
[20:19] <tallo> ouch
[20:20] <tallo> Oh, heh
[20:20] <nessy> but they were simple to install from src
[20:20] <nessy> just running test on paramiko
[20:20]  * tallo is happy on leopard
[20:21] <nessy> yeah - I should upgrade...
[20:21] <tallo> just having issues with bzr-svn :)
[20:21] <nessy> oh! :(
[20:21] <tallo> The upgrade was a pain on my macmini server box, as I'd forgotten how I'd configured it. :)
[20:21] <nessy> I just have a macbook
[20:21] <tallo> the leopard installer did a bunch of bad stuff, like overwrite crotab :(
[20:22] <nessy> that's what backups are for :)
[20:22] <tallo> thankfully there was only 1 cron line :)
[20:22] <tallo> didn't nuke any "user data", just made exim and apache unhappy
[20:22] <nessy> if you remembered your crontab, that's ok :)
[20:22] <tallo> again, mostly because I forgot what I'd done a year before to configure it in the first place
[20:23] <nessy> hmm... the paramiko test hangs after Ran 100 tests in 110.393s
[20:23] <nessy> OK
[20:23] <nessy> strange...
[20:29] <nessy> looks like it worked:
[20:29] <nessy>  bzr --version
[20:29] <nessy> Bazaar (bzr) 1.1.0
[20:29] <nessy> :0
[20:41] <thatch> For future reference, the issue with trac+bzr and 'unsupported version control system' under mod_python just required a complete stop/start of Apache to work.
[20:43] <lifeless> cool
[20:43] <lifeless> how are you going thatch ?
[20:47] <thatch> lifeless: I'm doing pretty ok.
[20:47] <thatch> Just got over some sort of cold
[20:48] <thatch> and school is keeping me occupied enough that I'm happy writing code
[20:52] <lifeless> :)
[21:35] <turnip> Hi guys, I'm new to bzr and dvcs in general. I think I'm fundamentally misunderstanding something... if I do "bzr branch someurl", I get a load of files. They have to exist somewhere, right? But if I do "bzr push someurl", it doesn't transfer the files, just the changes. So how do the files get to the remote server?
[21:36] <lifeless> turnip: the files are your working copy
[21:36] <lifeless> turnip: we don't copy around the working copy itself, because thats slow, we only copy the historical database
[21:37] <lifeless> if someone else whats what you've committed they can just bzr branch the thing you pushed
[21:38] <turnip> lifeless: surely then they have to have access to my machine?
[21:38] <lifeless> huh?
[21:39] <turnip> to get the files I've committed, they would need to be able to transfer them from my machine somehow
[21:39] <turnip> because they aren't on the remove server
[21:39] <lifeless> when you push to a remote server
[21:39] <lifeless> the historical data base is pushed
[21:39] <lifeless> it contains the information to recreate a working copy
[21:39] <turnip> aaah right
[21:39] <lifeless> have you used svn ?
[21:39] <turnip> yeah
[21:40] <lifeless> right - an svn server doesn't have your files in an editable form
[21:40] <lifeless> it just has a databse
[21:40] <lifeless> called a repository
[21:40] <turnip> yeah, I think I understand now
[21:40] <lifeless> but the svn client can ask the repository for enough information to create a working copy
[21:41] <turnip> yep it makes much more sense now. I wasn't thinking in terms of repositories because of the whole distributed thing
[21:42] <turnip> so what I want to use this for is a personal website. I basically want to make commits on my local machine, and then every now and then update the web server with the changes
[21:42] <turnip> given that the web server can't connect to my machine, but I can connect to the web server
[21:42] <turnip> does it make sense to push the changes to the server, and then have a branch on the server which is a working copy... ?
[21:49] <rolly> turnip: that's how I have it.
[21:49] <turnip> ok great thanks for your help guys
[21:49] <rolly> I use the push-and-update plugin
[21:49] <lifeless> turnip: sure; on the web server have a working copy and do 'bzr update' there
[21:50] <lifeless> turnip: the push and update plugin will use that to do an update for you when you push
[21:50] <turnip> ok thanks I'll check it out
[22:02] <xif> hey, I was wondering:
[22:03] <xif> at the time bzr was developed, why didn't Canonical just use the available Mercurial tool?
[22:06] <lifeless> hg did not exist when bzr was started
[22:30] <ubotu> New bug: #190052 in bzr "bzr commit on a split tree crashes" [Undecided,New] https://launchpad.net/bugs/190052
[22:32] <LarstiQ> oh boy
[22:33] <lifeless> LarstiQ: dude!
[22:33] <lifeless> its alive!
[22:34] <LarstiQ> I seem to be getting alive again, this much is true.
[22:34]  * LarstiQ has even been reading code today
[22:34] <fullermd> Shucks.  I had the high voltage all ready, too...
[22:35] <LarstiQ> granted, not bzr, but still
[22:35] <beuno> LarstiQ, python at least?
[22:35] <LarstiQ> beuno: yes
[22:36] <LarstiQ> bug 190052 looks like something I'd need to look at
[22:36] <ubotu> Launchpad bug 190052 in bzr "bzr commit on a split tree crashes" [Undecided,New] https://launchpad.net/bugs/190052
[22:36] <lifeless> xif: also, even if hg had existed, they have sufficiently problematic limitations I doubt we would have gone with it.
[22:37]  * beuno starts preparing for the "welcome back LarstiQ" party
[22:37] <lifeless> thats in London right ?
[22:37] <LarstiQ> is that a suggestion I should attend?
[22:38] <LarstiQ> wouldn't do to miss my own party
[22:39] <lifeless> LarstiQ: naturally
[22:39] <LarstiQ> k
[22:45] <tallo> jelmer: So, I'm guessing this has to do with swig not having the full environment when extracting function defs
[22:46] <tallo> There are some #defines for keychain support; when I hardcode them to #if 1, I get some bits of keychain_simple_provider in the wrapper
[22:46] <tallo> not enough, yet
[22:59] <igc> morning
[23:03] <Odd_Bloke> Why is it that ConfigObj is kept in bzr.dev?