[00:15] <poolie> lifeless: can tribunal already handle subunit?
[00:19]  * poolie just branches lp:tribunal
[00:19] <lifeless> tribunal runs a python test suite
[00:19] <lifeless> if that uses a SubProcessTestSuite, its transparent to tribunal
[00:19] <lifeless> igc: how are those reviews going
[00:20] <igc> starting now
[00:20] <igc> (been reading the threads with abentley's and spiv's comments)
[00:21] <lifeless> the one I pointed you at is much simpler
[00:21] <lifeless> *ones*
[00:51] <ubotu> New bug: #208039 in bzrtools (main) "Feature Freeze Exception: bzr 1.3" [Undecided,New] https://launchpad.net/bugs/208039
[01:12] <poolie> markh: that document is pretty interesting
[01:12] <markh> poolie: thanks!
[01:13]  * poolie avoids getting sucked into reading the whole Old new thing
[01:14] <markh> heh - its a very intersting blog for windows developers
[01:15] <markh> I'm going to dig deeper into the tsvn cache etc
[01:15] <markh> and decided to get sidetracked by pulling their svn tree via bzr ;)
[01:15]  * beuno pokes poolie and lifeless about the debconf bzr talk deadline
[01:16] <poolie> beuno: hi
[01:16] <poolie> thanks
[01:16] <beuno> hey poolie  :)
[01:16] <poolie> so what did we work out about that? that lifeless would propose a talk and james_w might go too, iirc?
[01:17] <beuno> yeap, he was willing to go
[01:18] <beuno> and jelmer and LarstiQ are interested in going too, they where going to apply for sponsorship by debian
[01:18] <beuno> and with me and Verterok, we might be a pretty big bzr possy
[01:19] <beuno> might even be worth organizing a sprint  :)
[01:21] <beuno> oh, and dato might come too, right dato?
[01:22] <jelmer> 'evening markh
[01:22] <jelmer> markh: great to see you taking on TortoiseBzr !
[01:22] <markh> hi jelmer - thanks!
[01:23] <markh> key to its success will be these "external apps" which we call to do the grunt work.  I haven't really looked at them yet
[01:23] <markh> I don't have pygtk locally
[01:23] <markh> but the cool thing is we can fix them later, and independently of the shell itself
[01:23] <jelmer> I think it would make sense to call out to qbzr from tortoisebzr rather than bzr-gtk
[01:24] <jelmer> qbzr is easier to install than bzr-gtk and looks more native on windows
[01:24] <markh> there is an existing impl for a couple of "commands" in the tbzr tree
[01:25] <markh> I *think* they are gtk, but I've really only noticed they exist, not what they do :)
[01:25] <jelmer> yeah, that's all gtk
[01:25] <markh> so I'm up for nuking them, or whatever everyone agrees
[01:25] <beuno> jelmer, hey  :)    I haven't had _any_ free time at all these past weeks, but I do have a few hours now. Is the bzr-gtk release missing anything other than the disable-through-nautilus bit?
[01:25] <jelmer> we initially created tortoisebzr as a fork of bzr-gtk
[01:25] <markh> but no1 focus should be the shell IMO
[01:25] <jelmer> beuno: yep, that's the only bit missing
[01:26] <jelmer> beuno: hi :-)
[01:26] <lifeless> right, I need a topic I think
[01:26] <jelmer> lifeless: "sock puppets" ?
[01:26] <markh> how about xul? ;)
[01:26]  * markh ducks
[01:26] <beuno> jelmer, alright, I'm on it. I'll try and get that done tonight
[01:26] <jelmer> beuno: that'd be awesome
[01:26] <beuno> xul!  that would be interesting!
[01:27] <poolie> beuno: if those people don't get sponsorship from debian talk to me
[01:28] <poolie> markh: i don't have any particular comments, but it looks like a good start
[01:29] <jelmer> markh: I think nuking them wouldn't be a problem - they're also in bzr-gtk anyway
[01:29] <abentley> lifeless: your deprecation of get_graph_with_ghosts appears to also affect get_graph
[01:29] <poolie> markh: i guess i would be inclined not to have a separate cache process other than the xmlrpc server, at least at first, just to reduce the number of moving parts
[01:29] <luislavena> jelmer: hello.
[01:29] <jelmer> luislavena: hi
[01:29] <poolie> also, maybe you could expand in a future post on what kind of debug/trace _is_ needed?
[01:30] <beuno> poolie, sure, I'll follow it closely. jelmer, LarstiQ, keep your agendas open got august  ;)
[01:30] <luislavena> jelmer: is there a way I can branch/svn-cache 16K svn revisions without hit the memory error?
[01:30] <luislavena> :-D
[01:30] <jelmer> beuno: will do, thanks :-)
[01:30] <markh> poolie: it we move to pure C++ for the shell, I'm a little concerned the xmlrpc requirement will complicate what should be fairly simple
[01:30] <jelmer> luislavena: use a version of python-subversion with the memory leaks fixed
[01:30] <markh> and slower and less secure if implemented via sockets on windows :)
[01:31] <poolie> hm
[01:31] <poolie> what would be better?
[01:31] <lifeless> abentley: thats 'index.get_graph' which is on a private attribute of knits - knit._index.get_graph.
[01:31] <poolie> i guess you could make a dcom server in python?
[01:31] <luislavena> luislavena: mmm, that will need me to swtich to ubuntu and put that on a pendrive :-D
[01:31] <jelmer> luislavena: or you can use "bzr init dir"; bzr pull -r1000; bzr pull -r2000; bzr pull -r3000.. etc
[01:31] <poolie> would that be easier to talk to?
[01:31] <beuno> markh, you'd also be able to get XML straigh out of bzr, just like with the current xmloutput plugin
[01:31] <markh> the cache process is likely to need to create a hidden window to receive shell notifications from explorer when a user deletes files, for example, and maybe register for asynch NT filechange notifications to even handle the command-line changing the file-system
[01:31] <luislavena> jelmer: pull directly instead of branch?
[01:32] <jelmer> luislavena: yes, pull 1000 revisions each time
[01:32] <poolie> markh, i guess i don't understand what you mean by "the xmlrpc requirement will complicate what should be
[01:32] <poolie>               fairly simple"
[01:32] <markh> poolie: dcom might work, yeah - but a few simple commands over a named pipe is really quite trivial
[01:32] <luislavena> jelmer: great, thank you for the pointer.
[01:32] <abentley> lifeless: acceptable breakage.
[01:33] <markh> xmlrpc imples a few C++ libraries I'm not familiar with
[01:33] <jelmer> DCE/RPC \o/
[01:33] <markh> and we want this as thin as possible, as it gets dragged into many processes
[01:34] <poolie> markh: another option is to talk the bzr network protocol
[01:34] <poolie> the encoding for it would be pretty trivial to write in c++
[01:34] <poolie> some of the commands you need may not exist
[01:34] <poolie> this will possibly be smaller or simpler than xmlrpc
[01:35] <poolie> probably more new code though
[01:35] <igc> lifeless: looks like abentley and I just reviewed that patch for you. One was approve and the other was resubmit (though my review was borderline tweak)
[01:36] <markh> Would all the gui apps be written to use this xmlrpc server?
[01:36] <beuno> markh, that's the plan, GUI and IDEs
[01:37] <abentley> lifeless: please to be running the test suite before submitting your patch.
[01:37] <bob2> snap
[01:37] <markh> But isn't it more moving parts for a GUI app that has direct access to bzrlib?  I do see the benfit for IDEs etc, but not so much for gui apps that are "part of" bzr
[01:37] <markh> but thats fine :)
[01:38] <markh> I don't need to be convinced ;)
[01:38] <poolie> i didn't think guis would but i might be out of date
[01:38] <beuno> markh, well, if you can access python directly, then it makes sense, yes
[01:38] <beuno> IIRC, there where some use cases for GUIs that couldn't interact with python
[01:39] <markh> so - that would make the shell code the only known consumer of this server on windows today.  Its not written yet, it adds complexity and offers a much richer API than we actually need :)
[01:40] <markh> hence I'm still on the "simple" side of the fence :)
[01:40] <lifeless> abentley: igc: both of you reviewed the superseded, broken, version of it
[01:41] <lifeless> abentley: I do run the test suite usually :)
[01:41] <abentley> Should BB have noticed that it was superseded?
[01:41] <beuno> markh, after a whole sprint of "windows support is extremely important", and nobody willing to do anything about it, I guess you should go down whatever path you want, and we can just help  :)
[01:42] <markh> I'm obviously happy to go with whatever is decided - but in the meantime I must take off to the shops for lunch.  bb in an hour.  thanks for the info about the server thinking!
[01:42] <markh> beuno: thx - its still obviously open for discussion!
[01:43] <abentley> I'm pretty sure BB didn't notice that it was superseded, because I voted using BB.
[01:43] <lifeless> oh hmm
[01:43] <igc> lifeless: sorry about that. I don't seem to have a more recent one in my email though and BB didn't list another with a similar name?
[01:45] <lifeless> hmm
[01:45] <lifeless> oh, *I* was confused
[01:54] <LaserJock> is there an advantage to having a shared repo on a bzr server other than saving space?
[01:56] <beuno> LaserJock, nope, and that just applies if the branches have common revisions
[01:57] <beuno> jelmer, we agreed on setting the nautilus disable flag in "~/.bazaar/bazaar.conf", right?
[01:59] <fullermd> Well,  You save a lot of traffic...
[02:00] <abentley> LaserJock: Yes, it also saves time.
[02:02] <LaserJock> I guess my question is, is there a difference if the user creates a shared repo or if it's already a shared repo on the server?
[02:02] <LaserJock> not sure if I was clear the first time
[02:03] <lifeless> LaserJock: no different really; but lp doesn't support or use shared repos's. if thats what you were thinking :>
[02:03] <beuno> LaserJock, my attempts to use shared repos for _many_ unrelated branches led to some weird results
[02:03] <LaserJock> lifeless: yeah it was
[02:04] <LaserJock> lifeless: does LP support rich-root-pack ?
[02:04] <lifeless> yes
[02:04] <beuno> LaserJock, LP has the latest version of bzr, so whatever you push to it will work
[02:05] <LaserJock> so just getting some LP bzr admin type to convert our dirstate-with-subtree branches to rich-root-pack should speed things up and allow us to make shared repos, correct?
[02:06] <LaserJock> that's my bottom line I guess :-)
[02:06] <beuno> LaserJock, you shouldn't need an admin if you have access to the branch
[02:06] <beuno> you can just "upgrade --format="
[02:06] <LaserJock> heh
[02:07] <LaserJock> but I can't really push it back up
[02:07] <LaserJock> if it takes pushing the whole branch
[02:07] <beuno> LaserJock, no, you can do bzr upgrade --format bzr+ssh://laserjock@baza....
[02:08] <lifeless> well
[02:08] <RAOF> beuno: But upgrade doesn't work over bzr+ssh, right?
[02:08] <lifeless> you can't beuno
[02:08] <beuno> oh?  sftp then?
[02:09] <RAOF> That works, or should.
[02:10] <beuno> LaserJock, right, sftp instead of bzr+ssh
[02:10] <LaserJock> so would the LP server then do the conversion?
[02:10] <beuno> yeap
[02:10]  * LaserJock struggles to wrap his brain around this stuff
[02:11] <RAOF> Well, no.  Your local bzr client does the conversion over sftp.
[02:11] <RAOF> So this can be _sloooooooow_.
[02:11] <LaserJock> so when I did it locally it took 40 min
[02:11] <beuno> of course, I'm not sure what wil happen when pushing/pulling from other local formats. You'd probably want to upgrade all current branches
[02:11] <LaserJock> when we first pushed this branch it took about 5 days
[02:11] <LaserJock> so roughly how long do you think it'd take?
[02:12] <beuno> LaserJock, I'd say run it and go to sleep  :)
[02:13] <LaserJock> I'd have to do it for 4 branches
[02:13] <LaserJock> and I only have 2 locally
[02:14] <beuno> LaserJock, many times it's faster to re-branch
[02:14] <LaserJock> what do you mean by re-branch?
[02:14] <beuno> upgrade in LP, and re-branch to your box
[02:14] <LaserJock> ah
[02:14] <beuno> much cheaper in big repos
[02:15] <LaserJock> if we could get that done before Intrepid get's really going I think it'd be a big advantage for new contributors
[02:16] <lifeless> beuno: upgrade over sftp copies all the data twice
[02:16] <lifeless> beuno: over the wire
[02:16] <beuno> LaserJock, if it's that big of a deal, then it might be faster to get a LP admin to do it. Maybe abentley?
[02:17] <beuno> lifeless, ah, so it should be cheaper to upgrade locally and fully re-upload?
[02:17] <LaserJock> beuno: yeah, I just sent an email to the team to start a discussion about shared repos and getting the format upgraded
[02:17] <LaserJock> we'll see how it goes, but I'm sure everybody will like the improvement
[02:18] <LaserJock> how old of a bzr version will handle rich-root-pack? 1.0 ?
[02:19] <beuno> LaserJock, I think from 0.92
[02:19] <beuno> or 0.91 even
[02:19] <beuno> so 1.0 should be a safe bet
[02:19] <LaserJock> k, just wondered about gutsy users
[02:20] <abentley> They were introduced in 1.0, according to NEWS.
[02:20] <beuno> abentley, wasn't it introduced with packs itself?
[02:20] <lifeless> no
[02:21]  * beuno is awfully wrong today
[02:21]  * beuno alt+tabs into vim
[02:26] <jdong> beuno: at least that's one thing right.
[02:27] <beuno> jdong, :p
[02:27] <LaserJock> jdong: I thought it was just typo ;-)
[02:28] <LaserJock> *just a
[02:40] <beuno> igc, btw, thanks for redirecting all the IDE people to be, I've got a pretty good list of people working on stuff. I'll put up a wiki page with it soon
[02:41] <igc> beuno: excellent. I almost did exactly that yesterday but didn't get to it
[02:41] <igc> I want a page called EditorsAndIDEs (say) that lists all of them together with software and/or contact points
[02:42] <beuno> exactly what I had in mind  :)
[02:42] <igc> we can also use that to direct people to the team you've set up
[02:43] <beuno> igc, yeap, sounds great. Seems the news from the sprint got many people excited about it
[02:44] <lifeless> igc: there were two patches ...
[02:45] <igc> lifeless: didn't abentley approve the seocnd one?
[02:49] <lifeless> *blush*
[02:49] <lifeless> ok
[02:59]  * igc lunch & doctor visit
[03:41] <lifeless> abentley: cool patch; I don't think I'll get to review it myself today
[03:42] <lifeless> abentley: but it sounds excellent (though I'm not 100% sure about validating against different formats automagically)
[03:42] <lifeless> abentley: spiv: duplication reduction ping
[03:42] <abentley> lifeless: Well, that's only on conversion.  And it's only if the obvious choice fails.
[03:43] <lifeless> so, I've reduced about half of the duplicate sites to use helpers; the rest are not actually all the same
[03:44] <lifeless> the knit and versionedfile ones don't filter nulls and so on
[03:44] <abentley> Otherwise, I would have to fail to convert.
[03:45] <lifeless> well, my thoughts were that if its wrong, its wrong and failure is expected.
[03:45] <lifeless> I'll sleep on it
[03:45] <abentley> So that means that if we convert something from format 5 into 6, we can't convert it to 8
[03:45] <abentley> And similarly for 7 -> 5
[03:45] <abentley> sorry, 7->6
[03:46] <lifeless> the way I looked at it, reading the old inventory will fail
[03:46] <lifeless> so this is a job for reconcile, which is allowed to be slower and more complex than just pull
[03:46] <spiv> lifeless: yeah, in the patch I saw I think there were two variants.
[03:47] <lifeless> spiv: do you want to see the new diff; I think its about as reduced as I'm comfortable with
[03:47] <lifeless> or an incremental diff?
[03:47] <lifeless> or <alternate>
[03:48] <abentley> lifeless: But then you're generating format 5 serializations with differing inventory_sha1s for the same revision.
[03:48] <spiv> lifeless: an incremental diff would do
[03:48] <lifeless> abentley: huh? whatever rich-root is today - yes. And it can happy today trivially.
[03:49] <lifeless> abentley: all you have to do to get different inventory sha 1s today is to do a bzr baz-import into a rich root repo, and also a bzr baz-import into a pack-0.92 which you then upgrade.
[03:49] <abentley> The 5, 6 and 7 serializers all use format 5 for their serialization.
[03:49] <abentley> of revisions.
[03:50] <lifeless> and ditto with bzr-hg/hg-import etc - all the deterministic importers will create this
[03:50] <lifeless> spiv: mailed you
[03:50] <spiv> lifeless: ta
[03:51] <abentley> lifeless: That's just them not being completely deterministic.
[03:51] <beuno> jelmer, sent the patch  :)  I suppose I have to add the stuff I ahve done up to now in NEWS, but I'll wait until it gets approved to send that in
[03:51] <lifeless> abentley: they would have to generate a format 5 inventory, grab its sha, and then reserialise to format 7 inventory
[03:52] <lifeless> abentley: I think they are being completely deterministic; its *our* bug on upgrade that makes any problems exist; which is what your patch is about fixing.
[03:52] <abentley> They're not deterministic.  They don't force the root revision_id to always be updated, AFAIK
[03:52] <abentley> which is the non-rich-root behavior.
[03:53] <lifeless> abentley: mmm, possibly;
[03:53] <abentley> i.e. what you'd get if you converted something from baz into knit, then rich-root.
[03:53] <spiv> lifeless: +1
[03:56] <lifeless> thanks
[03:57] <beuno> poolie, if you want some help with bzr packaging for ubuntu, just upload the current branches to LP and I'll pitch in to get 1.3 into PPA
[03:57] <lifeless> beuno: I need a topic suggestion; looms would be ideal but they aren't really polished yet :(
[03:58] <beuno> lifeless, how about generically going for "managing your packages with bzr"?
[03:58] <beuno> and then see how polished they are by august  :)
[04:16] <markh> is there a simple way to have bzr show the traceback when it can't load a plugin?
[04:17] <spiv> markh: the traceback is written to the .bzr.log
[04:17] <markh> ah - thanks!
[04:17] <spiv> markh: it might be good if there were a -Dplugin debug flag, perhaps.
[04:28] <poolie> markh: i would think -Derror should do that but i guess it does not?
[04:31] <markh> heh - the log is in "my documents" :)
[04:42] <markh> so - .bzr.log is misplaced IMO on windows.  What is the best place to discuss that?  Open a launchpad bug or just email the list?  The patch is trivial, but agreement on the correct place might not be ;)
[04:43] <lifeless> markh: see the archive first please
[04:43] <lifeless> markh: its not accidental where it is :>
[04:45] <markh> bugger - so it is to help the user find the log?
[04:46] <lifeless> it may be that there is a better place
[04:46] <lifeless> bzr --version shows where the log is going
[04:47] <lifeless> so please google a bit, and if you decide that it should be moved:- send a [MERGE] in  :)
[04:48] <markh> well - making it easy to explain to a user where to find the log is very true and I don't want to start a bikeshed discussion - but I think its safe to say I'm very glad that no other apps take the approach of dumping their logs where I store my documents ;)
[04:49] <lifeless> markh: which is why I am acking that there may be a better place; but asking you to check the history a bit first, and rather than openning a bikeshed discussion, send in a patch that does the right thing
[04:52] <markh> fair enough - tho me even bringing it up is kinda bikeshedding :)
[04:55] <lifeless> I don't think its bikeshedding to say 'here is a way to do things better'. bikeshedding is arguing about trivialities.
[04:55] <spiv> "I want my shed to be pink, and called 'My Documents'" ;)
[04:57] <markh> I did assume the location was "accidental" - but given it was explicitly decided, the location of the log file is almost a triviality at this stage of the game - much bigger fish to fry!
[04:58] <markh> eg, how we bend py2exe to allow plugins to work OK in binary releases.  For now I'll just switch to a source version of bzr instead though...
[05:18] <lifeless> tchau
[05:18] <poolie> bye lifeless
[06:28] <AfC> Is jam up? Guess not.
[06:29] <poolie> AfC: he's on holidays for the next week and a bit
[06:29] <AfC> poolie: ah! Nice. Thanks
[06:33] <poolie> i've forwarded your expenses
[06:33] <poolie> btw
[06:35] <AfC> poolie: thanks
[06:35] <AfC> !
[06:35] <AfC> poolie: So it's probably a rear guard action at this point,
[06:36] <AfC> but I'm trying to [automate] set up [of] bzr-svn branches for GNOME projects for people to use.
[06:36] <AfC> I'm happy to publish a selection of the resultant branches on our R&D server, but
[06:37] <AfC> I was wondering if the launchpad guys are {likely, in progress} doing that themselves
[06:37] <poolie> i'd like them to move to doing it through bzr-svn rather than cscvs
[06:37] <AfC> (versus bzr-vcs-import, which is unfortunately no good for projects that are not migrating but still using Subversion as their main)
[06:37] <poolie> for a few reasons including the result being more useful, ... well you can imagine
[06:38] <poolie> but that is not on their plate at present
[06:38] <poolie> um
[06:38] <poolie> i have heard there is interest in having those imports though
[06:38] <AfC> poolie: ok. Just thought I'd ask before writing a bunch of scripts and kicking them off.
[06:38] <poolie> sure
[06:38] <poolie> can you mail the list when you do it?
[06:38] <poolie> i'd like to at least mirror them to launchpad
[06:38] <AfC> poolie: yeah, I sorta heard that murmour in the back of the room in London; I also now understand some of the things the Launchpad team are up against.
[06:39] <poolie> :)
[06:39] <AfC> poolie: yeah, for sure.
[06:39] <poolie> we had an interesting thread about downtime recently
[06:39] <poolie> it's actually above 99% but whether that's good or not depends on your point of view
[06:40] <poolie> anyhow i should finish rebuilds
[06:40] <AfC> Not bzr-svn's fault, but I had to do the 100 revisions at a time trick to try and do the 19,000 revision repo. I didn't have a server handy with the patched Subversion, and the machine I was on (ie, my laptop) was in an environment that was VERY intermittent.
[06:40] <AfC> It took 9 days to do the import.
[06:40] <AfC> Needless to say, I'm not going to tell anyone else that :)
[06:40] <poolie> well
[06:41] <poolie> this is one reason it would be good to get it running on proper infrastructure
[06:41] <AfC> poolie: [99%.... for most people, that's pretty good. The one I usually look for is planned vs unplanned]
[06:41] <spiv> AfC: jelmer says bzr-svn 0.4.9 is much faster, btw
[06:41] <AfC> spiv: I was just going to grab it... I know it has the changes that you and he made a couple weeks back
[06:42] <spiv> AfC: so if the dependencies aren't too horrible, it'd be worth trying the upgrade
[06:42] <AfC> spiv: should be ok... I just had to jump through lots of stupid hoops to get Subversion to co-operate.
[06:42] <AfC> Anyway, it's on my list of things to contribute in April.
[07:59] <igc> night all - have a good weekend
[09:24] <james_w> thanks jdong
[09:26] <poolie> hi james_w
[09:26] <james_w> hi poolie
[09:26] <james_w> how are you?
[09:26] <poolie> very good
[09:27] <poolie> i should sign off though...
[09:27] <james_w> have a good weekend
[10:16] <Lo-lan-do> G'day all
[10:17] <james_w> Hi Lo-lan-do
[10:17] <Lo-lan-do> I'm reading about the new dpkg source formats, including one called "3.0 (bzr)".
[10:17] <Lo-lan-do> (Basically, replace orig.tar.gz+diff.gz with a single tarball containing a bzr branch)
[10:18] <Lo-lan-do> That sounds interesting to me, but converting my main package (gforge) to it would make the source package grow from ~10MB to ~60MB, because of the full history included.
[10:18] <Lo-lan-do> So I was wondering whether the history horizon/shallow branches feature is still being worked on...
[10:19] <Kamping_Kaiser> i expect any package will have that problem too :|
[10:20] <Lo-lan-do> Not every package has thousands of revisions, but yeah.
[10:20] <Lo-lan-do> It would be nice to be able to only keep like the last year of revisions.
[10:21] <poolie> some preparatory work is happening but it is still over the horizon
[10:22] <Lo-lan-do> I see.
[10:23] <poolie> um
[10:23] <poolie> but you can use lightweight checkouts in many places, i presume
[10:23] <poolie> and then they will not be so large
[10:23] <poolie> anyhow, really going now
[10:24] <Lo-lan-do> I know about lightweight checkouts, but that's not the use case I'm talking about.
[10:27] <james_w> poolie: nice pun :-)
[10:27] <dato> heh, so I wasn't the only one =)
[10:27] <james_w> hi dato
[10:28] <dato> hello james_w
[10:28] <james_w> Lo-lan-do: I haven't looked in to those formats to understand them yet.
[10:32] <Lo-lan-do> james_w: They sound promising to me, but I won't switch quite yet, because of the size problem.
[10:32] <james_w> yeah, I think that's reasonable.
[10:33] <james_w> it seems to me like they may be more of a stepping stone to get to a proper VCS based workflow
[12:20] <chadmiller> Moin moin.
[13:05] <yacc> Just making sure, when I work with a remote repo, I do a "bzr commit" and after that a "bzr push", right?
[13:06] <yacc> So that my changes get immediatly applied to the remote repository?
[13:06] <Lo-lan-do> Yes, unless you're in a checkout (bound branch)
[13:06] <luks> by repo you mean a branch created by 'bzr branch'?
[13:07] <yacc> luks: not hundred percent. By repo I mean a svn+https:// url that I have created via bzr svn-push.
[13:07] <yacc> andreas@andi-lap:~/lookery/lookery_memberfind> bzr merge svn+https://lookery_andreas@lookery.unfuddle.com/svn/lookery_process/trunk/logs/lookery-memberfind
[13:07] <yacc> bzr: ERROR: Repository KnitPackRepository('file:///home/andreas/lookery/lookery_memberfind/.bzr/repository/') is not compatible with repository SvnRepository('svn+https://lookery_andreas@lookery.unfuddle.com/svn/lookery_process')
[13:07] <luks> oh, no idea about bzr-svn
[13:07] <yacc> Isn't that peachy?
[13:08] <luks> this looks like a incompatible shared repository format
[13:08] <james_w> yacc: you created ~/lookery/lookery_memberfind with bzr-svn?
[13:08] <luks> and I think it's explained in bzr-svn's FAQ
[13:09] <yacc> No, lookery/lookery_memberfind was the initial directory where the project started, so it was created by bzr init.
[13:09] <bob2> the project originated in bzr, then was branched to svn?
[13:09] <yacc> bob2: yeah.
[13:09] <bob2> the bzr branch has to have a compatible repository format
[13:10] <yacc> Yeah, but upgrade --rich-root-pack breaks too.
[13:10] <bob2> 'bzr upgrade --rich-root-pack' (ideally after making a backupof it)
[13:10] <bob2> ah, suck
[13:10] <yacc> bob2: well, I did already svn-push from this directory.
[13:10] <bob2> the push will be fine
[13:11] <bob2> pull/merge won't, tho
[13:12] <bob2> some missing revision error from bzr upgrade?
[13:12] <james_w> yacc: what's the error on upgrade?
[13:12] <yacc> Yeah, but it complains about diverged branches and asks me to merge. Which is curious, as there have been no commits to the directory in the mean time.
[13:12] <yacc> bob2: it complains that some version does not exist in the repo.
[13:12] <yacc> james_w: bzr: ERROR: Revision {('andreas@andi-lap-20080318163204-v6cbndpdo3k2hneq',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0xb6c53b2c>".
[13:13] <james_w> suck
[13:13] <james_w> yeah, I don't know if there is a workaround for that problem yet, sorry
[13:13] <bob2> what about 'bzr missing' - does it show revisions missing on both sides?
[13:13] <james_w> abentley: hi, are you around?
[13:13] <yacc> james_w: yeah, I'm getting this sick feeling that despite jelmer's efforts bzr-svn is not a viable svn client solution ;(
[13:13] <bob2> 'bzr reconcile' might 'fix' it for now
[13:13] <yacc> bob2: I already run reconcile
[13:13] <abentley> james_w: hi
[13:14] <james_w> abentley: hi, is there a workaround known for yacc's error above?
[13:14] <bob2> yacc: the issue is with the conversion, as far as I know - if you'd started with rich-root-pack (or branched from svn), pretty sure it would be fine
[13:14] <yacc> That's curious, branching the svn repo freshly, commit the single again, and pushing it worked fine.
[13:14] <yacc> bob2: yeah, I have a feeling that the "start a svn repo with bzr" is not exactly a typical usecase.
[13:14] <james_w> yeah, you get the right local repository format that way, the problem is with the upgrade
[13:15] <bob2> yacc: maybe branching the original bzr branch into a rich-root-pack repo would work, too
[13:15] <abentley> What was the original format?  dirstate-tags?
[13:16] <yacc> bob2: well, I'll try to start my new egg with svn mkdir && bzr branch for a change.
[13:16] <yacc> abentley: the format before was pack-0.92.
[13:16] <bob2> abentley: KnitPackRepository
[13:16] <yacc> abentley: But svn-pushing worked before, ...
[13:16] <james_w> yacc: yeah, it's not the typical use case.
[13:16] <bob2> yacc: pushing wiwll work, it's the pulling of data from svn that is the issue, afaik
[13:16] <abentley> yacc: You were using bzr-svn 0.3?
[13:17] <yacc> abentley: nope :)
[13:18] <yacc> bob2: yeah, but it complained about diverging branches, so pulling was needed too.
[13:18] <yacc> bob2: despite that nobody has commited anything to the directory on svn.
[13:18] <bob2> yacc: does 'bzr missing' explain that?
[13:18] <abentley> yacc: AIUI, bzr-svn 0.4 requires a rich-root format.  So I don't know how you got that.
[13:19] <yacc> bob2: nope, I already managed to push it via a fresh branch.
[13:20] <yacc> abentley: which makes me wonder how the revisions in lookery-memberfind ended up in the svn repo in the first case?
[13:21] <yacc> Ok, I've got an idea what can be out of whack.
[13:21] <yacc> bzr missing complains that I'm missing the initial revision the directory is based on, that I did via "svn mkdir" if I remember right.
[13:21] <abentley> yacc: Could you run this in the root of your branch please?
[13:21] <abentley> python -c "from bzrlib import workingtree; wt = workingtree.WorkingTree.open('.'); wt.lock_read(); print wt.inventory.root; wt.unlock()"
[13:22] <yacc> abentley: nope, the branch had a portion of tender-love-care from rm -Rf ;(
[13:22] <abentley> yacc: So you didn't originate this bzr-svn conversion?
[13:23] <yacc> I did orginate yet again, but I solved it by branching the svn url freshly, applying my change and pushing it. Everything worked fine then.
[13:24] <james_w> yacc: did you just start with bzr init, made some commits, and then did bzr svn-push?
[13:24] <yacc> james_w: yes.
[13:24] <abentley> Alright, I guess there's nothing for me to see here.
[13:24] <james_w> thanks abentley
[13:25] <abentley> james_w: To somewhat answer your question, there are two fixable causes of that error.
[13:25] <abentley> One is the sort of data inconsistencies that reconcile will fix, so that's fixable.
[13:26] <yacc> And the second one?
[13:26] <abentley> The other is that the non-rich -> rich converter assumes non-rich trees have TREE_ROOT as their tree root.  That hasn't been addressed yet, but I'm planning to do it as part of my pack-1.4 work.
[13:28] <schierbeck> hey guys -- any news on nested branches?
[13:28] <james_w> abentley: great, thanks.
[13:29] <james_w> schierbeck: I think LarstiQ had almost all tests passing in London, so hopefully we will get the first bits to review at some point.
[13:29] <schierbeck> awesome!
[13:56] <deepjoy> bzr+http woohoo!!!
[13:56] <deepjoy> finally got the basics running
[13:57] <deepjoy> not if only I could figure out how to use the update the working tree remotely or an alternate work flow that will server multiple developers
[13:58] <deepjoy> I have bzr+http with write enabled working with mod_authz_ldap
[13:58] <deepjoy> anybody here to share my joy :-)
[13:58] <dato> "yay!"
[13:58] <Lo-lan-do> Yaaay.
[13:59] <deepjoy> dato: Lo-lan-do: thanks
[13:59] <chadmiller> Hi all.  I'm trying to push a Very Large pack-0.92 branch (total repo is ~500MB) to Launchpad using very recent bzr.dev over bzr+ssh.
[14:00] <bob2> deepjoy: you should document that somewhere :)
[14:00] <chadmiller> By my calculation, if it were just streaming data, it would take ~30 minutes over my 'net connection.
[14:01] <chadmiller> But, I stopped it yesterday at 8 hours, with the progress bar about 2/5ths the way across the screen.
[14:01] <Lo-lan-do> chadmiller: You might try packing it first
[14:02] <Lo-lan-do> (But I don't know what I'm talking about, so ignore me if I'm just giving nonsense)
[14:02] <chadmiller> It is packed.
[14:02] <bob2> was it still sending data when it stopped (according to iptraf or tcpdump or whatever)
[14:02] <chadmiller> bob2: Yes.
[14:04] <chadmiller> The trees are public, if anyone wants to try.
[14:04] <chadmiller> https://code.edge.launchpad.net/~mysql-developers/
[14:05] <chadmiller> branch from 6.0-trunk, push back.
[14:05] <Lo-lan-do> chadmiller: Are you trying to push over a DSL line?
[14:05] <chadmiller> Lo-lan-do: No.  Cable.
[14:06] <Lo-lan-do> Large latency?
[14:06] <chadmiller> No, not usually.  Very good, most of the time.
[14:06] <Lo-lan-do> If so, you may want to rsync over to a good server, and push from there
[14:07] <luks> pushing over sftp will be probably faster than over bzr+ssh if it's just one big pack file
[14:08] <chadmiller> Lo-lan-do: I can scp the whole repo in ~30 minutes.
[14:09] <Lo-lan-do> chadmiller: Hence the idea to push over bzr+ssh from a place where network roundtrips don't matter much
[14:09] <chadmiller> Lo-lan-do: That's not it, sorry.
[14:09] <Lo-lan-do> Then I'm happy to be ignored :-)
[14:17] <chadmiller> While I've been patient about other uses of bazaar, I'm trying to decide whether or not to use bazaar (and launchpad) for my Google-Summer-of-Code students.
[14:21] <james_w> chadmiller: the ~/.bzr.log from the push may give some clues
[14:22] <james_w> chadmiller: for future reference -Dhpss can help debugging this
[14:23] <chadmiller> james_w: The .bzr.log has the startup info, and then at t+33 "Using fetch logic to copy..." and is then silent.
[14:23] <james_w> chadmiller: that's not much use then.
[14:23] <james_w> shame
[14:24] <chadmiller> james_w: I left it running last night with -Dhpss, and (I suppose) it bogged down enough that the ssh socket timed out.
[14:24] <chadmiller> Oh, wait, that was -Devil.
[14:24]  * chadmiller uses hpss.
[14:25] <james_w> -Devil isn't that useful as it doesn't really change depending on your specific circumstances
[14:26] <chadmiller> (Yeah.  After the 8-hour wait, I wanted to see if there was anything obviously algorithmic in the way.)
[14:54] <asabil> when having a conflicts
[14:54] <asabil> is there a way to tell resolve to auto pick the .THIS ?
[14:54] <asabil> overriding the changed from .OTHER ?
[14:54] <james_w> I don't think so
[14:55] <asabil> oki thanks
[14:57] <fullermd> cp ; resolve
[14:57] <fullermd> Or revert, I s'pose.
[14:59] <asabil> fullermd: yes, but when you have a bunch of files
[15:00] <asabil> you need to end up using find
[15:00] <Lo-lan-do> Not necessarily.
[15:00] <fullermd> Nah, you could use perl instead   ;)
[15:00] <Lo-lan-do> How about "bzr conflicts --text | xargs bzr revert"?
[15:00] <james_w> that should work
[15:00] <asabil> hmmm right, forgot aboy xargs
[15:01] <asabil> about*
[15:01] <asabil> thanks
[15:01] <fullermd> Though it does lead one to think that bzr really needs a -0 option...
[15:02] <fullermd> Got it on ls, but not on conflicts.
[15:03] <Lo-lan-do> Also, this will entirely drop the parts of the patches that are not conflicting.
[17:00] <luislavena> hello guys, question for any using bzr-svn...
[17:00] <luislavena> even I created a branch in svn using svn copy from trunk, bzr merge is not accepting it:
[17:00] <luislavena> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
[17:00] <luislavena> I use bzr pull since branch was eating all my memory :P
[17:05] <Lo-lan-do> luislavena: I know, I already reported that bug.
[17:05] <luislavena> Lo-lan-do: oh, I see, I'm not the only one.
[17:05] <Lo-lan-do> https://bugs.launchpad.net/debian/+bug/197356
[17:05] <ubotu> Launchpad bug 197356 in debian "Branches created in svn don't seem related in bzr (dup-of: 203368)" [Unknown,Confirmed]
[17:05] <luislavena> Lo-lan-do: how do you workaround it?
[17:05] <ubotu> Launchpad bug 203368 in bzr-svn "svn-push a branch with no new history makes surprising commit to SVN repo" [Wishlist,Confirmed]
[17:05] <Lo-lan-do> Which is even a duplicate
[17:06] <Lo-lan-do> I, uh, don't.
[17:06] <Lo-lan-do> Apart from using bzr-push to create the branch in the first place.
[17:07] <luislavena> Lo-lan-do: the branch already existed :-(
[17:07] <luislavena> guess that will have to deal with the shelve.
[17:52] <Stavros> hello
[17:52] <Stavros> what's the difference between "bzr branch" and "bzr co"?
[17:52] <LeoNerd> Where the commits go
[17:52] <LeoNerd> If you commit to a 'branch'ed one, it's only stored there
[17:52] <LeoNerd> If you commit to a 'co'ed one, it'll try to push it back upstream again
[17:52] <Stavros> ah, so you need to push afterwards
[17:53] <Stavros> aha, thanks
[17:53] <LeoNerd> push, or pull from the other place, or merge..
[17:53] <Stavros> ah
[17:53] <LeoNerd> Basically, it's a question of "is this some other branched work, or is it supposed to be 'thesamework' in another physical location?"
[17:53] <Stavros> hmm, it's the latter, but i think i'll still tell people to branch
[17:54] <Stavros> so they can commit offline until they're ready to push
[17:54] <LeoNerd> Ah.. well, that can be done too
[17:54] <LeoNerd> For "occasional-offline" machines, you can co anyway.. and pass the  --local  flag to commit
[17:54] <Stavros> indeed...
[17:54] <Stavros> is there a windows setup package that includes a gui?
[17:55] <Stavros> i suggested bzr over svn so i want to make this as easy as possible
[17:55] <Stavros> (to avoid getting lynched, you understand)
[17:58] <jkakar> Is bzrtools distributed in the bzr PPA?
[17:58] <abentley> jkakar: yes
[18:00] <jkakar> abentley: Cool, thanks.
[18:21] <sabdfl> hey folks, should we still have "baz" packages in ubuntu, labelled "bazaar"?
[18:22] <chadmiller> sabdfl: I think it's to be fixed soon.  The disambiguating version number is about to be false too.
[18:23] <dato> sabdfl: afaik james_w and beuno are putting some work into having them renamed to baz, and have bazaar be bzr (at some point)
[18:23] <sabdfl> james_w: is that a hardy exercise?
[18:23] <sabdfl> imo, we definitely don't want "bazaar" being "baz" for all of hardy
[18:24] <james_w> sabdfl: I would like it to be, but baz FTBFS and I haven't been able to fix that yet
[18:24] <james_w> so the transition is stalled until we can fix that.
[18:24] <dato> .oO(unless you completely drop it from the dist)
[18:24]  * sabdfl is inclined to drop baz
[18:25] <sabdfl> does bzr still do a good job of conversion from baz?
[18:25] <chadmiller> sabdfl: What's the "sa"?
[18:25] <james_w> that's reasonable, we'd like to do the transition in Debian as well, and there is less support for just dropping it there
[18:25] <james_w> the other thing is that baz is a requirement for bzr baz-import, and so it's a way we can provide a migration path for baz users to bzr
[18:26] <ubotu> New bug: #208387 in bzr "bzrtools 1.3 is not available for feisty fawn" [Undecided,New] https://launchpad.net/bugs/208387
[18:31] <sabdfl> chadmiller: self-appointed
[18:58] <Stavros> hmm, i think bzr doesn't like cygwin
[18:58] <Stavros> bash: bzr: command not found
[19:00] <james_w> Stavros: did you install the cygwin or Windows bzr?
[19:00] <Stavros> james_w: python, i think
[19:00] <Stavros> definitely not cygwin
[19:00] <Stavros> let me doublecheck
[19:01] <james_w> I think you may need to adjust your $PATH
[19:01] <james_w> though I think windows bzr through cygwin is a long road to pain
[19:01] <ubotu> New bug: #208418 in bzr "ValueError when trying to pull/merge from a remote repository" [Undecided,New] https://launchpad.net/bugs/208418
[19:01] <Stavros> damn, it's huge
[19:01] <Stavros> james_w: it's not through cygwin
[19:01] <Stavros> i didn't touch cygwin
[19:02] <james_w> yeah, there's a separate cygwin port
[19:04] <Stavros> i have no clue wtf it's doing with bash now..
[19:04] <Stavros> oh
[19:04] <Stavros> maybe it's running bash on the remote server
[19:05] <Stavros> or maybe bash is telling me bzr wasn't found
[19:05] <Stavros> that's it :/
[19:05] <Stavros> what's an easy to install gui for windows?
[19:05] <james_w> ah, what command are you running?
[19:06] <Stavros> bzr+ssh
[19:06] <Stavros> but it's odd, because bzr is supposed to be there
[19:06] <james_w> BZR_REMOTE_PATH might help you there.
[19:06] <james_w> set that in your environment to be the path to bzr on your server
[19:07] <Stavros> hmm, it's multiuser, so it should just work :/
[19:07] <Stavros> i will ask the admin to do it
[19:10] <Stavros> hmm, shouldn't bare ssh:// work?
[19:10] <fullermd> Well, it doesn't.
[19:10] <fullermd> "should" is a very broad question  :p
[19:10] <Stavros> hmm
[19:12] <Stavros> so anything i can do now?
[19:23] <sabdfl> poolie: ping
[19:28] <james_w> Stavros: sftp:// should work for you
[19:28] <Stavros> oh, thanks
[19:28] <Stavros> ah, it needs paramiko :/
[19:29] <Stavros> does anyone have the link to the qt redist i need to install to get qbzr to work? the one i got is 70 mb
[19:30] <james_w> does it work?
[19:30] <Stavros> does what work?
[19:31] <james_w> the distribution you have?
[19:32] <Stavros> what do you mean? i'm in windows
[19:32] <james_w> you said "does anyone have the link to the qt redist i need...the one i got"
[19:32] <Stavros> oh
[19:32] <james_w> which seems contradictory to me
[19:32] <Stavros> i mean the link i found
[19:33] <Stavros> i didn't download it
[19:33] <james_w> ah, ok
[19:33] <Stavros> is that the correct one?
[19:33] <james_w> is it a qt distribution, or a qbzr one?
[19:33] <Stavros> qt
[19:36] <Stavros> damnit, why doesn't anyone include the correct link in the qbzr page? :(
[19:37] <luks> because you are supposed to use the binary qbzr installer
[19:37] <Stavros> what if you used the python bzr package?
[19:37] <luks> that's not a problem
[19:38] <Stavros> apparently it is, because i can't get it to work
[19:38] <luks> unless you have some strange version of python
[19:38] <Stavros> i just installed 2.5
[19:38] <Stavros> qt isn't included in what i installed
[19:38] <luks> yep, I said the binary installer
[19:38] <Stavros> the 110 kb one?
[19:39] <luks> you can use http://www.riverbankcomputing.co.uk/pyqt/download.php for the other one
[19:39] <luks> I dunno how big is it
[19:39] <Stavros> it doesn't include qt
[19:39] <luks> that's the wrong one then
[19:39] <Stavros> there's one for python and one for standalone
[19:39] <luks> "qbzr-setup-0.8.0.exe  "
[19:39] <Stavros> that's for the standalone bzr version
[19:39] <Stavros> i don't want that version
[19:40] <luks> ignore that
[19:40] <luks> otherwise, download pyqt from the link I posted
[19:40] <Stavros> ok, i'll do that and see...
[20:02] <james_w> jelmer: my apologies, I underestimated bzr-svn
[20:03] <jelmer> yacc: if you want a stable bzr-svn, use a release...
[20:04] <LarstiQ> bzr: ERROR: Unable to push revision 'wouter@chuck-20080328195425-e5de7xtz87t6ozd4' because it would change the ordering of existing revisions on the Subversion repository root. Use rebase and try again or push to a non-root path
[20:04] <LarstiQ> ho hum
[20:04] <LarstiQ> jelmer: I suppose this is due to different branching schemes
[20:06] <jelmer> LarstiQ: you can only append revisions when pushing to a repository root
[20:07] <jelmer> LarstiQ: you merged I think, and that would change the lhs revision history
[20:14] <jelmer> yacc: still there?
[20:16] <LarstiQ> jelmer: well. That sucks.
[20:16] <jelmer> LarstiQ: it's impossible to change the root in subversion
[20:17] <LarstiQ> jelmer: I don't understand it yet, but I'll just uncommit for now
[20:27] <fullermd> Anything's possible if you push hard enough   ;)
[20:31] <RainCT> Hi
[20:31] <RainCT> can I let bzr remember two commit URLs?
[20:32] <RainCT> ie, save a second one with an alias so that I don't have to write the complete URL each time I want to push there
[20:32] <beuno> RainCT, I don't think you can have aliases on a per-branch basis
[20:35] <RainCT> hm.. well I think I'll just keep two branches locally too
[20:35] <RainCT> thx
[21:06] <beuno> RainCT, you can always file a bug requesting it  :)
[21:16] <james_w> yeah, aliases would be a good thing to have
[21:19] <RainCT> james_w: great you want them too, feel free to request them then :P
[21:19] <james_w> feel free to implement them :-)
[21:20] <fullermd> It's probably been at least a month since they were last requested   :P
[21:24] <javierder> Hello!
[21:25] <javierder> I'm working in a bzr plugin for Gedit.
[21:25] <javierder> And I have a problem! :)
[21:25] <dash> Hi. does bzr have anything like svn's "externals"?
[21:26] <javierder> when doing a workingtree.smart_add("mypath") to add everything there, it only adds files in that directory, but it's not recursive...
[21:40] <beuno> jelmer, ping
[21:41] <abentley> dash: There has been some work on that, but it is incomplete.
[21:41] <dash> OK
[21:42] <dash> is it the useful-in-limited-situations kind of incomplete or the breaks-in-surprising-ways kind? :)
[21:43] <abentley> sabdfl: bzrtools does good conversion from baz, but it uses baz to do it.  (bzr itself has never handled baz)
[21:44] <abentley> dash: The latter.
[21:44] <dash> OK.
[21:44] <sabdfl> thanks abentley
[21:44] <dash> Guess I'll be patient then. :)
[21:44] <sabdfl> anybody know why 1.3 hasn't shown up in the PPA?
[21:45] <beuno> sabdfl, it has today  :)
[21:46] <beuno> I just installed a few minutes ago
[21:46] <beuno> ah, you meant bzrtools
[21:46]  * beuno goes back into vim
[21:52] <awmcclain> Just to be clear... there's no way to check out one file from a branch, correct?
[22:00] <james_w> corrrect
[22:01] <james_w> javierder: I think it should be recursive, is there a recursive parameter to the method?
[22:01] <james_w> javierder: another possibility is that all the files in there are ignored.
[22:31] <javierder> james_w, i found the problem. there was a .bzr inside the subfolder. thanks!
[22:34] <james_w> javierder: cool
[22:43] <awmcclain> uh oh
[22:44] <james_w> what's up?
[22:45] <awmcclain> I think i really broke something... I changed my .bzr/branch/location  from sftp:// to bzr+ssh://, got a bzr: ERROR: Generic bzr smart protocol error: bad protocol marker "error\x01Generic bzr smart protocol error: bad request '/'\n"
[22:45] <awmcclain> And now when i changed it back, i get bzr: ERROR: Not a branch: "sftp://bamboo.fluther.com/repos/conf/
[22:45] <james_w> ouch
[22:45] <awmcclain> any thoughts?
[22:45] <james_w> double ouch
[22:46] <james_w> I'm not really sure.
[22:46] <awmcclain> triple ouch
[22:46] <james_w> that's a public branch? Is there http access?
[22:46] <awmcclain> no, it's publicly available authenticated branch
[22:49] <james_w> ok, can you ssh to the machine?
[22:50] <james_w> if you can please do so and ls -R .bzr on the branch.
[22:50] <james_w> let's find out what state it is in
[23:00] <luislavena> hello everybody.
[23:00] <luislavena> been testing bzr-svn in my workflow, and found something funny...
[23:01] <luislavena> if you svn-push a new branch (which previously was a branch from trunk) and forgot to push the changes in trunk, it always mark as missing and don't let oyu push them...
[23:05] <awmcclain> ok
[23:06] <awmcclain> james_w: Here's the output of the ls http://dpaste.com/41918/
[23:08] <awmcclain> james_w: Fortunately, I don't have very many changes
[23:08] <awmcclain> james_w: I can re-checkout the branch and port my changes over
[23:10] <james_w> luislavena: you probably want to file a bug on that
[23:10] <james_w> awmcclain: sorry, I was trying to code, let me look now
[23:10] <awmcclain> james_w: np
[23:10] <hno> Is there any way of creating a submission bundle (bzr send) of changes already in trunk?
[23:10] <james_w> awmcclain: that's the remote branch?
[23:11] <awmcclain> james_w: Correct.
[23:11] <james_w> it looks ok. perhaps you should cat .bzr/branch/format and check it is sane
[23:11] <awmcclain> james_w: I just rebranched and was able to checkin
[23:11] <james_w> hno: you might be able to do it with a -r
[23:11] <awmcclain> err
[23:11] <beuno> hno, I suppose you could copy over trunk, bzr revert to where you want it, and do a send against that one
[23:11] <luislavena> james_w: ok, I'll try to recreate the steps and post on a bug.
[23:11] <luislavena> james_w: thank you.
[23:11] <james_w> and what beuno says
[23:11] <awmcclain> james_w: (re checked-out, i should say)
[23:12] <lifeless> hno: yes, just supply the exact revision range
[23:12] <hno> james_w: Not quote.. the patch gets rendered fine, but the resulting bundle is empty..
[23:12] <lifeless> hno: -r x..y
[23:12] <james_w> hi lifeless
[23:12] <hno> hi lifeless
[23:12] <james_w> awmcclain: odd, perhaps your local end was messed up
[23:12] <james_w> awmcclain: does it still happen with the original checkout?
[23:12] <awmcclain> hrm
[23:12] <hno> lifeless: I guess it's due to not really having a target branch..
[23:12] <james_w> awmcclain: -Derror and ~/.bzr.log might help if so
[23:13] <james_w> though I don't know if -Derror will change anything here
[23:13] <hno> (used trunk as the target)
[23:13] <james_w> hno: what do you want the merge directive for?
[23:13] <lifeless> hno: perhaps try manual target branch etc; it seems to me it should still add content in this case and I'd call it a bug
[23:14] <fullermd> Mmmph.  Seems like we've had that discussion more than once...
[23:15] <awmcclain> james_w: A ha!
[23:15] <hno> lifeless: I guess it would work specifying an empty target branch, or at least one not having the change...
[23:15] <awmcclain> james_w: Newline at the end of the file!
[23:15] <james_w> awmcclain: wow
[23:15] <fullermd> hno: I doubt that would do what you want either...
[23:16] <awmcclain> james_w: FTR, this is all because you can't do a branch on a rich-root-pack over ssh://
[23:16] <james_w> bzr+ssh://>
[23:16] <james_w> ?
[23:16] <awmcclain> james_w: Correct.
[23:17] <james_w> awmcclain: sorry, I'm not familiar with that problem, what is it?
[23:18] <awmcclain> james_w: Ah. Branch over a smart protocol default to creating the branch in the default format (pack?). If you have a branch converted from svn (in rich-root-pack) it will fail. The workarounds are 1) Do a lightweight checkout 2) cehckout into a shared repo formatted with rich-root-pack 3) checkout over sftp://, then change the protocol to bzr+ssh://
[23:18] <hno> using an empty target branch was not a good idea.. bzr send -r x..y /empty/branch is chewing up all the cpu...
[23:19] <lifeless> hno: yah; I think this is a bug :>
[23:19] <fullermd> It'll end up bundling the WHOLE branch.
[23:19] <lifeless> hno: using a branch without y, where -r x..y, will work; ideally the branch will contain x.
[23:20] <hno> Feels kind of odd to not be able to create an untargeted bundle..
[23:21] <fullermd> The logic (AIUI) goes like   - "-r" gives the rev range to be commanded   - The displayed patch is an approximation of the result of applying that   - The revisions bundled up are determined by what doesn't exist in the target branch
[23:21] <james_w> awmcclain: ah, I remember now, thanks
[23:23] <hno> fullermd: Yes, I understand that. But what I need in this case is to bundle exactly the revisions said without a specific target.. it's input to a separate cherrypicking/backporting tracker.
[23:24] <fullermd> Right; there isn't a way.
[23:24] <fullermd> What you'd do is make a temp branch to use as the target holding the base rev.
[23:25] <fullermd> (at least, there isn't a UI way; you could probably force it using bzrlib directly)
[23:25]  * hno isn't a very python guy..
[23:26]  * fullermd isn't either   :)
[23:27]  * hno wonders what that send against an empty target is up to.. it's still running..
[23:27] <fullermd> Bundling up the whole history of the branch.
[23:27] <fullermd> (after all, the target doesn't have ANY of those revs, so we need to send them ALL)
[23:28] <hno> that doesn't make sense.
[23:29] <fullermd> A merge directive is a directive to merge.  -rx..y defines what revs the other end is being told to merge.  The target branch determines what revs need to be bundled to do that.
[23:29] <fullermd> So the bundled revs are something like -r{HEAD_OF_TARGET_BRANCH}..y
[23:30] <fullermd> And since the head of your target branch is nothing (or at least, nothing in the ancestry of x or y, which is the same thing in this case)...
[23:36] <james_w> heh, it seems I've invented an O(ugliness of history algorithm)
[23:36] <james_w> or rather O(ugliness of history) algorithm
[23:36] <james_w> though I'm sure the former would be an interesting one to try and analyse
[23:39] <hno> fullermd: I believe you that it's what bzr does. But still doesn't make sense.
[23:39] <james_w> on bzr.dev: bzr mlog  4.21s user 0.09s system 93% cpu 4.598 total
[23:39] <james_w> on emacs: 0.24s user 0.05s system 87% cpu 0.328 total
[23:39] <james_w> (straight line history for the latter)
[23:41] <james_w> though I guess it's not unusual
[23:44] <fullermd> james_w: The prettier the algorithm is, the better it scales?  There's a PhD thesis in there somewhere...
[23:45] <james_w> I think so too
[23:46] <fullermd> Hm.  That suggests that code optimization could best be done in Befunge...