[00:37] <poolie> spiv, hi
[00:37] <poolie> approved
[00:37] <spiv> Thanks1
[00:42] <thumper> poolie: which project was it using reviews?
[00:42] <poolie> stevea's project
[00:54] <jml> ok. so how exactly should I do this again (switching the order of a pair of adjacent threads)
[00:55] <thumper> a quick question about bzr send
[00:55] <thumper> if using `bzr send --mailto foo@example.com` and thunderbird
[00:55] <thumper> does the attachment get added for others?
[00:55] <thumper> I'm trying to debug a weirdness
[00:57] <poolie> how do you mean 'for others'?
[00:58]  * jml walks away to think about the problem.
[00:58] <poolie> jml, i don't know
[00:59] <jml> poolie: behold, I show you a mystery
[01:09] <spiv> jml: edit your .bzr/branch/last-loom file? ;)
[01:09] <poolie> spiv, i'm reading john's pack-names patch
[01:10] <spiv> jml: More reasonably, pull --overwrite probably gives you the hammer you need.
[01:13] <jml> spiv: hmm. maybe. there are a bunch of merges that I need to work around.
[01:13] <jml> spiv: I'll have a play, anyway.
[01:14] <spiv> jml: ah, so it's more fundamentally that you need cherrypicking, rather than the ordering of the loom threads?
[01:14] <jml> spiv: yeah, probably.
[01:32]  * jml does uncommit and shelve shenanigans
[01:34] <poolie> spiv, ok, i'm going to send up john's patch, what next?
[01:37] <jml> and look, there's a criss-cross merge. what a shock.
[01:38] <spiv> poolie: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081117065938.GA18818%40steerpike.home.puzzling.org%3E perhaps?
[01:39] <poolie> yeah
[01:39] <poolie> there are some nontrivial conflicts, i'm just working through them
[01:39] <poolie> so you're both pretty confident in that interdiffing one
[01:40] <spiv> Yeah.
[01:41] <spiv> Oh, I should land my already approved improvement item_keys_introduced_by's signatures calculation.
[01:41]  * spiv does that
[01:42] <spiv> Not sure why I didn't notice that sooner, I guess the rapidly shrinking list of things in bundle buggy made it more obvious :)
[01:42] <james_w> poolie: "either 1.6 (from hardy)" <- did you mean Intrepid?
[01:42] <poolie> i did
=== jamesh_ is now known as jamesh
[02:32] <spiv> poolie: I'm going to land the interdifferingserializer improvement (I'm confident and the bb:comments were essentially positive), and then I think I'm out of changes for 1.10
[02:32] <poolie> ok
[02:32] <poolie> i've just finished resolving the pack-names thing
[02:32] <poolie> i'm going to send that up, then have lunch, then roll 1.10rc1
[02:32] <spiv> Woo
[02:38] <mwhudson> poolie: getting anywhere on that bug of mine?
[03:03] <poolie> mwhudson: tbh not yet, we're trying to finish off work that's already queued and to get a release out
[03:03] <mwhudson> ok
[03:03] <poolie> but after that, it's top of the list
[03:04] <poolie> i'm not totally sure this is the right approach but things have gone for us when we try to fix just one more bug before releasing
[03:20] <poolie> spiv, mine merged, when yours does i'll start packaging
[03:23] <spiv> poolie: cool.  I'm off to lunch to now.
[03:30] <mwhudson> huh, i managed to push https://code.edge.launchpad.net/~mwhudson/launchpad/manual-stacking-on-launchpad-branches-bug-272372 via devpad
[03:31] <mwhudson> which has bzr 1.9
[03:31] <poolie> so are you saying your bug may be to do with the server code?
[03:32] <mwhudson> no
[03:32] <mwhudson> i pushed locally with bzr 1.9 --> boom
[03:32] <mwhudson> i pushed to devpad, then from devpad i seem to be able to push with bzr 1.7
[05:20] <spiv> poolie: how's the releasing going?
[05:24] <poolie> hey
[05:24] <poolie> i'm uploading bzr-svn, and working out how it uses bzr builddeb
[05:24] <poolie> did your things all land?
[05:25] <spiv> Apparently so!  http://bundlebuggy.aaronbentley.com/?selected=pending&unreviewed=n is almost unrecogniseably shorter :)
[05:26] <toytoy> hi guys, i was doing 'bzr uncommit' then did bzr commit, then in the other pc, i did bzr update, but I see that the last log that was part of the 'bzr uncommit' became a pendig merges. is that normal? or I want to remove that pending merges since that's no use
[05:28] <poolie> assuming you don't want to keep that uncommitted revision, you should revert the other checkout
[05:28] <spiv> toytoy: that's an interesting case.  I think that is probably a bug, although not a surprising one.  You can clear pending merges with "bzr revert --forget-merges".
[05:44] <poolie> This release of Bazaar focusses on performance improvements when pushing
[05:44] <poolie> and pulling revisions, both locally and to remote networks.  The popular
[05:44] <poolie> ``shelve`` and ``unshelve`` commands, used to interactively revert and
[05:44] <poolie> restore work in progress, have been merged from bzrtools into the bzr
[05:44] <poolie> core.  There are also bug fixes for portability, and for stacked branches.
[05:44] <poolie> how's that
[05:46] <spiv> Sounds good, although shelve/unshelve was rewritten rather than merely merged.
[05:46] <spiv> I'm not sure the distinction matters for that text, though.
[05:46] <poolie> to use internal merge, rather than patch and diff?
[05:46] <spiv> Yeah.
[06:16] <spiv> poolie: I'm off to SLUG.  I'll have a play with the rc1 when I get home tonight :)
=== poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.10rc1 released 28 Nov | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
[06:16] <poolie> spiv, ok, cheerio - btw (i should have reminded you earlier) i have a holiday on monday again
[06:16] <poolie> but john and robert will be back
[06:18] <spiv> poolie: I'll be on leave (OSDC that week), but pretty easy to contact.
[06:21] <poolie> ah, right
[06:21] <poolie> hm, maybe i should move it
[06:21] <poolie> have a fun conference anyhow
[06:21] <poolie> and btw it's great how many things you landed into 1.10, and that insert_r_s is coming along
[07:22] <vila> hi all
[07:44] <robin_dewd> ls
[07:57] <GPHemsley> Is there any way for me to merge the history of two branches that don't share a common ancestor within Bazaar, though they do share a common ancestor file-wise?
[07:58] <GPHemsley> fullermd: Would you happen to be around?
[08:11] <GPHemsley> poolie: You still around?
[08:18] <jamesh> GPHemsley: you can merge the two branches in a way that will give you the files from both branches
[08:19] <jamesh> GPHemsley: but it won't merge contents of files from the two branches
[08:19] <jamesh> "bzr merge -r 0.. otherbranch" should do it
[08:19] <GPHemsley> hmm...
[08:20] <jamesh> as the branches don't share history, it has no way of knowing that two files with the same name should be merged (you'll get a naming conflict), let alone how to merge the contents
[08:21] <GPHemsley> hmm
[08:23] <GPHemsley> darn
[08:29] <AfC> Haven't actually done it, but if you  `bzr add --file-ids-from` the files into the new branch, then do the merge, it might work?
[08:30] <GPHemsley> It's alright
[08:30] <GPHemsley> it's not that important
[08:30] <GPHemsley> but thanks
=== doko__ is now known as doko
[08:48] <GPHemsley> jamesh, AfC: What's the proper syntax for `bzr init-repo` via SFTP?
[08:51] <GPHemsley> nevermind, got it
[08:57] <GPHemsley> jamesh, AfC: Whats the difference between `bzr init ; bzr pull` and `bzr branch`?
[09:00] <maco> is it safe to install bzr 1.6 in ubuntu 8.04?
[09:00] <maco> im not sure if i should ask that in an ubuntu place or here
[09:00] <maco> i just dont know if it'd be unhappy with library versions or something
[09:12] <poolie> maco: yes, it's fine
[09:12] <GPHemsley> poolie: What is rich root?
[09:12] <poolie> you can get a package from launchpad.net/~bzr/+archive
[09:12] <maco> poolie: ok, thank you
[09:12] <poolie> GPHemsley: it's a series of alternate repo formats that support primarily svn interoperation
[09:13] <GPHemsley> Is that their only benefit?
[09:13] <poolie> just about
[09:13] <GPHemsley> ok
[09:16] <jamesh> GPHemsley: the only real difference between init+pull and branch is the format of the resulting branch: the first will use bzr's default format, while the second will use the format of the source branch
[09:33] <maco> jamesh: ooo i was wondering that
[10:49] <spiv> poolie: yeah, it's very satisfying watching stuff land :)
[11:32] <abeaumont> is it possible to set commands configuration in a configuration file or similar? e.g: i'd like to use --line switch in bzr log by default
[11:32] <abeaumont> configuration topic in help does't talk about such possibilities...
[11:43] <spiv> abeaumont: yes
[11:43] <spiv> abeaumont: create an alias
[12:25] <abeaumont> thanks spiv
[12:28] <abeaumont> much better than what i had in mind :D
=== asac_ is now known as asac
[13:27] <CaMason_> What's the best way to set up a SFTP user that will point to /srv/bzr/myrepo ?
[13:33] <rocky> jelmer: which  version of bzr-svn should i be using for bzr-1.10rc1 ? :)
[13:34] <jelmer> rocky, nothing yet - 1.10 breaks API compatibility for 0.4.15 but I hope to release 0.5.0 at some point before 1.10
[13:35] <rocky> jelmer: don't suppose it's safe to use a branch of bzr-svn then?
[13:35] <jelmer> well, it won't corrupt your repository or anything but some operations may give tracebacks
[13:36]  * rocky reluctantly sticks with bzr 1.9 for the time being... :)
[13:38] <CaMason_> hi guys. I've had a project under bzr control just from bzr init. Now, I've just set up a SFTP connection, and I'd like to make my current repo a central repo on the SFTP server
[13:38] <CaMason_> how do I go about doing this?
[13:41] <jelmer> CaMason_, bzr push the branch to the sftp server
[13:42] <jelmer> after that, you should be able to "bzr checkout" it
[13:42] <CaMason_> jelmer: thanks, I'm just reading that bit now
[13:42]  * rocky loves that every bzr repo can be used as-is by merely hooking up network access to it for someone else
[13:42] <rocky> i don't think svn was like that right?
[13:43] <CaMason_> rocky: nope
[13:43] <CaMason_> you know, I think I can use a folder under both SVN and .bzr control..
[13:44] <CaMason_> i.e. my local project has a single folder that I want to put on a SVN server elsewhere (for others). If I ignore the .svn files with bzr, it shoudln't cause any conflicts, if I think correctly?
[13:45] <rocky> CaMason_: you can probably do something a little slicker with bzr-svn, but jelmer would be the one to poke for that ;)
[13:52] <CaMason_> I think I've pushed my current repo to a central location. However, the file sizes are different
[13:53] <CaMason_> the central repo seems to be about 500kb big, but my local one is about 700kb
[13:54] <KangOl> hi
[13:54] <CaMason_> well, I managed to checkout the central branch. so..
[13:54] <CaMason_> I assume everything is ok!
[13:55] <beuno> CaMason_, bzr optimizes repos, so I wouldn't be surprised
[13:57] <KangOl> why doing a merge between 2 branches without common ancestor with cherrypicking doesn't keep the history ?
[13:58] <CaMason_> and it seems I've bound my working copy to the central repo now. This is brilliant :)
[14:00] <CaMason_> and I can unbind.. brillian. I can now work on the train offline :D
[14:01] <beuno> yes, the magic of bzr
[14:02] <CaMason_> I have to say, compared to SVN, the setup process has been very painless
[14:03] <beuno> CaMason_, blog about it!  the world needs to know!  ;)
[14:03] <CaMason_> I will as soon as I get my blog up
[14:14] <KangOl> someone can explain me this behavior ?
[14:14] <KangOl> ~$> bzr clone -q <urlA> A
[14:14] <KangOl> ~$> bzr clone -q <urlB> B
[14:14] <KangOl> ~$> cd A
[14:14] <KangOl> A$> bzr merge ../B/
[14:14] <KangOl> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
[14:14] <KangOl> A$> bzr merge -q -r 0..-1 ../B/
[14:14] <KangOl> A$> bzr st | grep pending
[14:14] <KangOl> pending merges:
[14:14] <KangOl> A$> bzr revert -q
[14:14] <KangOl> A$> bzr merge -q -r 0..-1 ../B/somedir/
[14:14] <KangOl> A$> bzr st | grep pending
[14:14] <KangOl> A$>
[14:28] <uws> jelmer: bzr-svn seems to think subtrees of my svn checkout are are in different svn repos
[14:28] <uws> jelmer: refusing   'bzr commit dir1/somefile dir2/somefile'
[14:28] <uws> jelmer: note that this is a svn checkout, not a bzr-svn checkout
[14:50] <jelmer> uws, what's the exact error?
[14:51] <uws> ERROR: dir1/dir/somefile is not in the same branch as dir22/dir/someotherfile
[14:51] <uws> jelmer: ^
[14:51] <uws> jelmer: "bzr root" in dir2/dir gives dir2/, instead of 2 levels up)
[15:01] <jelmer> uws: Ah, that's actually correct. It's fixed in 0.5, you can workaround it in 0.4 by explicitly setting a branching scheme and setting it to be mandatory
[15:03] <uws> jelmer: how?
[15:07] <uws> jelmer: what value should I use for  bzr svn-branching-scheme --set svn+ssh://.... ?
[15:07] <uws> jelmer: repo layout is  /project/{trunk,branches/tags}
[15:07] <uws> jelmer: my svn checkout is from  /project/trunk/
[15:18] <jelmer> uws, that should be trunk1 (in ~/.bazaar/subversion.conf)
[15:26] <rotty> hmm, I've a strange problem when using bzr+ssh:
[15:26] <rotty> nathot:~/src/spe/systems% bzr branch sftp://delenn/home/rotty/src/spe/systems/xitomatl
[15:26] <rotty> rotty@delenn's password:
[15:26] <rotty> bzr: ERROR: Not a branch: "/home/rotty/src/xitomatl/
[15:26] <rotty> (erm, that's with sftp, but bzr+ssh yields the same error)
[15:27] <rotty> (note the difference between the path names specified on the command line, and in the error message)
[15:27] <rotty> (also, when doing the same on delenn, using 'localhost' as hostname, it works without a flaw)
[15:45] <rotty> arghl! bzr stores the absolute directory inside .bzr/branch/location -- so if you move the dir, this info becomes bogus.
[15:46] <rotty> I think storing locations globally in ~/.bazaar/locations.conf and inside ~/.bzr is a real misfeature
[15:46] <Odd_Bloke> rotty: What version of bzr are you using?
[15:46] <rotty> 1.5
[15:46] <Odd_Bloke> Weird.
[15:46] <Odd_Bloke> I'm not seeing a ~/.bzr/branch/location...
[15:47] <rotty> in the repo: /path/to/repo/.bzr/branch/location
[15:47] <Odd_Bloke> Sorry, I didn't mean to put the ~ there.
[15:47] <Odd_Bloke> My fingers betrayed me.
[15:47] <Odd_Bloke> I'm not seeing one in my branches.
[15:47] <rotty> i've been bitten by stuff like that on several occassions -- no other dvcs I've used has problems when you move repos around
[15:48] <Odd_Bloke> rotty: Are you talking about repositories or branches?
[15:48] <rotty> Odd_Bloke: aren't those the same in bzr?
[15:48] <Odd_Bloke> rotty: No.
[15:49] <Odd_Bloke> A repository is Just a Bunch Of Revisions.  A branch is a pointer to one of those revisions (which in turn point to their parents and so on, giving you history).
[15:52] <Odd_Bloke> rotty: Often, the repository and the branch will be in the same location, but not necessarily.
[15:52] <Odd_Bloke> For example, when using shared repositories.
[16:00] <rotty> I just have repos and branches that share location
[16:02] <rotty> (btw, removing that .bzr/branch/location file makes the branch not work anymore)
[16:04] <rotty> (and trying to correct it also doesn't work)
[16:07] <Odd_Bloke> rotty: I'm afraid I'm not sure what's going on.
[16:07] <Odd_Bloke> Perhaps a ML post would be in order.
[16:11] <rotty> well, running "bzr branch" locally, and using the newly created branch instead, worked
[16:20] <Odd_Bloke> rotty: Yeah, that's the recommended way of doing it.
[16:21] <Odd_Bloke> Sorry, it should have occurred to me to mention that. >.<
[16:23] <beuno> vila, going to be working on improving log performance?
[16:23] <beuno> you become my instant personal god if you are
[16:23] <vila> beuno :-)
[16:24] <vila> I have a problem with log, but not only a performance problem, so I'm reviewing the related bugs, tagging them along the way
[16:25] <vila> But out of curiosity, what is your use case (there are several ways log performance can be improved)
[16:25] <beuno> vila, loggerhead
[16:25] <beuno> so bzr log -v  ;)
[16:26] <vila> log -v is quite a big hammer, you use it without limiting the revision range ?
[16:27] <beuno> vila, no, I do limit it
[16:27] <beuno> it's the only remaining thing we *have* to cache in loggerhead
[16:27] <beuno> the changed files per revision
[16:30] <vila> beuno: can't you use tree.iter_changes directly ?
[16:30] <beuno> vila, IIRC, the problem is that we have to get all the files changed for a revision in mainline, with all it's sub-revisions
[16:31] <beuno> for 20 (mainline) revisions at a time
[16:31] <beuno> on a big tree (20k revs), you think using inter_changes would be fast to get that info?
[16:31] <beuno> I don
[16:31] <beuno> I don't remember atm how we get that information
[16:34] <vila> beuno: oh, your context is a bit too complicated to be definitive :-/ (Except that iter_changes will only give you the delta between two arbitrary revisions and I don't think that address your "for 20 (mainline) revisions at a time"
[16:35] <vila> Do you need (or use) the revnos ? That can make a difference, and if you use them, you'd better *not* call log -v multiple times
[16:35] <beuno> vila, right, I need it per mainline revision
[16:36] <beuno> I only use revnos for the mainline, so it's fine
[16:36] <beuno> vila, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/changes
[16:36] <beuno> that's the page
[16:36] <beuno> all the information you see there is what we need to get
[16:37] <beuno> and, if you're interested in peaking at the file: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/247?file_id=history.py-20061211064342-102iqirsciyvgtcf-5
[16:38] <beuno> vila, maybe it's _get_deltas_for_revisions_with_trees?
[16:39] <beuno> it says "This is copied from bzrlib.", but I suspect that comment is from the 1980's
[16:39] <beuno> (sept 2007, actually)
[16:41] <vila> beuno: right, you don't use log -v :-) You use bzrlib :)
[16:41] <beuno> right
[16:41] <beuno> but I'm hoping that improvements to one will trickle down
[16:41] <beuno> :)
[16:41] <beuno> wishful thinking?
[16:42] <vila> No, you're right. But my remark about revnos doesn't apply then.
[16:43] <vila> and changes_from calls iter_changes 2 levels down :)
[16:44] <beuno> right
[16:44] <beuno> so, "I'm screwed"
=== thekorn_ is now known as thekorn
[16:45] <vila> beuno: nooo, just be patient ;-)
[16:45]  * beuno hugs vila and goes back to the launchpad bug sprint
[16:45] <beuno> will I see you at UDS?
[16:46] <vila> beuno: no
[16:46] <beuno> ay...
[16:46] <beuno> we need a bzr sprint soon then!
[16:48] <Kobaz> sprinting eh
[16:48] <Kobaz> what do you guys use for tracking your scrums
[16:48] <beuno> always!
[16:54] <Kobaz> we use scrumworks
[16:54] <beuno> we use... wikis and drawings?
[16:54] <Kobaz> ah
[17:34] <Glenjamin> hey guys, i'm looking at setting up a smart server, and i'm hoping to get some sort of authenticating system where various branches can be read-only, private or public
[17:34] <Glenjamin> is there any existing wsgi sorta thing i can just drop in?
[17:35] <Glenjamin> ie: something a bit like lp, where if you push to ~user/project/branch, it knows what to do
=== NfNitLoo` is now known as NfNitLoop
[18:25] <tristil> Does anyone use nested trees? I've had trouble getting a straight answer googling around, so I'm guessing no.
[18:28] <Kobaz> i like little forests
[18:29] <beuno> tristil, bzr doesn't support nested trees yet
[18:30] <beuno> LarstiQ is the mastermind behind it
[18:30] <beuno> but hasn't finished yet
[18:33] <tristil> Kobaz, I thought I liked subtrees but nested trees appears to be the best I can get.
[18:33] <tristil> beuno, Thanks the various references on the web and the different formats are confusing.
[18:35] <tristil> So people use configmanager instead for composite projects?
[18:37] <Kobaz> i dont even know what i want yet
[18:37] <Kobaz> so far i've got
[18:38] <Kobaz> projectcontainer/project/repo/trunk
[18:42] <tristil> Kobaz, but what's in projectcontainer? Is it a bzr repo/branch?
[18:42] <Kobaz> it's just a directory
[18:42] <Kobaz> like, a second order grouping of projects
[18:42] <Kobaz> like
[18:42] <Kobaz> web/mainwebsite/core/trunk
[18:43] <Kobaz> web/mainwebsite/modules/trunk
[18:43] <Kobaz> web/internal/core/trunk
[18:45] <tristil> Oh, well, what I really want is just svn:externals. I guess I can just keep adding, removing and exporting my subprojects.
[18:45] <Kobaz> aww, there's no externals in bzr?
[18:45] <tristil> That's what I thought nested trees were.
[18:46] <tristil> Of course, in Rails/Ruby they use a tool called piston to check in the externals anyway.
[18:47] <tristil> So you can freeze at a revision.
[18:50] <Kobaz> ah
=== fta_ is now known as fta
=== Mario_ is now known as pygi
[20:12] <Kobaz> dustybin: lvextend is a safe operation
[20:12] <Kobaz> er
=== tchan1 is now known as tchan
[20:24] <dudus> is there a way to make nautilus integration work under ubuntu?
[20:25] <jelmer> dudus, the bzr-gtk ubuntu package is b0rked
[20:25] <jelmer> there's an open bug about it
[20:25] <dudus> yeah I just subscribed to it
[20:26] <dudus> jelmer: I think it may be solved on debian
[20:27] <dudus> I think It's broken since gutsy
[20:28] <jelmer> Yes, it is solved in Debian
[20:28] <jelmer> dudus, nautilus-bzr was not enabled in gutsy intentionally iirc
[20:29] <dudus> jelmer: why?
[20:29] <jelmer> dudus, it slowed down nautilus too much
[20:30] <dudus> ahn the good old synchronous programming
[20:31] <jelmer> nautilus-bzr isn't any better now, but we added a button to allow users to disable it
[20:31] <jelmer> the main problem is that the nautilus extension API is just too poor
[20:33] <dudus> jelmer: nice
[21:49] <LeoNerd> I'd like to split apart the files in a branch, into two branches. There's no particular logic to which goes where, other than my judgement... I could just branch it twice, then delete half the files in each side, and go on from there.. but is there a nicer way?
[22:07] <lifeless> LeoNerd: what you described is appropriate
[22:11] <LeoNerd> I've also seen 'bzr split'.. not sure about that
[22:21] <jelmer> LeoNerd, that splits out a specific directory, so would require you to move all of the files for one of the branches into a directory first
[22:21] <LeoNerd> Ahh... Hrm.. I suppose I could do that
[22:21] <jelmer> LeoNerd, and the result is similar to what you described
[22:22] <LeoNerd> Ohright
[22:48] <LeoNerd> OK.. So.. I've now created my two new branches on my server, each with their respective halves of the files... How to "close" the original branch, disallow further commits?
[22:58] <jelmer> chmod?
[22:58] <LeoNerd> Ooh. that'd work
[23:39] <lifeless> LeoNerd: or rm
[23:40] <lifeless> LeoNerd: but someone can always branch from the old branch and do commits; fortunately bzr will merge happily into both new branches