[00:00] <poolie> that makes sense to me
[00:00] <poolie> under /srv or something?
[00:01] <bradm> yeah, /srv/pqm.ubuntu.com/chroot-pqm-bzr-amd64-lucid
[00:03] <bradm> poolie: okey, all changed.
[00:03] <poolie> thanks, we can call that ticket done then if you like
[00:04] <poolie> i don't know if it's easy for you to then do 42500(?) about the dchroot warnings, or if that's with someone else
[00:04] <bradm> poolie: did you want to leave the old chroot hanging around until the end of the week?
[00:07] <poolie> if that's not too much trouble
[00:08] <bradm> nope, thats fine, I'll just reply to the ticket saying its all done bar the shouting^Wremoval, and close it off after I get rid of it on Friday after checking with you
[00:09] <poolie> you could even lodge an at job now
[00:09] <poolie> though i would find an at job doing 'rm -rf' a little scary to set up myself :)
[00:10] <poolie> ah, and of course it will need care if anything is bind mounted
[00:11] <bradm> poolie: yeah.
[00:11] <poolie> brb, rebooting natty
[00:21] <vila> poolie: passing around, but there was a problem with pqm, see https://code.launchpad.net/~jelmer/bzr/importwarning/+merge/57184
[00:23] <poolie> oh hi vila
[00:23] <poolie> thanks for pointing that out
[00:25] <poolie> vila, i had inferred that this was just a change due to moving from 2.4 to 2.6
[00:25] <poolie> that it now raises a warning rather than an error
[00:25] <poolie> does the patch fix it?
[00:26] <vila> yes, at least it landed, I'm surprised we never encounter it though, so I wonder if there isn't something weird in the pqm setup
[00:27] <poolie> vila, it may be that pqm runs selftest with -Werror and we normally don't?
[00:27] <poolie> or i normally don't
[00:27] <poolie> or actually does selftest turn that on itself?
[00:27] <vila> IIRC all branches are configured independently and each one specify PYTHON=python2.4, so I don't know if only trunk were updated for that or all other branches too (well at least the ones we still need: 2.3, 2.2, 2.1 may be not 2.0)
[00:27] <vila> ha right, yeah good point
[00:28] <vila> tsk, I even mentioned to jelmer that -Werror may be involved...
[00:28] <poolie> bradm, ^^ can you just check we don't have any more PYTHON= things hanging around?
[00:28] <vila> I don't think selftest turns it on, it's make check I think
[00:28] <poolie> that was what i thought, but i'm not sure without checking
[00:30]  * jelmer waves
[00:30] <jelmer> vila: you're up late :)
[00:31] <bradm> poolie: looking..
[00:31] <vila> jelmer: yeah, can't sleep :-/
[00:31] <bradm> poolie: nope, definately no PYTHON= in the bzr-pqm.conf
[00:31] <poolie> excited about your trip?
[00:31] <poolie> thanks
[00:31] <poolie> or, trying to fix everything in bzr before you go? :)
[00:44] <vila> poolie: hehe, probably hafl excited and half worried about my daughters and half trying to finish fixing the remaining bugs ;)
[00:50] <poolie> are they going to be looking after themselves while you're away?
[00:51] <vila> yup for roughly a week, after that they'll be with family
[00:51] <vila> first time I managed to convince Val, so now *I'm* worried ;)
[01:04] <spiv> Good morning.
[01:23]  * spiv reboots into natty, hopefully
[01:34] <inductiveload> hello! how do i create a patch containing binary files?
[01:37] <inductiveload> i just added some icons to a project, and i'd like to send the changes as a patch, but all it says in the diff is "Binary files ....... and .......... differ"
[01:44] <inductiveload> and when i try to do --format=svn (it's an SVN repo i want to contribute a patch to), it complains about it being a binary file
[01:48] <spiv> inductiveload: the patch format doesn't support binary files.
[01:48] <spiv> inductiveload: bzr's native merge directives support them
[01:48] <spiv> inductiveload: but I don't know that SVN has a builtin tool to consume patches to binary files.
[01:48] <inductiveload> ok
[01:49] <spiv> (If it does, then it'd probably be a bug in the bzr-svn plugin if --format=svn doesn't emit that)
[01:49] <inductiveload> then what would be the "right" way for me to hack on an SVN project and submit a patch (or patch-like sometihng) that can be used to apply my changes?
[01:50] <inductiveload> i've only ever submitted normal diffs to things before, and never a binary file
[01:53] <idnar> favourite command-line of the day: bzr missing --mine-only --include-merges :parent
[01:53] <mDuff> inductiveload, ...well, there's xdelta, but the real issue is that there _isn't_ any format which will show the differences between two binary files in a human-readable and mergable way, and at that point you might as well just submit the whole new file unless it's a size/bandwidth constraint.
[01:53] <mDuff> (err, maybe it's xxdelta)
[01:55] <inductiveload> right, so i just have to send an archive with the image folder saying "paste this into the root directory"?
[01:56] <inductiveload> there's no size or bandwidth problem, it's just that I thought there'd be a way to pass over a single file holding all the changes i'd made
[01:56] <idnar> for binary files, svn diff just says "Cannot display: file marked as a binary type."
[01:58] <idnar> and I don't think svn has a command for *applying* patches at all?
[01:58] <inductiveload> i have no clue, i've never used svn, that's why i'm using bzr
[01:59] <inductiveload> but the sourceforge repo is SVN, so how do i get my change across, short of tarring the whole damn thing, and letting them make a diff?
[02:00] <spiv> inductiveload: ask the developers how they'd like to receive changes
[02:00] <inductiveload> ok, i tohught there would be an "easy" way to do it ;-)
[02:00] <spiv> inductiveload: or e.g. send them the xxdelta, but also explicitly say "if you'd prefer this in another format, just let me know"
[02:01] <spiv> Not that I know of, unfortunately.  But talking to people is usually not *too* hard ;)
[02:01] <inductiveload> :-p ack....interaction....
[02:22] <poolie> hi there spiv
[02:23] <poolie> spiv i'm going screen and un-hide the ubuntu bzr bugs
[02:27] <inductiveload> spiv and co, thank you for you help
[02:27] <spiv> poolie: sounds good.
[02:27] <spiv> inductiveload: you're welcome.
[02:27] <inductiveload> and thanks for making bzr - it's great!
[02:29] <spiv> poolie: I've been spending the morning mainly getting used to natty & unity, and about to dive back into that pack retry bug
[02:30] <spiv> (I'm going to have to retrain my fingers a bit; I used to use Super-<num> to switch workspaces…)
[02:36] <poolie> ok
[02:36] <poolie> how's hamster?
[06:51] <vila> poolie: almost there ;) For hamster on natty, Alberto Milone started a project to put hamster into the indicator area: http://albertomilone.com/wordpress/?p=502
[06:51] <poolie> spiv, well, i hit some more natty bugs including the rather amusing 758335
[06:52] <poolie> but now, for sure, bug re-publicizing
[06:52] <poolie> hi vila
[06:52] <poolie> that sounds good
[06:52] <vila> poolie: I didn't found the time to test it yet, only looked at the code which seems simple enough
[06:52] <poolie> i was thinking about puttting it into couch so it would sync across machines
[06:52] <poolie> there may be easier ways
[06:53] <vila> poolie: hehe was about to mention my trick
[06:53] <thomi> hi - I'm wondering if it's a bug that 'bzr qlog' shows revision numbers starting at 1 and 'bzr log --line' shows them starting at 0? It's really confusing when 'bzr revno' doesn't show the same number as 'bzr qlog'.
[06:53] <thomi> is this worth reporting? It seems like something you probably already know about...?
[06:54] <vila> poolie: there is a single file you can copy across hosts (~/.local/share/hamster-apple/hamster.db)
[06:54] <vila> poolie: I have tested that it can be copied while no activity is tracked
[06:55] <poolie> that's true
[06:55] <poolie> maybe i should just do that
[06:55] <poolie> thomi, bzr log --line really shows a revision 0?
[06:55] <vila> good enough for me, I never track two activities at once
[06:55] <poolie> please do file if so
[06:58] <thomi> poolie: pretty sure....I'll double check thanks
[06:59] <poolie> vila, i was a bit concerned it would touch the file even if nothing's being tracked
[06:59] <poolie> probably unlikely
[07:02] <vila> poolie: it seems to update it only when needed
[07:02] <vila> hehe, probably too vague a description :-)
[07:03] <spiv> thomi: interesting, is the very first revision a merge perhaps?
[07:03] <vila> but I did some copys back and forth across several dats
[07:03] <thomi> spiv: possibly - I just noticed that it doesn't happen to all branches - but I have access to the branch where I noticed the issue
[07:04] <thomi> err, how would I tell? in qlog it doesn't show as a merge...
[07:05] <thomi> unfortunately I cannot make the branch public, it's not open source code :(
[07:05] <spiv> Oh wow, doing a merge in the initial rev gives some screwed up results!
[07:05] <spiv> revno -174 anyone?
[07:06] <poolie_> spiv, there might already be a bug for that
[07:06] <spiv> Yeah, I think so too, this looks familiar
[07:07] <thomi> oooh - if I do 'bzr log --include-merges' the numbering becomes identical to what qlog reports
[07:07] <spiv> 'bzr init foo; cd foo; bzr merge $otherbranch; bzr ci' makes a branch with broken revision-info according to 'bzr check'
[07:08] <thomi> nice...
[07:09] <spiv> thomi: what does 'bzr check --branch' report for your branch?
[07:09] <spiv> poolie_, thomi: bug 522740
[07:10] <poolie_> yup; probably should bump that up to at least medium
[07:12] <thomi> found error:Internal check failed: revno does not match len(mainline) 15 != 16
[07:15] <thomi> so, is there an easy way to "fix" my branch?
[07:19] <spiv> thomi: bzr reconcile
[07:24] <thomi> cool - that works a treat, thanks
[07:36] <vila> hi all ! Last run ;)
[07:38] <poolie_> so what's up for the last day of school?
[07:41] <vila> poolie_: addressing some FIXMEs in my config proposals, mostly related to tests
[07:42] <vila> poolie_: I came across them yesterday trying to implement the current locking scheme, hmm, more like option life cycle scheme instead
[07:43] <vila> the later should just be to save on every modification, but testing that was... messy, so I stepped back
[07:44] <vila> the "bug" is that from_string can't be easily re-used for all stores as it requires handling the same parameters as __init__
[07:44] <vila> that's wrong
[07:44] <vila> mainly because it makes creating in-memory config objects far too hard
[07:46] <vila> so I will allow load_from_string instead, targeted at tests only (AFAICS) as it makes no sense for code to inject a bunch of new options without going thru the "regular" API
[07:46] <poolie_> sorry, i didn't get to read them last ight
[07:46] <vila> no worries
[07:46] <vila> you'll have two weeks ;)
[07:47] <vila> but if I can leave you a cleaner place, you should enjoy playing with it a bit more ;)
[07:49] <vila> also, loading from a string *is* wrong if the store is already loaded (unless you're testing a particular case and knows what you're doing)
[07:50] <vila> I'm not quite sure if I should leave such a method in the public API or only hack it from tests (test code in production is bad) but I'll start with the former anyway
[08:40] <poolie> sorry i didn't look closely enough to say
[08:41] <poolie> vila bug 712775 may be of interest?
[08:42] <vila> poolie: 85% sure it's a dupe and fixed in later releases
[08:43] <poolie> :)
[08:43] <poolie> hooray
[08:44] <vila> bumping to 95%, the bug was due to my misunderstanding of the tt API, never ever try to use relpaths, always deal with parent_id and basename
[08:44] <vila> :)
[08:45] <vila> ghaaaaaaa
[08:45] <vila> one more VM dying under my crying eyes :(
[08:46] <fullermd> Don't cry.  It makes VB sad, that's why it's crashing.
[08:47]  * vila disables karmic again, as silly as it seems, the huge number of spurious failures these last days *always* included it
[08:48] <vila> on the positive side, upgrading the natty vm *today* allowed unity to start for the second time (since I started tracking it)
[09:30] <maxb> hmm. natty
[09:30] <maxb> I wonder when I should dare upgrade my main machine
[09:34] <vila> maxb: AIUI, one of the main risks is the graphic card (any card less than 5 years should be supported though)
[09:36] <vila> maxb: I had 3 tests setups: vbox, kvm, an apple laptop, all 3 works today but only the later has been working for a couple of weeks now
[09:38] <maxb> My laptop's under a year old, so I should be fine
[09:42] <vila> maxb: there is a live CD that should allow you to test it without installing too
[09:43] <vila> maxb: another important risk is that the UI is quite different so if you customized your setup you'll probably have to find alternatives
[09:44] <vila> for values of setup including mainly the desktop/wm that is
[09:47] <spiv> I just started using natty today.  I haven't found the transition too painful.
[09:47] <spiv> Despite having some custom key shortcuts I've been used to that unity really wants to use for a completely different purpose :)
[09:48] <vila> two remaining nits: gnome do incremental matching is better than the dash one, no more hamster in the toplevel bar
[09:49] <vila> spiv: yup, Unity stealing my Super key from emacs required some xmodmap trickery and muscle memory re-training
[09:49] <soren> My major gripe is the globalmenu.
[09:50] <soren> It really doesn't work very well with focus-follows-mouse.
[09:50] <vila> I love it, one more usable line to display code
[09:50] <soren> I can appreciate more screen real estate for code.
[09:50] <vila> soren: hehe, yeah, same here, one trick is to type Alt first to activate the menus
[09:51] <soren> vila: Oh, that makes them stay?
[09:51] <vila> soren: yeah, if Alt is still available (which isn't my case ;-})
[09:51] <soren> Heh :)
[09:51] <soren> vila: I should try that. I've just disabled the globalmenu proxy thing.
[09:51] <vila> Alt is Meta here
[09:52] <vila> soren: the other trick is to use applications where I *use* the menus in full screen mode (where ffm doesn't really make sense anymore ;)
[09:56] <soren> I have a pretty big monitor. I bought so that I didn't have to make all the windows fullscreen to be usable. :)
[09:57]  * fullermd would be lost without his ffm...
[09:58] <fullermd> 'course, I don't have to deal with gnomes or "globalmenu"en, whatever that is.
[09:58] <spiv> soren: happily I stopped liking focus follows mouse over a decade ago so I don't have that problem :)
[09:59] <soren> fullermd: It's a plugin that takes the menu from your application and puts it at the top of the screen. Whichever window is active is the one whose menu shows at the top.
[10:00] <fullermd> How odd.  That would cover up my xbuffys...
[10:00] <vila> fullermd: the twist compared to other global menus implementations is that most of the time the menu isn't shown
[10:01] <vila> spiv: well, ffm to me, is a bit like tapping instead of clicking, I just move my mouse where I want the focus, I don't have to clik to confirm
[10:02] <vila> a bit like: 'Are you sure you want to do that ?' , yes, don't ever ask again
[10:02] <fullermd> Plus most clicky implementations autoraise the window too.  Blech.
[10:02] <spiv> vila: you move the mouse to change focus?  How inefficient ;)
[10:02] <fullermd> (never mind the poor interaction with the icon manager...)
[10:03] <vila> spiv: hehe, no, I also use other means
[10:03] <fullermd> Oh, I'm sure he doesn't.  Why bother with the mouse when he can just Ctrl-Meta-Q Hyper-Meta-N Ctrl-Top-Shift-X and *boom*, changed!
[10:04]  * Tak also <3 FFM
[10:04] <vila> spiv: but since I share my keyboard and mouse bewteen two hosts, yes, switching from one to the other still requires moving the mouse
[10:04] <vila> tsk tsk, switching from frame to frame and from buffers inside the frame (emacs window) is bind to...
[10:04] <vila> M-TAB, what else ?
[10:05] <vila> eerrrr
[10:05] <vila> Ctrl-TAB
[10:05] <fullermd> Six of one, half a dozen of the other.  You just mash your hand down on the left side of the keyboard, it'll hit the right keys at some point.
[10:07] <mgz> bug 686161 looks like more failing-to-treat-paths-as-unicode fun
[10:07] <vila> everybody loves shortcuts, but emacs *itself* only uses Ctrl and Meta, the others are free, I regularly check that I'm not overriding the emacs ones but only defines new ones (including using Hyper since Unity insists on using Super ;)
[10:08] <vila> mgz: grr, str(thing)
[10:08] <vila> mgz: hello by the way !
[10:08] <mgz> hi!
[10:09] <mgz> the Conflict class doesn't even have a __unicode__ method
[10:09] <vila> mgz: bah, did that even exist in these days ?
[10:09] <mgz> even though most/all the subclasses need to present paths to the ui
[10:15] <vila> yeah...
[10:16] <mgz> wonder if I'll have some time this evening to write up some tests for the whole module.
[10:17] <soren> Do you guys have any idea how long it takes to branch lp:linux?
[10:17] <vila> mgz: that would be nice
[10:18] <vila> soren: that will heavily depends on your bandwidth/latency, but well, don't expect miracles either
[10:18] <soren> vila: hours? Days?
[10:19] <soren> I'm 25 minutes in now.
[10:19] <mgz> right, time to leave
[10:19] <vila> soren: 'bzr info -v lp:linux' should give you an idea
[10:19] <vila> mgz: have fun !
[10:24] <jam> soren: Looking at the repo, it is about 500MB, probably less once it is all tightly packed in your local repository.
[10:24] <jam> ah, missed one, make that 700MB
[10:30] <soren> jam: "bzr branch" says it's copied 557803kB so far. "du linux/.bzr" says 252568. Which one of those must reach ~700MB before I'm done? :)
[10:30] <jam> soren: the first, though it may go up a bit  more that 700
[10:31] <jam> I wouldn't expect much more, though.
[10:31] <soren> jam: No problem. I'm just trying to gauge the order of magnitude and whether I want to wait for it.
[10:32] <soren> "675747kB   868kB/s / Fetching revisions:Inserting stream:Estimate 1879972/2512932"
[10:32] <poolie> hi jam, soren, mgz
[10:32] <poolie> maxb: thanks for all the ppa updates
[10:32] <soren> o/
[10:32] <poolie> should we update the topic now?
[10:32] <poolie> i think so
[10:32] <poolie> sheesh
[10:32] <maxb> nice topic
[10:33] <maxb> :-)
[10:33] <jam> poolie: hi
[10:33] <jam> poolie: for bug 758164, if we are printing the filenames, and decoding to unicode, isn't that enough to explain the difference?
[10:33] <poolie> jam, it could very well be
[10:33] <maxb> Actually, bzr/beta still needs love
[10:33] <jam> Your "very different" is 400ms vs 200ms
[10:33] <jam> which yes, is 2x, but it is also only 200ms
[10:33] <poolie> indeed
[10:34] <jam> poolie: I know we took pains to *not* decode utf-8 to Unicode for paths that don't appear modified
[10:34] <poolie> jam, i was going to profile it and see if anything stuck out
[10:34] <poolie> we almost need 'status -q' :)
[10:34] <jam> but if everything is freshly added, we shouldn't be sha1-summing things (that would be more like 30s)
[10:35] <poolie> right
[10:35] <poolie> so it may be that formatting the file names is slower than it could be
[10:35] <poolie> well, almost certainly it could be made faster
[10:35] <poolie> but i don't know if it sticks out as something especially slow
[10:39] <jam> poolie: utf-8 => unicode => utf-8
[10:39] <jam> would be something that sticks in my head
[10:40] <jam> we like dealing with unicode in memory, but it does have a fair amount of overheda
[10:40] <jam> overhead
[10:40] <poolie> heh
[10:41] <vila> hmm, so I have a registry which return classes, but building objects require different parameters, what could be a tasteful way to design the __init__ methods and how could test provide parameters knowing that they'd like to refer to the test instance itself for that ?
[10:42] <vila> example: a global config doesn't requires at most a transport object but a branch config requires a branch object
[10:42] <jam> vila: "doesn't requires at most" ?
[10:42] <vila> s/doesn't//
[10:43] <poolie> that's quite a sentence
[10:43] <vila> hehe
[10:44] <vila> ok, want me to split it ? (the point being that I can imagine solving both points separately but I'm still searching a combination that works well)
[10:44] <poolie> i guess generally speaking, provide a method or function that takes only the parameters the callers are likely to care about
[10:44] <vila> for the __init__ ?
[10:44] <poolie> perhaps add either an adapter layer, or a separate class method, that will convert to the right constructor call
[10:45] <soren> jam: Hmmmm... "1091782kB   520kB/s / Fetching revisions:Inserting stream:Estimate 1994478/2512932
[10:45] <soren> Still ~20% to go.
[10:46] <jam> soren: and "du linux/.bzr" ?
[10:46] <soren> 333440	linux/.bzr
[10:46] <vila> right, but this route leads me to a test that needs to define a method which knows about the specific parameters OR a test method on the config class (bad)
[10:47] <vila> hmm
[10:48] <vila> ha, right, one test registry where specific adapters can be added
[10:48] <poolie> ok, i've disposed of about 70% of the ubuntu/bzr stuck bugs
[10:48] <poolie> the rest are now non-private
[10:48] <vila> \o/
[10:48] <poolie> i had a quick check for anything sensitive
[10:48] <poolie> https://bugs.launchpad.net/ubuntu/+source/bzr/+bugs?search=Search&field.status=New
[10:49] <poolie> many are dupes
[10:49] <poolie> of course
[10:49] <poolie> so that's most of what i've been doing
[10:49] <poolie> i wrote a little script to put the traceback attachemnte into the description-
[10:49] <vila> poolie: and that's because you can now see the private ones right ? (I ~remember looking at the list but it was quite short)
[10:49] <poolie> that's right
[10:50] <vila> great
[10:52] <soren> If I CTRL-C my way out of a "bzr branch"... Can I resume it at a later time?
[10:53] <poolie> good night all
[10:54] <jam> soren: unfortunately, no
[10:54] <jam> if you start from scratch, you can do "bzr branch -r XXX; and then bzr pull -r YYY" etc.
[10:57] <jam> soren: btw, do you know if you are going via http or bzr+ssh?
[11:02] <jam> jelmer: question for you
[11:02] <jam> '92745@138bc75d-0d04-0410-961f-82ee72b054a4:trunk%2Flibstdc%2B%2B-v3%2Ftestsuite%2Ftr1%2F4_metaprogra...'
[11:03] <jam> is that a revision id from bzr-svn?
[11:03] <soren> jam: bzr+ssh.
[11:03] <jam> It is measuring ~ 158 characters
[11:03] <jam> which is a *lot* longer than the standard 60char bzr revid
[11:03] <soren> jam: It has transferred 1.6GB now.
[11:04] <jam> soren, when it finishes, the final transfer amounts should all be in .bzr.log
[11:04] <jam> you're welcome to submit a bug about this. 1.6 seems significantly excessive
[11:04] <jam> I have thoughts as to why, but nothing very concrete.
[11:04] <soren> jam: Will do.
[11:09] <soren> jam: bug 758620
[11:10] <vila> jam: question for you, I just tried 'bzr branch lp:linux' with bzr.dev and -Dhpss, and after 10 minutes it seems to still be issuing get_parent_map calls *only* alarmingly under-using my bandwidth
[11:11] <vila> jam: could that be another fallout from querying tags first ?
[11:11] <jam> soren: if you wait for it to finish, the summary of bytes transferred will be in bzr.log, It would be nice to get that in the bug report as well.
[11:11] <jam> vila: into an existing repo, or into a new standalone branch?
[11:12] <vila> jam: new repo
[11:12] <vila> shared
[11:12] <vila> but empty
[11:12] <soren> jam: I'll do that once it finishes. If the average time per revision transferred holds, it'll be another 11 minutes.
[11:12] <vila> also, the perfmeter shows little peaks every ~30 seconds...
[11:13] <jam> vila: so into a shared-but-empty means we end up walking the whole history to find that you don't have anything we don't need to transfer.
[11:13] <vila> jam: as if the smart server was... maybe loading the the ancestry graph to answer each query and being quite slow at that
[11:13] <vila> >-/
[11:13] <vila> jam: a standalone branch would be better /
[11:13] <vila> ?
[11:13] <jam> vila: we have a special case in place for "target did not exist"
[11:14] <jam> which is known deficient for "target exists but is empty"
[11:14] <vila> ok
[11:14] <jelmer> jam: That's a file id from bzr-svn
[11:15] <jam> jelmer: k, still really-really big :)
[11:15] <jam> I was debugging some loggerhead memory consumption
[11:15] <jam> and 6MB for the intern dict ,+ 20MB of interned strings
[11:15] <jelmer> jam: It looks like an old style one though, from bzr-svn < 0.6
[11:15] <jam> jelmer: it is the gcc-linaro repo
[11:18] <jelmer> jam: bzr-svn parses the file id at the moment so this is tricky to solve easily
[11:19] <jelmer> from looking at the code, it could indeed also be a new style file id
[11:19] <jam> jelmer: it isn't critical at this point. but it is something that surprised me.
[11:42] <soren> Is there a fast way to create a repository out of this mammoth branch (lp:linux)? I could just "bzr init-repo ." in its parent dir and do a "bzr branch linux linux2", but given the size of this, I was hoping there'd be a simpler way.
[11:43] <soren> Err... Not necessarily simpler, but quicker.
[11:43] <fullermd> Well, nothing will be really quicker.  You can use 'reconfigure' to turn the existing branch into one using the shared repo.
[11:43] <fullermd> Not necessarily quicker, but simpler   ;)
[11:44] <fullermd> ('course, a local 'branch' will be a putz of a lot quicker than going across the network, so it would certainly be 'quicker' in that sense)
[11:45] <soren> I did it a couple of hours ago with lp:launchpad. It wasn't much faster than the initial bzr branch lp:launchpad, actually.
[11:45] <soren> fullermd: bzr reconfigure --use-shared ?
[11:45] <fullermd> Sounds like it, yah.
[11:46]  * soren awaits
[11:46] <soren> Oh, lunch!
[11:46] <jam> soren: touch .bzr/repository/shared-storage
[11:46] <jam> it is now a shared repository
[11:47] <soren> jam:  So to make other branches share its data, I have to... what?
[11:47] <jam> soren: create them underneath that dir
[11:47] <soren> Oh.
[11:47] <soren> What about its existing working dir?
[11:47] <jam> soren: if you really want to relocate stuff, I would say:
[11:47] <jam> bzr init-repo ../
[11:47] <jam> rm -rf ../.bzr/repository
[11:47] <jam> mv .bzr/repository ../.bzr
[11:48] <soren> Wicked.
[11:48] <soren> Can I safely kill a "bzr reconfigure --use-shared
[11:48] <soren> "?
[11:48] <jam> soren: I think so
[11:48] <jam> I'm pretty sure it just does a fetch
[11:48]  * soren takes a chance
[11:49] <soren> Awesomesauce. Looks to have worked.
[11:51]  * jelmer is off to the dentist, back in ~1.5 hours or so
[11:52] <soren> bzr actually just committed a changed file faster than git.
[11:56] <cheater> hey guys
[11:57] <cheater> if i make a cvs, svn or git checkout inside my bzr checkout - how do i make bzr not treat it with imports and all that stuff, just ignore the metadata?
[11:57] <LeoNerd> I believe bzr by default will ignore metadata from most other VCSes
[11:57] <LeoNerd> I've run mixed bzr + svn checkouts before
[11:57] <cheater> nah i did svn i think and it did that
[11:58] <cheater> i had to rm -rf all .svn dirs
[11:58] <LeoNerd> Both bzr and svn have the ability to ignore files based on wildcard matches
[11:58] <cheater> is that the way to do it then?
[11:58] <LeoNerd> bzr ignore .svn;  svn setprop svn:ignore .bzr
[11:58] <cheater> or is it possible to turn off this importing stuff?
[11:58] <Peng> I don't know if that would prevent bzr-svn from noticing the .svn dirs, though...
[11:58] <LeoNerd> Ahhh... That's an interesting one. Yes, you would have to disable the bzr-svn plugin
[11:58] <LeoNerd> (or uninstall it or something)
[11:59] <cheater> even if the dirs are ignored?
[11:59] <cheater> ok i am now going to make a git checkout (ok clone) and will need bzr not to get confused by that
[11:59] <LeoNerd> bzr ignore .git
[11:59] <LeoNerd> Which I suspect it'll do by default
[12:00] <cheater> yeah but then i get bzr-git or something like that
[12:00] <cheater> and it will go crazy, no?
[12:00] <LeoNerd> Hmm.. I'm not sure
[12:00] <cheater> same situation as peng mentioned
[12:00] <vila> hmm hmm, I think foreign plugins detect the dor dirs before even thinking about .bzrignore
[12:00] <LeoNerd> Without plugins, a mixed bzr+git checkout should be fine
[12:00] <cheater> what do you think Peng? what will happen?
[12:00] <LeoNerd> I'm not sure how the bzr-git plugin will react in the presence of both sets of metadata
[12:00] <cheater> i hadn't installed any extra plugins but i don't know what is installed by default
[12:01] <cheater> how do you find out what plugins are installed?
[12:01] <LeoNerd> Ideally, it'd be nice if you could disable plugins on a per-workdir basis
[12:01]  * Peng shrugs
[12:01] <Peng> cheater: "bzr plugins"
[12:01] <LeoNerd> So just configure "Oi; bzr-svn, not now please"
[12:01] <vila> but the foreign plugins are also intended to allow you to interact with foreign repos, not mix things into your working tree
[12:01] <cheater> hmm i did "bzr help topics" and "plugins" was not listed as a command
[12:02] <cheater> oh it's in "bzr help commands"
[12:02] <LeoNerd> help topics  just lists a few more things you might want to ask for help about;  help commands  lists all the commands
[12:07] <cheater> thanks
[12:15] <jam> cheater: I would expect bzr-git to work fine with .git and .bzr in the same dir, because .bzr is probed first
[12:15] <jam> however
[12:16] <jam> bzr-svn and bzr-hg both put their probers before bzr
[12:16] <jam> AIUI
[12:16] <jam> and with bzr-svn if you were in a subdir, bzr wouldn't see the .bzr in the parent dir before bzr-svn saw .svn in the current dir
[12:20] <cheater> jam: my problem is that i don't want bzr-git to work at all
[12:20] <jam> cheater: then why have it installed?
[12:20] <cheater> jam: i don't want any git integration stuff or anything, i just want it to be normal files to bzr
[12:21] <cheater> jam: i guess i don't have it installe
[12:21] <cheater> d
[12:21] <jam> You can set "BZR_DISABLE_PLUGINS=git" I believe if you ever do have to have it installed but not working.
[12:21] <cheater> thanks
[12:21] <LeoNerd> Ahhh cute
[12:25] <jam> cheater: you can do similar things with bzr-svn, etc "BZR_DISABLE_PLUGINS=git:svn:..."
[12:26] <cheater> cool :)
[12:26] <cheater> thank you jam
[12:45] <vila> aaaargh, noooo not *now*: bzr: ERROR: exceptions.AttributeError: 'LoomMetaTree' object has no attribute 'inventory'
[12:46] <vila> jelmer: ^ :-/
[12:48] <vila> pfew, reverting to revno 578-0 indeed worked
[13:05] <vila> jelmer: I filed bug #758696
[13:11] <jelmer> re
[13:11] <jelmer> vila: thanks, I'll have a stab at that bug
[13:12] <jelmer> jam: bzr-git, bzr-svn and bzr-hg all insert themselves before the bzr prober for server side things
[13:18] <jelmer> vila: https://code.launchpad.net/~jelmer/bzr-loom/inventorytree/+merge/57311
[13:19] <vila> jelmer: and compatible, rock&roll ! Well done
[13:19]  * vila hot bugs are always easier to fix...
[13:20] <vila> jelmer: approved
[13:20] <jelmer> vila: Thanks :)
[13:35] <mok0> When I am done with a branch in a shared repo, I usually just rm -r the directory. Is there any other way to do it? I am concerned that the data in the shared repo just accumulates this way
[13:36] <beuno> mok0, not really, those revisions do stay around
[13:36] <mok0> beuno: and there's no way to clear it out?
[13:36] <beuno> not sure if there's a plugin that will clean out un-referenced revisions
[13:38] <mok0> Hm, this source tree is around 75 Mb
[13:38] <mok0> So if I get 75Mb of orphaned revisions every time I make a junk branch...
[13:39] <mok0> Need I say more? :-)
[13:39] <beuno> right, although if it shares any revisions with other branches, it re-uses them, obviously
[13:40] <mok0> beuno: ok, so it's not quite as bad... but still, a whole bunch of bookkeeping files I imagine
[13:40] <vila> mok0: a single revision use only a fraction of the tree size, so what accumulates is only the set of revisions that are not merged in any other branch
[13:41] <mok0> vila: I see, thanks
[13:41] <vila> mok0: not a single one, if you rm the branch, the .bzr/branch (which contains the files related to the branch itself) are deleted
[13:41] <vila> mok0: only the shared repo is preserved since it's in a parent directory
[13:42] <mok0> vila: is that "bzr rm branch" ?
[13:43] <vila> hmm, no a regular 'rm -fr', 'bzr rm' is for versioned files
[13:43] <vila> versioned files *inside* a versioned tree that is
[13:43] <mok0> vila: ah so it's what I've been doing
[13:43] <vila> mok0: yes
[13:43] <mok0> vila: yeah bzr rm ... I use that frequently
[13:44] <vila> ok, I'm off, time to pack (a bit more than one hour before leaving for... see, sun and fun :)
[13:44] <vila> have fun all !
[13:45] <mok0> See you, vila
[17:56] <TeTeT> hi, just encountered a problem with bzr on Lucid - a fix might be worth an SRU: http://pastebin.ubuntu.com/593214/
[18:46] <maxb> TeTeT: I believe it's already planned, though the intent is currently to get the in-flight maverick SRU sorted first
[18:47] <TeTeT> maxb: great, thanks!
[19:44] <cheater> if i have a bzr checkout, and i do commit --local, what happens?
[19:45] <jelmer> cheater: the revision only gets committed to your branch, not to the master branch
[19:45] <jelmer> so they diverge
[19:55] <cheater> if i later do a successful commit (without --local), will it add all those local commits too?
[19:55] <LeoNerd> Useful for offline commits, say, on a laptop
[19:56] <LeoNerd> You won't be able to commit at that point. You'll have to push first.
[19:56] <LeoNerd> My usual workflow is: on laptop (offline), commit --local. When I get home, push. Or if I have some outstanding changes push --no-strict
[19:59] <cheater> LeoNerd: but if i just "commit" i don't need to push, right?
[19:59] <LeoNerd> You won't be able to commit
[20:00] <LeoNerd> commit on a bound branch without --local will -first- try to check upstream. It will then notice the remote branch is not up to date, and refuse to work
[20:00] <LeoNerd> To solve that, you have to commit --local (even though you are now online), then push. push will repopulate the remote branch.
[20:01] <LeoNerd> Alternatively, you can immediately push --no-strict, to push the outstanding revisions, ignoring the fact you have local uncommitted changes
[20:25] <Jordan_U> I'm looking for a good introduction to bzr aimed at a new user, on Windows, that has no concept of what a revision control system is at the moment. Preferably GUI.
[20:31] <jelmer> Jordan_U: have you seen the desktop guide ? http://doc.bazaar.canonical.com/bzr.dev/en/
[20:35] <Jordan_U> jelmer: I hadn't that looks great (aside from the navigation being a bit non-intuitive).
[20:35] <Jordan_U> Scratch that last comment about being intuitive, the page hadn't finished loading.
[20:43] <Jordan_U> jelmer: Thanks :)
[20:46] <jelmer> np
[23:07] <groo_> hi/2 all
[23:07] <groo_> ranch imports?
[23:07] <groo_> could any kind dev tell me what is the status in supporting git nested trees in branch imports?