[00:01] jml: hi [00:07] * jml waves hello [00:08] lifeless: are you waiting on anything from me for the testresources merge? [00:09] no [00:09] just time [00:09] ok. [00:14] jam: ping [00:23] re.search(r'^(?!Bazaar)', 'Bazaar') [00:24] poolie: ? [00:24] is for jam. not for you. [00:24] In [11]: re.search(r'^(?!.*\[merge\])', 'Subject: [merge]taheout') [00:24] In [12]: re.search(r'^(?!.*\[merge\])', 'Subject: [mer]taheout') [00:24] Out[12]: <_sre.SRE_Match object at 0x8a2dfa8> [00:24] lifeless: hi [00:24] I should be heading out soon [00:24] oh, on the call? didn't see a invite.. [00:24] jam: I want to talk per file log [00:25] we can chat briefly [00:25] In [14]: re.search(r'^Subject: (?!.*\[merge\])', 'Subject: re: re: [merge]taheout') [00:25] irc or voice? either is fine for me [00:25] ATM, I'm thinking we could add a flag to switch between "only the things in the per-file graph" and "also include merges" [00:27] so [00:28] IIUC what we have at the moment is roughly 'when log -v would mention the file' union (per-file graph nodes) with containing commits listed to give an organisation sense [00:30] lifeless: I'm not sure how you are defining "containing commits", as I'm pretty sure it is just when "bzr log -v" would mention the file [00:30] (is what we have now) [00:30] say we have a triangle [00:30] A [00:30] B [00:30] C [00:31] A<->C doesn't alter FOO [00:31] B<->C does [00:31] and A<->B does [00:31] lifeless: so you modify B and then revert it to C [00:31] (e.g. b makes a change, but its rejected when merged to A [00:31] ? [00:31] yrd [00:31] yes [00:31] meh, not complex enough to show [00:31] anyhow [00:31] right, we'll show C [00:32] I think, because it is different from a merge parent, but I'm not 100% sure [00:32] however, that should also show up in the per-file log [00:32] sorry, per-file graph [00:32] thats what I mean by not complex enough to show the point [00:33] I should really get going. Perhaps we can phone-chat later? [00:33] so one benefit of showing the file where log -v would show it, is that its unsurprising to users [00:33] please, ping me [00:33] poolie: have you done the daily chat? [00:33] yes [00:34] i pinged you on irc just beforehand [00:34] if we call from inside the call everyone has to talk over the ring tone [00:34] poolie: yes, I saw, but didn't see a skype prompt pop up [00:34] poolie: I'm not stressed, was just confirming [01:18] chore to run, brb [01:25] poolie: Do you want to talk about reivews now? [01:35] lifeless: ping for great justice [01:43] abentley, sure, if you want to [01:43] poolie: I think this is the day we planned to. So let's. [01:44] jam: I've replied in mail [01:44] lifeless: yeah. It sure looks like you wanted to vote in there :) [01:45] lifeless: I replied to you. And basically I think we are in agreement. [01:47] jam: ok, cool then [01:47] I'd approved previously, consider it reinstated === dereine is now known as dereine[afk] [03:11] igc: you should upgrade http://bazaar.launchpad.net/%7Eian-clatworthy/bzr-usertest/trunk/. [03:36] abentley: around ? I'd like to run an idea past you [03:37] lifeless: okay [03:37] this is about rich roots. [03:38] I'm thinking to remove the watershed event by writing a rich-root->non-rich-root-with-root-in-rev-property->rich-root-by-reading-rev-property set of code [03:39] abentley: What I want to ask you is two-fold; do you think this is a reasonable thing to do, and do you think I can avoid a new rich-root-format to enable this (I don't think I can) [03:40] abentley: uhm, various little details that might matter are - I'm not suggesting to add rich-root capabilities to non-rich-root formats, just allow pulling from rich to non-rich [03:40] lifeless: So, roundtripping? [03:41] abentley: yes [03:41] abentley: I think its 1-2 days work tops, and if it gets rid of the watershed it may allow more motion on this [03:42] lifeless: The lack of round-tripping is not the biggest issue for me. The biggest issue for me is the whole "let's add a new serializer as a condom" thing. [03:43] abentley: uhm, wasn't that your idea though? [03:45] kinda originally. But then when I realized that we had to mutate the sha1s for existing rich-root formats, I didn't see much point in it. [03:45] But then you wanted it as a "condom" to ensure that sha1s were correct. [03:46] abentley: I think we must have talked past each other then; I want the sha1 chain to be intact regardless of repo format and serializer. [03:46] abentley: thats my primary issue, so that 'check' can actually do its job [03:47] So would you have any hesitation about making 1.6-rich-root our next default format? [03:48] abentley: my set of concerns is ([has-the-sha1-thing-been-fixed, how-will-users-find-the-change]) [03:49] abentley: I admit to some trepidation that the one-way nature of the change will burn some users that want to interoperate, as 'init' 'init-repo' etc will all suddenly make them unable to interoperate with bzr's more than 2 months old [03:49] abentley: the sha1 is a MUST for me; I'll happily follow consensus on the other [03:49] So has the sha1 thing been fixed? [03:50] abentley: there is an outstanding patch of yours; I'll poke around at the sha1 code in the near future and see [03:51] Right, so I believe that's the last piece. [03:51] And the problem with that patch is that it's overbroad. [03:53] I think the interoperability situation is quite good. bzr 1.0 supported "rich-root", so anything in 1.6-rich-root can be converted into a 1.0 compatible format. [03:53] abentley: oh true [03:54] a possibly useful test would be a script to mass-convert everything on lp to rich root, to see if it all works [03:54] (s/convert/branch and do a convert locally|branch-into-a-rich-root-branch/) [03:54] lifeless: Why do you think it would be useful for mthaddon to kill me? :-) [03:54] tom would love it [03:55] we have that shiny new machien [03:58] So possibly a torture-test would be useful. Bazaar itself was pretty tortuous. [03:59] My patch handles weaves repos and their predecessor format. You said you thought it should only cover knits and packs, IIRC. [03:59] We land that, and reconcile will fix sha1s. [04:01] This doesn't prevent revisions with bad sha1s from being fetched, of course. [04:03] Does that remove your concerns about correctness? [04:03] lifeless: ^^^ [04:11] abentley: I thought it should only cover the cases where we know that fetch creates broken sha1s [04:11] abentley: not-fetching-bad-sha1s will come in after this because I can actually land my patch to do that without breaking every rich root user :) [04:33] lifeless: I think that TreeTransform should be able to set the SHA1 of a file. Do you agree? [04:33] abentley: with a caveat - the stat cache cutoff time [04:34] abentley: which basically means that any file we write we usually can't put in the stat cache [04:35] lifeless: do renames update the stat values used? [04:36] Actually, even if they did, only a few files are actually renamed. [04:36] abentley: I don't know for windows; for unix no - the directories inode changes, not the files [04:36] IIRC doing a hard link invalidates the stat cache [04:37] lifeless: Pity that. [04:37] But I think many tree constructions would take long enough that we could use the stat values. [04:38] So for those files, at least, we'd be able to avoid the initial SHA. [04:38] abentley: we can use the stat value if we write the dirstate outside the cutoff time AND noone-else could have touched the file inside that period either [04:39] lifeless: So if the file is inside .bzr/workingtree/limbo, is that safe enough? [04:39] abentley: so pragmatically, I think that if the cutoff time is passed while its in limbo, then its safe [04:39] abentley: yes, if someone fucks with limbo they can keep both pieces [04:41] So for TT to update this data, should we update apply_inventory_delta, or introduce a new function? [04:41] abentley: I have a branch up for review that adds a function to tree- _observed_sha1 [04:41] lifeless: Yeah, I saw it. [04:41] abentley: its the commit-updates-sha patch; is that function suitable for you ? [04:42] lifeless: I thought it might be better to do the operation on a list. But I could also use _observed_sha1. [04:42] abentley: I think a new function, that takes a list form of the parameters for _observed_sha1 would be fine [04:43] abentley: possibly just make _observed_sha1 take a list of tuples [05:15] I'm new to Bazaar so please bear with me. I have started a project on my local machine and now I want to move it to a centralized location (hopefully with full history). Am I correct in thinking that `put` is the command I'm looking for? [05:15] ReachingFarr: push. [05:15] I don't think 'put' _is_ a command... [05:15] Hehe ya, sorry. Push. [05:16] ReachingFarr: That's exactly what the "push" command is for. [05:16] ReachingFarr: Have you been reading a tutorial? [05:17] OK, second problem then is why does my Bazaar install not deal with authentication over http. From what I have seen while Googleing it is supported but when I try pushing it just errors out on 401. [05:18] At one time, it would only even try auth if you put the username in the URL. Not sure when/if that changed. [05:18] Peng_: I did a while ago then started using Bazaar locally. I thought `push` was the correct command and have been trying to use it as such. But the authentication issue is why I'm really here and thought I would make sure I was using the correct command first. [05:20] Part of the problem here is that Fedora only has 1.5 in the repo. I guess I better update to something recent before I start asking for help. [05:24] 1.5 isn't that old. I'm not sure much has changed in auth since then. [05:25] (updating is a good idea in general, of course. But I don't think it'll fix this) [05:27] ReachingFarr: Do you have FTP or SFTP access to your server? That might be easier to use than HTTP auth. [05:28] Peng_: I don't think so. We are using my friends Dreamhost account and I'm not entirely sure how things are set up on it. [05:29] Dreamhost? You can set up the smart server on Dreamhost? [05:29] fullermd: I wouldn't recommend it due to procwatch. [05:30] ReachingFarr: Well, DH offers SFTP access, but your user may not be configured to allow it. Try it, or ask your friend. [05:31] Well, that was somewhat my point... [05:32] Whenever I put the username in the address (http://user@example.org) bzr crashes on me. And this is after I installed 1.7. [05:38] Crash how? Pastebin it. [05:38] i have to work with an svn repo... I'd like to use bzr & loom to do it. Am I crazy? [05:40] what i mean is, is it possible? [05:45] seb_kuzminsky: Check out the bzr-svn plugin. But yes, you're probably crazy. :P [05:46] i got that installed, (0.4.11, from intrepid), and i branched my svn repo to a local shared repo, that was slow but it worked :-) [05:47] Sounds about right. [05:47] i branched locally, checked out, and loomified and we'll see what happens next ... [05:50] fullermd: http://pastebin.com/d5317e471 [05:51] Well, that's pretty wacky. [05:51] vila: ^^^ [05:52] vila's the http guy; he'll know better what to look at. [05:52] You have the fgci/mod_python smart server all setup and working on it? [05:52] Er, fcgi that is. [05:56] what does 'bzr record' do? i dont understand the --help message [05:59] a thread has a "tip", but what does that mean? [06:01] seb_kuzminsky: the tip of a thread is just like the tip of a branch; its a pointer into the revision graph [06:01] that makes sense... [06:03] if i 'bzr push' from a thread, will it also push all the threads below it? [06:04] two cases; pushing from a loom to an existing normal branch; this pushes the current thread into that branch [06:04] the threads below it are included if you have merged them into that thread (which is what happens when you 'up-thread') [06:05] second case; pushing from a loom to a new branch (or to an existing loom) [06:05] this will push the last recorded loom (much like 'push' from a normal branch pushes the last commit from that branch) [06:06] lifeless: thanks! [06:06] is there something like 'bzr log' for 'record'? [06:08] or is that the wrong way of thinking of it? [06:08] seb_kuzminsky: there should be; I haven't written it yet :( [06:09] wow, you wrote loom?! I love it! (though i'm having a bit of a hard time learning to use it) [06:09] thanks for some sweet software :-) [06:09] thanks, I'm glad you like it [06:10] hm, i think it just ate my changes (or i'm misunderstanding how to use it) [06:11] it shouldn't have any bugs of that nature; what were the last few things you did? [06:11] How do you think I should set up logging for the HTTP smart server? [06:12] Just a couple lines with the logging module? Something in bzrlib? [06:12] spiv: ^ your public awaits [06:12] * Peng_ reads trace.py [06:13] Peng_: it probably already logs to ~/.bzr.log [06:13] lifeless: i just tried it again and it did the same thing [06:13] bzr loomify; bzr create-thread test [06:13] # hack, hack [06:13] bzr commit [06:14] bzr combine-thread [06:14] ah, yes, you misunderstand :P [06:14] now my loom has just the original thread, and it doesnt have the change from the test thread [06:14] oh good :-) [06:14] combine-thread is used to remove a thread from the list :P [06:14] ah [06:14] Use combine-thread to remove a thread which has been merged into upstream. [06:14] hm, just like the --help says... [06:14] right [06:14] (the help describes exactly what it does) [06:15] so i should bzr push before i combine-thread? [06:15] then up in the bottom thread? [06:15] lifeless: Why do you think it would use ~/.bzr.log? I mean, it isn't normally used when you "import bzrlib", is it? [06:15] seb_kuzminsky: so, the general use case would be [06:15] Peng_: oh, hmm, gues snot [06:15] (my branch is bound to an svn repo) [06:15] seb_kuzminsky: a trunk, at URL $TRUNK (your svn repo in this case) [06:15] sorry, unbound but parent is an svn repo [06:16] seb_kuzminsky: a developer with a loom, containing a bottom thread 'trunk' (or similar) [06:16] seb_kuzminsky: then you create threads and hack. when a particular thread is accepted by upstream, doing a pull in the 'trunk' thread will bring in changes you already have higher up in your stack. [06:17] seb_kuzminsky: when you (up-thread & commit) those changes, the difference the thread contains will go away, and you would then combine thread [06:17] Hmm, I could change the location by setting os.environ['BZR_LOG'[, right? [06:17] Err, minus the syntax error. :P [06:17] lifeless: i see [06:17] seb_kuzminsky: so yes, you should push the thread you've finished into svn before removing it :P [06:18] heh, that might help :-) [06:18] seb_kuzminsky: or have the person that will accept and commit the patch do so,a nd then you get it back via your trunk thread [06:18] i think the "combine" in combine-thread threw me off [06:18] if i'd read your docs i would have understood [06:19] thanks for teaching me :-) [06:19] seb_kuzminsky: theres been some talk of renaming it [06:19] this is evidence towards doing that [06:19] drop-thread or delete-thread maybe? [06:19] yah [06:19] or evidence i should read tfm [06:19] :P [06:19] drop-thread is a fast version of down-thread :p [06:19] knowing the tool is good; reducing the learning curve is also good [06:20] If I do "from bzrlib import trace; trace.push_log_file(...)", will anything have been logged yet? [06:22] lifeless: when should i record? [06:22] Peng_: there was a patch about this to the list recently [06:24] Peng_: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C418c22640809141502o187ee0det95166e025836aba%40mail.gmail.com%3E [06:24] seb_kuzminsky: whenever you like; the main reason for record is to allow collaboration on a loom-scale between loom-users [06:24] (Which oddly was approved by John, but not merged...) [06:25] seb_kuzminsky: if you're just managing your own patches via loom, and are not publishing your loom anywhere, you don't need to push at all. [06:25] dont need to record at all? [06:25] seb_kuzminsky: otherwise, if you are sharing them, or are publishing your loom, record before you push [06:25] seb_kuzminsky: yes, I made a typo :) [06:25] ok i get it :-) [06:26] i got a backtrace just now [06:26] i'll pastebin it [06:26] seb_kuzminsky: (before you push the /loom/ as opposed to pushing a thread into svn or something similar) [06:26] seb_kuzminsky: thanks [06:27] http://pastebin.ca/1210326 [06:28] Peng_: I suspect that patch probably isn't as flexible enough yet; I'm guessing you'd like to be able do something like "make_app(..., logfile='/foo/bar')" ? [06:28] i tried to change the nick of a loomified branch [06:28] afterwards (now), show-loom shows no active thread, and it keeps leaving the lock around [06:28] does bzr attempt to perform 'globbing' on its cmdline args on windows? I'm surprised to find 'bzr revert foo*.py' not work... [06:28] seb_kuzminsky: oh, put the nick back to the name of the thread you were on [06:28] Peng_: if you do get logging set up to your satisfaction, please mail the list with details of how you did it :) [06:29] seb_kuzminsky: the nickname is managed by loom automatically when you switch threads (bzr up-thread, bzr down-thread, bzr switch) [06:29] markh: yes, see cmd_add for example, for instance [06:29] indeed! thanks! [06:30] lifeless: usertest is upgraded now as requested [06:30] igc: thanks :P [06:30] i'm gettin me all kinds of learning tonight :-) [06:33] thanks lifeless, see you later [06:35] lifeless: revert, status and diff seem not to - is that a bug? [06:36] * beuno stabs beuno_ [06:36] dir [06:36] heh === beuno_ is now known as beuno [06:38] markh: I'd say its a bug, yes [06:41] spiv: I've got it set up, but not to my satisfaction. I just used bzrlib.trace.push_log_file(), so it doesn't show the date, time, PID or any sort of contextual information. (At least for the messages I've been able to get it to generate so far: warnings about a knit repo.) [06:42] Peng_: ah, crummy. [06:42] Hmm. Using enable_default_logging would make it output that information, but it would also set up a stderr logger, which I don't want. [06:44] Yeah, the stderr handler doesn't sound like a good idea :) [06:44] so, there is an existing bug that 'commit' doesn't glob on windows. Should I just 'adopt' that bug and broaden it for all commands known to need that support added? [06:45] I might just copy parts of enable_default_logging(). [06:45] markh: I don't like broadening bugs [06:45] so add 4 new bugs all identical except for the specific command? [06:45] markh: because it marks it harder to ever actually close it; unless you think there is a simple fix-for-all-commands [06:46] well yeah, the same fix would be used for all, but possibly need to be applied for each commaand [06:46] markh: it's easier to combine separate bugs (by marking as dupes) than it is to separate an existing bug into multiple bugs. [06:46] markh: what would be ideal is a simple way to test globbing-on-windows-on-commands, so we can tell if things regress etc [06:46] markh: so when in doubt it's probably best to default to filing multiple bugs. [06:46] even easier to avoid it if possible, hence my question ;) [06:46] Well, true :) [06:46] Unless you count asking questions as hard work ;) [06:47] markh: put it this way, if you're writing code to fix it for all commands you know of, why bother touching the bug :P [06:47] :) less work than re-touching 4 bugs that are effectively dupes if that isn't what was wanted. But as it is, I'll do it. [06:47] markh: just wrte the code, tell the bug you have a branch, and bingo its done :) [06:47] I'm not proposing to fix it ;) [06:47] heh [06:47] then we spend 5 weeks debating the style, remember ;) [06:48] mmmm, I don't think we do. But YMMV [06:49] the bug actually notes a fix was previously submitted but resubmission was requested multiple times, according to the bug anyway [06:49] No, someone sends one "bb:tweak" suggesting the style be changed, and then everybody forgets about the branch for a few months until someone reminds them to check the BB queue. [06:49] * Peng_ ducks [06:49] ditto for my "update -r" bug I must get back to [06:50] markh: I think someone sent a patch for that. Was it you? [06:50] "update -r" - yeah [06:51] I picked up old work that I thought was quite close, so I merged it and updated it for 2 years worth of changes, but it turns out a number of other things still need doing, and I really can't justify spending any more personal time on it :( I asked for help landing it in the bug... [07:06] hi all ! [07:07] fullermd, ReachingFarr (actually he seems to be gone :-/): on that particular one (65 data rewind), I think spiv knows more than me [07:09] I've never reproduced it so I don't know where to lookt at [07:11] spiv: OK, I've got it set up to my satisfcation (as far as I can tell) [07:43] Hi all. Does anyone know if possible to do a partial checkout? I have a big tree of related sub-projects, and usually only want to work on one or two, and do not want a complete working tree. [07:44] pysquared, you can't currently, no [07:44] Shame [07:45] Any plugins to do this that you know of? [07:45] Is there a feature request for this (that I have not found yet), or shall I add one? [07:45] no, I don't think you can do that currently [07:46] feel free to add it [07:48] I'm thinking about making a certain branch public, so I was just reading through the log to see if it's appropriate. One message includes a declaration of love for one of bzr's developers. Whoops. [07:49] that's very appropriate [07:49] Ah, just found a note about it on jam's blog - http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html [07:49] Should I file a feature request anyway? [07:49] pysquared, yeap, go for it [07:52] if there isn't already one [07:54] Ahah, I spent ages searching for something before. Found this: http://bazaar-vcs.org/FilteredViews [07:54] It was linked from http://www.infoq.com/articles/dvcs-guide [07:54] night all [07:55] g'night lifeless [07:55] AFAIK filtered views still bring in the full repo [07:55] I may be wrong [07:55] igc is working on it [07:55] they always will in the current designs [07:56] anyhow, /gone [08:08] jelmer: did you notice that debian experimental now has bzr-svn 0.4.13 which depends on bzr (<< 1.7~) so it cannot be installed with bzr 1.7 from debian experimental after your yesterday uploads? [08:41] mwhudson, I'm cleaning up bugs in LH: https://bugs.edge.launchpad.net/loggerhead/+bugs?search=Search&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed [08:41] the last two NEW have your name on it :) === dereine[afk] is now known as dereine [09:10] spiv: There's a typo in your -Eallow_debug patch. It should be "sanitisation", not "santisation". === dereine is now known as dereine[afk] [09:11] That hardly sounds sanitized :p [09:11] Oh, my email client unfroze now. [09:11] Peng_: d'oh, thanks. === dereine[afk] is now known as dereine [09:12] :) [09:14] vila: how's your patch to remove SmartClientMedium from RemoteTransport's set of base classes doing? [09:15] waiting review :) [09:15] vila: My -Dhpss patch on the list reminded me just how many SmartClientMedium instances we're currently creating, and it's a bit nuts... [09:15] Hmm, I don't see it in my bundle buggy queue. [09:16] my fault wrong subject it appears [09:16] it's part of the python-2.6 compatibility RFC [09:17] the patch includes caching the medium created so that should address your concern [09:17] The controversial bit is that I use weakref to avoid a circular dependency [09:18] Huh, interesting. [09:18] What's wrong with a circular reference? [09:19] Because the medium has a __del__ it causes uncollectable cycles? [09:19] no more gc ? [09:19] __del__ will never be called if the ref never reach zero, the medium references the transport [09:20] and is an attribute of the transport [09:21] so I made the transport attribute a weak ref in the medium [09:21] all of the above applies to SmartClientHTTPMedium only of course [09:21] I suspect it's possible to find a more elegant solution. [09:21] But I don't think it's worth wasting the effort to find it :) [09:22] Thanks for the update. [09:22] * spiv goes swimming [09:22] (idea: maybe the HTTP transport and HTTP medium could share a reference to an HTTP channel, rather than to each other?) [09:23] spiv: the root problem is that both the transport and the medium have a 'base' attribute with isn't related to the http channel [09:24] so while the http 'channel' can be shared between transport/medium pairs, the base must be shared by each pair [09:25] and this sounds is a bit complicated for what we want to achieve [09:25] I don't have problems with weakref per se but I'm not sure this is view shared by everyone [09:27] spib: Anyway, I'd like to rework my python-2.6 branch into a loom so I can more easily extract that smart medium part if you think it's worth merging sooner [09:27] spiv (grr): Anyway, I'd like to rework my python-2.6 branch into a loom so I can more easily extract that smart medium part if you think it's worth merging sooner [09:40] vila, hi [09:40] how are you going? [10:46] so, I have these two branches on two machines being both parented to the online one [10:47] how can I avoid a double network activity to bring them both in sync with the online one ? [10:47] ie: can I have hostA pull from hostB on a case-by-case basis ? [10:48] case-by-case means: sometime I want hostB to pull from hostA [10:54] strk: I guess you could keep a copy of the parent on one of the machines, then have the other pull from it. [11:17] hi, i need help: "bzr revert" returns 'bzr: ERROR: Could not acquire lock "D:/duscher/docs/ProjektM/dev/.bzr/checkout/dirstate"' [11:17] I am using bzr.dev on windows [11:17] break-lock does not help [11:21] re-checkingout the branch produces the same error in the new branch [11:31] does anyone have a clue how to recover from this state? I have a presentation in 2 hours and I would like to be able to revert... [11:39] jonnydee: Sorry, but I don't know. My only two ideas are 1.) Are you using the most recent version of bzr?, and 2.) did something get marked read-only? === dereine is now known as dereine[afk] [11:53] night all [11:53] jonnydee: probably there is still a bzr process running somewhere [11:53] kill it off and you should be ok [11:53] if all else fails :-( reboot [11:54] hth === strk is now known as strk_lunch === TheMuso_ is now known as TheMuso === strk_lunch is now known as strk === beaumonta is now known as abeaumont === bac_afk is now known as bac [14:04] Hello. Is there a way to reconfigure a shared repository to have the --no-trees option? [14:06] pysquare1: touch .bzr/repository/no-working-trees [14:06] I don't think there's a nice way to do it with the 'bzr' command line, although there ought to be. [14:08] Thanks spiv, I just did; bzr init-repo t1; bzr init-repo --no-trees t2; diff -r t1 t2; and got "Only in t2/.bzr/repository: no-working-trees" -- cool. === thekorn_ is now known as thekorn === mw is now known as mw|out [14:32] <_dereine> hi, are there any private bazaar hosting services? [14:32] Anything with a webserver I should think [14:32] You don't need a special server.. anything you can (s)ftp to and http from is sufficient [15:29] Hi all [15:29] I apologise in advance for being rude, but is there work done on performance these days? [15:29] Specifically, start-up time? [15:30] hey Lo-lan-do [15:30] there was a discussion on the list just recently about that very topic, discussing where and how to reduce start-up time [15:30] Goody :-) [15:31] Has it been suggested that maybe not all of bzr needs to be loaded and initialized for each invocation? [15:32] I understand lots of code has to be loaded for complex operations, but maybe "bzr info" could do without it (and come below 2 seconds)... [15:34] I have a large root+lots of feature branches+integration branch setup, with a script to merge all feature branches back into the integration branch, and it seems like a shame to spend so much time waiting for bzr nick to answer. [15:34] Lo-lan-do: if that script is in python, you could use bzrlib directly [15:35] It's shell so far. [15:35] Maybe "bzr shell" could help? [15:38] maybe, but I'm not familiar with 'bzr shell' [15:39] I meant when your script needs to iterate over a lot of branches, it might make sense to do that in python with bzrlib directly to avoid loading bzrlib for every branch but just once at startup of that script [15:39] Yes, and I think bzr shell does approximately that. [15:40] Except it behaves as a shell, with extra (or overridden) commands such as status, merge, cat, info, nick and so on. [15:40] is your script for package maintenance? [15:40] More or less. I use it to prepare packages of patched apps for clients. [15:41] hm. in that case, you could perhaps add some more magic into the bzr-builddeb plugin [15:41] I'd rather keep it generic. [15:42] I mean, the patches I do are not Debian-related, they just happen to be on source trees that will eventually be turned into debs. [15:43] is there any documentation for bzr-svn? I have having trouble finding anything except the faw [15:47] also is there any way to get a graphical log like hg glog? (I am just trying out dvcs and found that quite helpful) [15:47] Besides, I would honestly prefer keeping my shell script and have it run faster :-) [15:47] thrope: bzr viz, in the gtk plugin [15:48] As for bzr-svn, it's supposed to be "transparent" [15:48] Lo-lan-do: ah - how to i 'activate' the plugin (I installed it but get error with bzr viz) [15:48] Lo-lan-do: for bzr-svn it is owkring ok but I expect bzr push to update the svn repository but it said no location known [15:49] bzr push svn//url [15:49] oh - it won't store it anywhere? [15:49] push doesn't default the url the branch was branched from [15:49] it will once you specify it once [15:49] oh [15:49] right [15:49] (this is a debated feature) [15:49] I use a checkout (bound branch) for that. [15:50]