[01:41] Hello again. Here's an interesting issue - if I have svn cache.tdb files in my .cache/bazaar/svn directory I can't use bzr-git. [01:42] The quick fix is to just blow away the .cache/bazaar/svn directory, but I'm still trying to work out why bzr-git was the thing affected (since bzr-svn and normal svn work fine) [01:42] thats odd :) [01:44] I'm wondering if it's some sort of auto-probe like the transports do. My work has a weird certificate config that means I can only use svn+https because https straight will explode. [01:44] "Initialising Subversion metadata cache in /home/dcoles/.cache/bazaar/svn/a64d3506-044a-4e67-9bab-d6d69bd6860d." [01:44] Hm. It's a git checkout... [01:45] Though ffmpeg was being dual-hosted with svn. [01:51] heh [02:05] dcoles: I suppose as a workaround you could set BZR_DISABLE_PLUGINS=svn when working with that location [02:07] spiv: Well the weird thing is that if I do a new checkout of the ffmpeg trunk with git then it works [02:07] Looks like for some reason it the first repo was missing .git/branches and thus caused bzr-git to assume it was not a repository [02:09] (Which then caused a whole bunch of other behavior in bzr-svn like trying to look at all the svn repos it had cached) === med_out is now known as med === med is now known as medberru === medberru is now known as medberry [08:33] * jelmer waves [09:04] morning jelmer, you're up early :) === hunger_ is now known as hunger === kgoetz is now known as Kamping_Kaiser [10:47] hi jam, jelmer, vila [10:48] * jelmer waves [10:48] hi poolie [10:50] hi jelmer [10:50] i'm out in the atrium space [11:06] hi all [11:07] Is there somethong to configure in qbzr so that the user defined bugtrackers are displayed in qlog tree tags ? [11:13] rom1: unfortunatelly, no [11:14] rom1: there is a currently a hard-coded list of URL pattenrs in the source [11:14] http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/view/head:/lib/bugs.py [11:22] luks: huh [11:22] luks: seems like that should be using bzrlib.bugtracker.tracker_registry somehow [11:23] luks: (maybe some helper APIs need to be added to bzrlib?) [11:30] spiv: that doesn't really work [11:30] spiv: because bzr stores only the full URL [11:30] spiv: but not a way to get the ID from it [11:30] can bzr be made to print out the current revno before updating if i involve 'bzr pull'? [11:31] luks: right, so we probably should extend the APIs there to allow that. [11:31] luks: it would be useful for more than just qbzr :) [11:31] spiv: well, it's not possible without changing the format [11:32] spiv: because bug tracker configuration is stored in the user's configuration file [11:32] so I get an arbitrary URL, I don't know what the user that committed it had configured as a bug tracker [11:33] this would be a nice use case for versioned properties, IMO [11:34] luks: sure, but you can use the current user's config as a likely reasonable approximation [11:34] (I agree we could store more structured data in the properties) [11:34] o/ spiv [11:35] thanks for all the reviews [11:35] Hi mbp, just having a quick bike shed before dinner :) [11:46] heh [11:46] i bet people can really bikeshed on your dinner too [11:46] hm === mbp_ is now known as poolie [11:46] that's better [11:47] that's good news fram maritza === mrevell is now known as mrevell-lunch === nlisgo_ is now known as nlisgo === mrevell-lunch is now known as mrevlel === mrevlel is now known as mrevell [13:06] Thx luks [14:06] jam, vila, hi? [14:06] hi poolie [14:06] can you join #ubuntu-uds-arany [14:06] we're just going to talk about bfbip === Kraln- is now known as Kraln === cdbs is now known as cdbs-isnt-good === cdbs-isnt-good is now known as cdbs [15:50] why does bzr diff tries to go to launchpad to search for differences? I would like to do a local diff only [15:58] santagada: if you are using a lightweight checkout, the data isn't stored locally to diff against [15:58] if you're not, then I don't see why it would be connecting to launchpad [15:58] jam: stacked means lightweight? [15:58] santagada: no [15:59] then no [15:59] but stacked may-or-may-not have the data locally [15:59] I have huge checkouts [15:59] since stacked inherently stores some comment remotely [15:59] content [15:59] at least the latest version should be here [15:59] I'm doing a simple bzr diff [16:00] without any parameters, so I can't think of any for that it would have to look on the internet to do it [16:00] s/for/form [16:00] because it should at least have the revision I'm on [16:02] Not if you are using a lightweight checkout [16:03] why would I want such a lightweight checkout? I'm going to find the command I did to checkout stuff, but I remember it was huge and slow [16:03] Run 'bzr info' and tell us the first line [16:04] bzr info is kinda slow also [16:04] Actually, pastebin all of 'bzr info's output [16:04] https://gist.github.com/6440ba487ad80f038ece [16:04] Oh, OK, your local branch is stacked on the remote launchpad branch [16:05] i.e. bzr is configured to not store locally any revisions which are present in the remote branch [16:05] maxb: he's using "bzr branch --stacked" which may or may not have local content. I'm guessing at the least, we are always opening the stacked-on location just as part of opening the branch. [16:05] Seems likely [16:05] by default we *don't* have the tip revision at the time of branching, because that is in the stacked location (and by default we have nothing in a stacked branch that is in the stacked-on location) [16:05] after a commit, we *should* have some of the data locally [16:05] (the newly committed stuff) [16:06] "bzr branch --stacked" was what I used [16:06] but I'm guessing we would still connect to the stacked-on location (because Branch.open() opens fallbacks) [16:07] there is no point of downloading the whole repo at x revision and not keep at least the tip [16:07] so I downloaded tons of megabytes from launchpad, suffered thru it and I don't have the tip to do a diff :) [16:08] I'm not mad, but it doesn't make much sense to me [16:09] is there a way to get at least the tip? [16:13] santagada: its something we want to support (bzr branch --shallow), but it isn't in the immediate plans. It is something that is rated moderately high for stuff like UDD development [16:13] so I would guess it would be implemented in the next few months. [16:13] it isn't trivial to create in the current model, since as I said, we default to not storing data that is already present [16:14] mostly because '--stacked' was an answer for pushing stuff up to Launchpad, where you *don't* upload a whole set of contents. [16:18] hey jam, thanks for joining in [16:33] jam: so I should just download the whole repo === medberry is now known as med_out === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck === Ursinha-afk is now known as Ursinha === tomaw_ is now known as tomaw === awilkins_ is now known as awilkins === cinerama_ is now known as cinerama === mnepton is now known as mneptok