[00:21] jelmer: Are the "bzr:file-ids" and "bzr:text-revisions" old meta-data properties? [00:21] enigma42, the file properties you mean? [00:21] Yeah. They are file properties of the svn directory that contains the project. [00:22] enigma42, they are used by both bzr-svn 0.4 and 0.5 if you are not using svn 1.5 on the client and server [00:22] I tracked down that "missing" ID that I pasted earlier. [00:22] That ID that is being reported as "missing" is set in bzr:text-parents for the project I'm working with. [00:23] ack. [00:23] I mean "bzr:text-revisions" [00:23] NOT "bzr:text-parents" [00:25] jelmer: Sorry. Pidgin melted down and I lost my connection. [00:26] jelmer: Anyway...I found that problem id in "bzr:text-revisions" file property. [00:26] I'm wondering what would happen if I deleted the file property and committed that back in. [00:28] enigma42, it may help, but not guarantees bzr-svn won't look at the file properties in older revisions [00:28] s/not/no [00:29] OK. So, at best, the change would only work from the current revision onward. [01:06] spm: can you add markh as a committer to the bzr pqm please [01:06] lifeless: sure [01:07] thanks [01:14] lifeless: is done [01:14] markh: ^ [01:14] markh: there is setup info in the dev guide [01:15] lifeless, spm: excellent, thanks. [01:15] markh: it's against your @skippinet address fwiw [01:16] excellent, thanks. Will it see that address in a "reply-to"? [01:16] (I subscribe to the mailing list via a gmail acct) [01:16] markh: the mailing list is unrelated [01:17] oh - I thought maybe to pick up votes... [01:17] markh: this is for sending commits to the trunk, not for voting [01:17] ok, gotchya - thx [01:17] I'll read that guide as soon as I finish this little distraction I'm working on... [01:32] where does bzr save the backups after a "bzr revert" ? [01:32] rocky: in tree, as .~1~ files [01:33] then .~2~ if there is a .~1~ etc. [01:34] thx [01:35] hello all... [01:36] Is there a way to authenticate with bzr-svn? When I do a checkout from the svn repository normally, it asks me for my password. But trying to branch it with bzr just gives me Errno 111 Connection Refused. [01:39] lifeless: you referring to the "Core Developer Tasks" section in that guide? [01:39] mrooney: connection refused doesn't sound like a failed authentication [01:39] Ahh, and if I try http:// instead of svn:// I get "Unable to handle http code 401: Authorization Required" [01:39] mwhudson: okay well what about that? :) [01:40] that sounds more likely, yes :) [01:41] mrooney, try svn+http:// [01:42] ah hi jelmer [01:42] :) [01:42] * mwhudson stops trying to google this [01:42] hey Michael :-) [01:45] jelmer: thanks, that seems to be doing something! Although it says the svn+ syntax is deprecated. [01:51] mrooney, that's correct, it will go away at some point in the future [01:52] mrooney, without "svn+" doesn't work atm because of a bug in bzr [01:52] jelmer: oh, so which (svn:// or http://) will work when it becomes removed? [01:52] mrooney, svn:// and http:// are different beasts [01:53] mrooney, svn:// is for use with the svnserve daemon on the server side [01:53] mrooney, http:// is for an http server on the server side [01:53] mrooney, svn+http:// will disappear and be replaced by a properly working http:// [01:54] jelmer: okay, I have branched it which was super slick. Now I have committed and want to push, but I am not sure how to tell it my username (it isn't my unix username) [01:54] mrooney, it should prompt you [01:55] jelmer: it prompts for the password for my unix username [01:55] but that doesn't work since my unix username isn't a user on the repo, alas [01:55] mrooney, you should be able to use http://username@host/../ in the URL [01:55] oh yes that seems wise :) [01:56] * mrooney hugs jelmer [01:56] thanks! [01:56] np [01:56] this is way more transparent than I expected, good job everyone who worked on bzr-svn! === Mario__ is now known as pygi === mr-rus1 is now known as mr-russ === Mario__ is now known as pygi [05:15] ok, thats a day for me [05:15] ciao [05:30] hello [05:49] Hello, this is more of a general VCS question: what is the usual way to include code from other projects in your project? Would you just put it in a subdirectory and ignore it with .bzrignore? Also, what if it uses its own version control system? [05:50] mi3: Generally, people do _not_ include code from other projects. [05:52] You could put it in a subdir and ignore it; as far as I'm aware, there are plans for bzr to support the 'checkout of other bzr repository in this directory' concept, too. [05:53] RAOF: So if I was borrowing code from an LGPL project and including it in my GPL project, I would generally exclude any code from the other project in version-tracking for my own. That makes sense now that I think about it [05:57] What LGPL project? It's generally frowned upon to actually include the source of another project in your own (if you could possibly link to it). [05:57] If a branch gets copied (cp -r) to another spot and separate changes are made to both and committed, is there anyway to merge them back together? [05:58] Each thinks there are no new revisions to merge. [05:59] RAOF: the situation is that I am including some LGPL code I wrote in one project, in another project (which will be GPL). It is all written in PHP, and will essentially rely on 'include' statements for the linking. When distributing it I want to distribute the whole thing, rather than have users have to download two parts from different locations. If you can suggest improvements to how I'm doing it I'd be interested to hear [06:01] billam: works here; I copied a branch to foo-1 and foo-2, added different things to each, committed to each, then merged foo-1 into foo-2 [06:03] mi3: I guess it depends on what the older project was. If it's some form of library which is useful outside the new project, it might deserve to be shipped seperately. If no one else is interested in the old project, you can do what you want ;) [06:03] billam: How exactly were you trying to merge them? [06:12] RAOF: The shared part is a library that may be useful for my own future projects. Thinking out loud here... I guess it is similar to how several Mozilla projects include gecko code, or thousands of projects include GTK+ code. hmm [06:13] Please don't model on the gecko code; that's horrible to embed :) [06:14] You are of course free to do what you want. Just bear in mind that if you've got a bunch of shared code across projects it makes most sense to factor it out as a library, and ship it separately. [06:15] hehe, well the analogy really doesn't go too far. If the gecko code is a car, then my library would be a single hub cap [06:15] Thanks for your help [06:15] Once it's in a distro the package manager takes care of the dependencies. And many distros will frown on code duplication, and packagers will curse your name :). [06:18] ah yep I see. I guess if it were ever to be packaged for a distro then it could be configured to all point to a separate central library. I think my concern was how I was going to manage the source code, and I think I have my answer - that the app is project A, the library it's using is project B, and the two shall not be combined into a branch [06:20] so that the same bit of source code is not version tracked in two different projects [06:21] That will probably make things easier, yeah. [06:21] and I would have the option of distributing it separately too [06:21] thx [06:36] RAOF, thank you for checking for me. I was using an improper path, works fine with the correct path. [06:56] hi all === k4v is now known as m4v [09:55] night [10:00] night igc [10:14] morning === asabil_ is now known as asabil [12:01] jelmer: is there a init.d variant for loggerhead serve-branches? [13:00] does bazaar have any per repository configuration [13:01] Jc2k: only locations.conf [13:01] so not really [13:01] james_w: oh, fail [13:04] james_w: and locations.conf can't really be shared between users? [13:04] no, it can't [13:04] bugger :) [13:04] there's nothing that is sticky to the branch or to the repository [13:05] Sure it can! You just make it a FIFO with a perl script on the other end, see... [13:05] well, there is .bzr/branch/branch.conf [13:05] but that won't be copied verbatim [13:06] so i'd like to have some things configured per repository, mostly hooks [13:06] any branches in foo repository should email-on-commit [13:06] but not in the bar repository [13:06] and the email address might be different per repository, too [13:07] locations.conf *could* work, but there are multiple users [13:07] Jc2k: not sure if this is what you want, but what about lp:bzr-hookless-email? [13:08] email was just an example, i'd want to hack bzr-cia to be set-up-able per repo too [13:08] and likely other random things [13:09] in pre-change-branch-tip, i could take params.branch.repository.base and look for my own file, but that feels like complete gash [13:10] (more post than pre, FWIW) [13:21] folks, I have a repository bla/ with branches in it like bla/1.0.0, bla/1.0.1 etc. Now we are releasing new major release (2.0). Is it OK if I create a directory inside bla/ and move the branches from the 1.0 series to it? [13:22] loxs, this is a shared repo you have in bla/ then? if it is, then yes [13:22] Hello! Please, can somebody put bzrtools 1.11 to bzr-beta-ppa? [13:22] beuno, yes, it's a shared repo [13:23] beuno, so nothing will go wrong if I move the branches in such a way? [13:23] loxs, not at all [13:23] bzr will find the revisions [13:23] thanks [13:24] just don't move the branches outside of their repository [13:30] Hi guys. :-) [13:37] I am new to bzr, and just wondering why bzr push --create-prefix bzr+ssh://alex@slice.gaww.net/home/alex/bzr/misc just publishes an empty directory [13:37] from the same directory bzr log & bzr ls indicate both revisions and files [13:38] fatcnt, is it empty, or does it have a .bzr file? [13:38] drwxr-xr-x 8 alex staff 272 Jan 14 00:23 .bzr [13:38] bzr doesn't create working trees remotely [13:38] so all your data is in the .bzr dir [13:38] :/ [13:39] the howto indicates this is possible [13:39] you can 2 plugins to create the working tree remotely: push-and-update, or, if you don't need bzr's metadata remotely (ie, a website) bzr-upload [13:39] $ bzr push --create-prefix sftp://your.name@example.com/~/public_html/myproject [13:39] 2 revision(s) pushed. [13:39] ah, okay. I need plugins. cool. [13:40] Or, I could just rsync it all up. That might be more effeicent too, right? [13:42] How does bzr handle symlinks? [13:42] fatcnt, well, bzr isn't very rsync-friendly, but you can do that too [13:44] ait [13:44] I just need to bzr update? === Mario__ is now known as pygi [15:16] is it bzr that's creating these foo.ext.~1~ files? [15:23] phinze, yes, when you "bzr revert" a file [15:23] phinze, the --no-backup option will prevent it from doing that [15:24] jelmer: gotchya, thanks [15:32] Hi all.. quick question (I hope). Is it possible (directly or via some plugin) to perform content replacement in checked-out files a la RCS "$Id$"? Thanks! [15:36] hi kinkie [15:36] kinkie, there's some work happening at the moment to support that, not sure how much of it will end up in 1.11 [15:36] igc, ^ === sabdfl1 is now known as sabdfl [15:37] jelmer: I'm not in a hurry. I'm just happy it's in the roadmap. Useful to put a snapshot date in the debugging output to a developing project. [15:37] Thanks === eaumontab is now known as abeaumont [16:19] jam, hi! from what I've been reading, revnos are always calculated, and never stored. Is that interepretation correct? [16:20] beuno: ATM, yes [16:20] jam, aha! So finally I understand why it's so expensive :) [16:20] thanks for the confirmation [16:21] They technically vary based on the branch tip [16:21] though with some stability guarantees based on how the ancestry actually would change [16:21] we do save the last_revno, right? [16:21] and go from there down? [16:21] Right [16:21] yep [16:22] (Though I consider time to flow downward :) [16:22] most of the time, at least [16:22] intersting, a lot of emails now make *so* much more sense [16:23] jam: time flowing downward? such the pessimist! [16:23] in muy head, tip == top [16:23] beuno: I *always* do 'bzr log --forward' [16:24] Considering my "bzr commit" [16:24] so it *has* to flow downward [16:24] and my shell time goes downward [16:24] the command I wrote earlier is above the current one [16:24] I think "bzr log"'s default mode is an ugly hack because we don't know how many revisions the person wants [16:24] but we know they generally want the newest ones [16:24] (and it is consistent with all other programs that do that sort of thing) [16:24] but --forward is much more "logical" IMO [16:25] I realize that HTML pages (blog posting) etc work differently [16:25] as you expect old things to get pushed off the bottom of the page, to keep new stuff showing up first [16:25] right, now we write it literally as a "log" [16:25] Certainly if you read a book, though [16:25] time goes "down" [16:26] Rarely does the next paragraph come before the previous [16:26] although listings ordered by date can be expected in either order, depending on the relevance of the "newer" data [16:27] if the terminal didn't scroll, then the current way is fine [16:27] beuno: and whether the arrow points up or down, right? [16:27] right [16:27] I think I'd still have a hard time for a while re-mapping the time flow in my head [16:27] beuno: well people expect to do "$VCS log | less" [16:27] but it's worth experimenting the change with an alias [16:28] beuno: I would recommend "bzr alias log='log --short --forward -r-10..-1'" [16:28] It is what I use everywhere [16:28] I can always do "bzr log -r XXX" if I need more, or do "bzr log --no-aliases" [16:28] jam, will try it out for a week and see how my happiness levels differ [16:28] but it gives me about 1 screenful of information [16:28] without scrolling [16:28] and giving the summary of what has been happening [16:29] aaah, I forget how fast --short is... [16:30] * awilkins just uses bzr qlog [16:30] But I'm evil [16:30] beuno: and "bzr log --short -r -10..-1" is multitudes faster than 'bzr log' [16:31] as in 4s versus 0.4s for bzr.dev on my machine [16:31] jam, incredibly so. I never realized the big difference [16:31] beuno: well, I've personally made sure that bzr log --short -r -10..-1 is fast [16:31] as a) I use it all the time [16:31] and b) it is *possible* for it to be fast [16:31] as it doesn't depend on big history data [16:31] right, no dotted revnos [16:32] yep, and we can find -10 by just walking back 10 revs from the tip [16:33] I don't know about other people, but I generally have a "My mind is thinking and hands are idle, so I'll type something" commands [16:33] It used to be 'ls' [16:33] it is now either "bzr st" or "bzr log" [16:34] right, if bzr log is that cheap, it's absolutely more informative than ls [16:34] it's amazing how a second or two changes your behaviour completely [16:34] yep [16:34] It goes into the "without thinking about it" timespace [16:34] versus "waiting for it, and switching context" [16:35] For TDD they give the threshold as about 10s [16:35] that >10s you will go look at something else [16:35] which will destroy your TDD cycling [16:47] Does anyone know if there is a way to have dpush create a new branch? [16:47] If not, how do I get a branch started so I can "dpush" the rest? === Spaz is now known as Kittens [17:14] james_w, ping [17:15] jelmer: Is there a way to get "dpush" to create a new branch? [17:15] I think it should already be able to create new branches [17:16] I get "not a branch" errors. [17:22] hey jelmer === beaumonta is now known as abeaumont [17:46] Hi all === asac_ is now known as asac [17:47] I'm trying out bzr and bzr-svn from Debian experimental (as opposed to the versions from unstable), and I'm having a few questions. [17:47] enigma42, Please file a bug [17:47] Lo-lan-do, hi [17:48] First, when I run bzr ls svn+https://svn.gforge.org/svn/gforge/trunk, I get a warning that I should use https://.../trunk instead. [17:48] Lo-lan-do, I was about to go to dinner, but please ask anyway, I'll be back in ~30 min [17:48] ...but when I do that, I get error: (51, "SSL: certificate subject name (gforge.com) does not match target host name 'svn.gforge.org'") [17:48] Hi jelmer [17:49] I'll probably pester you later on, I'll go to dinner soonish too :-) [18:05] jelmer: I filed a bug and included steps to reproduce it: https://bugs.staging.launchpad.net/bzr-svn/+bug/316205 [18:05] Ubuntu bug 316205 in debian-installer "Regression: USB/Wireless keyboards not working on Jaunty alternate daily CD - from Alpha 2" [Undecided,New] [18:05] jelmer: Thanks again for all your help. :-D [18:06] Hm...it looks like ubottu grabbed the wrong bug. ;-) [18:09] Lo-lan-do, that's correct, it's a known bug in bzr [18:18] http://launchpad.net/bzr-xmloutput/trunk/0.8.2/+download/bzr-xmloutput-setup-0.8.2.exe does not seem to give me a usable windows executable, does this work for anyone or is my firewall bungling something up -- the file I get is 24.5k [18:20] error I get \\mypath\bzr-xmloutput-setup-0.8.2.exe is not a valid Win32 application. [18:29] enigma42, thanks [18:30] bitner: is there a particular reason you need the 0.8.2 vers... oh, xmloutput. duh. [18:30] Hmmm. [18:31] unfortunately, I don't have a windows box handy to test that on. [18:41] bitner: I get a 116K file with wget [18:41] hrmmmmmm [18:41] @#$ firewall [18:41] jelmer: Any known workaround, or shall I stay with svn+https:// instead? [18:43] jelmer: Also, a simple bzr update just took 28 minutes, mostly spent in "determining changes". [18:45] I'm running it again, in case it was due to some cache being refreshed for the 0.5 version, but it seems to be not much faster. [18:48] in bzrlib/status.py:_raise_if_nonexistent(), I'm trying to figure out why old_tree and new_tree params have those names instead of, say, inventory and working_tree. [18:48] Is there any reason why the more general names are significant? [18:58] you can take the status between any two trees [18:58] is that function only for working trees and their basis? [19:15] enigma42: it looks like you filed your bug in staging? That won't stick at all, will it? === mtaylor_ is now known as mtaylor [19:39] folks [19:39] did status just get substantially faster on large trees? [19:39] in brisbane-core? [19:40] like, MUCH faster? 20%? [19:40] or is this an artifact of something else in my tests? [19:43] sabdfl: in brisbane-core what revisions are you comparing against? I don't know of any specific work on status, though if your -core was a bit old I've been merging in bzr.dev periodically. [19:43] My first guess would be that you compiled the bzr.dev extensions [19:43] which would have an impact [19:44] no, my test script always does that [19:44] Hm. 33 minutes to commit a single-line patch. Not everything goes faster as time passes :-) [19:45] jelmer: Will you be at FOSDEM? [19:47] jelmer: If so, maybe I could entertain you for a couple of beers, and you could maybe diagnose what I keep doing wrong... [19:55] Lo-lan-do: are you sure all extensions are compiled? Certainly 33min is rather excessive [19:56] jam: This is on a branch bound to an SVN repo. Most of the time is spent in the network. *Lots* of https connections. [20:00] Lo-lan-do: jelmer will be at fosdem [20:02] Lo-lan-do, yep, I'll be at FOSDEM [20:02] * LarstiQ has a hotel booking, but still has to see if he can stand upright [20:03] LarstiQ, flu? [20:03] jelmer: yeah [20:04] jelmer: I'm back at work, but not being able to understand people is a hint I'm not entirely fit yet. Also, the coughing and snot. [20:04] ah :-/ [20:09] jelmer: Expect to be cajoled :-) [20:09] jelmer: hi [20:10] jelmer: what's the current usability status of svn-server? [20:10] s/server/serve/ [20:10] Lo-lan-do, :-) [20:10] thumper, pretty much the same as last time you asked :-) [20:10] :) [20:11] what is the name of that web-based bzr browser that is build with Paste. I think the name has something to do with turtle.. [20:11] thumper, in other words, a proof-of-concept basically. It doesn't support incremental updates yet, nor commits [20:11] ok [20:11] eleftherios: loggerhead [20:12] thumper, most of the underlying logic is there already (required for the rest of bzr-svn), but the protocol code isn't there [20:12] thumper: ah thanks! [20:12] jelmer: is the protocol complicated? [20:12] thumper, no, it's not too bad [20:13] morning [20:22] moin mwhudson [20:29] vila: hello! thanks for your explanation on issue 3232; I'm not getting a word of it, but I'm re-trying :-) === spm_ is now known as spm [20:30] guilhembi: rats, want some private chat for better explanations ? [20:30] vila: good idea [20:30] here we go [20:36] jelmer: If you have a couple of minutes, could you have a look at http://pastebin.com/f5245a8a8 ? [20:36] jelmer: do you have any plans for fosdem btw? [20:37] It's the log from the two "bzr update", two "bzr status" and one "bzr commit" [20:37] jelmer: in case we might want to do something bzry, before I start volunteering for the Debian video team. [20:37] The timing information depresses me :-( [20:39] Lo-lan-do, whoa, that's really slow [20:39] Lo-lan-do, you may want to use -Dtransport also [20:39] (that will print the SVN remote operations) [20:39] LarstiQ, not particularly yet - meeting up with Lo-lan-do and Jc2k [20:40] LarstiQ, perhaps it's a good idea to have a meetup of all people interested in bzr [20:40] jelmer: count me in [20:40] jelmer: just a meetup, or maybe some sprinting as well? [20:41] LarstiQ, some sprinting would be nice as well, but it depends a bit on whether we can find space, etc [20:41] jelmer: Temporary output is at http://pastebin.com/f7dde941f [20:42] Lo-lan-do, thanks [20:43] * Jc2k would be interested in FOSDEM/bzr action === beaumonta is now known as abeaumont [20:44] (alas my sprinting usefulness is limited to bzr-git and a few small plugins) [20:45] jelmer: we can ask the organizers :) [20:45] Jc2k: that's fine [20:57] * Jc2k crosses his fingers and chants at bzr-git [20:58] Jc2k: Would that be two-way? [20:58] Lo-lan-do: hmm? [20:59] Sorry, I thought you were implying you were working on bzr-git, and I wondered whether it's two-way (or planned to be). [20:59] I think it would be very interesting to have a talk about the inner working of bzr during the FOSDEM [21:00] and maybe explain the design decision/difference between bzr and git [21:00] asabil: As a user, I would love such a talk, yes. [21:01] :) [21:01] I think bzr weakest point is its marketing [21:01] Lo-lan-do: i am, but not on that bit. its planned to be, but its just git -> bzr atm [21:01] Lo-lan-do: (i'm writing a git server, so git users can clone and push to bazaar hosted repos) [21:01] asabil: I think we're too late for a talk, but we can certainly discuss it [21:02] jam, so, continuing our previous conversation, it should be easy-ish to cache the revnos in bzr itself, and invalidate (or update) the cache if the tip changes, right? [21:02] makes me wonder if I should spend my time doing that instead of all the madness I have planned for Loggerhead to tip-toe around the slowness to get revnos [21:03] beuno: well my point is that its a bzrlib core issue [21:03] beuno: effort put into fixing it should be put into the core :) [21:03] lifeless, right. I'm warming up to that idea. [21:04] it scares me ten times as much, because of all the touches, but I guess it's part of learning [21:04] e.g. consider a plugin that maintains the cache per-branhc (like bzr-search does) [21:04] right, that sounds like a nice start [21:04] polish on top of the plugin until it's in a mergable state [21:04] I may just do that [21:05] I ahve to research a little to make sure it's the only thing I need to drop getting the full revision graph [21:05] s/ahve/have [21:05] beuno: you'll need the merge depth [21:05] I believe [21:06] right, to get the changed-files-per-mainline-commit [21:06] Is this worth reporting / anyone know what's going on? http://paste.pocoo.org/show/99505/ [21:06] I also don't know what info you would want to be able to display non-mainline revs in a fold [21:06] jelmer: do you understand the SVN exception mrooney has? [21:07] jam, well, can I access the merge depth without getting the full revision graph? [21:07] beuno: probably not, but you'll also probably want the mainline revision that merged that revision [21:07] merge_sort gives things to you in a specific order that you can use [21:07] so you probably need some way to preserve that ordering [21:08] I don't know how loggerhead caches it now [21:08] jelmer: Full log at http://pastebin.com/f39f8723e [21:09] james_w: I think it is still possible to get a Talk [21:09] jam, the only thing that LH caches right now, is what files changed in each mainline revision and it's children [21:09] you will probably just need to contact them [21:09] * mrooney waves at james_w [21:09] hey mrooney [21:12] jelmer, Jc2k, Lo-lan-do: devrooms at fosdem are taken, so no official sprinting room [21:12] lifeless, in part, what changed my mind about where to cache revnos, is understanding *today* that they where calculated every single time again [21:13] we should hang around the GNOME guys in Bazaar t-shirts... [21:25] Lo-lan-do, thanks [21:25] mrooney, don't think I've seen that one before [21:25] Jc2k: hmm, mightn't that be offensive? [21:25] mrooney, please file a bug [21:25] jelmer: it seems to be the result of perhaps the output of a post-commit hook? [21:26] will do! [21:26] mrooney, please test with 0.4.16 / 0.4.17 as well [21:26] mrooney, I'm not sure, I think that gives a different exception [21:27] LarstiQ: :] it wouldnt offend me, i cant speak for my Git using counterparts, though :] [21:27] Jc2k, asabil: it would be nice to talk about roundtripping revisions [21:27] at FOSDEM, I mean [21:27] jelmer: yes [21:27] jelmer: is there a PPA for that by any chance? What is the easiest way to try those versions in Intrepid? [21:27] jelmer: oh, git head just got a new command we need to look at too - git note(s) [21:28] jelmer: for associating arbitary blobs with commits (but not in commits) [21:29] jelmer: sure [21:29] mrooney, yeah, there is a PPA for the latest versions of bzr, I don't think it includes the latest bzr-svn at the moment though [21:29] Jc2k, ah, that sounds interesting.. [21:30] jelmer: it fills me with fear :-\ [21:30] Jc2k, uhm, fear? [21:33] jelmer: i dont think it would be the right place for us to stash mapping data, but it is another "thing" for us to worry about supporting [21:34] Jc2k, it sounds like the perfect place to store mapping data.. [21:34] im wondering if it might be local only - not sure how it would work with push/pull [21:36] Jc2k: what about trying to get a slot in the GNOME devroom about bzr git-serve ? [21:36] I know it maybe a bit late to ask [21:36] but it would probably be possible to get a slot if you ask for it [21:37] jelmer: It seems that the SVN revision 6019 corresponds to the first commit I did through bzr-svn on that tree. Dunno if that helps, but it looks conspicuously like bzr-svn does a get-dir for every subsequent revisions on the same branch. [21:37] jelmer: see bf4d57 [21:38] asabil: only if i can get a demo working in next few days [21:38] if you ask for a slot, you will get it working :p [21:45] jelmer: ta-da! https://bugs.edge.launchpad.net/bzr/+bug/316891 [21:45] Ubuntu bug 316891 in bzr "bzr-svn: SubversionException on certain statuses of post-commit hook" [Undecided,New] [21:45] does it look okay? === Mario__ is now known as pygi [21:52] beuno: Listen more carefullt next time, I *told* you :-) [21:52] mrooney, thx [21:55] vila, did you? I must have some level of ADD [21:56] I know I do. [21:56] I'm pretty sure it came on the table the time we walk together in loggerhead code, but some info needs more time than others to travel in brains :) [21:57] vila, right. Maybe it's one of those things I had to discover, no matter how much it was explained to me [21:58] beuno: exactly, remember: learning is always painful or it's not learning :) [21:59] I try to forget that ;) [22:01] beuno: when will you learn ... [22:02] * beuno hurts [22:03] :) === rocky1 is now known as rocky [23:12] jam: installer looks good :) [23:56]