[00:17]  * fullermd didn't get said hi to   :(
[00:21] <jfroy> Can aliases override commands?
[00:21] <james_w> yes
[00:22] <fullermd> For instance, I've aliased 'rm' to 'rm --keep' since the option was added.
[00:22] <jfroy> mmmm
[00:22] <thumper> commit to commit --strict :)
[00:22] <thumper> now...
[00:22] <jfroy> yes I've just confirmed
[00:22] <fullermd> 'course, maybe it's a bug that options aren't recursive so that actually works   ;)
[00:22] <jfroy> I saw some revert backup files in a directory
[00:22] <thumper> I'm trying to find the revno on trunk that introduced a particular change
[00:22] <jfroy> and I have revert = revert --no-backup
[00:23] <jfroy> was wondering if it wasn't working
[00:23] <jfroy> but I guess they were old
[00:23] <jfroy> thumper: annotate should be able to get you the revno at which a particular line was last modified
[00:23] <jfroy> (or a list of revnos?)
[00:24] <thumper> it gives a dotted revno
[00:24] <thumper> I want the mainline revno
[00:24] <jfroy> aaah
[00:25] <fullermd> You'd have to track forward to where it was merged.
[00:25] <jfroy> so it was modified in a merge revision and you want the merge revision?
[00:25] <jfroy> yeah
[00:25] <fullermd> Though ISTM there was some discussion about a flag to annotate to do just that...
[00:25] <jfroy> *in a merged revision
[00:26] <jfroy> is there a way to list merge revisions, incidentally
[00:34] <lifeless> james_w: hi
[00:38] <james_w> hey lifeless
[00:50] <lifeless> james_w: so where/how are you using stacked branches?
[00:50] <james_w> in bzr-builder
[00:50] <james_w> using shared-repos is a pain, so stacked branches seemed the obvious choice
[00:51] <james_w> it's just doing it as it needs the tree at minimum, and then perhaps enough history to do a merge
[00:51] <james_w> but never full history
[00:51] <james_w> it's not necessarily the best solution though
[00:52] <lifeless> there is significant work needed in bzr to fix this bug
[00:52] <lifeless> we're moving to shared repos or something like it as the main way of working
[00:52] <lifeless> and downloading all the history should be faster than stacking anyway
[00:52] <lifeless> actually thats the key point
[00:52] <lifeless> stacking -> VFS operations -> slow.
[00:53] <lifeless> stream all history -> fast.
[00:53] <lifeless> stacking with a local tree requires downloading all the tree data over vfs *anyway*
[00:53] <lifeless> so ignoring shared repositories, not stacking should be faster in this use case regardless
[01:01] <AfC> bzr-buildbot-net... a botnet for Bazaar? Cool. Er, um.
[01:01] <AfC> :)
[02:30] <poolie> hello all
[02:30] <lifeless> hi
[02:40] <poolie> how's stuff?
[02:40] <poolie> it's hot and humid here
[02:40] <poolie> more humid than hot though
[02:41] <lifeless> well
[02:42] <lifeless> I've been landing lots of little 2a-default fixes
[02:42] <lifeless> and spivs network delta thing is landable now
[02:44] <poolie> ah that is good
[02:45] <lifeless> I spent some time with the u1 folk this morning - they are fsyncing in their dirstate equivalent... and its slow ;)
[02:45] <poolie> heh
[02:45] <poolie> i guess at least they know what platform it's running on
[02:45] <poolie> well, kinda
[02:45] <lifeless> lynne, stephane and I are doing yum cha & a movie on sunday; the hoyts website is _terrible_
[02:46] <spiv> Landable, and in PQM's queue!
[02:46] <poolie> that's nice
[02:46] <poolie> woo
[02:48] <lifeless> jam: don't suppose you are still around
[02:48] <lifeless> jam: WT3.update_basis wants xml inventories from the repo
[02:49] <poolie> lifeless: generally i think fsync is a poor deal: may not give you much protection and slow with it
[02:49] <lifeless> yep
[02:49] <poolie> one property we can rely on is that files written a long time ago and not touched are unlikely to be affected by future writes
[02:50] <poolie> only by media failure
[02:50] <poolie> so something like obsolete_packs feels write except
[02:50] <poolie> - it might be nice not to remove them at all
[02:50] <lifeless> right? :)
[02:50] <poolie> heh, thanks freud
[02:50] <poolie> and s/remove/move
[02:51] <poolie> - it would be good to automatically detect the latest consistent state, without relying on any fs access
[02:51] <poolie> blah my fingers are flaky today
[02:51] <poolie> i meant, without relying on any fs ordering guarantees
[02:51] <lifeless> yes
[02:51] <lifeless> thats the tricky bit
[02:51] <poolie> conceptually if you could read the whole file and compare it to a hash at the end
[02:52] <poolie> that would get away from assuming that if a file's been renamed, all the data previously written to it made it to disk
[02:52] <lifeless> oh, complete tangent - http://eu.squid-cache.org:8081/
[02:52] <poolie> and you wouldn't need to sync
[02:52] <lifeless> thats the squid hudson instance
[02:52] <lifeless> what I'd like to get away from is the root node
[02:53] <lifeless> its the only really fragile bit today
[02:53] <lifeless> (not that its failed ever as far as we know)
[02:54] <poolie> meaning the pack names?
[02:54] <lifeless> .bzr/repository/pack-names, yes
[02:54] <poolie> mm
[02:54] <lifeless> I don't mean 'dont have a root node'
[02:54] <poolie> the other thing that's reasonable to assume is that the fs can keep its own structures coherent, specifically directories
[02:55] <poolie> but then you get into trouble with places that can't list directories, so it may not help much
[02:55] <poolie> it's something to think about for wt metadata at least
[02:55] <lifeless> wt metadata is less of a problem I think
[02:55] <lifeless> much less at stake, and less likely to be over e.g. http
[02:56] <fullermd> Corrupted dirstate would be even less of an issue if we had a revert --blat-me-out-a-fresh-dirstate-already...
[02:56] <lifeless> fullermd: well, there are things that dirstate does today we will definitely fix ;)
[02:56] <poolie> true
[02:57] <lifeless> fullermd: but over and above that there are cases repositories [and branches] are expected to handle gracefully that wt's aren't...
[02:57] <fullermd> I mean, you'd lose add's...   no big deal.  Lose rm's with the file still around...  not too bad.  Lose mv's...  that's the big hiccup.
[02:57] <lifeless> or aren't-so-much
[02:57] <fullermd> But when your alternative is to sit around with every op blowing up on the dirstate, or creating a new checkout and manually moving files around to simulate it, as people get told to do...
[02:58] <poolie> rebooting karmic, biab (i hope)
[02:58] <poolie> fullermd: i agree that revert op would be good
[02:58] <poolie> thought it's kind of a kludge
[02:58] <fullermd> Oh, it totally is.  But I like software that gives me big hammers to power through unpleasant situations once I'm in 'em.
[02:59] <lifeless> hmm, do you use BSD?
[02:59] <lifeless> :>
[02:59] <fullermd> Sure, but that's not powering through; BSD is dying, everybody knows that.
[03:00] <lifeless> oh
[03:00] <lifeless> what BSD flavour/version do you use?
[03:00] <fullermd> (and it's really BAD at it too, 'cuz it's been doing it for more'n a decade, and it's still twitching.  Just can't do ANYTHING right...)
[03:00] <fullermd> I'm on Free.
[03:00] <lifeless> (given that macosx has ~= desktop share with linux, its hardly dying)
[03:00] <lifeless> what version?
[03:00] <fullermd> FreeBSD 8.0-BETA2 #0: Sat Aug  1 04:27:00 CDT 2009     to be Pacific.
[03:01] <lifeless> and what arch
[03:01] <lifeless> care to run a squid buildslave
[03:01] <fullermd> (RELENG_7 from Feb on another box, an old REL_6 elsewhere....   bunches of 'em)
[03:01] <lifeless> we have 6.4 under test
[03:01] <fullermd> Workstation's amd64.
[03:01] <lifeless> nothing recent
[03:02] <fullermd> Oh, I can do occasional build/report type things.  Not really in a position to lay out automation, though.
[03:02] <lifeless> http://wiki.squid-cache.org/BuildFarm
[03:03] <lifeless> read the 'Activating a slave machine (as the machine owner)' section
[03:03] <lifeless> if that sounds ok; then woot
[03:03] <lifeless> and if you want to run it sporadically thats fine too
[03:12] <fullermd> Hm.  Well, maybe I'll get a chance to look more at it.
[03:13] <fullermd> It'd be nice to have some ballparks on resource utilization involved on that page.
[03:14] <lifeless> theres ~ a commit a day
[03:14] <lifeless> a build can be as short as 30 minutes
[03:14] <fullermd> What does a run eat, though?  50 megs of disk?  2 gig?  Does it churn the CPU for 10 minutes, or kill the IO subsystem for an hour?
[03:15] <lifeless> good questions
[03:16] <lifeless> the build includes make distcheck
[03:16] <lifeless> and some tests
[03:20] <fullermd> 3.1.0.13 build takes
[03:20] <fullermd> 133.100u 40.812s 2:57.68 97.8%  6213+2442k 0+50io 997pf+0w
[03:22] <lifeless> thats not the autotest :)
[03:22] <lifeless> which does some more work
[03:22] <fullermd> Yah, I expect so, seeing ~30+ minute times in some clicking around the buildfarm thing
[03:22] <lifeless> the 2h one is a nuts slow machine
[03:23] <lifeless> # du -sh 3.HEAD-i386-FreeBSD-6.4
[03:23] <lifeless> 119M    3.HEAD-i386-FreeBSD-6.4
[03:24] <lifeless> we do a minimal build
[03:24] <lifeless> and a build with everything we can turn on turned on
[03:30] <jam> lifeless: so I think you're saying that WT3 + 2a is broken... IIRC the WT3 code can handle when the basis inventory is not present, and just fetch it from the repo.
[03:30] <jam> So can we just have it skip caching the inventory?
[03:32] <spiv> jam: btw, I'm not sure exactly what you fixed in InterDifferingSerializer recently, but I still see stacking-related test failures with a 2a target if I use IDS.  Your test changes don't notice, but assertCanStreamRevision does.
[03:33] <spiv> jam: so I suspect something still isn't quite right.
[03:33] <jam> spiv: I won't say I caught everything, but I certainly made it a lot better
[03:33] <spiv> Oh, I don't doubt you made it better :)
[03:33] <jam> given that your change to IDS was causing it to store the current inventory under the name parent_id
[03:34] <lifeless> jam: we have tests that test that it caches eventually
[03:34] <jam> lifeless: if self.branch.repository.supports_chks: don't cache
[03:36] <lifeless> jam: I'm submitting an implementation of _iter_inventory_xmls
[03:36] <jam> so, given that caching the xml is probably going to end up *slower*, I don't see the benefit
[03:37] <jam> and it sort of hurts in the long run
[03:37] <lifeless> its for WT3
[03:37] <lifeless> its an extremely corner case
[03:37] <jam> but it leaves a get_inventory_xml lying around
[03:37] <jam> and now functional
[03:37] <lifeless> I know, but we use it from two places
[03:37] <lifeless> bundles and wt3
[03:38] <lifeless> we use the conceptual functionality, I mean.
[03:38] <lifeless> honestly, having repository.deserialise_inventory != _serializer.read_inventory_from_string is more of an issue for me
[03:39] <lifeless> when you say caching the xml is slower, do you mean 'merge etc operations on wt3 will be faster using CHKInventory' ?
[03:40] <lifeless> because, I'm not entirely sure I buy that, not without profiling/testing.
[03:40] <jam> lifeless: given how slow it is to build the xml... hard to say for sure
[03:41] <jam> I suppose if merge has to read the whole inventory anyway
[03:41] <jam> it would be paying that on each action
[03:41] <lifeless> jam: so, I don't have a windows machine, which is kindof needed to properly measure this, as win32 is the only place we suggest/encourage wt3
[03:42] <jam> lifeless: hm... I don't use it there
[03:42] <lifeless> 'diff', 'status' operations are both full tree
[03:42] <jam> WT4 works just fine
[03:42] <lifeless> jam: bialix often says he uses wt3
[03:42] <jam> I think that is more win98
[03:42] <jam> but now that isn't even true anymore
[03:42] <jam> since we switched to CreateFile
[03:43] <jam> LockFileEx doesn't exist in Win98
[03:43] <jam> which was how we took the os lock in the past
[03:45] <lifeless> with that patch, we're down to FAILED (failures=19, errors=17, known_failure_count=22)
[03:45] <lifeless> on my reduce workflow
[03:45] <lifeless> when they are fixed, I'll be doing a full run
[03:47] <lifeless> jam: I think https://bugs.edge.launchpad.net/bzr/+bug/336383 is fixed, do you?
[03:51] <jam> lifeless: given that --2a works with bzr.dev, I'm pretty confident it is fixed
[04:06] <AfC> Hm. So, if I have a branch that has revisions not on mainline, but there is nothing on mainline since the branch was taken,
[04:07] <AfC> why would merging that branch back create a mess?
[04:07] <AfC> (ie, I could pull, but I've been out of that habit)
[04:07] <lifeless> what sort of mess?
[04:07] <AfC> I was astonished to see merge conflicts and worse highly incorrect choices on the stuff that didn't conflict.
[04:07] <AfC> lifeless: ^
[04:07] <lifeless> did it warn about criss-cross merge?
[04:07] <AfC> n
[04:07] <AfC> o
[04:08] <AfC> (at least, not recently. Few weeks ago)
[04:08] <lifeless> check the scrollback please; its not very obvious
[04:08] <AfC> sorry?
[04:08] <lifeless> in your console?
[04:08] <AfC> what's a scrollback
[04:08] <AfC> oh
[04:08] <AfC> gotcha. Checking
[04:09] <AfC> _oh_
[04:09] <AfC> so, I was bad and didn't run `bzr status` in the 'mainline' branch before running the merge.
[04:09] <AfC> And surprise, it was "Run bzr update"
[04:10] <AfC> I hate that
[04:10] <lifeless> I'm confuse - what commands did you run?
[04:10] <AfC> I would have thought it wouldn't let me merge or something.
[04:10] <AfC> lifeless:
[04:10] <AfC> $ bzr merge ../fix-text-replacement
[04:10] <AfC> lifeless: that's it
[04:10] <AfC> but then, just now, I ran
[04:10] <AfC> $ bzr status
[04:10] <AfC> and saw
[04:11] <AfC> working tree is out of date, run 'bzr update'
[04:11] <lifeless> ah
[04:11] <lifeless> so it got a mangled merge.
[04:11] <AfC> (there were some revert --no-backups in there)
[04:11] <AfC> I assume it won't bork now that I've run update
[04:11]  * AfC tries again
[04:11] <lifeless> should be fine
[04:12] <AfC> All changes applied successfully
[04:12] <AfC> So as noted, I've backed myself into this corner before. Quite frequently, in fact.
[04:12] <lifeless> you need a flashingblinkinbeepinlight
[04:12] <AfC> I must admit it's in the category of things I should like to think I couldn't do to myself with bzr
[04:13] <AfC> lifeless: I need it to say
[04:13] <AfC> working tree is out of date, run 'bzr update' before you run 'bzr merge', stopping now so you can fix it
[04:13] <AfC> lifeless: though if you've got a spare blinkenlight, I'll borrow it
[04:14] <AfC> yeah, it's clean. Build & test passed
[04:14] <AfC> Hm.
[04:14] <lifeless> how long does a java-gnome program take to start
[04:14] <AfC> Not sure if that counts as a bug report, but it sure is a "experienced bzr user managing to screw up, fyi"
[04:14] <lifeless> yeah
[04:14] <lifeless> I'd love to make it better
[04:14] <AfC> lifeless: {shrug} < 1 second?
[04:16] <AfC> lifeless: but GTK & window manager & X sometimes take a long time to do first presentation of a new GtkWindow. That's not anything I can do anything about; http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/Widget.html#showAll() :)
[04:18] <AfC> It also takes longer when the person who is supposed to be typing `make test` is typing in an IRC channel instead :)
[04:18] <lifeless> :>
[04:53] <johnjosephbachir> what is the bzr "equivalent" to svn's switch (for a branch, not a checkout)-- in terms of appropriateness for upgrading code to a new tagged version
[04:54] <lifeless> switch
[04:54] <lifeless> oh, not a checkout
[04:54] <lifeless> bzr pull --overwrite
[04:54] <johnjosephbachir> ah okay, i'll experiment with that. thanks
[04:59]  * igc1 lunch
[05:16] <spiv> Gar, PQM failed my branch after running about 90% of the tests (test_scenarios).  Oh well, resubmitted...
[05:16] <lifeless> spiv: :(
[05:18] <lifeless> spiv: https://code.edge.launchpad.net/bzr/+activereviews - I'm trying to dominate the page :)
[05:19] <spiv> Heh.
[05:20] <lifeless> failures=12, errors=16,
[05:21] <lifeless> the numbers, they are shrinkin
[05:23] <fullermd> I can resend my log of test failures if that'll help   ;p
[05:25] <lifeless> of wha
[05:25] <lifeless> t
[05:26] <fullermd> Well, bzr.
[05:26] <fullermd> I presumed you were bemoaning the cursed fate of numeric shrinkage.  I'm all about being helpful   :)
[05:26] <lifeless> thanks
[05:44] <overshard> Hello, I have dont a few commits on a system of which I forgot to set whoami on... is there a way to change the commiter name and email on past commits?
[05:45] <lifeless> you can use uncommit + shelve to pop them off
[05:45] <lifeless> then commit again
[05:45] <lifeless> so
[05:45] <lifeless> uncommit
[05:45] <lifeless> shelve --all
[05:45] <lifeless> uncommit
[05:45] <lifeless> shelve --all
[05:45] <lifeless> uncommit
[05:45] <lifeless> commit <new options>
[05:46] <lifeless> unshelve
[05:46] <lifeless> commit <new options>
[05:46] <lifeless> unshelve
[05:46] <lifeless> commit <new options>
[05:46] <lifeless> would be how you do it for 3 revisions
[05:49] <overshard> when doing shelve --all i'm getting an error to where it can't acquire a lock on .bzr/checkout/dirstate etc etc
[05:50] <overshard> doesn't look like anything has it open
[05:51] <poolie> lifeless: could https://bugs.edge.launchpad.net/bzr/+bug/377261 be resolved by your delta fixes?
[05:52] <lifeless> yes, I expect it wouldn't wedge itself now
[05:58] <lifeless> EODing
[06:38] <lifeless> AfC: is libjava-gnome-java on ubuntu your project?
[06:38] <lifeless> or the other one
[06:40] <AfC> lifeless: uh,
[06:40] <AfC> lifeless: http://java-gnome.sourceforge.net/4.0/get/ubuntu.php
[06:40] <AfC> lifeless: from that PPA, yes
[06:40] <AfC> (sync from Debian is rather behind, I gather)
[06:42] <AfC> Guillaume has done a nice job of that package, and I nudged him on the few things that caught my eye with respect to how it was being built. So as far as I know that's good to go.
[06:44] <AfC> lifeless: I'm going to be on my way out the door shortly, but we can always chat further in #java-gnome on gimpnet should you have project specific questions.
[06:44] <lifeless> ok
[06:44] <lifeless> karmic has 4.0.9
[06:46] <lifeless> debian has 4.0.7 only
[06:46] <lifeless> so its something else
[06:47] <AfC> lifeless: I guess I should take an interest in bugging someone about that, then.
[06:47] <AfC> Where's Peter :)
[06:48] <lifeless> http://packages.qa.debian.org/j/java-gnome.html
[06:48] <AfC> Hey look! Zero bugs :)
[06:49] <lifeless> zaroo!
[06:53] <poolie> hi lifeless
[06:53] <poolie> do you want me to do anything more on 2a test failures, or is it all in flight in that branch?
[06:53] <poolie> i have probably about 3 hours here and am looking for some juicy fruit in small pieces
[06:54] <lifeless> poolie: hi
[06:54] <lifeless> I'm down to a small number of failures
[06:54] <lifeless> there are two conceptual things to do
[06:54] <lifeless> 1) drive that to zarooo
[06:54] <lifeless> 2) run the full test suite again to find things missed in the first pass
[06:54] <lifeless> both of those would be useful
[06:54] <poolie> i could probably do reviews or finish john's changes for apport
[06:54] <lifeless> I'll be picking it up again on Monday.
[06:55] <lifeless> I think getting this branch ready is essentially the most important thing we have; as its critical path for getting feedback from early testers of the impact of the change
[06:55] <lifeless> theres also 3 or 4 more changes up for review from that branch
[06:55] <poolie> yep
[06:56] <lifeless> and after we finish the branch it needs a review
[06:56] <poolie> i just don't want to churn by investigating or fixing things you've already done
[06:56] <lifeless> I'd love it if you kept the branch rolling along
[06:56] <poolie> oh i guess you'll be finishing soon
[06:56] <lifeless> its all either a) in the branch or b) not investigated
[06:56] <lifeless> poolie: I finished an hour ago - the perks of starting at 6:15
[06:56] <poolie> kk
[06:57] <lifeless> I've been spinning off little branches; if you keep the branch moving I'd encourage you to do that so that the final thing isn't a review headache.
[07:04] <AfC> lifeless: [I commented the Ubuntu bug about java-gnome 4.0.12]
[07:05] <poolie> lifeless: yeah that's why i was splitting them off
[07:06] <lifeless> poolie: right, I just made branches instead:)
[07:06] <poolie> instead of branches and bugs?
[07:06] <poolie> mm
[07:07] <lifeless> if we really need a bug for every change that lands, I know a CMM lvl 3 consultant. :)
[07:07] <lifeless> though that should be cmmi these days, I guess.
[07:09] <AfC> lifeless: if you pay me enough, I'll help you convince your boss not to do that :)
[07:09] <lifeless> :P
[07:10] <poolie> i'm really thrilled wine was so easy
[07:11] <lifeless> wine?
[07:12] <poolie> the win32 implementation
[07:12] <lifeless> I'm totally lost :)
[07:12] <AfC> That would be pronounced whine.
[07:12] <poolie> i just sent mail
[07:13] <poolie> if you install it and then install win32 python you can run bzr in a win32 environment from within your regular unix workspace
[07:14] <lifeless> oh right
[07:14] <AfC> poolie: you should have a chat with Erik de Castro Lopo about his experiences with that & automated builds & automated testing. Quite successful for libsoundfile and secret rabbit code, I gather.
[07:14] <lifeless> cool
[07:14] <poolie> mm
[07:14] <poolie> he might have mentioned it
[07:14] <poolie> i anticipated it would be more trouble than it has been so far
[07:15] <poolie> of course that may just mean.... *splat*
[07:15] <poolie> but for example
[07:15] <poolie> % winepython ./bzr missing http://bazaar.launchpad.net/~mbp/bzr/doc
[07:15] <poolie> works
[07:15] <poolie> running ssh may be hard
[07:15] <fullermd> Funny.  I was kinda looking forward, when I built this workstation, to seeing how much better stuff through wine performed...  didn't really think it through though.
[07:17] <acestar> Hello, today when trying to commit my project to LaunchPad I'm getting the following error:  bzrlib.errors.TooManyConcurrentRequests
[07:17]  * AfC waves g'weekend
[07:18] <poolie> acestar:  that's probably a followon from something else
[07:18] <poolie> did you get a previous weekend
[07:18] <poolie> cheerio afc
[07:19] <lifeless> fullermd: how so?
[07:20] <fullermd> Oh, I carefully avoided thinking about wine's stunning capabilities on a 64 bit OS...
[07:20] <lifeless> lp is down
[07:20] <lifeless> fullermd: I play WoW on wine on my i7
[07:20] <fullermd> Well, theoretically it might work if it were built as an i386 binary.
[07:21] <acestar> Hmmm, when I do a bzr update, I get a notice that says bazaar.launchpad.net has refused the SSH connection.  Any ideas?
[07:21] <fullermd> But that would take fiddling by itself, never mind that I'd also have to build 32 bit versions of half of X and a bunch of other stuff that it links to...
[07:21] <poolie> acestar: there's a problem with that system
[07:21] <poolie> people are working on it
[07:21] <lifeless> acestar: launchpad has just suffered a problem, and we're fixing it now
[07:21] <poolie> (i hope)
[07:22] <acestar> poolie: lifeless: oh ok thanks for the info!  will do local commit :)
[07:22] <poolie> we really need a system status page
[07:24] <poolie> lifeless: i'm *this* close to just creating a Launchpad system status page on help
[07:26] <lifeless> google appserver + N buttons, anyone can click, everyone can see
[07:26] <lifeless> and have it do a ping on request to the various servers.
[07:27] <poolie> i thought just on the wiki
[07:27] <poolie> even being manually updated would be an advance
[07:27] <lifeless> if auth is down you can't update it
[07:31] <poolie> interesting point
[07:31] <poolie> is that common?
[07:33] <vila> hi all
[07:33] <poolie> hi vila
[07:34] <pygi> greetings vila
[07:34] <vila> power outage here ~4 hours ago, just finished restarting everything :-)
[07:34]  * fullermd waves at vila.
[07:35]  * vila waves back
[07:35] <vila> hey pigy, poolie
[07:36] <pygi> vila, just you joke about my nick :p
[07:36] <vila> rats, no, low coffee => typo :)
[07:44] <vila> wow, ssh: connect to host bazaar.launchpad.net port 22: Connection refused ???
[07:47] <spm> vila: yeah. (hi btw! :-) ) cherry pick that went sour.  should be good now.
[07:47] <fullermd> vila: You're only allowed to connect via htpps   ;>
[07:47] <vila> hi spm ! Great, confirmed, works now
[07:48] <vila> fullermd: got that wrong ! Should have been hhtps :)
[07:48] <fullermd> Ah!  No wonder it wasn't working for me...
[07:48] <vila> anyway, I use a patched /etc/services just in case, so it works for me even with the typo....
[07:49] <spm> vila: you need: "apt-get install sl" as well then. for those "ls <--> sl" moments
[07:49] <vila> tsk tsk, sl is aliased to show-loom around here, totally different beast :)
[07:53] <spm> for shame. having a train scroll across one's screen is entertaining!
[08:14] <poolie> spiv, how did you go with the delta patch?
[08:14] <jrydberg> If I merge some specific changes, can I tell my target branch that it is up to date with source somehow?
[08:14] <jrydberg> I want to merge 1-4, 5-10
[08:15] <jrydberg> err. 1-3, 5-10
[08:15] <fullermd> i.e., not bring in 4?
[08:15] <poolie> but pretend you did?
[08:15] <poolie> after doing the merges
[08:15] <poolie> do 'bzr merge source'
[08:15] <poolie> then 'bzr revert .'
[08:16] <poolie> this will keep the merge marker but revert the file changes
[08:16] <spiv> poolie: landed!
[08:16] <poolie> then commit
[08:16] <poolie> woo way to go
[08:16] <poolie> have a weekend on the house
[08:16] <spiv> Hah.
[08:16] <jrydberg> fullermd: exactly
[08:16] <poolie> is it nice and fast?
[08:16] <fullermd> Well, you could do three merges, doing as poolie said on the middle one.
[08:16] <spiv> Actually, it's a pretty busy weekend, weddings and things, but I'll be sure to enjoy it :)
[08:16] <fullermd> Another option is to just merge everything, then make another commit rolling back 4 afterward.  That may be clearer.
[08:17] <jrydberg> Thank you. Worked like a charm.
[08:18] <fullermd> Either is appropriate if you don't want the changes in 4; it's still in the history though, so if you want to not have it for reasons like "that version contains my PGP passphrase" or the like, it won't do what you want.
[08:23] <lifeless> spiv: after some testing, say wed/thur we should ask for a cp to launchpad production
[08:24] <lifeless> spiv: to get larger scale know-how.
[08:24] <spiv> lifeless: +1
[08:31] <vila> spiv: congrats for the wedding and enjoy :-)
[08:32] <spiv> vila: well, my wedding was a while ago now :)  By I can pass on a your congratulations to my friend if you like ;)
[08:32] <vila> lol, sorry for the misunderstanding then :-)
[09:15]  * igc1 dinner
[09:49] <bialix> I need some advice. I have central bzr server where all finsihed stuff present. I have MANY local branches that either mirrors of branches on central server or they're feature branches merged or not merged yet. Sometimes I feel the need to reduce this burden and clean all mirrors or finished feature branches from the disk. How you deal with this?
[09:56] <wgrant> bialix: I use the bzr-removable plugin.
[09:56] <vila> bialix: I just delete (rm -fr) the merged branches when I grow tired of seeing them
[09:56] <bialix> bzr-removable? I'll check it, perhaps it's what I need
[09:56] <bialix> vila: it's not easy to do for me.
[09:57] <vila> bialix: But the biggest picture is that I'd like a tool to help me track all the branches I'm working on.
[09:57] <bialix> vila: after merge of feature branch I need to test it on real hardware (I'm embedded system engineer) so sometimes I need to fix something after testing
[09:57] <bialix> this is the problem
[09:58] <bialix> I can't run buildbot to auto test my firmware ;-)
[09:58] <vila> bzr-removable is a step in the right direction but doesn't address needs like: are my plugins up-to-date ?
[09:58] <vila> bialix: in that case it means you're not done with the branch, when I said merged, I abused the term to mean, I'm done with it
[09:59] <bialix> well, we build the final product as collection of many smaller components. So problem for me is the amount of different branches for different components
[09:59] <bialix> it begins to out of my control
[09:59] <vila> I use 'check' with some success on embedded software projects where only the high levels of the application couldn't be tested automatically...
[10:00] <vila> argh, several uprocs involved or just software components ?
[10:00] <bialix> several devices involved
[10:01] <bialix> main PC with Linux with several software components too
[10:01] <bialix> because main software works with real hardware (via COM-ports or USB) it's not easy to unittest it
[10:01] <vila> backward/forward compatibility involved or do you deploy on all components at once ?
[10:01] <bialix> backward compatibility -- yes, very hard
[10:02] <bialix> for some hardware I have branch for every customer we support
[10:02] <bialix> just because I have memory restrictions and unable to build universal firmware
[10:02] <vila> so, your manager knows about the suport costs right ?
[10:03] <bialix> we very small company. I'm main dev and manager as one man
[10:03] <vila> bialix: ha ! Of course you have memory restrictions ! Where will be the fun in working in embedded software otherwise !!!!
[10:03] <bialix> yeah
[10:04] <vila> well, your *boss* knows about the costs ? Or if it's your own company, *you* know about the support costs :)
[10:04] <bialix> wgrant, vila: description of bzr-removable is very promising! thansk for the tip
[10:04] <vila> Automated tests are all about transferring support costs into building and maintaining a test framework :-D
[10:05] <bialix> vila: I'm not boss, but yes, I'm trying to explain why we need to push our solution to universal side
[10:05] <bialix> vila: of course, until you need to test some specific GUI or sensors that require specific environment
[10:07] <bialix> jml: why you put plugin code for bzr-removable into subfolder?
[10:08] <bialix> jml: it makes hard to install it
[10:08] <vila> well, the last project I was involved used a specific UI on the device (buttons and LCD display), yet I was able to use pyGtk on *windows* (wink) to emulate the UI and some sensors, the rest of code was common between the PC and the device...
[10:08] <vila> so most of the work could be done on the PC without the need to flash or debug in the field... they were quite happy about it...
[10:09] <bialix> I have similar emulator now for our terminals. But I'm using Tkinter and PIL. It works great
[10:10] <bialix> rats, bzr-removable does not work on windows
[10:10] <bialix> os.path.samefile?
[10:10] <vila> :-/
[10:10] <poolie> hi bialix
[10:10] <bialix> hi poolie
[10:11] <poolie> i hoped my mail about wine might please you
[10:11] <poolie> now i can experience os lock problems more often :)
[10:11] <bialix> poolie: :-)
[10:11] <bialix> yes, it is indeed
[10:11] <bialix> OSLMD!
[10:11] <poolie> +1
[10:12] <poolie> the main thing i have at the moment is that i don't have paramiko installed there, so can't do networking
[10:12] <poolie> but i could either install paramiko or the bzr installer
[10:12] <bialix> paramiko has not extra dependencies
[10:12] <bialix> only pycrypto
[10:12] <bialix> and pycrypto has installer
[10:13] <bialix> BzrWin32Installer page or WindowsInstall provides the links
[10:13] <bialix> it's not so hard
[10:13] <bialix> of course it's not apt-get
[10:13] <bialix> maybe easy_install will work
[10:13] <poolie> right
[10:14] <poolie> i was actually going to use it as a test run for easy_install
[10:14] <bialix> it will be interesting to hear
[10:14] <bialix> about easy_install
[10:14] <bialix> maybe you'll check full round
[10:15] <vila> bialix: http://docs.python.org/library/os.path.html#os.path.samefile
[10:15] <bialix> easy_install bzr
[10:15] <bialix> vila: right, but was is closest equivalent for samefile on Windows? just compare abspaths?
[10:16] <vila> return path1 == path2
[10:16] <bialix> ok
[10:16] <LarstiQ> is that what it does?
[10:16] <LarstiQ> bialix: you can have links in Windows, right?
[10:17] <bialix> yes, but not easy
[10:17] <bialix> hardlinks
[10:17] <bialix> symlinks only for directories
[10:17] <LarstiQ> ok
[10:19] <bialix> and because I have no links on my disks anyway I'll follow vila's advice
[10:30] <bialix> I don't understand how bzr-removable supposed to work
[10:37] <awilkins> You can have symlinks in Vista and up
[10:37] <awilkins> "Junction points" are available in XP and below (folders only)
[10:37] <bialix> I'm on XP and below
[10:38] <awilkins> Most people are
[10:43]  * bialix mutters: something need to be done about branch aliases like :push, :parent. Why people should convert them explicitly?
[10:43] <bialix> grr
[10:48] <bialix> about bzr-removable: my sequence of actions now to detect is it safe to delete branch: run bzr st, check for .shelf, run bzr info and see is it pushed, run bzr missing :parent or bzr missing :push
[10:49] <poolie> bialix: yes the aliases don't seem to work in every place
[10:49] <poolie> and i agree about the workflow for removing things too
[10:51] <bialix> perhaps I need write my own removable
[10:56] <poolie> mm
[10:56] <poolie> maybe
[11:01] <poolie> i'd like to consider it as part of the ui 3 thing
[11:03] <bialix> sorry, I've lost connection
[11:05] <fullermd> I wish somebody would tell me where I could download an extra 8 hours in the day.  Then maybe I could write out ui 3 thoughts before...   y'know.  3.
[11:09] <bialix> 3?
[11:16] <jrydberg> ui 3?
[11:19] <awilkins> UI 1 : big red off switch
[11:19] <awilkins> UI 2 : Windows
[11:19] <awilkins> UI 3 : Something better   ?
[11:20] <awilkins> Oh, damn, WinXP installs fast in a VM
[11:20] <awilkins> I guess the host hardware is somewhat meaty
[11:26] <poolie> jrydberg: http://doc.bazaar-vcs.org/devnotes/bzr-2009-ui-refresh.html
[11:27] <lifeless> awilkins: also, 'hits disk' isn't well defined in a vm :)
[11:27] <awilkins> lifeless: Given the amount of RAM this box has I wouldn't be surprised if the entire partition was cached
[11:32] <poolie> vila did you mention a bug with some failures on karmic?
[11:32] <poolie> i seem to have a new failure in TestLocale
[12:54] <awilkins> I think the win32 build page is a bit out of date
[13:10] <garyvdm> Hi vila
[13:10] <vila> hi garyvdm
[13:10] <garyvdm> How are you?
[13:12] <vila> garyvdm: fine thanks, how about you ? You seem to be pretty active in qbzr these days :)
[13:13] <igc1> night all
[13:15] <vila> night Ian
[15:20] <denys> vila: keys and certs from ssl_certs are not installed by setup.py - shouldn't they be?
[15:22] <vila> denys: right you are ! There is even a bug filed about it. Feel free to fix :D
[15:22] <denys> vila: i'll add the fix to my branch
[15:23] <vila> denys: it's easier if you have a single intent by merge proposal, so if you want to fix bug #392401, it's better to fix only that in a dedicated branch
[15:35] <vila> jam: *now* the changes you made to the build config are responsible for the failures :-) At least the bzrtools tag not existing on the public branch that is...
[15:41] <denys> vila: ok, I push a fix https://code.launchpad.net/~denys.duchier/bzr/bug-392401
[15:42] <vila> denys: great ! now, just do 'bzr lp-open' in your branch and click the 'Propose for merging' button !
[15:44] <denys> vila: it's already done I think (but this is my first day using launchpad, so I may have screwed up)
[15:45] <vila> denys: perfect
[15:51] <vila> denys: already approved by jam, I'll add a NEWS entry and merge
[15:52] <denys> vila: thank you
[15:52] <awilkins> Bah, now I have to install the platform SDK
[15:52] <awilkins> Or something
[15:53] <awilkins> I'm missing MSCVRT90.dll
[15:55] <vila> denys: thank *you* and congrats, your first patch is currently processed for landing in bzr.dev :D
[15:59] <awilkins> Who's building the Windows installers and how do they get the 2.6 Python installer extensions building?
[16:00]  * vila whispers jam is building the windows installers
[16:07] <denys> hmm... I have pushed new revisions to my bzr.ssl branch on lp, but the diff that is shown on the merge review page is still the old one.  is that normal?
[16:08] <james_w> denys: yeah...unfortunately
[16:09] <denys> how are people supposed to review the tip of the branch?
[16:09]  * awilkins woots because he managed to get `make python-installer` to finish
[16:09] <james_w> by generating the diff themselves apparently
[16:09] <denys> that's a little bit on the sucky side :-(
[16:10] <james_w> bug 338002
[16:12] <vila> denys: you should 'resubmit' aka inform launchpad that your merge-proposal is superseded by a new one
[16:13] <denys> vila: ah... ok
[16:14] <vila> denys: the rationale is that the diff represent the difference between the two branches at the time of submission, because people comments refers to that, so the diff itself shouldn't change...
[16:15] <denys> vila: when you say resubmit, you mean click on the "propose for merging" link again?
[16:16] <vila> denys: don't know if that will work, no, I meant click the 'Status' near the top of the page of your actual mp: https://code.edge.launchpad.net/~denys.duchier/bzr/bzr.ssl/+merge/10147
[16:17] <vila> denys: the little pen icon to be precise
[16:18] <denys> vila: pfff.... that's hard to discover!
[16:18] <vila> denys: EWRONGCHANNEL :-)
[16:19] <vila> denys: try https://edge.launchpad.net/launchpad/+filebug instead :)
[16:19] <vila> denys: but yes, that one is tricky, the UI is still worked on AFAIK
[16:24] <der|> hi, I'm getting the following error when trying to commit on my project:   bzr: ERROR: 4f7d6b49ca2b8f885b0bd192a5e89b62.rix is not an index of type <class 'bzrlib.index.GraphIndex'>.
[16:26] <der|> seems like my branch got corrupted :/, I can't uncommit, raises the same error
[16:31] <vila> denys: hmm, looks like some mail didn't reach you before you resubmit...
[16:32] <vila> denys: I thought you've seen my mail about wrap_socket but apparently no :-/
[16:48] <DonDiego> hi everybody
[16:49] <DonDiego> i'm working on a gnu arch --> bazaar transition
[16:49] <DonDiego> i had great trouble finding baz-import
[16:49] <DonDiego> it's no longer part of bzrtools, but the websites do not reflect this
[16:50] <DonDiego> maybe you could update them
[16:50] <DonDiego> thx
[16:50] <vila> DonDiego: it's a wiki, your experience is certainly worth reporting !
[16:52] <DonDiego> http://bazaar-vcs.org/ is not a wiki afaict
[16:52] <vila> DonDiego: it is
[16:52] <vila> DonDiego: look at the small print at the end of the page :)
[16:52] <DonDiego> saw it..
[16:53] <DonDiego> i'd prefer if somebody who knew what they were doing edited it instead of me
[16:53] <vila> DonDiego: damn, there was changes here, how do I logged out ? :)
[16:54] <DonDiego> ?
[16:55] <vila> DonDiego: but nobody knows what you did and where you looked, fixing your modifications (if needed !) will be far easier that interviewing you to find what should be chaged
[16:55] <vila> s/chaged/changed/
[17:09] <CaMason> hi guys. I've got a project that has a sub-folder that exists as a linked tree (I believe)
[17:10] <CaMason> I want to move this out into a seperate repo, and occasionally move the libs in manually. Can I just do `bzr split` ?
[17:12] <CaMason> or is it actually 'join' ?
[17:21] <kiko> hey
[17:22] <kiko> does anyone know if 1.18 is due today?
[17:28] <james_w> kiko: I can't find a metronome that states when it is due
[17:28] <james_w> I can't even find the mail saying that it will be 1.18 not 2.0 now
[17:39] <kiko> james_w, I'm a bit surprised because I see a milestone with a bunch of fixed bugs so..
[17:39] <kiko> https://edge.launchpad.net/bzr/+milestone/1.18
[17:39] <kiko> the only bug for 1.18 and not rc1 would be 398608
[17:40] <kiko> I wanted to find somebody to verify https://bugs.edge.launchpad.net/bzr/+bug/393677
[17:51] <CaMason> how can I convert a rich-root-pack into a pack-0.92 ?
[17:58] <CaMason> I've got a project that doesn't need rich root ( no idea why it was made like that). I just want to convert it over to default (pack-0.92) so that I can I can move it into this shared repo
[18:06] <vila> CaMason: the new format (2a) that will become the default with bzr-2.0 is rich-root, so getting away from rich root now is not a good idea
[18:06] <CaMason> so I'd be better off upgrading to rich-root?
[18:08] <CaMason> basically I want to have /home/bzr/projects/myproject/ and be able to have several folders (trunk, branches, releases) that I can checkout individually
[18:10] <CaMason> not really sure which format I need to use :'(
[18:13] <CaMason> I'm using bzr 1.13.1 (ubuntu)
[18:16] <CaMason> I'd prefer to have them all as pack-0.92 at the moment, as that's default
[18:18] <vila> CaMason: Upgrading to rich-root is a safe bet, you can either use --1.9-rich-root or go straight to --2a
[18:18] <vila> CaMason: If you prefer, just wait for 2.0 to be released
[18:19] <CaMason> ok, well I'll wait - but any idea how I can get my project layout sorted for now with pack?
[18:20] <CaMason> I'm just concerned that I'm going to have problems again in the future if I choose --1.9-rich-root
[18:20] <vila> you can't get from rich-root to non rich-root
[18:21] <vila> the single problem is that rich-root and non rich-root are not compatible and that you can't go back,
[18:21] <CaMason> ok. so what is your recommendation for now?
[18:21] <CaMason> bzr upgrade --1.9-rich-root?
[18:22] <vila> CaMason: wait 2.0, --1.9-rich-root, --2a are the options in roughly safest order
[18:23] <vila> how big are your projects ? # revisions, # files ?
[18:23] <CaMason> only small really
[18:23] <CaMason> <100 files each
[18:24] <vila> no problem then, upgrade to 2a
[18:24] <CaMason> when will 2.0 be out?
[18:24] <vila> soon :)
[18:25] <vila> 1.18 is about to be released and also be the last monthly release befor 2.0
[18:26] <lvh> does anyone know any distributed issue trackers that dont suck and work nicely with bzr?
[18:26] <lvh> optimal would be the ability to sync with launchpad but I'm guessing this is mostly impossible
[18:26] <lvh> or at least doesnt exist yet:-)
[18:27] <LarstiQ> lvh: which have you tried?
[18:27]  * kfogel is away: looooooooonch
[18:27] <lvh> LarstiQ: ditz.
[18:27] <LarstiQ> lvh: the only (real) distributed one I know is Bugs Everywhere
[18:27] <lvh> and BE, which is basically ditz but in ruby.
[18:27] <lvh> err
[18:27] <lvh> well, ditz but *not* in ruby
[18:27] <lvh> :-)
[18:28] <lvh> they have a number of problems, mostly that it's too hard to submit bugs
[18:28] <lvh> people should not have to do a full checkout
[18:30] <lvh> I like my bug reporters, I want to make their lives harder
[18:30] <lvh> there's a "don't" in that sentence somewhere
[18:30] <denys> vila: I resubmitted with "wrap_socket" mods and cleaned up the tests a bit (but not quite separated out because they are _litterally_ the same tests).  see if you like it better now
[18:32] <vila> denys: I know they are even *exactly* the same tests, that's why I said you want to parameterize them, look at various load_tests methods, you want a class where you set your 'use_ssl' attribute in load_tests() so that the test is written once but instantiated (and executed) twice
[18:32] <davidstrauss> Can I configure EOL filters just on the server side, or does it have to be on the client, too?
[18:33] <LarstiQ> lvh: you could something on the web to feed things into one copy
[18:34] <lvh> LarstiQ: one copy?
[18:34] <lvh> web interface with commit access to an incoming-bugs branch?
[18:34] <LarstiQ> lvh: yeah
[18:35] <LarstiQ> lvh: ala ikiwiki or hatta
[18:35] <denys> vila: I used common helper methods with a use_ssl parameter (no attribute anymore)
[18:35] <lvh> i dont know any of those
[18:35] <LarstiQ> lvh: dvcs backed wiki(compiler)s
[18:35] <lvh> oh
[18:36] <lvh> LarstiQ: so "accepting" bugs could be cherrypicking commits into working branches
[18:36] <vila> denys: right, but you shouldn't have :-/ You identified some tests that needed to run against the two kind of servers, more will come
[18:36] <LarstiQ> lvh: yeah
[18:37] <lvh> does anyone who works on/with bzr a lot think that that would be disgusting?
[18:37] <LarstiQ> lvh: I think that would be fine
[18:38] <lvh> okay, how about displaying bugs
[18:38] <lvh> syncing with launchpad would be mostly impossible without modifying launchpad
[18:39] <LarstiQ> lvh: use launchpadlib?
[18:40] <lvh> also im not entire sure that lp would be happy with the extra load that I might generate from generating bug state from repo state :-)
[18:41] <LarstiQ> gah, out of power, again
[18:42] <vila> denys: test_osutils.py contains a rather simple load_tests() you can look at in parallel with the TestDirReader class
[18:42] <vila> in fact the previous version of your tests was closer to the desired result that your actual one
[18:42] <vila> s/that you/than your/
[18:45]  * vila EODing
[18:50] <denys> vila: thanks, I am looking, but all this really clever loading magic takes a while to puzzle out
[18:53] <lvh> LarstiQ: the biggest problem I can see is that bug state inspection should be easy, and people dont understand bugs-over-time.
[18:53] <CaMason> I've upgraded my files into --1.9-rich-root, and one of the folders is throwing up an error when using bzr-trac: AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'
[18:54] <davidstrauss> Is there a way to enforce EOL rules on the server?
[18:54] <vila> denys: you want something like (untested) http://paste.ubuntu.com/253293/
[18:56] <vila> denys: and thenos mething like http://paste.ubuntu.com/253297/
[18:56] <vila> denys: and then something like http://paste.ubuntu.com/253297/
[18:56] <vila> interesting typo, I should really EOD now :)
[18:57] <vila> denys: ^ does that help ?
[18:58] <vila> denys: anyway, if you can't get them right, wait for spiv review, I think he'll ask for some more tweaks/tests
[18:59]  * vila really gone now
[18:59] <denys> vila: it's going to, I am sure ;-) but I am going to have to study this carefully (I hate not understanding)
[19:00] <vila> denys: good, feel free to ask questions when do merge proposals then, we welcome that :)
[19:17] <CaMason> any thoughts on why I get this in trac? "AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'"
[19:17] <CaMason> only happens on one particular repo, that was upgraded using `bzr upgrade --1.9-rich-root`
[19:19] <emmajane> beuno, any predictions for Monday yet? :)
[19:21] <beuno> emmajane, I've done my part, I now need to get someone assigned
[19:21] <beuno> we won't have the design by Monday, that I know
[19:21]  * emmajane nods
[19:21] <beuno> but, "next week" sounds plausible
[19:21] <beuno> it's been my #1 urgency for the past 3 days
[19:21] <emmajane> boo for "next week" and "plausible" but yay for "urgency" :)
[19:22] <beuno> heh
[19:22] <beuno> emmajane, I'm trying to get the HTML as well
[19:22] <beuno> so we iterate over a design
[19:23] <beuno> and then get the HTML/CSS for the approved design
[19:24] <emmajane> beuno, oh, cool!
[19:25] <beuno> emmajane, so maybe that will make up for lost time
[19:25] <emmajane> :)
[19:27] <emmajane> beuno, I would be delighted if they used 960.gs or some other CSS framework. it'll make inner pages and applying some of the design to other parts of the site (e.g. docs and wiki) a lot easier.
[19:27] <emmajane> beuno, I'm most familiar with 960, but I've worked a little with some of the others.
[19:27] <CaMason> argh bzr-trac is barfed on my install :/
[19:28] <CaMason> only one of the branches within the shared-repo will show
[19:28] <CaMason> all others show "AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'"
[19:29] <beuno> emmajane, I can't promise that, but I can try  :)
[19:30] <emmajane> beuno, thanks :)
[19:33] <jwhitley> hi all.  Is there currently (1.17) a way to nest two preexisting trees?  split doesn't appear to handle this, only breaking off a versioned subdir into a tree.
[19:39] <micahg> hi, is there an easy way to import all of the history from an svn branch to a bzr brach?
[19:46] <johnjosephbachir> whenever i try to do anything over bzr+ssh (init-repo, push), i get a 'wrong client version' message
[19:47] <johnjosephbachir> do my local and server clients have to match up? i thought that for modern versions of bzr i only had to worry about the formats
[19:50] <CaMason> say I have /project, and I also have /project/lib/myplugin, what's the best way to bring the code from an external branch into /project/lib/myplugin ?
[19:50] <CaMason> ack brb dinner
[19:55] <micahg> is there a way with bzr to see the history for just one file?
[20:05] <jderose> micahg: bzr log file-name-1, file-name-2, ...
[20:06] <micahg> jderose: is it possible with a gui so I can see the revisions as well?
[20:07] <jderose> micahg: i haven't really played with any of the gui's, so i'm not sure.
[20:12] <jderose> micahg: seems like you can do it in loggerhead: go to Files, find the file, and then click "view changes to this file"
[20:12] <jderose> micahg: for example: http://bazaar.launchpad.net/~bzr/bzr/trunk/changes?filter_file_id=setup.py-20050314065409-02f8a0a6e3f9bc70
[20:13] <alexharrington> Heya. Puzzled about line endings conversion. I know I need to upgrade to --1.14 which I thought I'd done, but it still doesn't seem to work
[20:14] <alexharrington> Anyone advise on how I should upgrade an entire launchpad project to use the newer format so we don't keep getting problems with mangled line ends?
[20:18] <micahg> jderose: yeah, but my repo isn't on LP :)
[20:18] <micahg> that would've been my first choice
[20:18] <jderose> micahg: then that's all i got.  ;)
[21:35] <ronny> yo
[21:35] <ronny> is there a simple way to do what bzr ignore does from the api?
[21:38] <struberg> hi folks, good evening!
[21:39] <struberg> I have a quick question about bazaar protocols
[21:39] <beuno> ronny, have you looked at what the command does?
[21:39] <struberg> I currently try to fix the maven-scm-provider-bazaar because we don't use authentication for bzr+ssh for example
[21:40] <struberg> currently the code support the following protocols: FILE, FTP, SFTP, AFTP, HTTP, HTTPS
[21:40] <struberg> anyone who can tell me what protocols are missing and where I may read more about it?
[21:41] <ronny> beuno: meh, every time i do that i end up wasting 1-2 hours
[21:42] <beuno> ronny, there's always a learning curve...  :)
[21:42] <beuno> that said
[21:42] <beuno> ronny, http://bazaar-vcs.org/Integrating_with_Bazaar
[21:42] <beuno> don't know if there's an example there
[21:42] <beuno> if not, and you do spend those couple of hours
[21:42] <beuno> please add to that  :)
[21:43] <ronny> beuno: im writing a lib to abstract the different vcs's
[21:43] <lifeless> import ignores
[21:43] <struberg> ronny: in which language?
[21:43] <lifeless> igores.tree_ignores_add_patterns(tree, ptterns)
[21:45] <ronny> struberg: python of course
[21:46] <ronny> lifeless: nice, thanks
[21:46] <mobodo> if I have a web interface that I'd like listed on the bazaar plugin page, should I send an email or can I just tell somebody here?
[21:47] <lifeless> ronny: (looking the command :P)
[21:47] <beuno> mobodo, just add it, it's a wiki
[21:47] <mobodo> ahhh, just got to login I guess :)
[21:51] <ronny> lifeless: at some point you guys really should work on killing code-size, im still in fear by the sheer amount of code in bzr
[21:51] <struberg> I assume the bzr protocol supports authentication in the form bzr://username:password@server... ?
[23:02] <elmo> hey, possibly a stupid question, but what's the bzr magic for 'show me the changes in the WT relative to rev $foo'?
[23:04] <lifeless> set -r $foo
[23:04] <lifeless> bah
[23:05] <lifeless> bzr st -r $foo
[23:05] <lifeless> or diff if you want a diff
[23:05] <lifeless> elmo: ^
[23:05] <elmo> lifeless: that doesn't seem to DTRT
[23:06] <lifeless> perhaps I don't know what you mean then.
[23:06] <elmo> if I do that, it tells me about an added file blah, but blah wasn't in $foo, and bzr cat -r $foo blah, confirms
[23:06] <elmo> lifeless: I have a tree, with some changes.  and i want to know how my current tree compares to revision 70
[23:06] <lifeless> ok
[23:06] <elmo> I could just bzr branch -r 70 and diff, but that seems .. inelegant
[23:06] <lifeless> and the file blah is in your tree and not in 70
[23:07] <elmo> blah is neither in my tree, nor 70
[23:07] <lifeless> orly
[23:07] <elmo> it got added and removed, somewhere between 70 and now
[23:07] <lifeless> let me test
[23:08] <elmo> lifeless: le sigh
[23:08] <elmo> lifeless: i'm so sorry, apparently I'm on epic levels of crack
[23:08] <lifeless> ?
[23:09] <lifeless> elmo: what was going on?
[23:09] <elmo> lifeless: the file is in my current tree, I'm just a muppet
[23:09] <lifeless> heh
[23:09]  * lifeless cancels his test
[23:09] <elmo> I was utterly convinced I'd rm -fr'ed /etc/apache2 on this box, but apparently not
[23:10] <lifeless> tricky things those fr's
[23:14] <fullermd> A fr once bit my sister...