[00:01] <ubotu> New bug: #111826 in bzr-gtk "Broken menu items in nautilus integration " [Low,Fix committed] https://launchpad.net/bugs/111826
[00:01] <ubotu> New bug: #149061 in bzr-gtk "Cannot view diff of first revision" [Medium,Fix committed] https://launchpad.net/bugs/149061
[00:28] <radix> PenguinOfDoom: bzr branch lp:~subol-hackers/subol/shared.dev
[00:28] <radix> oops, mischan
[00:36] <poolie> hi radix!
[00:37] <radix> yo poolie :-)
[00:42] <RAOF> Heya radix!
[00:42] <radix> wow, it's a party
[00:42] <radix> Hi RAOF :)
[00:42] <RAOF> :)
[00:43] <poolie> lifeless: what are your thoughts on rich-root-pack conversion bugs and 1.3?
[00:44]  * Odd_Bloke pumps out the beats.
[00:47]  * TFKyle pumps out the beasts
[00:49]  * j1mc jumps to the pumped out beats
[00:49] <TFKyle> (aka. party-goers)
[00:59] <lifeless> poolie: 1.3 is time based, I don't think those things are related
[01:00] <lifeless> poolie: as the conversion issues are not regressions
[01:01] <j1mc> lifeless: just wanted to say thank you for your explanations yesterday.  you were very helpful.  the history is now correct, and i've used bzr bind to ensure i won't have the same problem again.
[01:01] <poolie> in other words go ahead without it
[01:01] <lifeless> j1mc: cool
[01:01] <j1mc> :)
[01:01] <lifeless> poolie: yah
[01:09] <lifeless> poolie: what do you think
[01:10] <poolie> it does seem to have been present for a while
[01:13] <lifeless> bbiab food ftw
[01:37] <lifeless> squid folk are liking bzr fwiw
[01:37] <lifeless> need to do some tweaks to bb for them
[01:37] <lifeless> use the right bugtracker
[01:37] <lifeless> and allow anonymous email voting
[03:00] <hunmonk> anybody have a sec to help me w/ an rspush error i'm getting?
[03:00] <lifeless> sure
[03:01] <hunmonk> lifeless: 504 colossus$~/Sites/apartmentlines.com/www: bzr rspush watchdog:bzr/apartmentlines.com
[03:01] <hunmonk> bzr: ERROR: Rsync could not use the specified location.  Please ensure that "watchdog:bzr/apartmentlines.com/" is of the form "machine:/path"
[03:01] <hunmonk> lifeless: if i run scp foo watchdog:bzr/apartmentlines.com
[03:01] <hunmonk> lifeless: works perfectly
[03:02] <hunmonk> lifeless: so i'm a bit confused what the issue is
[03:02] <lifeless> hmm
[03:02] <Odd_Bloke> hunmonk: The path you're giving isn't absolute, which the error message would suggest is required.
[03:03] <lifeless> well spotted
[03:03] <hunmonk> Odd_Bloke: full path doens't work, either
[03:03] <lifeless> also, are you aware of push-and-update ? its a plugin
[03:03] <lifeless> I would look in .bzr.log and see if anyting interesting is there
[03:03] <lifeless> also perhaps try strace and snarf the actual rsync command line being tried
[03:06] <hunmonk> lifeless: where is .bzr.log?
[03:06] <hunmonk> home dir?
[03:06]  * hunmonk looks
[03:06] <hunmonk> yup
[03:12] <hunmonk> lifeless: http://pastebin.ca/949874
[03:14] <lifeless> rsync is erroring
[03:14] <lifeless> strace is your friend
[03:15] <hunmonk> lifeless: lol.  no strace on my mac
[03:15] <hunmonk> lifeless: guess it's time to hit fink...
[03:15] <lifeless> truss perhaps ?
[03:15] <hunmonk> nope
[03:16] <lifeless> got to me some equivalent
[03:16] <bob2> dtrace11
[03:16] <lifeless> anyhow, rsync is existing with status 12
[03:17] <hunmonk> lifeless: doesn't scp use rsync as well?
[03:17] <bob2> no, scp is like cat over ssh
[03:17] <lifeless> hunmonk: no
[03:17] <hunmonk> oh
[03:17] <mwhudson> 'ktrace'
[03:17] <mwhudson> i think
[03:18] <fullermd> I'd expect rsync is spitting an error somewhere.  Try just running it manually.
[03:18] <hunmonk> fullermd: yeah, that was my next thought as well
[03:20] <hunmonk> lifeless: rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-30/rsync/io.c(359)
[03:20] <hunmonk> lifeless: i've never seen that before  :|
[03:21] <fullermd> Why, of course!  You forget to giblinetch the huntra in the config file.  Duh
[03:21] <bob2> could any of your login scripts on the remote machine be printing something out?
[03:22] <hunmonk> bob2: maybe
[03:27] <hunmonk> lol
[03:27] <hunmonk> lifeless: found the problem
[03:27] <hunmonk> lifeless: no rsync installed on destination server  :)
[03:41] <abentley> lifeless: Do you want to preserve the code style differences between the loom plugin and bazaar?
[03:47] <jml> I sense some restrained frustration there :)
[04:04] <jml> poolie: how's the release going?
[04:06] <jml> poolie: also, where's the branch for it?
[04:07] <lifeless> abentley: which ones?
[04:07] <abentley> The imports are the main thing I'm noticing.
[04:08] <poolie> jml, http://bazaar-vcs.org/bzr/bzr.1.3
[04:08] <abentley> In bazaar proper, we hardly ever do "import bzrlib.merge", for example.
[04:08] <abentley> It would be "from bzrlib import merge as _mod_merge"
[04:08] <lifeless> abentley: oh, its because loom is old code
[04:09] <abentley> Or possibly a direct object import.
[04:09] <lifeless> abentley: it was written in the same style as bzr of the time
[04:09]  * jml registers
[04:09] <abentley> By which I take it it's fine to use current Bazaar style in it?
[04:09] <lifeless> totally
[04:09] <abentley> Cool.
[04:11] <abentley> I'm running into a test case failure because we can't represent a tree whose last_revision is NULL_REVISION that has pending merges.  I think I'm going to drop it, but we should really fix that in Bazaar.
[04:16] <lifeless> uhm
[04:16] <lifeless> whats the reason for it ?
[04:16] <lifeless> like is it an existing test
[04:16] <lifeless> or a new one, and if new whats the use case?
[04:17] <abentley> No, I'm writing a new test, and I got an unexpected error.
[04:17] <abentley> I'm doing up_thread(); up_thread()
[04:17] <abentley> The second up_thread raises cannot switch threads with anout of date tree. Please run bzr update.
[04:18] <abentley> The underlying cause is that when last_revision is NULL_REVISION, tree.get_parents() is []
[04:19] <abentley> So adding a pending merge sets the lefthand parent.
[04:20] <lifeless> right, thats currently by design
[04:20] <lifeless> its consistent with our history storage too
[04:22] <abentley> Well, intentional or not, it's a limitation on what Bazaar can do, and it's occasionally reported as a bug.
[04:23] <lifeless> so I'm guessing your use case looks like
[04:23] <abentley> And in this case, it's causing looms to give an error that doesn't make a lot of sense.
[04:23] <lifeless> loomify, create-thread, down-thread, commit, up-thread
[04:23] <abentley> And then up-thread again.
[04:23] <lifeless> I would say in this case that up-thread leaving the new-thread the same as the bottom thread is actually fine
[04:24] <abentley> So you're saying that if up-thread changes the last_revision, it should change it on the branch also?
[04:24] <lifeless> uhm
[04:24] <abentley> The bottom thread has a new revision.
[04:24] <abentley> Call it X
[04:25] <abentley> bzr up-thread will set X as the tree's last revision, but will set the branch's last_revision to NULL_REVISION
[04:26] <abentley> You are saying it should set the branch's last_revision to X as well?
[04:27] <lifeless> I think it should set X as the threads last revision in this specific case; which will change the branch's last-revision as teh branch is just reflecting the thread state.
[04:31] <abentley> lifeless: What mechanism sets a thread's last revision?  All I see being set is the branch and tree.
[04:33] <lifeless> set_threads & _set_last_loom
[04:36] <lifeless> see for instance LoomSupport.record_thread
[04:36] <lifeless> thats the api you probably want to use here
[04:45] <abentley> lifeless: up_thread is currently doing Branch.generate_revision_history.  Swapping Branch.record_thread in breaks things horribly
[04:47] <abentley> I'll leave it generating revision history, and update it so it sets it to X when appropriate.
[04:50] <lifeless> abentley: you need both
[04:50] <lifeless> abentley: here's why.
[04:51] <lifeless> there is some duplicate data in the current loom branches, because of lazy-robert.
[04:51] <lifeless> the duplicate data is the current branch tip in .bzr/branch/last-revision, and the current thread version of the same data in .bzr/branch/current-loom[branch.nick]
[04:52] <lifeless> up-thread is normally just setting the last-revision to match the thread, but now it has to (sometimes) update the thread too
[04:52] <abentley> But hardly anything updates the thread copy, right?
[04:52] <abentley> Why isn't that calamitous?
[04:55] <lifeless> abentley: with a last-loom format update to record the revno in each thread, we could drop last-revision from disk and remove the duplication
[04:56] <lifeless> abentley: its not alamitous because looms hook in very lightly, and try to preserve regular branch behaviour as much as possible.
[04:56] <abentley> But commit doesn't update the thread copy, so why should up-thread update the thread copy?
[05:01] <lifeless> commit updates it
[05:01] <lifeless> now I need to remember how
[05:02] <lifeless> or if it doesn't then thats an interesting bug
[05:02] <abentley> I was just assuming that the behavior was lazy enough that it didn't matter.
[05:04] <lifeless> unlock does it
[05:04] <lifeless> read the unlock code
[05:04] <lifeless> so yes, you can be lazy here.
[05:04] <lifeless> and just set branch.last_revision
[05:04] <lifeless> as long as you'll be on the right thread when the branch is unlocked
[05:05]  * poolie starts 1.3 packaging
[05:09] <poolie> lifeless, abentley: any opinions on my mail about testing for unreleased locks?
[05:12] <abentley> As long as we do it, I don't care how.
[05:13] <poolie> i think i will keep a list of held locks
[05:13] <poolie> which is essentially what we're getting python to do for us, but in a flaky way
[05:13] <lifeless> poolie: did we not plan this at allhands?
[05:13] <lifeless> poolie: I thought the plan was to - provide a global event anyone can subscribe to which fires on lock and unlock
[05:13] <poolie> it rings a bell, i can't recall what was decided though? i think we said what i just said
[05:14] <lifeless> poolie: then add to the root TestCase a subscriber to that which accumulates lock/unlock events. And finally an addCleanup that asserts they are all matched.
[05:14] <lifeless> this is better than a global list of locks
[05:15] <poolie> k
[05:17] <lifeless> its better because we can then write tests that test the number of locks actually taken/released by a command
[05:17] <lifeless> and things like that
[05:17] <poolie> right, that sounds good
[05:18] <lifeless> it also doesn't depend on gc() having been run before the test finishes, or no-loops, and other such implementation details
[05:18] <poolie> sure
[05:18] <poolie> it's a strict superset
[05:19] <poolie> of what i was proposing
[05:19] <poolie> i'll send a patch for it
[05:19] <lifeless> sweet
[05:20] <lifeless> stab stab stab get_revision_graph
[05:20] <poolie> "that, and a pair of testicles"
[05:20] <poolie> makes me smile every time i make a release
[05:20] <poolie> vale jdub
[05:26] <poolie> welcome back tim
[05:32] <poolie> it turns out jam's renvo code has some bugs.
[05:35] <abentley> At least it doesn't have a pair of testicles.
[05:42] <lifeless> who knows
[05:42] <lifeless> hno in squid called bb bundlebunny the other day
[05:42] <abentley> hehe.
[05:51] <Odd_Bloke> jml: I'm struggling to get ``bzr merged-branches`` working at all.  If I have a 'bzr' directory with 'bzr.dev' and my topic branches under it, how can I get it to tell me which of those topic branches have been merged?
[05:53] <bob2> that wasn't supported according to the release announcement
[05:54] <lifeless> k, time to call it a week.
[05:54] <lifeless> shee you folk tuesday; except for poolie of course :)
[05:54] <bob2> don't od on eggs
[05:55] <Odd_Bloke> bob2: Right, but I can't work out what _was_ supported.
[05:55] <lifeless> bob2: *blink*
[05:55] <Odd_Bloke> lifeless: Happy Easter!
[05:56] <bob2> Odd_Bloke: ~/repository/bazaar/bzr/{trunk,fix-bug-41921921,make-foo-baz}, afaict
[05:56] <poolie> hello bob, odd
[05:56] <Odd_Bloke> bob2: Right, so I have a symlink from trunk to bzr.dev now, but am still getting odd errors.
[05:57] <bob2> Odd_Bloke: ah, sorry, I imagined a comma (with 'bzr.dev', and my topic branches under it)
[06:03] <abentley> lifeless: Okay, I've merged in the up-thread stuff.  Shall I do export-loom (with no default) too?
[06:09] <lifeless> abentley: yes please; please be sure to do a merge into the trunk, or use a bound branch - I'd like the mainline to be like bzr's with only the result of feature branches, now that loom is released
[06:09] <poolie> gack
[06:09] <abentley> lifeless: Sure, I understand.
[06:10] <abentley> To be safe, you should set append_revisions_only
[06:10] <lifeless> how do I do that
[06:10] <lifeless> is there an api call?
[06:10] <lifeless> also, append_revisions_only doesn't enforce all that I want ;)
[06:10] <poolie> bug 202778 killed my 1.3 merge
[06:10] <ubotu> Launchpad bug 202778 in bzr "false test failure when run in a directory containing the version name" [High,Confirmed] https://launchpad.net/bugs/202778
[06:10] <poolie> oh well
[06:10] <abentley> lifeless: Branch.set_append_revisions_only
[06:11] <lifeless> it only prevents pivots; it doesn't prevent push as opposed to merge + commit
[06:11] <abentley> Oh.  Perhaps that's another flag we should support.
[06:12] <abentley> Branch.set_commit_only_merges ?
[06:13] <lifeless> abentley: something like that would represent want I want yes
[06:13] <lifeless> abentley: but anyhoo I'm off
[06:13]  * lifeless waves
[06:13] <abentley> Happy bunny time.
[06:14] <peteshinners> Anyone have luck getting the eclipse plugin up? The updates site has no files according to eclipse?
[06:15] <poolie> i'm going to trivial in http://pastebin.ubuntu.com/5915/
[06:16] <abentley> r=abentley
[06:16] <poolie> thanks
[06:19] <abentley> I think that could give a false success, though.
[06:19] <poolie> that's true though
[06:19] <abentley> If there was a file, but the version number was wrong.
[06:19] <poolie> particularly on the directory name
[06:19] <poolie> exactly
[06:19] <poolie> maybe i should check it's in the first line
[06:20] <poolie> or indeed the exact format of the first line
[06:20] <poolie> hm
[06:21] <abentley> Either one sounds good.  I lean towards the second.
[06:21] <poolie> good point, thanks
[06:21] <poolie> are you in an unusual timezone or sleep pattern?
[06:28] <poolie> http://pastebin.ubuntu.com/5916/ instead then
[06:29] <Odd_Bloke> The comment seems superfluous now.
[06:30] <poolie> you're right, thanks
[06:34] <abentley> poolie: sleep pattern.
[06:56] <Odd_Bloke> jml: I've done some work on the merged-branches plugin that's at https://code.launchpad.net/~daniel-thewatkins/+junk/merged-branches
[06:57] <Odd_Bloke> It now takes a target branch and a directory (which defaults to '.'), uses a transport and has some better user feedback.
[07:18] <jml> Odd_Bloke: thanks.
[07:18]  * jml looks
[07:22] <Odd_Bloke> jml: I'm writing some tests ATM. :)
[07:23] <jml> Odd_Bloke: thanks!
[07:24] <poolie> ok i'm done, good nightall
[07:24] <poolie> jml, 1.3 is out
[07:24] <jml> poolie: thanks-
[07:24] <poolie> jml, the tarball is up but the merge has not completed yet
[07:24] <poolie> :/
[07:25] <jml> poolie: no worries
[07:25] <jml> poolie: I'll probably submit it tomorrow anyway
[07:25] <Odd_Bloke> poolie: Congrats! :)
[07:25] <poolie> oh one more thing
[07:25] <jml> yes?
[07:25] <poolie> that.
[07:26] <poolie> cheers
[07:26] <jml> heh heh
[07:26] <poolie> actually i'm going to visit Oksh briefly
[07:26] <poolie> see you
[07:30] <Odd_Bloke> jml: Some rudimentary tests have been pushed.
[10:43]  * awilkins yawns
[10:43] <awilkins> Dammit, 0400 hackathons do not suit me in my old age
[11:56] <ubotu> New bug: #204211 in bzr-svn (universe) "Displays a version warning on every operation" [Undecided,New] https://launchpad.net/bugs/204211
[12:52] <nekohayo> mmmh, is there a way to use bzr-svn without the breakalot rich-root-format? or convert rich-root into pack-92 or something?
[12:53] <dato> nekohayo: no, bzr-svn needs rich-root. what's your problem with it?
[12:54] <nekohayo> well, the fact that it seems to break :) https://bugs.launchpad.net/bzr/+bug/177874
[12:54] <ubotu> Launchpad bug 177874 in bzr "upgrading to rich-root-pack fails" [Medium,Confirmed]
[12:55] <nekohayo> so I was wondering if there was a way around it
[12:56] <nekohayo> more precisely I am the one who reported https://bugs.launchpad.net/bzr/+bug/202884
[12:56] <ubotu> Launchpad bug 202884 in bzr "can't merge (dup-of: 177874)" [Undecided,New]
[12:56] <ubotu> Launchpad bug 177874 in bzr "upgrading to rich-root-pack fails" [Medium,Confirmed]
[13:33] <abentley> nekohayo: There are some problems with upgrading to it.  I'm not aware of any problems for branches that are already in it.
[13:34] <nekohayo> abentley: well merging dirstate into rich-root fails
[13:34] <Qhestion> why is the description of a command in the output of "bzr help" indented to column 19 (starting with 1)?? shouldnt that be 20 ??
[13:35] <Qhestion> http://en.wikipedia.org/wiki/Off-by-one_error ??
[13:35] <abentley> nekohayo: Are you talking about the general case, or about the Bazaar source tree?
[13:35] <nekohayo> what do you mean?
[13:35] <abentley> The Bazaar source tree has some weirdness in it that is going to require extra care to upgrade.
[13:36] <abentley> The bug you referenced is an upgrade of the source tree to Bazaar itself.
[13:37] <abentley> Now you're talking about merge of dirstate failing.
[13:37] <abentley> But I don't know if you're talking about the Bazaar source base in particular, or some other source base.
[13:37] <nekohayo> abentley: yeah, my bug is #202884, but it was marked a duplicate
[13:40] <abentley> nekohayo: Is this a really old branch?
[13:41] <nekohayo> abentley: the one in rich-root is a freshly made one from svn, and the other one is dating back from the summer I think
[13:44] <abentley> So the revision in the example is from 2007-05-17.  At that time, we supported unique root ids in our development version, for a while.  I don't believe it was in any released version.
[13:45] <nekohayo> abentley: that is what makes things break?
[13:45] <nekohayo> any way to have bzr convert that?
[13:45] <abentley> That's what's been diagnosed so far.
[13:45] <abentley> I haven't looked at your particular branch.
[13:46] <abentley> Though I was going to.
[13:46] <abentley> To answer your original question, rich-root is mandatory for bzr-svn.  It was created especially for bzr-svn.
[13:47] <nekohayo> aah, that explains. the fact that there are multiple formats kind of puzzled me
[13:49] <abentley> nekohayo: I have inspected your branch, and it does have a unique id for the tree root.  So it's the same *root* cause :-)
[13:49] <nekohayo> what is that unique id thing?
[13:50] <nekohayo> isn't an "ID" unique by definition ?_?
[13:51] <abentley> In pre-2007 trees, the root directory always has an ID of "TREE_ROOT"
[13:51] <abentley> Trees created in the rich-root format always have unique IDs.
[13:53] <abentley> We're working on making a rich-root format the default.  It will be a slight tweak of rich-root-pack.
[13:58] <nekohayo> abentley: so can this be converted or salvaged without using the method "create a giant patch and lose history"?
[14:02] <abentley> We haven't yet got a solid patch that fixes it.  You might be able to re-generate the history using rebase.
[14:03] <abentley> This would preserve metadata such as your comments, but would generate new revision-ids.
[14:03] <nekohayo> oh, but once such a patch comes in bzr, it should heal itself ?
[14:04] <abentley> Yes, we'll support that conversion one way or another.
[15:26] <ubotu> New bug: #125751 in bzr-svn "Push raises exception about invalid property changes" [Medium,Fix released] https://launchpad.net/bugs/125751
[15:40] <lnxtech> Which repository format has the best performance (or will be the new standard in future releases)? I will be the only developer using the repo so I'm not concerned about backwards compatibility.
[15:43] <dato> lnxtech: the current default, pack-0.92
[15:45] <lnxtech> thanks
[16:41] <stammi> hi
[16:42] <statik> poolie: i don't see any ops in this channel, i suspect announcer is still banned. i've fixed it now, know what I should do to get the ban lifted?
[16:45]  * jdong taps jelmer's shoulder...
[16:45] <jdong> bzr co on bzr-svn doesn't exactly create a "bound branch" , does it?
[16:46] <ubotu> New bug: #204320 in bzr ""bzr patch" internal error" [Undecided,New] https://launchpad.net/bugs/204320
[16:46] <jdong> I tried a bzr co svn+file:///some/svn/repo on system foo, then on bar I did bzr co sftp://foo/bzr/checkout
[16:46] <jdong> then when on bar I tried to ci, I got some sort of svn assertion error
[16:47] <jdong> then I checked bzr info and apparently everything was some sort of svn format, not standard rich-root-pack bzr branches
[16:53] <abentley> staik: The ops don't usually fly their flag.  Hmm, how do I get ops again?
[16:53] <dato> /msg ChanServ op #bzr abentley
[16:53] <dato> I think
[16:54] <jam> abentley: well /op user is used to give ops to 'user', but I think you have to be op first :)
[16:55] <abentley> Anyone know the syntax for listing/altering bans?
[16:58] <abentley> help /op
[16:58] <jam> abentley: looking at plain help, I only see /kick, and no /ban
[16:58] <abentley> I think it's a mode you set on a wildcard.
[16:58] <jam> abentley: then '/help mode'
[16:59] <abentley> something like /mode +b *announcer*
[16:59] <jam> So /mode -b nick
[16:59] <jam> something like that
[17:00] <Parker-> /mode -b *!*announce@*
[17:00] <stammi> is there any chance to check out a svn repository with bzr via https?
[17:01] <stammi> it seems to fail, while svn works
[17:02] <stammi> i tried  bzr svn-import https://subversion..... as well as bzr co
[17:02] <stammi> it responds with 401 Auth required
[17:03] <james_w> stammi: try svn+https://...
[17:04] <abentley> statik: How you like it now?
[17:05] <Parker-> /mode -b *!announce@165.198.204.68.cfl.res.rr.com
[17:05] <Parker-> ;)
[17:05] <stammi> it says "No Repository found at ... use bzr branch" if i do so there comes a legthy error which essentially says SubversionException: ("Undefined tunnel scheme 'https'"
[17:05] <Parker-> abentley, after that there is no bans
[17:05] <statik> abentley: thank you, we should see it work when the next PQM commit mail comes through
[17:06] <dato> statik: shouldn't it join the channel first?
[17:06] <dato> or will it auto-join by then?
[17:06] <statik> dato: it is supposed to auto-join when it has something to announce
[17:06] <dato> ok
[17:06] <abentley> statik: Okay, holler if it doesn't work.
[17:07]  * stammi just recently noticesd to be out of vcs for the next two weeks
[17:07] <statik> but, I don't really have a good way to see the response from the IRC server to the IRC-talking part of the bot, I'm just re-using radix's publish-bot
[17:07] <statik> abentley: thanks for the help
[17:17] <j^> hi, is it possible to import tags from svn?
[17:24] <jelmer> j^: yes, but only as branches not as bzr tags yet
[17:25] <jelmer> stammi: Looks like your subversion library wasn't built with http support
[17:26] <jelmer> jdong: still there?
[17:27] <jdong> jelmer: yeppers
[17:27] <jelmer> jdong: you can't make a checkout of a checkout in bzr
[17:27] <j^> jelmer, i was hoping for bzr tags, getting the revision numbers and creating the tags should not be to hard
[17:27] <jdong> jelmer: oh.
[17:27] <jelmer> (which if I understand correctly, is what you're trying to do)
[17:27] <jdong> jelmer: I didn't know that :) well that explains a lot
[17:27] <stammi> jelmer, have ubuntu 7.10 and installed bzr-svn
[17:28] <stammi> and its https not http
[17:28] <jelmer> stammi: the svn+https:// / svn+http:// syntax was broken in bzr-svn 0.4.1, which is what is in gutsy
[17:28] <stammi> jelmer, so i should just manually install bzr from the homepage?
[17:28] <j^> there is a newer version in guty-backports
[17:29] <stammi> ahh ok
[17:32] <stammi> thx jelmer
[17:44] <jelmer> j^: it's not trivial since tags may be in different locations across svn repositories
[17:46] <j^> true, is there a way to map svn revision to the one used in bzr, that way one could collect the revision numbers and run a script to apply the tags, right now i would have to look up the commit message, find the one in bzr and map the revision that way
[17:47] <jelmer> j^: just taking the revision in which the tag was created in svn won't help
[17:48] <jelmer> since that will be a revision that's not actually in your bzr branch
[17:48] <jelmer> you would have to take the revision from which the tag was created
[17:48] <jelmer> but that's not going to be correct in a lot of cases either, since the revision that created the tag could also have slightly modified it
[17:55] <j^> what could cause
[17:55] <j^> SubversionException: ("PROPFIND request failed on '/!svn/bc/12853/trunk/foobar'", 175007)
[17:57] <jelmer> does "svn log -r12853 <repos-url>" work?
[17:59] <j^> ------------------------------------------------------------------------
[17:59] <j^> is all i get
[18:03] <jelmer> j^: is this a public branch?
[18:04] <j^> at that revision there is nothing in svn log, its one before the trunk was moved from a branch
[18:04] <j^> https://svn.xiph.org/trunk/theora
[18:30] <jam> statik: you should have a new pqm email
[18:30] <jam> I just had a patch merged
[18:31] <statik> jam: cool, i hope we see an announcement in a couple of minutes
[18:40] <grutte_pier> Does anyone know what happened to the webserve plug-in?
[18:41] <james_w> grutte_pier: it's still going
[18:43] <grutte_pier> So which url should i branch from then? on the webpage there is a 'download' link and an 'URL to branch' link
[18:43] <grutte_pier> the former gets me an 500-error (Internal Error)
[18:43] <grutte_pier> the latter gets me the source-code of some webpage
[18:43] <james_w> https://code.launchpad.net/~bzr/bzr-webserve/webserve-dev
[18:45] <grutte_pier> thanks a lot! Is there a way that I could or should have found this link myself?
[18:46] <james_w> grutte_pier: I'm not sure, maybe we should contact the author to update his webpage.
[18:46] <james_w> Note that launchpad is just mirroring his branch, so I imagine that he has reorganised things at some point and not updated the webpage.
[18:51] <grutte_pier> sounds like something that could easily happen.....
[19:10] <blueyed> What's the reason that e.g. "bzr status" does not list the files relative to the current working directory, but to the branch root?
[19:11] <blueyed> It's not as easy to select filenames for further actions then, e.g. by doubleclicking them.
[19:12] <LeoNerd> Because there might be more files modified than just within cwd
[19:13] <LeoNerd> So how do you display those?
[19:14] <blueyed> LeoNerd: well, good point for commands on the branch, but with e.g. "bzr st ." there's a path given..
[19:14] <blueyed> otherwise they could get prepended with "../" anyway.
[19:15] <yacc> What's the recommened way to push a local bzr branch to a fresh (not yet existing) SVN url?
[19:15] <ubotu> New bug: #204370 in bzr "bzr bombs during push to svn" [Undecided,New] https://launchpad.net/bugs/204370
[19:15] <yacc> nice ubotu detected my bug report ;)
[19:25] <fbond> Hi, using bzr-svn I get "CHECKOUT of ...: authorization failed" when trying to push to the repository...
[19:25] <fbond> bzr-svn 0.4.7
[19:25] <fbond> bzr 1.2.0
[19:25] <fbond> What do I need to do?
[19:25] <fbond> svn has my credentials cached already.
[19:25] <fbond> I'm pushing over http
[19:25] <yacc> ahhh, the newest version of bzr-svn works for bzr 1.1 *weep*
[19:26] <fbond> yacc: but not for 1.2.0?
[19:34] <yacc> Well, the wiki page shows only versions for up to 1.1 ;(
[19:38] <yacc> Please anybody tell me that there is svn support for current bzr versions?
[20:02] <nekohayo> hm, is there people working primarily on bzr-gtk?
[20:03] <ubotu> New bug: #151825 in bzr-gtk "jumping progressbars" [Undecided,New] https://launchpad.net/bugs/151825
[20:06] <ubotu> New bug: #125144 in bzr-gtk "Crashes when directory contains broken symlink" [Undecided,Confirmed] https://launchpad.net/bugs/125144
[20:09] <jelmer> nekohayo: yeah
[20:11] <nekohayo> ok, so I assume my pile of bugs (a few of them with patches) were not seen
[20:11] <nekohayo> so I'm changing them all to be assigned to bzr-gtk
[20:24] <yacc> fbond: ok, the branch seems to be maintained :) => but the current head seems to work only with bzr >= 1.3 ;)
[20:32] <yacc> It still bombs :(
[20:40] <awmcclain> Is it possible to import a single file into my repo?
[20:41] <awmcclain> Or do I have to import the containing directory like SVN?
[20:54] <yacc> awmcclain: any repo is a directory so logically speaking your question does not make much sense ;)
[20:55] <awmcclain> yacc: s/repo/branch
[20:55] <awmcclain> :P
[20:55] <yacc> Yeah, still your question makes no sense ;)
[20:56] <awmcclain> Is it possible to commit a single file which does not live under an existing branch into a branch. I'm pretty sure the answer is no.
[20:57] <awmcclain> Hrm. Can you check out or branch a subset of a working tree?
[20:58] <dato> those are two different questions?
[20:58] <awmcclain> yes
[20:58] <dato> ok
[20:58] <dato> (b) you can't do partial checkouts
[20:58] <awmcclain> hrm
[20:58] <awmcclain> Okee doke.
[20:58] <dato> (a) I'm failing to see your question, how's what you ask different to `bzr add $FILE` ?
[20:59] <awmcclain> dato: Becauase I'm guess bzr add $FILE will only work if the containing directory is in a working tree
[20:59] <awmcclain> I'm trying to collect a bunch of conf files scattered about into source control
[21:00] <dato> well
[21:00] <dato> the file has to be underneath the branch, of course
[21:00] <awmcclain> I'll just put them in a directory and then move from there
[21:12] <yacc> bzr: ERROR: Revision {('andreas@andi-lap-20080318110425-b4uvstmj62j90z2s',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0xb6c6a30c>".
[21:12] <yacc> on upgrade --rich-root-pack
[21:12] <Peng> yacc: Known issue.
[21:13] <yacc> Yeah, but what do I do, considering that I should deliver my stuff today?
[21:13] <yacc> Trying to do a svn-push I'm getting an error too :(
[21:14] <Peng> yacc: I don't know of a solution.
[21:14] <yacc> Well, I can try to revert to bzr 1.1, and see if that helps, ...
[21:15] <Peng> I dunno.
[21:20] <kiko> abentley, ping?
[21:20] <abentley> kiko: pong
[21:20] <kiko> abentley, do you have any advice for yacc's problem above?
[21:22] <abentley> At this point, we don't have a fix for that.
[21:22] <kiko> abentley, what's the source of the problem?
[21:23] <yacc> abentley: basically bzr svn-push craps out with the "SubversionException: ('At least one property change failed; repository is unchanged', 175008)" problem ;(
[21:23]  * yacc had such high hopes to have escaped svk, ...
[21:24] <abentley> Wait, which is your bug?  SubversionException or Revision not present?
[21:25] <yacc> abentley: SubversionException. README in bzr-svn (I think, might been google) suggested that an upgrade --rich-root-pack might be useful, ...
[21:26] <abentley> Which version of bzr-svn have you been using?
[21:26] <yacc> head of stable with bzr 1.3
[21:26] <yacc> Now I'm downgrading to bzr 1.1rc1 in Debian, that include bzr-svn 0.4.7 I think.
[21:27] <yacc> Well, bzr1.1 gives me the "at least one property changed" traceback too :(
[21:28] <abentley> bzr plugins should tell you the version number
[21:28] <yacc> 0.4.7
[21:28] <yacc> and bzr 1.1
[21:28] <yacc> Same error as it was with bzr 1.3/stable-head
[21:29] <abentley> So "stable-head" doesn't help me understand what's going on.
[21:29] <abentley> There was a major change at 0.4, and if you're using something earlier, the scenario is completely different.
[21:29] <yacc> stable head == an hour old pull from the branchurl on the plugins wiki page.
[21:30] <yacc> No it's the newest one.
[21:31] <dato> yacc: trunk, or the bzr-0.4 branch?
[21:31] <yacc> http://people.samba.org/bzr/jelmer/bzr-svn/stable/
[21:32] <abentley> Okay, so if you do bzr info -v in your branch, what does it say about formats?
[21:32] <yacc> dato: no idea which branch is stored at that url.
[21:32] <yacc> you mean the one that I try to push to svn?
[21:32] <abentley> yacc: yes
[21:32] <yacc>        control: Meta directory format 1
[21:33] <yacc>   working tree: Working tree format 4
[21:33] <yacc>         branch: Branch format 6
[21:33] <yacc>     repository: Packs containing knits without subtree support
[21:33] <abentley> So is this a branch that you originated in Bazaar?
[21:33] <yacc> Yes, it orginated from a bzr init (with bzr 1.1rc1)
[21:34] <yacc> I wonder if it would help to push an empty bzr branch first to the SVN url, ...
[21:35] <yacc> any ideas how to get the stuff into svn?
[21:36] <abentley> Could you run this and tell me what the output is?
[21:36] <abentley> python -c 'from bzrlib.workingtree import WorkingTree; wt=WorkingTree.open("."); wt.lock_read(); print wt.inventory.root.file_id; wt.unlock()'
[21:36] <abentley> You need to run it in your working tree.
[21:37] <yacc> TREE_ROOT
[21:38] <abentley> Well, that's normal.  I don't know why upgrade would be a problem.
[21:39] <abentley> I don't think you'll be able to push into svn until you change your format.
[21:39] <yacc> Well, it complains that a version does not exist where it expects it. but technically speaking the upgrade is less of an issue for me, bzr-svn is :(
[21:39] <yacc> To which format?
[21:39] <abentley> I would recomment rich-root-pack.
[21:40] <yacc> Well, rich-root-pack and rich-root both complain about non-existing versions, and it seems to be a known bug :(
[21:41] <dato> abentley: fwiw pushing from !rich-root to svn works just fine. I use it in one of my projects.
[21:41] <abentley> dato: Ah, okay.  It's been a while since I used bzr-svn.
[21:41] <yacc> Any hints that I can try?
[21:42] <abentley> We probably need Jelmer to debug the SubversionException.
[21:43] <abentley> jelmer: ping
[21:43] <abentley> It sounds like the upgrade's not necessary, and we're planning to fix it for branches like yours.
[21:43] <yacc> Which timezone jelmer is in?
[21:44] <dato> CET
[21:44] <james_w> UTC+1 I think.
[21:44] <james_w> hi dato
[21:44] <abentley> yacc: One thing you could try is running "reconcile".
[21:45] <yacc> reconcile?
[21:45] <abentley> ie "bzr reconcile".
[21:45] <dato> hi james_w. I meant to ask you the other day, were you in dc7?
[21:45] <james_w> dato: nope.
[21:46] <yacc> abentley: what does reconcile do?
[21:46] <dato> ok. then no regrets I didn't meet you :-P
[21:46] <yacc> abentley: same SubversionError :(
[21:46] <james_w> dato: :-)
[21:46] <james_w> dato: are you going to dc8?
[21:46] <abentley> yacc: Running reconcile in your repository gives you a SubversionError?
[21:47] <yacc> no, but doing a svn+push after the reconcile.
[21:47] <yacc> the reconcile did fine.
[21:47] <abentley> bzr reconcile corrects some kinds of data inconsistency.
[21:47] <yacc> Whatever it did.
[21:47] <dato> james_w: it's going to be a bit complicated, but so has been the previous 3 times and I always managed. but maybe I'm overconfident this time. :-)
[21:47] <abentley> Does the upgrade work?
[21:47] <yacc> abentley: but the upgrade to rich root pack did work :)
[21:48] <yacc> The question is if that will help the svn+push or not.
[21:48] <yacc> Nope, same thing as before.
[21:49] <abentley> I don't know enough about bzr-svn to understand that error.
[21:50] <abentley> I'm glad the upgrade worked, but you may want to go back.
[21:51] <abentley> It depends on whether you're expecting to pull/merge from bzr-svn.
[21:52] <yacc> Well, for the moment I'm the only one that will be commiting around that svn path ;)
[21:52] <yacc> I might try it out if pushing to my private svn repo works.
[21:52] <abentley> Probably you should stick with it.
[21:53] <abentley> Existing projects shouldn't convert to rich-root-pack unless all their members are willing to upgrade.
[21:53] <abentley> But yours is a new project, so it doesn't matter.
[21:53] <yacc> abentley: basically, I'm having a high level of aversion against svn, svk and git-svn, that doesn't leave many options when you need to work with a svn repo ;(
[21:54] <yacc> abentley: mine is a project where nobody but me will see the bzr branch, because all other will be pulling it from svn.
[21:54] <abentley> What's the command you're running?  push or svn-push?
[21:54] <yacc> svn-push
[21:54] <yacc> push gives an IndexError.
[21:55] <yacc> Googling the error returns basically only the bzr-svn problems and one old svn error which was fixed back then by upgrading the svn client version, ...
[21:55] <abentley> yacc: Do the permissions on your SVN repo forbid changing revision properties?
[21:56] <yacc> abentley: as this is a public svn repo server, I have no idea.
[21:56] <yacc> abentley: but that's an interesting theory.
[21:56] <abentley> I know it's a configurable option.
[21:56] <yacc> abentley: It will most probably forbid changing revprop.
[21:56] <dato> both for SVN and bzr-svn
[21:57] <dato> i.e. bzr-svn does not do it by default
[21:57] <yacc> abentley: Actually it's a hook that decides which properties you are allowed to change.
[21:57] <yacc> dato: What?
[21:57] <dato> my understanding is that bzr-svn uses properties in a way that is allowed by default in SVN repositories
[21:58] <dato> and then it has a switch to override svn:date and svn:author, but I don't know if this was abentley meant or not
[21:58] <yacc> dato: which switches.
[21:59] <dato> or maybe your repo is forbiding even the kind of safe properties bzr-svn needs, though it sounds unlikely
[21:59] <yacc> svn:date won't be overrideable in that repo for sure.
[21:59] <dato> % grep override ~/.bazaar/bazaar.conf
[21:59] <dato> override-svn-revprops = True
[22:00] <yacc> dato: I have no bazaar.conf ;)
[22:00] <dato> k
[22:00] <abentley> yacc: You are allowed to create one :-)
[22:01] <yacc> abentley: yeah, but where do I learn about the options/sections (assuming that it's a ConfigParser thing)
[22:01] <abentley> It's ini format.  There are no mandatory sections.
[22:02] <abentley> bzr help configuration will tell you about Bazaar's options, but not bzr-svn's.
[22:02] <yacc> Yeah, but where does that override-svn--revprops belong to?
[22:02] <dato> I have in [DEFAULT]
[22:03] <abentley> But DEFAULT is optional.
[22:03] <yacc> Now, it would be highly interesting what the default for it is.
[22:03] <dato> aha
[22:03] <dato> I'm sure it defaults to False
[22:03] <abentley> You can just have a single-line file with "override-svn-revprops = True"
[22:05] <yacc> Well, technically it defaults to None, but yes that's false too *g*
[22:05] <yacc> Ok, the SubversionError is raised in something that looks like a decorator that catches SVN exceptions.
[22:07] <yacc> How does one set the debug.debug_flags in bzr?
[22:08] <abentley> With -Dfoo
[22:08] <abentley> where foo is the flag you want to set.
[22:10] <yacc> So let's see what bzr-svn is doing before it the bad thing happens :)
[22:10] <yacc> abentley: see you are bad. You made me start debugging myself,
[22:11] <yacc> ;)
[22:12] <abentley> You could also try doing import pdb; pdb.set_trace() in the final else clause of convert_error
[22:12] <yacc> Well, it's one of these then:
[22:12] <yacc> setting revision property 'bzr:file-ids' to '\tTREE_ROOT\n.bzrignore\tbzrignore-20080314001943-npoqulq31axmxa8g-1\nez_setup.py\tez_setup.py-20080314002020-4ktxnl1abormwysn-1\nsetup.py\tsetup.py-20080314002020-4ktxnl1abormwysn-2\nlookery\tlookery-20080314002159-q2mdytaryo7wbdcf-1\nlookery/__init__.py\t__init__.py-20080314002211-5qqxrkuk0wqqoyvi-1\nlookery/lib\tlib-20080314002211-5qqxrkuk0wqqoyvi-2\nlookery/lib/apachelog.py\tapachelog.py-200803140022
[22:12] <yacc> 11-5qqxrkuk0wqqoyvi-4\nlookery/lib/__init__.py\t__init__.py-20080314002211-5qqxrkuk0wqqoyvi-3\nlookery/scripts\tscripts-20080314011426-ok2xe2a2a4am6oot-1\nlookery/scripts/llfp.py\tllfp.py-20080314011426-ok2xe2a2a4am6oot-3\nlookery/scripts/__init__.py\t__init__.py-20080314011426-ok2xe2a2a4am6oot-2\n'
[22:12] <yacc> setting revision property 'bzr:revision-info' to 'timestamp: 2008-03-14 02:15:10.638999939 +0100\ncommitter: Andreas Kostyrka <andreas@andi-lap>\nproperties: \n\tbranch-nick: lookery\n'
[22:13] <yacc> setting revision property 'bzr:revision-id:v3-single-trunk/logs/Lookery-Base' to '1 andreas@andi-lap-20080314011510-z091afzyx1t7i3gq\n'
[22:13] <yacc> abentley: I'm not big on pdb style debugging. Lucky for me bzr-svn is not in an egg, so adding prints is not exactly hard.
[22:17] <abentley> Acutally, it would be better if convert_error just did "raise" when it couldn't convert.
[22:18] <abentley> That would give a more useful traceback.
[22:18] <rindolf> Hi all.
[22:19] <rindolf> I'm trying to do {{{ bzr export http://www.gnome.org/~jdub/bzr/planet/2.0/ }}} but it tells me "not a branch".
[22:19] <rindolf> What's the equivalent of svn export URL in bzr?
[22:20] <abentley> rindolf: I don't know svn.  In bazaar, it creates a copy of the working tree files, optionally gzipped, tarred, zipped, etc.
[22:20] <dato> abentley: but does it work over remote?
[22:21] <dato> oh, you'd need to give it a second arg
[22:21] <rindolf> dato: thanks.
[22:21] <james_w> rindolf: bzr export target http://www.gnome.org/~jdub/bzr/planet/2.0/
[22:21] <dato> rindolf: personally I'd recommend you just clone instead of export, for easy updating
[22:21] <rindolf> james_w: thanks.
[22:21] <dato> rindolf: but your choice :)
[22:21] <rindolf> OK, it's making slow progress.
[22:22] <rindolf> dato: problem is that at the moment, my Internet connectivity sucks.
[22:22] <yacc> Now I wonder if there is a doc on the SVN API somewhere ;)
[22:22] <rindolf> blame my ISP.
[22:22] <james_w> yacc: I have found API docs
[22:23] <abentley> rindolf: Also, it's in an older, less-efficient format.
[22:23] <james_w> I found them to be under-documented, but at least better than un-documented
[22:23] <yacc> james_w: me too ;)
[22:23] <rindolf> abentley: what is?
[22:24] <abentley> http://www.gnome.org/~jdub/bzr/planet/2.0/ is in a slower format.
[22:24] <yacc> That's cool, http://svn.collab.net/svn-doxygen/search.php?query=change_dir_prop gives me the HTML source including PHP ;)
[22:25] <yacc> Well, at least there is google ;)
[22:26] <abentley> http://svn.collab.net/svn-doxygen/structsvn__delta__editor__t.html#o11
[22:27] <awmcclain> Is 1.2 in gutsy yet?
[22:29] <abentley> awmcclain: No idea, but packages.ubuntu.com should know.  Or you can use our gutsy APT repository.
[22:29] <awmcclain> abentley: Yeah, it's only at 0.9. Thanks!
[22:31] <abentley> awmcclain: If you mean *our* repository is at 0.9, that is unlikely.  0.9 was released in 2006
[22:32] <awmcclain> No no gutsy. I'm using 1.2 from your repository now.
[22:33] <abentley> Gutsy includes 0.90, not 0.9
[22:33] <abentley> gutsy-backports has 1.0
[22:36] <jdong> I will update backports to bzr 1.3 if Hardy is going to get it plus bzr-svn and friends.
[22:37]  * abentley is completely disconnected from the Ubuntu release cycle.
[22:38] <jdong> who typically takes care of Ubuntu packaging for bzr?
[22:39] <dato> jdong: package just migrates from debian
[22:39] <dato> (fwiw I'll upload 1.3 to debian tomorrow; rc1 is in atm)
[22:40] <james_w> jdong: I can't remember who did the last sync, someone just pinged me on IRC one day to confirm that they had all the necessary bits together.
[22:40] <james_w> I wasn't going to FFe for 1.3 in Hardy. I've just submitted a patch to get bzr-svn to stop complaining about version mismatch.
[22:40] <jdong> james_w / dato: Ok, I'll take some time later tonight to look into this; I'd like to ensure we freeze Hardy with the latest bzr release in there.
[22:40] <dato> james_w: are the syncs manual at this point?
[22:41] <jdong> dato: have been for a long time
[22:41] <james_w> dato: yes, and they have been for a while.
[22:41] <james_w> dato: thanks to your work it's just a quick test and a manual sync though.
[22:41] <jdong> james_w: unless bzr devs have any objection/hesitation, I'd have no problem FFe'ing bzr. I don't think any of the folks will complain
[22:42] <jdong> everyone in Ubuntu-land loves bzr anyway :)
[22:42] <james_w> *almost* everyone :-)
[22:42] <dato> *g*
[22:43] <james_w> jdong: I don't think anyone will mind. I was just wary as it will be post-beta.
[22:43] <james_w> jdong: but I haven't got a feel for the Ubuntu release cycle yet, so that may be quite common.
[22:43] <jdong> james_w: normally I would be too, but you guys have such a solid track record
[22:44] <james_w> jdong: that's true. And there will probably be a boat load of fixes in there.
[22:44] <jdong> james_w: indeed
[22:44] <james_w> well the 1.3 NEWS is a little smaller than usual due to all the sprints/conferences etc. this month.
[22:44] <jdong> james_w: I'd rather not have a LTS kick off with outdated bzr :)
[22:45] <james_w> jdong: yeah, let's go for it. Anything you would like me to do?
[22:45] <jdong> well I think I'll have time later tonight to research the bits; just poke me when the Debian package is uploaded :)
[22:46] <james_w> jdong: sure. Though I will be online for limited periods this weekend.
[22:46] <jdong> ok
[22:46] <james_w> dato: would you mind poking jdong when you upload 1.3?
[22:46] <dato> sure
[22:46] <james_w> The only other thing I haven't seen an upload for is bzr-gtk, is there a new release available?
[22:46] <james_w> dato: great, thanks.
[22:47] <james_w> jdong: you'll need bzr-svn as well I think, and I'd like it if you took bzr-builddeb as well.
[22:47] <dato> and bzrtools
[22:47] <james_w> oh, of course.