[00:00] <jelmer> hi *!
[00:00] <beuno> OMG, jelmer is back
[00:01] <jelmer> hey beuno :-)
[00:01] <BrianRice> hi. is there a way to run, say, the update command and have it only indicate what it *would* do rather than take action?
[00:01] <jelmer> beuno, Do I have you to blame for the bzr-search upload? If so, thanks !
[00:02] <beuno> jelmer, yeah, I took advantage of debcamp  :)  welcome'
[00:02] <beuno> now, I'm about to release loggerhead 1.6.1, which would be nice to have in debian/ubuntu too  :)
[00:02] <beuno> even PPA meanwhile
[00:03] <beuno> BrianRice, I don't think there's a --dry-run option. Feel free to file a bug requesting it
[00:03] <BrianRice> ok
[00:03] <lifeless> 08:46 < mwhudson> "Port Loggerhead should listen on (default 8080 is the default."
[00:03] <jelmer> beuno, ah, cool
[00:03] <BrianRice> "bzr log" comparison seems to do well enough in the mean-time
[00:04] <jelmer> beuno, will see what I can do to get into debian once I'm rested
[00:04] <lifeless> mwhudson: perhaps
[00:04] <lifeless> "Port Loggerhead should listen on (8080 is the default)."
[00:04] <beuno> jelmer, where were you, btw?  vacation?
[00:04] <mwhudson> lifeless: that was a typo, yes
[00:04] <jelmer> beuno, yep, went cycling in the alpes for ~10 days
[00:05] <lifeless> jelmer: wow back already
[00:05] <pickscrape> Bet you're knackered now :)
[00:06] <beuno> jelmer, cool. Welcome back then.
[00:06] <beuno> pickscrape, I still owe you your review. I'm sucking at getting to stuff quickly lately
[00:06] <jelmer> lifeless, yeah, bad weather so came back one day early
[00:06] <jelmer> lifeless, thanks for the bzr-gtk pqm update
[00:09] <pickscrape> beuno: no rush at all
[00:13] <jam> lifeless: Some interesting results when tweaking the knobs on ChunkWriter for the btree index
[00:13] <jam> http://rafb.net/p/owGbxj90.html
[00:13] <jam> This is with the artificial nodes from the test suite.
[00:13] <jam> But still interesting.
[00:13] <jam> I'm planning on putting something together with real data tomorrow.
[00:14] <jam> The only problem with using copy() is that it will change the page sizes if it is/isn't available
[00:14] <jam> which means the test suite will become very brittle.
[00:15] <jam> The "current" algorithm creates 490 pages, the "best" creates 390
[00:15] <jam> So there may be some room to either be a bit faster, or compress a bit better in the same time
[00:16] <jam> Anyway, I'm done for the evening.
[00:19] <lifeless> jam: gnight
[00:19] <lifeless> jam: perhaps we should do the zlib interface ourselves
[01:03] <jelmer> hmm, rc5!?
[01:04] <beuno> jelmer, don't ask
[01:07] <AfC> It's ok. It's called "quality". That's a good thing.
[01:15] <LarstiQ> AfC: what is this "quality" thing you speak of?
[01:23] <AfC> It's what happens when you take the time to polish a release after you've decided to make one in the first place. There is a point of diminishing returns, but I've long felt that being shackled to particular dates and thereby shipping arbitrary bugs does not result in a better user experience.
[01:24] <beuno> thumper, working on the gnome theme, progress so far: lp:~beuno/loggerhead/gnome_theme   (still have to fix quite a few things)
[01:24] <lifeless> beuno: cool
[01:25] <LarstiQ> AfC: a hard shackling to a specific date, no. But I feel it's better to not ship it if it needs too much polish.
[01:25] <beuno> lifeless, you have access to gnome to push this once it's finished, don't you?
[01:26] <lifeless> beuno: maybe:)
[01:26] <beuno> :)
[01:26]  * beuno -> dinner
[01:46] <lifeless> LarstiQ: so if something needs too much polish, what - you give up on the project?
[01:47] <LarstiQ> lifeless: include it in the next release
[01:48] <lifeless> LarstiQ: well, thats what we're doing :)
[01:50] <LarstiQ> lifeless: I was disagreeing with AfC's general statement, I think :)
[02:05] <lifeless> oh suck
[02:05] <lifeless> some plugin is making TestOutsideWT.test_url_log fail hard
[02:06] <jelmer> lifeless, have you updated bzr-svn recently?
[02:06] <lifeless> jelmer: FSVO recent
[02:06] <lifeless> jelmer: remember it segfaults for me
[02:07] <jelmer> lifeless, ahh
[02:07] <jelmer> lifeless, it should no longer segfault
[02:07] <jelmer> lifeless, if it does, please let me know
[02:07] <lifeless> 0.4 still ?
[02:07] <jelmer> it also contained a bug that made test_url_log hang
[02:07] <jelmer> yep
[02:08] <jelmer> I worked on a fix for this with Mark Hammond, which made it into the 0.4.11 rc
[02:08] <lifeless> pullink
[02:11] <lifeless> eek
[02:11] <lifeless> I'm in install-revisions, in fetch :(
[02:12] <lifeless> EFREAKINGSLOW
[02:15] <lifeless> jelmer: editor.c: In function 'py_dir_editor_change_prop':
[02:15] <lifeless> editor.c:358: warning: unused variable 'p_c_value'
[02:16] <jelmer> lifeless, thanks, fixed
[02:16] <lifeless> also,
[02:16] <lifeless> ra.c:1141: warning: 'py_revstart_cb' defined but not used
[02:16] <lifeless> ra.c:1161: warning: 'py_revfinish_cb' defined but not used
[02:18] <lifeless> meh,
[02:18]  * lifeless disables Werror
[02:19] <jelmer> ah, looks like that happens when you build against svn 1.4
[02:19] <jelmer> fixed as well
[02:20] <lifeless> hmm, build_ext -i is broken
[02:20] <lifeless> actually, no, its fine
[02:20] <lifeless> ok, that test isn't hanging now, thanks
[02:20]  * lifeless returns to log hacking
[03:55] <lamont>  'No handlers cound be found for logger "bzr"'
[03:55] <lamont> ^^ wassat?
[03:55] <lamont> 1.6~rc3-1~ bzr and 1.6.0-1~ bzrtools
[04:30] <lifeless> lamont: a race?
[04:30] <lifeless> lamont: from pqm or something?
[04:30] <lifeless> lamont: also, bzr-playground?
[04:31] <mneptok> that'll teach him to unidle.
[05:38] <jml> lifeless: testresources?
[05:38] <lifeless> jml: yes, high on my queue
[05:39] <lifeless> jml: or are you wanting to chat about it right now?
[05:39] <jml> lifeless: no, just thought I'd take the opportunity to pester :)
[05:46] <lifeless> can I review-by-mail?
[05:48] <lifeless> jml: I see why you wanted the review; you went rather critical.
[05:48] <lifeless> unfortunately, some of what you did isn't suitable
[05:48] <jml> lifeless: that's ok. I figured that would be the case.
[05:49] <lifeless> in particular the licence changes are incorrect
[05:50] <jml> lifeless: review by mail is fine by me.
[05:55] <lifeless> we'll see if lp forwards it to you
[06:27] <chmac> beuno: I'm loving bzr upload, it works like a charm. :)
[08:05] <lifeless> later all
[08:38] <sadleder> hi, i've a question regarding launchpad-cscvs, is this the right place to ask?
[08:42] <siretart> beuno: jelmer: I've prepared an upload for bzr1.6rc3 to experimental, I've compiled it locally on hardy, and a bzr selftest tells me this: FAILED (errors=32, known_failure_count=14)
[08:42] <siretart> beuno: jelmer: is this something to worry about or shall I continue uploading it?
[08:42] <thumper> sadleder: probably #launchpad is better
[08:44] <sadleder> thumper: thanks
[10:27] <luks> is it intentional that http://bazaar-vcs.org/releases/src/ doesn't have the latest 1.6 RCs?
[10:27] <luks> oh
[10:27]  * luks is blind
[11:28] <awilkins> Since MarkH is producing .exe installers, would you like my builds of the Python-flavoured ones?
[11:32]  * awilkins finds the python ones to be easier to hack/dogfood on
[11:33] <luks> jam: (when you are here, and if you are interested) http://bazaar.launchpad.net/~luks/bzr/packaging-tools/annotate/3?file_id=ppa.txt-20080821102811-jhoajulm56uo6vgm-1
[12:09]  * luks wonder why https://launchpad.net/~bzr/+archive has 1.6rc5 for hardy
[12:11] <luks> +s
[12:11] <awilkins> Is everyone dead at their desk?
[12:13] <bob2> yes!
[12:13] <awilkins> Arrgh, 'tis zombie bob2
[12:25] <bazaar> hi. is it possible to change commit metadata (message, commiter etc)?
[12:31] <bob2> no
[12:31] <bob2> unless you count "bzr uncommit"
[12:31] <bob2> or merging them and giving better information in the merge revision
[12:42] <jelmer> siretart, hi
[12:43] <siretart> hey jelmer
[12:44] <siretart> jelmer: I've prepared an upload for bzr1.6rc3 to experimental, I've compiled it locally on hardy, and a bzr selftest tells me this: FAILED (errors=32, known_failure_count=14). is this something to worry about or shall I continue uploading it?
[12:45] <jelmer> what are the errors exactly?
[12:45] <AfC> jam: did you cut bzr-1.6-rc5 yet?
[12:46] <jelmer> AfC, yep, according to the website :-)
[12:48] <siretart> jelmer: I can mail you the full log if you want to know
[12:48] <siretart> jelmer: where should I mail it to?
[12:49] <jelmer> siretart: jelmer@samba.org
[12:49] <jelmer> siretart, It's probably nothing, but let's check just in case
[12:50] <siretart> jelmer: should be in your inbox now
[12:50] <AfC> jelmer: ah. Nice. Someone should change channel topic then.
[12:51] <siretart> AfC: this channel is -t
[12:56] <lifeless> bazaar: please choose a different nickname; you will confuse people with the nickname you have :)
[13:05] <lamont> lifeless: in my case, it was a root owned ~/.bzr.log
[13:05] <lamont> the other person seeing it doesn't have such a simple explanation
[13:06] <jelmer> siretart, thanks
[13:11] <siretart> jelmer: is that expected breakage, local breakage or is there something really wrong?
[13:14] <jelmer> siretart, I haven't received your email yet
[13:15] <jelmer> ah, got it
[13:17] <siretart> the file has been created with this command: env -i bzr --no-plugins selftest -v | tee selftest.log
[13:25] <jelmer> ah, it's all poll errors from pycurl
[13:25] <jelmer> lifeless/jam: ping
[13:30] <AfC> Oh dear. I got the error at https://bugs.launchpad.net/bzr-svn/+bug/229419 / https://bugs.launchpad.net/bzr-svn/+bug/234010 and, upon upgrading to bzr-1.6-rc5 and bzr-svn trunk, trying to bzr pull in a (from Subversion) checkout seg faults
[13:32]  * AfC is not even sure where to turn next
[13:32] <fullermd> Is bzr-svn trunk something runnable?
[13:32] <fullermd> I thought jelmer was doing all his stuff in the 0.4 branch or something...
[13:33] <AfC> Oh?
[13:33]  * AfC tries that...
[13:34]  * fullermd doesn't really know, just vaguely remembers conversations here.
[13:34] <AfC> fullermd: sure. Thanks
[13:34] <fullermd> He must be dead, though.  It's been two minutes since I said 'jelmer' out loud, and he hasn't shown up.
[13:34] <AfC> I'm not entirely sure he is required to come running just because someone says his name.
[13:37] <jelmer> AfC, did you rebuild bzr-svn after updating it?
[13:37] <jelmer> fullermd, coffee brake :-)
[13:37] <jelmer> *break
[13:37] <Peng_> Is it safe to have another web server serve Loggerhead's static files, instead of passing them back to Paste?
[13:38] <fullermd> Oh, good.  I was getting worried about you   ;)
[13:39] <jelmer> (-:
[13:40] <AfC> jelmer: so I just did a fresh branch of 0.4 (ok, branch + pull --overwrite --remember, whatever)
[13:40] <AfC> jelmer: and then ran `make` there.
[13:40] <AfC> jelmer: and it too segfaults
[13:41] <AfC> jelmer: .bzr.log shows it getting as far as "opening SVN RA connection to 'svn+ssh://afcowie@svn.gnome.org/svn/gtk+/trunk/"
[13:41] <AfC> jelmer: and then that's it
[13:41] <jelmer> AfC, any chance you can run it inside gdb and paste the backtrace?
[13:41] <AfC> Sure, I can try
[13:42] <AfC> gdb bzr pull ?
[13:42]  * AfC doubts
[13:42] <luks> `gdb python` and inside gdb `run /path/to/bzr pull`
[13:42] <AfC> k
[13:45] <AfC> jelmer: http://rafb.net/p/2Gm5ck59.html I hope
[13:45]  * AfC has never tried Python inside gdb before, but has plenty of scars from trying to debug segfaults in Java code reaching to a native library. Pain.
[13:46] <jelmer> AfC, thanks
[13:46] <jelmer> AfC, It's not too bad with Python
[13:46] <jelmer> AfC, there's even gdb macros that allow you to inspect the python stack
[13:46] <AfC> jelmer: single threaded :)
[13:46] <AfC> jelmer: oh yeah? Nice.
[13:46] <AfC> jelmer: [now that Java is finally free, we're starting to see some progress along those lines]
[13:46] <jelmer> AfC, Ah, of course. Multiple threads would make things more complex in java
[13:54] <rocky> hrm, if i bzr merge something but don't commit it, what's the standard way to revert the merge?
[13:54] <fullermd> revert?
[13:55] <rocky> i bzr revert'ed each of the individual file changes but when i run bzr stat it still says i have a pending merge
[13:55] <jelmer> rocky, just revert without any arguments
[13:55] <fullermd> revert <file> doesn't touch the merges, just the full version.
[13:55] <jelmer> rocky, (which will revert all changes in the working tree)
[13:55] <rocky> ah thanks ;)
[13:55] <jelmer> rocky, or revert --forget-merges
[13:55] <fullermd> (there's an arg to touch ONLY the pending merges too, but if you're blowing away the merge, you don't care about that)
[13:56] <rocky> jelmer: btw... i've troubleshooted the speed issue with bzr-svn 0.4.10 a bit again... and i'm seeing that everytime i commit, it basically checks properties on every folder in the remote svn repo (100's of svn requests)
[13:56] <jelmer> siretart, seems fine to me to upload
[13:56] <jelmer> siretart, there's an issue with pycurl, but I think that's known
[13:56] <jelmer> rocky, even with 0.4.11~rc1?
[13:57] <rocky> jelmer: 0.4.11-rc1 only works with bzr 1.6rcX right?
[13:57] <jelmer> rocky, yep
[13:57] <rocky> jelmer: i tried playing with that in a sandbox the other day and got tracebacks all the time
[13:58] <rocky> jelmer: does that mean you won't be trying to fix this in the 0.4.10 branch?
[13:58] <jelmer> rocky, what backtraces exactly?
[13:58] <jelmer> rocky, yes, 0.4.10 won't see any further development
[13:58] <rocky> jelmer: i'll have to try again (i didn't at the time because you weren't around) to see the tracebacks
[13:59] <AfC> jelmer: (am I in error to be working from your 0.4 branch? Should I grab the 0.4.11-rc1 tarball instead?)
[14:00] <AfC> (or trying to bludgeon Subversion, or...?)
[14:00] <fullermd> Wouldn't you be doing that anyway, just on GP?   :p
[14:01] <AfC> fullermd: I was thinking more a rapier missile battery on fully-automatic, but yes
[14:01] <jelmer> AfC, no, the 0.4 branch should work just fine (atm it's the same code as 0.4.11~rc1)
[14:01] <jelmer> AfC, I'm not sure what's causing your backtrace, still looking into it
[14:01] <AfC> jelmer: (that's what I figured)
[14:02] <rocky> jelmer: what version of svn does bzr-svn 0.4.11 require?
[14:02] <AfC> jelmer: Most kind. I hope it's not something stupid I'm doing (or with my environment).
[14:02] <jelmer> rocky, 1.4
[14:02] <rocky> jelmer: will it work with svn 1.5.x ?
[14:03] <jelmer> AfC, even then it shouldn't be segfaulting
[14:03] <jelmer> rocky, yes
[14:03] <rocky> jelmer: atm i'm testing with http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.4/  ... should i keep testing with that or switch to your tarball or?
[14:04] <jelmer> rocky, that seems fine, though you may want to use the original location (http://people.samba.org/bzr/jelmer/bzr-svn/0.4 instead since the lp mirror may be out of date)
[14:04] <AfC> (I would automatically blame Subversion, except that I was able to do an `svn checkout` of a different project whereas that URL segfaulted for bzr-svn trying to do a checkout)
[14:04] <rocky> jelmer: gotcha
[14:22] <rocky> jelmer: here's a traceback just trying to check out a svn branch...  http://cluebin.appspot.com/pasted/601
[14:23] <jelmer> rocky, was this in a clean sandbox?
[14:24] <rocky> jelmer: that toplevel "repo" dir was a fresh repo i just created with "bzr init --rich-root-pack repo" if that's what you mean
[14:25] <rocky> jelmer: but... the remote svn repo it's connecting to has lots of bzr props set from other versions of bzr-svn
[14:29] <rocky> jelmer: and, the remote svn repo i'm connecting to is publically available so you can play with it if you'd like
[14:36] <jelmer> rocky, thanks, will give it a try
[14:53] <ktenney> for a while my prompt (Ubuntu) included the version of the current tree, now it doesn't
[14:53] <ktenney> where is that set?
[14:56] <james_w> ktenney: I think there may be something in /usr/share/doc/bzr/examples , but I'm not sure
[14:59] <jelmer> beuno, ping
[15:00] <beuno> jelmer, pong
[15:00] <jelmer> beuno, any chance you can set a tag for the loggerhead release?
[15:01] <beuno> jelmer, I've never used tags. Do I have to change the repo format?
[15:01] <jelmer> beuno, if the branch is in a packs format, you should already be able to use tags
[15:02] <jelmer> beuno, e.g. "bzr tag -r213 loggerhead-1.6"
[15:02] <beuno> jelmer, sure then. Tag && push?  IIRC, they don't propagate automatically?
[15:02] <beuno> although I have a checkout, that may do it
[15:03] <jelmer> beuno, yep, a checkout should do it
[15:03] <jelmer> beuno, they should propagate automatically
[15:03] <beuno> beuno@beuno-laptop:~/bzr_devel/loggerhead/trunk$ bzr tag -r213 loggerhead-1.6
[15:03] <beuno> Created tag loggerhead-1.6.
[15:04] <beuno> AKA, done  :)
[15:04] <beuno> we should have 1.6.1 out tomorrow, the code is up for review
[15:04] <LarstiQ> don't you need to commit it though?
[15:05] <jelmer> beuno, I see it here, thanks!
[15:05] <ktenney> james_w .. no examples, I'll poke around. Odd how it appeared and disappeared ...
[15:05] <beuno> LarstiQ, it seems not. I never quite got my head around how tags propagate
[15:06] <jelmer> rocky, thanks, I can reproduce that
[15:07] <rocky> jelmer: excellent :)
[15:07] <rocky> jelmer: if you can get this issue fixed i'll try again and if everything's ok i'll start using bzr-svn 0.4.11 for all my stuff ;)
[15:08] <rocky> since i'm using a bzr branch of your bzr-svn 0.4 i should be able to test quickly
[15:12] <jelmer> rocky, cool
[15:12] <rocky> jelmer: if it wasn't for the fact that i love bzr so much i would have given up by now due to the speed issues with 0.4.10 :(
[15:14] <jelmer> siretart, while you're at it, any chance you can sponsor an upload of loggerhead to debian and ubuntu?
[15:14] <jelmer> rocky, 0.4.11 should really be a lot better in that regard
[15:14] <rocky> excellent :)
[15:20] <awilkins> Does anyone want my rc5 Python/Win32 installer builds?
[15:27] <jelmer> awilkins, somebody asked me about them
[15:27] <jelmer> awilkins, perhaps just add them to the releases wiki page?
[15:28] <awilkins> jelmer: As attachments?
[15:28] <jelmer> awilkins, Just pointing at the URLs if you have uploaded them somewhere
[15:29] <jelmer> awilkins, alternatively, maybe you can upload them to the bzr launchpad project?
[15:29] <jelmer> awilkins, It may be useful to talk with John or Mark about that
[15:30] <awilkins> jelmer: The "exe" version is convenient but I prefer the Python version which is more hackable
[15:31] <awilkins> jelmer: I have no inkling of how to upload a file to the launchpad project (I feel certain that I have no rights to do so)
[15:31] <jelmer> awilkins, I think it makes sense to have both available for users to download
[15:31] <jelmer> awilkins, John, Mark or Martin should be able to help there
[15:32] <awilkins> markh: Ping? jam: ping?
[15:32] <awilkins> jam: Ping?
[15:33] <jam> jelmer: pong
[15:33] <jam> awilkins: pong
[15:34] <jelmer> jam, siretart is seeing select/poll errors in the testsuite from pycurl
[15:34] <jelmer> jam, is that a known issue?
[15:34] <awilkins> jam: Hello, I have a build of the python-installer packages for windows if you want them
[15:34] <jam> jelmer: there is a known issue with newer versions of pycurl giving select/poll errors, yes
[15:34] <jam> I don't know that anyone has really dug into it
[15:34] <jelmer> jam, ah, ok
[15:34] <jelmer> jam, So this occurs with older versions of bzr as well?
[15:34] <jam> I thought vila poked at it a bit, but has been gone the last 3 weeks, and doesn't really start up again for about 24hrs
[15:35] <jam> jelmer: it has to do with the new pycurl, not so much bzr
[15:35] <jam> As I understand
[15:35] <jam> so <hardy works
[15:35] <jelmer> jam: Ah, cool - thanks
[15:35] <jelmer> siretart, ^^
[15:36] <jelmer> jam, well, not *cool* but good it's not a new issue introduced by bzr :-)
[15:37] <siretart> jelmer: sec
[15:38] <siretart> jelmer: okay, I'll upload then rc5 in a minute then
[15:38] <siretart> jelmer: where to find the loggerhead packaging branch?
[15:39] <jelmer> siretart, http://bzr.debian.org/pkg-bazaar/loggerhead/unstable
[15:39] <jam> awilkins: thanks, I would guess it is easier to just have me reboot and build them, or have markh do it when he does the full installer. Mostly because someone needs to upload them, and sending 5MB email attachments isn't great :)
[15:39] <timnik> when doing a "bzr pull" is it possible to tell bzr to not overwrite a particular file? (ever?)
[15:40] <timnik> i.e. one of the files under version control
[15:41] <timnik> I'm guessing it's not, but if I'm wrong would be cool :-)
[15:44] <Peng_> beuno: ping
[15:44] <beuno> Peng_, pong
[15:45] <Peng_> beuno: Just to make sure, is it safe to have Loggerhead's /static/ directory served by another web server instead of LH itself?
[15:45] <jam> timnik: generally not
[15:46] <beuno> Peng_, sure, I don't see why that would blow up at all
[15:46] <awilkins> jam: Fair enough
[15:46] <Peng_> Yeah, it seems to be working fine.
[15:46] <beuno> it accesses everything through the URL, so you should be fine
[15:46] <Peng_> Thanks. :)
[15:47] <awilkins> timnik: A pull will never overwrite a file. It may move it, but not destroy it
[15:47] <beuno> Peng_, anything for our star tester  :)
[15:47] <timnik> jam, thanks
[15:47] <Peng_> :)
[15:47] <timnik> awilkins, would it not attempt to update it, if it's contents had changed?
[15:47] <awilkins> timnik: Unless that's part of the revisions pulled of course....
[15:48] <timnik> awilkins, well, yes
[15:48] <timnik> awilkins, not to worry. It's more a matter of me being lazy than any real problem.
[15:48] <timnik> thanks!
[15:52] <awilkins> timnik: You could write a post-pull hook that restored your file I suppose
[15:53] <timnik> awilkins, Thanks for the hints. What I should really do is fix my program to use a custom settings file not under version control. :-D
[15:54] <timnik> awilkins, admittedly I was looking for the lazy way out
[15:54] <awilkins> timnik: I like a versioned template that you copy, but it's on the ignore list in it's "active" position
[15:55] <timnik> awilkins, hmm, that's an idea
[15:55] <luks> the problem with this is that you have to manually copy any change to the real config
[15:55]  * timnik runs to try it
[15:55] <luks> I'd really like to see a proper solution to that problem
[15:55] <luks> but I can't think of anything
[15:55] <awilkins> Primary file is versioned but secondary ignored file overrides it?
[15:55] <timnik> luks, it should really ever be a problem. If it's needed, the developer is doing something wrong, imho.
[15:56] <timnik> In this case it's me, and I'm too lazy to fix it.
[15:56] <luks> timnik: well, software evolves and you need to add some configuration options
[15:56] <timnik> *never
[15:56] <timnik> luks, well, have a default file, and use it, unless a custom file exists. The settings in the custom file override that of the default.
[15:57] <timnik> default is under version control, custom is not, and is only ever used if it exists.
[15:57] <luks> hmm, yeah, that works for some cases
[15:57] <luks> but it's still not as flexible as I'd like
[15:57] <timnik> heh, now you sound like me :-P
[15:58] <timnik> is in possible to undo a "bzr ignore" other than edit the ignore file?
[15:58] <luks> I don't think so
[15:58] <timnik> oh, ok. Almost had it. :-D
[16:07] <awilkins> Is it just me or are the google IMAP servers being a right pain in the bum today...
[16:09] <pickscrape> They go through spells. Unfortunately Thunderbird doesn't deal with it particularly well :(
[16:12] <Peng_> The only issue I ever have is having to log in frequently.
[16:12] <Peng_> Is that what you meant?
[16:16] <awilkins> Peng_: Yes, that's what I mean
[16:16] <Peng_> That is a pain, but I've gotten used to it. :\
[16:17] <Peng_> That shows how much it happens.
[16:17] <beuno> awilkins, FWIW, I'm having problems with gmail through the web interface
[16:17] <beuno> it's doing odd things
[16:18] <Leonidas> What does hgext.convert.common.getchanges mean by "where id is the source revision id of the file."
[16:19] <siretart> jelmer: oh, loggerhead is a completely NEW package, isn't it?
[16:19] <Leonidas> I thought it was the revision id where the file was last modified.
[16:19] <jelmer> siretart, yes
[16:19] <Leonidas> oops, sorry, wrong channel ;)
[16:19] <Leonidas> (although the question is bzr-related, too)
[16:19] <awilkins>  Leonidas Filthy mercurial user! Begone!
[16:20] <siretart> jelmer: oh, that meas I have to do a more thourough license check and such, I won't get to it today, will try tomorrow. If I fail to manage it until saturday, please ping me again
[16:20] <jelmer> siretart,
[16:20] <siretart> jelmer: btw, did you run 'licensecheck -r .' on the source?
[16:20] <Leonidas> awilkins: hey, when i implement the bzr_sink, you'll be able to convert hg repositories to bzr ;)
[16:20] <jelmer> siretart, thanks!
[16:20] <jelmer> siretart, no, wasn't aware of that tool yet
[16:20] <jelmer> siretart, I will, now :-)
[16:21] <siretart> jelmer: it is a rather simple tool using regex to determine the license of each file. of course not bulletproof, but a great asset for ftpmasters ;)
[16:21] <siretart> it is in the 'devscripts' package
[16:22] <jelmer> siretart, yep, found it
[16:22] <jelmer> siretart, I did a recursive grep for Copyright, that seemed to've covered everything
[16:23] <jelmer> siretart, I'll keep this in mind for next time though, very useful
[16:24] <jam> Leonidas: my understanding was that with hg fast-export | bzr fast-import you already *can*
[16:24] <jam> Or with the bzr-hg plugin, though I don't know if it has received any polish in a while.
[16:24] <jam> Leonidas: I don't really understand that sentence, in the context of hg or bzr
[16:25] <jam> "source revision id of the file" sounds like the revision id that initially added the file?
[16:25] <Laney> Is this bug known and/or fixed? http://paste.ubuntu.com/39425/
[16:26] <Leonidas> jam: Yeah, but as far as I have seen it should be the "current" revision.
[16:27] <Leonidas> jam: I haven't tried fast-(im/ex)port, need to give it a try. I am currently hacking up hg convert so there is support for continous integration of new changesets into repositories.
[16:27] <jam> Laney: sounds like you have the bzr-dbus plugin installed
[16:27] <jam> I don't know why it would need X11
[16:27] <jam> you could do "bzr pull  --no-plugins" and have it work
[16:27] <jelmer> siretart, any chance you can commit your changes for rc5 in the bzr branch on alioth?
[16:27] <Laney> I have no idea what that is jam
[16:28] <Laney> I'll file the bug
[16:28] <jelmer> Laney, that's a known issue in bzr-dbus
[16:28] <Laney> Oh!
[16:28] <jam> Laney: I don't know who did your setup then :) But you seem to have the bzr-dbus package installed. If you don't use it, you could "apt-get remove" it
[16:28] <Laney> jam: Maybe it was pulled in as a dep of something?
[16:29] <Laney> "Automatically installed: yes"
[16:29] <Laney> Well if it's known then I will wait
[16:29] <jelmer> Laney, https://bugs.edge.launchpad.net/bzr-dbus/+bug/107169
[16:30] <jelmer> bzr-gtk suggests or recommends bzr-dbus these days, I think apt may automatically install it when you install bzr-gtk by default
[16:31] <Laney> Probably. But I don't know why bzr-gtk would be involved at all - I'm invoking this over SSH
[16:32] <Leonidas> To read a file from a repo I just need to lock_write it, right? Because lock_read 8which is unfortunately undocumented) would lock it also for reading, as far as I can guess. Am I right?
[16:32] <jelmer> Laney, If you install bzr-gtk, apt may also install bzr-dbus for you
[16:33] <jelmer> Laney, bzr-gtk isn't involved here, but bzr-dbus probably came along with it if you installed it
[16:33] <siretart> jelmer: err, I already did?
[16:33] <Laney> jelmer: Right, I get that. But shouldn't bzr-dbus be disabled if calling over SSH too, or?
[16:33] <siretart> >> bzr missing sftp://bzr.debian.org/bzr/pkg-bazaar/bzr/unstable/                                                          :0.0
[16:33] <siretart> Branches are up to date.
[16:34] <Laney> jelmer: Anyway, removing bzr-dbus has fixed it. Many thanks
[16:34] <jelmer> siretart, sorry, my bad
[16:34] <jelmer> siretart, my mail is just very slow today
[16:34] <jelmer> pulling manually does indeed work
[16:36] <siretart> jelmer: I work with checkouts, my local branch is bound to alioth
[16:38] <jelmer> siretart, I was checking for a commit email from alioth, but for some reason are not seeing any
[16:39] <siretart> ok, heading home now, cu later!
[16:40] <jelmer> see you!
[17:32] <jam> beuno: did you see luks: http://bazaar.launchpad.net/~luks/bzr/packaging-tools/annotate/3?file_id=ppa.txt-20080821102811-jhoajulm56uo6vgm-1
[17:33] <jam> vila: I submitted my patch (with test) for bug #259855 so I closed that bug, but opened a new one about FTP transport and assigned it to you. It is priority low, so you are welcome to ignore it, unassign it
[17:34] <beuno> jam, oh, open source rocks!  :)
[17:34] <jam> beuno: I haven't tried it
[17:34]  * beuno branches
[17:34] <jam> but it looks like he set up a few packaging branches
[17:34] <jam> and has the whole thing fairly scripted
[17:34] <jam> I noticed he left out "intrepid"
[17:35] <jam> and he hosted the packaging branches as "bzr" project branches, which isn't quite correct.
[17:35] <jam> but in general, it could make things a lot easier.
[17:35] <luks> jam: they already were under bzr
[17:35] <jam> I would probably create a "bzr-packaging" project, and migrate things over to ~bzr/bzr-packaging etc.
[17:35] <jam> luks: ah, well, that doesn't make it *right* :)
[17:35] <jam> Probably martin did that
[17:36] <luks> I think it's common on launchpad to have debian/ubuntu packages under the product
[17:36] <beuno> luks, very cool. I'll poke at it in a bit
[17:36] <luks> beuno: the main advantage is that it uses bzr-builddeb
[17:36] <luks> so you don't have to mess with tarballs
[17:37] <luks> the scripting is just extra bonus (yes, I was bored :))
[17:37] <beuno> luks, so you worked around the .c/pyrex problem?
[17:37] <luks> there is no .c/pyrex problem
[17:37]  * LarstiQ waves a spoon about.
[17:38]  * pickscrape watches the spoon bend
[17:39]  * timnik thinks there is no spoon
[17:39] <beuno> luks, didn't jam mention something yesterday?
[17:39] <luks> yes, and he was wrong
[17:39] <luks> sorry :)
[17:39] <beuno> that's great news!
[17:39] <jam> luks: so how do you get the .c files into the output?
[17:39] <jam> if you aren't using tarballs?
[17:40] <luks> jam: *you* put them there
[17:40] <luks> it does use tarballs
[17:40] <luks> but bzr-builddeb takes care of it, not the packager
[17:40] <jam> luks: ok, you just said: (11:36:52 AM) luks: so you don't have to mess with tarballs
[17:40] <jam> Just a bit confused
[17:40] <jam> but as long as it works :)
[17:40] <luks> sorry
[17:41] <beuno> jam, can you release a rc6, so I can test this?
[17:41]  * beuno ducks
[17:42] <jam> beuno: You'll get a 1.6-final in a few days
[17:42] <jam> is that sufficient :)?
[17:42] <jam> You could do everything but upload
[17:42] <beuno> sure, let's alpha-test with 1.6 final  :p
[17:42] <beuno> I'm kidding, yes
[17:42] <beuno> I can upload to my own PPA n' stuff
[17:42] <fullermd> 1.6-final is a RC for 1.7   :p
[17:42] <luks> heh
[17:43]  * beuno slowly moves away from jam 
[17:44] <jam> beuno: isn't that what 1.6.1 is for? :)
[17:44] <jam> actually 1.6~bazaar2
[17:45] <jam> since the tarball doesn't change
[17:45] <jam> just the packaging
[17:45] <teratorn> beuno: back away, slow. don't take your eyes off of it
[17:45] <jam> or maybe 1.6~bazaar1~hardy2 ?
[17:45] <beuno> yeah, as of today, I can upload all bzr packages with "control + r" and changing 4 or 5 characters
[17:45] <jam> I don't strictly understand all the numbering ideas
[17:46] <fullermd> Yeah.  Like "1.6i+5".  It gets so complex.
[18:16] <Odd_Bloke> I checked out part of a Subversion repo using bzr-svn.  I did some local commits and then tried to do a non-local commit (which I was expecting to sync up all the commits).  I was told that the local branch was out of date with the SVN branch.  Nothing has changed in that part of the repo (though I don't know about the repo as a whole).
[18:16] <jelmer> Odd_Bloke, you need to "bzr up" first
[18:17] <jelmer> Odd_Bloke, and you may have to push the changes to svn first
[18:17] <Odd_Bloke> I'm now trying to push my changes into there and bzr-svn seems to be browsing the ~245 branches (as per the branching scheme) on the server, without any actual pushing seeming to happen.
[18:18] <vila> fullermd: ROFL
[18:18] <jelmer> Odd_Bloke, it is checking whether the revisions are already there somewhere in one of the other branches
[18:18] <Odd_Bloke> OK, I'm now pulling from my branch into a pristine checkout of the SVN.  Which seems to be working...
[18:18] <vila> jam: ok, I'll look into it in 12.5 hours 8-)
[18:19]  * fullermd clicks off a stopwatch.
[18:20]  * vila tweaks fullermd's watch to adjust it: 12h40m
[18:40] <kek2> hi
[18:45] <kek2> hi everybody. i'am using bzr first time. I Committed revision 1. How can i push the commit to a server over ssh?
[18:47] <Odd_Bloke> kek2: 'bzr push sftp://<user>@<server>/<path>'.
[18:47] <jelmer> Odd_Bloke, "bzr push <svn-url>" would've also worked
[18:47] <kek2> ok, i will test
[18:47] <Odd_Bloke> jelmer: Yeah, I realised this just now (when it did work :D).
[18:47] <Odd_Bloke> But the pulling option is actually quicker, because it doesn't feel the need to scan for the revision in every branch.
[18:47] <kek2> kekz@firefly:~$ bzr push sftp://kekz@kekzkbook/home/kekz/test
[18:47] <kek2> bzr: ERROR: Not a branch: "/home/kekz/".
[18:48] <kek2> whats the mistake?
[18:48] <Odd_Bloke> kek2: Well, '/home/kekz/' is not a branch.
[18:48] <kek2> the same error when i use bzr push bzr+ssh: ... usw.
[18:48] <Odd_Bloke> kek2: So you can't use bzr to push it anywhere.
[18:48] <Odd_Bloke> Which directory were you in when you committed revision 1?
[18:49] <kek2> oh ... so i must initalize an empty commit on server?
[18:49] <Odd_Bloke> kek2: No, locally.
[18:49] <Odd_Bloke> kek2: What directory were you in when you committed revision 1?
[18:50] <kek2> /media/daten/devcenter
[18:50] <kek2> no .. the last time i try from /home/kekz
[18:50] <kek2> aah :)
[18:51] <kek2> ssh: kekzkbook: Name or service not known
[18:51] <kek2> bzr: ERROR: Unable to connect to SSH host kekzkbook; EOF during negotiation
[18:51] <kek2> ok, i think i have an dns problem
[18:51] <kek2> wrong hostname
[18:51] <kek2> ok, it works
[18:51] <kek2> Odd_Bloke: Thank you
[18:52] <kek2> its pushing =)
[18:53] <Odd_Bloke> kek2: No worries, glad I could help. :)
[18:57] <kek2> i have a pc and a notebook and a server (in vmware on the notebook). Sometimes i work on my pc, sometimes i work on my notebook. What is the best practice .... to push and pull from server      OR    to push and pull between pc and notebook directly?
[18:58] <Odd_Bloke> Argh, I'm having to commit for the third time because I forget that bzr-svn will prompt for passwords multiple times.
[19:04] <uws> Odd_Bloke: ssh keys to the rescue?
[19:10] <jelmer> Odd_Bloke, bzr-svn doesn't prompt multiple times, bzr does :-)
[19:17] <jelmer> kek2, either will work fine I think
[19:17] <jelmer> hmm, bb down again?
[19:17] <jelmer> james_w, hi
[19:19] <beuno> jelmer, it's been down for a while, and abently is on vacation
[19:25] <jelmer> beuno: ah, ok
[19:28] <Odd_Bloke> jelmer: Hmm, I've only noticed it when using bzr-svn.
[19:28] <jelmer> Odd_Bloke, the checkout logic is all inside of bzr
[19:29] <jelmer> Odd_Bloke, have you used local commits with checkouts and native bzr branches?
[19:29] <Odd_Bloke> No, I suppose not.
[19:31] <kek2> bye
[19:31] <kek2> and thanks for help
[19:33] <vila> jam: I agree 60% with your analysis and 100% with your patch for #259855, I'll address the remaining 40% while fixing #260131, so BB:approve
[19:33] <mwhudson> jelmer: i was trying to help a guy the other week who (it turned out) was doing 'bzr ci' in a svn working tree when the svn server was inaccessible
[19:33] <mwhudson> jelmer: the error was not very clear :)
[19:34] <vila> ubottu: grrr, bug #259855
[19:34] <jelmer> mwhudson, did you file a bug ? :-)
[19:34] <jelmer> mwhudson, or, do you perhaps remember what the error message was?
[19:34] <jam> vila: shame on you for harassing the ubottu :)
[19:35] <vila> ubottu: grrr, bug #260131, yeah, mister bot, but come on #226131 is *obvious* !!!
[19:35] <mwhudson> jelmer: oh, it was https://bugs.edge.launchpad.net/bzr-svn/+bug/211683, you commented already
[19:35] <vila> jam:  :-P 23.5 hours to go :)
[19:35] <mwhudson> jelmer: that's what the comment from chris perkins was about
[19:36] <fullermd> What?  It was 12.5 an hour and a quarter ago!
[20:30] <beuno> mwhudson, hi. Want to see something weird?  bug #260190
[20:31] <mwhudson> beuno: !?
[20:33] <beuno> mwhudson, I have *no* idea how different tabs can be show on different places
[20:37] <jam> vila: wouldn't that mean you start late in the evening on Friday? I should get your TZ sometime so I can keep track of your offset.
[20:37] <jam> Though I guess knowing your working hours is just as important :)
[20:38] <beuno> vila should be UTC +2
[20:38] <jam> beuno: so basically your template is der-broken?
[20:38] <jam> That is kind of odd
[20:38] <jam> But I certainly see the same thing
[20:39] <jam> the help tab disappears when you are under changes
[20:39] <beuno> jam, well, the tabs are generated from one place only, so this kinda throws me off  :)
[20:45] <james_w> hey jelmer
[20:45] <jelmer> james_w, Have you had any time to look into my debian directory service patch for bzr-builddeb yet?
[20:46] <james_w> jelmer: I put it on hold, sorry.
[20:46] <jelmer> james_w, No hurry, just making sure it's not forgotten
[20:46] <james_w> ah, ok.
[20:46] <jelmer> james_w, How's the bzrification of the archive going?
[20:46] <james_w> I may try and fold it in this week, but I'm wondering how it interacts with my other work
[20:47] <james_w> I haven't started another conversion run since the sprint as I have been focusing on other things, but it's hopefully on track
[20:52] <jelmer> james_w, ah, cool
[20:53] <jelmer> james_w, you've probably already seen it, but just in case: https://wiki.ubuntu.com/BzrMaintainedPackages
[20:53] <james_w> ah, great, thanks
[20:53] <james_w> that's probably going to be useful
[21:16]  * mwhudson hmms
[21:16] <mwhudson> lifeless: awake yet?
[21:27] <rocky> anyone here using TracBzr ?
[21:28] <rocky> curious what it's "status" is
[21:29] <pickscrape> I am
[21:29] <pickscrape> Though I'm not sure of its status
[21:29] <rocky> pickscrape: is there a released version to use or is using a snapshot from bzr the best bet or?
[21:29] <pickscrape> It seems to have some problems with bzr 1.6.
[21:29] <pickscrape> We're using a snapshot from bzr
[21:29] <rocky> this branch seems to be working on bzr 1.6 compat
[21:29] <rocky> https://code.launchpad.net/~scott-idealist/trac-bzr/bzr-1.6
[21:30] <pickscrape> ooh, I hadn't seen that...
[21:30] <pickscrape> Thanks for pointing me at that :)
[21:30] <rocky> np :)
[21:30] <rocky> i'm not so interested in 1.6 support yet ... what i'm more curious about is just how fast it is compared to trac's native svn support and being sure it won't blow up my server ;)
[21:32] <pickscrape> Our experience is that it seems to be slower, though that could be because we have it pointing at a directory containing multiple shared repositories that contain multiple branches
[21:32] <rocky> hm
[21:33] <rocky> does it have any kind of support for cross-referencing revision links in wiki formatting? (ie with svn support, if in a ticket you reference r23 it automatically links to svn/browser r23 changeset url)
[21:34] <pickscrape> Yes
[21:34] <pickscrape> It looks like [branch_name,revno]
[21:34] <pickscrape> e.g. [trunk,34]
[21:35] <rocky> oh cool
[21:35] <rocky> i'ven ever hosted an actual bzr repo before so that's something i'll have to play with anyhow
[21:35] <pickscrape> Though there is an annoyance in that if the branch name contains a slash, it gets escaped and looks awful. Not sure if that's a problem with trac core or trac-bzr though.
[21:41] <brl4n> just installed and started playing with bzr an hour ago. Trying to do a push via sftp but I'm getting an "Connection abandoned.
[21:41] <brl4n> bzr: ERROR: Unable to connect to SSH host localhost; EOF during negotiation
[21:42] <brl4n> not exactly sure if it is an ssh problem or bzr problem
[21:42] <mwhudson> brl4n: sounds like an sftp problem
[21:43] <brl4n> well I am able to connect through a sftp client.
[21:43] <mwhudson> hmm
[21:43] <mwhudson> what platform?
[21:44] <brl4n> winXP using openshh
[21:44] <brl4n> bzr returns the rsa2 key finger print
[21:45] <brl4n> "Connection abandoned" then the Error: Unable ... etc
[21:45] <brl4n> i've googled around but wasn't able to come up with anything
[21:46] <mwhudson> oh windows
[21:46] <mwhudson> i know things can be a bit hard to set up there, don't know the details though :/
[21:47] <mwhudson> markh probably does, but i guess he's asleep
[21:47] <brl4n> yah that is what I'm thinking
[21:47] <brl4n> okie
[21:47] <brl4n> i'll idle around then.
[21:47] <brl4n> thanks
[21:47] <mwhudson> jam, vila: maybe you can advise brl4n ^ ?
[22:12] <lifeless> jam: ping
[22:12] <jam> lifeless: pong
[22:12] <lifeless> that log patch was against bzr.dev
[22:12] <lifeless> no missing revisions
[22:13] <lifeless> if you'll note it was started on rev 3642 of trunk -   (jam) Merge in 1.6rc5 and revert disabling default stack on policy
[22:14] <lifeless> also, good morning
[22:14] <jam> lifeless: well, the patch I see includes the NEWS entry for 1.6rc4 and 1.6rc5
[22:14] <jam> Are you sure it was against bzr.dev proper?
[22:14] <jam> (are you sure your bzr.dev copy is up-to-date)
[22:15] <lifeless> oh wrong parent,
[22:15] <lifeless> its got integration as my parent for some retarded reason
[22:15] <jam> aha
[22:15] <jam> good morning to you, too :)
[22:15] <lifeless> resent
[22:17] <rockstar> Is there a way you can put a plugin in the plugins directory, and blacklist it so it doesn't load in bzr?
[22:17] <lifeless> yes, don't put it in there
[22:17] <lifeless> rockstar: why do you want to do that?
[22:24] <rockstar> lifeless, because we need the functionality of the plugin, but don't want bzr actually trying to use it
[22:24] <lifeless> rockstar: 'we' ?
[22:24] <rockstar> All the imports are 'from bzrlib.plugins.foo'
[22:24] <rockstar> lifeless, lp-code
[22:24] <lifeless> rockstar: a little more detail and I can probably be really clear and helpful :)
[22:25] <rockstar> lifeless, sorry
[22:25] <lifeless> if you have python code you want to use froma python program that also uses bzrlib
[22:25] <lifeless> you can just import it
[22:25]  * rockstar winds up
[22:25] <lifeless> if its not a bzrlib plugin, don't put it in plugins
[22:25] <lifeless> if it is a plugin, put it in plugins
[22:26] <rockstar> So, I'm trying to implement a new layer into cscvs which will use the work jelmer did for svn.
[22:26] <rockstar> So, we need the bzr-svn code, but we don't actually want it used by bzr
[22:26] <lifeless> well
[22:26] <lifeless> you'll need to restructure bzr-svn then
[22:26] <lifeless> or
[22:27] <lifeless> only have it in the bzrlib plugins path when cscvs is running
[22:27] <lifeless> BZR_PLUGINS_PATH
[22:27] <rockstar> Yea, that's what I had figured, and that's what mwhudson and I decided would be a good idea
[22:28] <lifeless> though I'd just install it normally and use it
[22:28] <lifeless> (where normal is probably in the lp rollout system)
[22:28] <lifeless> unless you have a specific reason /not/ to have it available
[22:29] <lifeless> bzr.dev is looking at shipping bzr-svn by default
[22:30] <mwhudson> lifeless: it seems like it would be a bad idea to have bzr-svn active when running the supermirror-pull.py mirror script
[22:30] <mwhudson> unless we want to start supporting imports via bzr-svn essentially by accident
[22:30] <lifeless> mwhudson: doesn't the pull check the branch type already?
[22:31] <lifeless> mwhudson: seems like the 'manually create an identical format in the target' step will fail epicly with bzr-svn branches and repositories :)
[22:31] <mwhudson> lifeless: that's true i guess, but a bit of a detail
[22:31] <mwhudson> lifeless: also, we use clone() for the initial branch creation now
[22:32] <mwhudson> lifeless: which relates to something else really i want to talk to you about...
[22:33] <mwhudson> ('manually create an identical format in the target' is also broken for bzr+http of course)
[22:34] <lifeless> mwhudson: indeed
[22:34] <lifeless> so, what I'd do is to integrate and test bzr-svn carefully
[22:35] <lifeless> rather than doing something complex and hoping noone says 'this is too complex' and 'fixes' it later
[22:35] <lifeless> without thinking of the things you have thought of
[22:35] <mwhudson> though oh god, we'll probably completely re-mirror a bzr+http branch each time the puller runs now :(
[22:36]  * mwhudson biles a fug
[22:38] <lifeless> better than buggering a file
[22:53] <mwhudson> bug 45277
[23:22] <AfC> So revision specs can be used with -r arguments, all good; is there a way to use them with commands that just take a branch URL (ie, I'd like to do `bzr missing push:` but that doesn't fly)
[23:22] <mwhudson> well
[23:22] <mwhudson> i think you mean bzr missing :push
[23:23] <mwhudson> that works and isn't a revisionspec
[23:25] <AfC> ooooh
[23:25] <AfC> nifty
[23:25]  * AfC wonders where he could have learned that himself
[23:25] <AfC> mwhudson: (but I was referring to forms like `bzr diff -r parent:` )
[23:37] <mwhudson> AfC: it's not documented yet
[23:43] <james_w> AfC: I think parent is also :parent
[23:43] <AfC> Interesting
[23:43] <jonnyde1> hi, I've got a question regarding bundles: is it possible to backup a bazaar branch and all its revisions using a bundle? if so, how would it look like?
[23:43] <james_w> AfC: but if you mean e.g. "branch:" then I think "branch:29:wherever" is the way
[23:44] <AfC> I'm going to observe that it seems a bit strange that the thing: pattern was inverted to :thing
[23:44] <james_w> the :thing things are not revision specs, they are location specifiers
[23:45] <AfC> (if it's meant as a suffix, then fine, it makes sense, but it is rather glaring as using the same names in an inconsistent way. That tends to be a UI foible)
[23:45] <james_w> I'm not sure that they are the same names
[23:45] <AfC> james_w: parent, branch?
[23:45] <mwhudson> it's not really the same class of thing, even
[23:45] <AfC> same
[23:45] <mwhudson> though i agree it's a bit confusing
[23:45] <james_w> I'm not that keen on :parent et. al., but I don't think they conflict
[23:45] <james_w> AfC: it's branch: and :parent, they are two different words
[23:46] <AfC> james_w: bzr command -r branch:path
[23:46] <AfC> james_w: bzr command  path:branch
[23:46] <james_w> you can say using very similar things is a problem, but I don;t think they are the same
[23:46] <james_w> AfC: the second doesn't make any sense as far as I am aware
[23:46] <jonnyde1> (I would like to have a backup which is independent of the repository format)
[23:46] <james_w> or is that one I'm not familiar with?
[23:46] <AfC> ok
[23:47] <AfC> james_w: bzr command -r parent:
[23:47] <AfC> james_w: bzr command :parent
[23:47] <james_w> I could imagine it as "the branch of this tree wherever it is"
[23:47] <AfC> you're trying to tell me that people aren't going to go out of their minds trying to remember when to use which?
[23:47] <james_w> I don't think parent: is recognised
[23:48] <james_w> oh, I don't dispute that, but you said "same words", and I don't think there are any actually replicated
[23:48] <AfC> james_w: as may be.
[23:48] <AfC> james_w: were I a betting man, I'd be wagering heavily on this one.
[23:49] <james_w> AfC: is the very nature of these things a problem, or is it just the presentation?
[23:49] <james_w> would e.g. branch: and @parent be easier?
[23:50] <jonnyde1> I think somehow creating a diff (bundle) between an empty branch and the branch to be backed up should do it, shoudn't it?
[23:51] <james_w> jonnyde1: I think so
[23:52] <jonnyde1> so this should also be a way to convert a format into another format where no direct upgrade/downgrade is available...?
[23:52] <james_w> direct upgrade is available from every format since 0.4 or something as I understand
[23:53] <james_w> (so long as you don't try and go rich-root->non-rich-root or similar)
[23:53] <jonnyde1> well, but as I figured out this is not true for downgrading
[23:53] <james_w> and as a bundle contains the revision data you won't be gaining anything
[23:54] <bob2> going via bundles won't let you downgrade repository formats
[23:54] <jonnyde1> why not? is the bundle format specific to a repository format?
[23:55] <james_w> I think it just serialises the source repository format
[23:55] <jonnyde1> ok, I see. So a cannot apply a bundle to a repository where the formats are incompatible...
[23:57] <bob2> well, pretty sure it works upwardly
[23:58] <bob2> but you can't go back (from rich-root to plain)
[23:58] <jonnyde1> I wonder why there is no way to just export a series of commits. This way, I could just replay the commits, no matter what format the repository has...
[23:58] <james_w> you can fast-export, but it's lossy
[23:59] <jonnyde1> bob2: btw, thanks for your feedback
[23:59] <bob2> you can, as diffs or fast-export, but that doesn't help you