[00:01] <lifeless> jml: hi
[00:07]  * jml waves hello
[00:08] <jml> lifeless: are you waiting on anything from me for the testresources merge?
[00:09] <lifeless> no
[00:09] <lifeless> just time
[00:09] <jml> ok.
[00:14] <lifeless> jam: ping
[00:23] <poolie> re.search(r'^(?!Bazaar)', 'Bazaar')
[00:24] <lifeless> poolie: ?
[00:24] <poolie> is for jam. not for you.
[00:24] <poolie> In [11]: re.search(r'^(?!.*\[merge\])', 'Subject: [merge]taheout')
[00:24] <poolie> In [12]: re.search(r'^(?!.*\[merge\])', 'Subject: [mer]taheout')
[00:24] <poolie> Out[12]: <_sre.SRE_Match object at 0x8a2dfa8>
[00:24] <jam> lifeless: hi
[00:24] <jam> I should be heading out soon
[00:24] <lifeless> oh, on the call? didn't see a invite..
[00:24] <lifeless> jam: I want to talk per file log
[00:25] <jam> we can chat briefly
[00:25] <poolie> In [14]: re.search(r'^Subject: (?!.*\[merge\])', 'Subject: re: re: [merge]taheout')
[00:25] <lifeless> irc or voice? either is fine for me
[00:25] <jam> 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] <lifeless> so
[00:28] <lifeless> 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] <jam> 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] <jam> (is what we have now)
[00:30] <lifeless> say we have a triangle
[00:30] <lifeless> A
[00:30] <lifeless>  B
[00:30] <lifeless> C
[00:31] <lifeless> A<->C doesn't alter FOO
[00:31] <lifeless> B<->C does
[00:31] <lifeless> and A<->B does
[00:31] <jam> lifeless: so you modify B and then revert it to C
[00:31] <lifeless> (e.g. b makes a change, but its rejected when merged to A
[00:31] <jam> ?
[00:31] <lifeless> yrd
[00:31] <lifeless> yes
[00:31] <lifeless> meh, not complex enough to show
[00:31] <lifeless> anyhow
[00:31] <jam> right, we'll show C
[00:32] <jam> I think, because it is different from a merge parent, but I'm not 100% sure
[00:32] <jam> however, that should also show up in the per-file log
[00:32] <jam> sorry, per-file graph
[00:32] <lifeless> thats what I mean by not complex enough to show the point
[00:33] <jam> I should really get going. Perhaps we can phone-chat later?
[00:33] <lifeless> so one benefit of showing the file where log -v would show it, is that its unsurprising to users
[00:33] <lifeless> please, ping me
[00:33] <lifeless> poolie: have you done the daily chat?
[00:33] <poolie> yes
[00:34] <poolie> i pinged you on irc just beforehand
[00:34] <poolie> if we call from inside the call everyone has to talk over the ring tone
[00:34] <lifeless> poolie: yes, I saw, but didn't see a skype prompt pop up
[00:34] <lifeless> poolie: I'm not stressed, was just confirming
[01:18] <lifeless> chore to run, brb
[01:25] <abentley> poolie: Do you want to talk about reivews now?
[01:35] <jam> lifeless: ping for great justice
[01:43] <poolie> abentley, sure, if you want to
[01:43] <abentley> poolie: I think this is the day we planned to.  So let's.
[01:44] <lifeless> jam: I've replied in mail
[01:44] <jam> lifeless: yeah. It sure looks like you wanted to vote in there :)
[01:45] <jam> lifeless: I replied to you. And basically I think we are in agreement.
[01:47] <lifeless> jam: ok, cool then
[01:47] <lifeless> I'd approved previously, consider it reinstated
[03:11] <lifeless> igc: you should upgrade http://bazaar.launchpad.net/%7Eian-clatworthy/bzr-usertest/trunk/.
[03:36] <lifeless> abentley: around ? I'd like to run an idea past you
[03:37] <abentley> lifeless: okay
[03:37] <lifeless> this is about rich roots.
[03:38] <lifeless> 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] <lifeless> 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] <lifeless> 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] <abentley> lifeless: So, roundtripping?
[03:41] <lifeless> abentley: yes
[03:41] <lifeless> 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] <abentley> 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] <lifeless> abentley: uhm, wasn't that your idea though?
[03:45] <abentley> 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] <abentley> But then you wanted it as a "condom" to ensure that sha1s were correct.
[03:46] <lifeless> 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] <lifeless> abentley: thats my primary issue, so that 'check' can actually do its job
[03:47] <abentley> So would you have any hesitation about making 1.6-rich-root our next default format?
[03:48] <lifeless> abentley: my set of concerns is ([has-the-sha1-thing-been-fixed, how-will-users-find-the-change])
[03:49] <lifeless> 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] <lifeless> abentley: the sha1 is a MUST for me; I'll happily follow consensus on the other
[03:49] <abentley> So has the sha1 thing been fixed?
[03:50] <lifeless> abentley: there is an outstanding patch of yours; I'll poke around at the sha1 code in the near future and see
[03:51] <abentley> Right, so I believe that's the last piece.
[03:51] <abentley> And the problem with that patch is that it's overbroad.
[03:53] <abentley> 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] <lifeless> abentley: oh true
[03:54] <lifeless> 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] <lifeless> (s/convert/branch and do a convert locally|branch-into-a-rich-root-branch/)
[03:54] <abentley> lifeless: Why do you think it would be useful for mthaddon to kill me? :-)
[03:54] <lifeless> tom would love it
[03:55] <lifeless> we have that shiny new machien
[03:58] <abentley> So possibly a torture-test would be useful.  Bazaar itself was pretty tortuous.
[03:59] <abentley> My patch handles weaves repos and their predecessor format.  You said you thought it should only cover knits and packs, IIRC.
[03:59] <abentley> We land that, and reconcile will fix sha1s.
[04:01] <abentley> This doesn't prevent revisions with bad sha1s from being fetched, of course.
[04:03] <abentley> Does that remove your concerns about correctness?
[04:03] <abentley> lifeless: ^^^
[04:11] <lifeless> abentley: I thought it should only cover the cases where we know that fetch creates broken sha1s
[04:11] <lifeless> 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] <abentley> lifeless: I think that TreeTransform should be able to set the SHA1 of a file.  Do you agree?
[04:33] <lifeless> abentley: with a caveat - the stat cache cutoff time
[04:34] <lifeless> abentley: which basically means that any file we write we usually can't put in the stat cache
[04:35] <abentley> lifeless: do renames update the stat values used?
[04:36] <abentley> Actually, even if they did, only a few files are actually renamed.
[04:36] <lifeless> abentley: I don't know for windows; for unix no - the directories inode changes, not the files
[04:36] <lifeless> IIRC doing a hard link invalidates the stat cache
[04:37] <abentley> lifeless: Pity that.
[04:37] <abentley> But I think many tree constructions would take long enough that we could use the stat values.
[04:38] <abentley> So for those files, at least, we'd be able to avoid the initial SHA.
[04:38] <lifeless> 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] <abentley> lifeless: So if the file is inside .bzr/workingtree/limbo, is that safe enough?
[04:39] <lifeless> abentley: so pragmatically, I think that if the cutoff time is passed while its in limbo, then its safe
[04:39] <lifeless> abentley: yes, if someone fucks with limbo they can keep both pieces
[04:41] <abentley> So for TT to update this data, should we update apply_inventory_delta, or introduce a new function?
[04:41] <lifeless> abentley: I have a branch up for review that adds a function to tree- _observed_sha1
[04:41] <abentley> lifeless: Yeah, I saw it.
[04:41] <lifeless> abentley: its the commit-updates-sha patch; is that function suitable for you ?
[04:42] <abentley> lifeless: I thought it might be better to do the operation on a list.  But I could also use _observed_sha1.
[04:42] <lifeless> abentley: I think a new function, that takes a list form of the parameters for _observed_sha1 would be fine
[04:43] <lifeless> abentley: possibly just make _observed_sha1 take a list of tuples
[05:15] <ReachingFarr> 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] <fullermd> ReachingFarr: push.
[05:15] <fullermd> I don't think 'put' _is_ a command...
[05:15] <ReachingFarr> Hehe ya, sorry.  Push.
[05:16] <Peng_> ReachingFarr: That's exactly what the "push" command is for.
[05:16] <Peng_> ReachingFarr: Have you been reading a tutorial?
[05:17] <ReachingFarr> 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] <fullermd> 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] <ReachingFarr> 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] <ReachingFarr> 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] <fullermd> 1.5 isn't that old.  I'm not sure much has changed in auth since then.
[05:25] <fullermd> (updating is a good idea in general, of course.  But I don't think it'll fix this)
[05:27] <Peng_> ReachingFarr: Do you have FTP or SFTP access to your server? That might be easier to use than HTTP auth.
[05:28] <ReachingFarr> 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] <fullermd> Dreamhost?  You can set up the smart server on Dreamhost?
[05:29] <Peng_> fullermd: I wouldn't recommend it due to procwatch.
[05:30] <Peng_> ReachingFarr: Well, DH offers SFTP access, but your user may not be configured to allow it. Try it, or ask your friend.
[05:31] <fullermd> Well, that was somewhat my point...
[05:32] <ReachingFarr> 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] <fullermd> Crash how?  Pastebin it.
[05:38] <seb_kuzminsky> i have to work with an svn repo...  I'd like to use bzr & loom to do it.  Am I crazy?
[05:40] <seb_kuzminsky> what i mean is, is it possible?
[05:45] <Peng_> seb_kuzminsky: Check out the bzr-svn plugin. But yes, you're probably crazy. :P
[05:46] <seb_kuzminsky> 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] <Peng_> Sounds about right.
[05:47] <seb_kuzminsky> i branched locally, checked out, and loomified and we'll see what happens next ...
[05:50] <ReachingFarr> fullermd: http://pastebin.com/d5317e471
[05:51] <fullermd> Well, that's pretty wacky.
[05:51] <fullermd> vila: ^^^
[05:52] <fullermd> vila's the http guy; he'll know better what to look at.
[05:52] <fullermd> You have the fgci/mod_python smart server all setup and working on it?
[05:52] <fullermd> Er, fcgi that is.
[05:56] <seb_kuzminsky> what does 'bzr record' do?  i dont understand the --help message
[05:59] <seb_kuzminsky> a thread has a "tip", but what does that mean?
[06:01] <lifeless> seb_kuzminsky: the tip of a thread is just like the tip of a branch; its a pointer into the revision graph
[06:01] <seb_kuzminsky> that makes sense...
[06:03] <seb_kuzminsky> if i 'bzr push' from a thread, will it also push all the threads below it?
[06:04] <lifeless> two cases; pushing from a loom to an existing normal branch; this pushes the current thread into that branch
[06:04] <lifeless> the threads below it are included if you have merged them into that thread (which is what happens when you 'up-thread')
[06:05] <lifeless> second case; pushing from a loom to a new branch (or to an existing loom)
[06:05] <lifeless> this will push the last recorded loom (much like 'push' from a normal branch pushes the last commit from that branch)
[06:06] <seb_kuzminsky> lifeless: thanks!
[06:06] <seb_kuzminsky> is there something like 'bzr log' for 'record'?
[06:08] <seb_kuzminsky> or is that the wrong way of thinking of it?
[06:08] <lifeless> seb_kuzminsky: there should be; I haven't written it yet :(
[06:09] <seb_kuzminsky> wow, you wrote loom?!  I love it!  (though i'm having a bit of a hard time learning to use it)
[06:09] <seb_kuzminsky> thanks for some sweet software :-)
[06:09] <lifeless> thanks, I'm glad you like it
[06:10] <seb_kuzminsky> hm, i think it just ate my changes (or i'm misunderstanding how to use it)
[06:11] <lifeless> it shouldn't have any bugs of that nature; what were the last few things you did?
[06:11] <Peng_> How do you think I should set up logging for the HTTP smart server?
[06:12] <Peng_> Just a couple lines with the logging module? Something in bzrlib?
[06:12] <lifeless> spiv: ^ your public awaits
[06:12]  * Peng_ reads trace.py
[06:13] <lifeless> Peng_: it probably already logs to ~/.bzr.log
[06:13] <seb_kuzminsky> lifeless: i just tried it again and it did the same thing
[06:13] <seb_kuzminsky> bzr loomify; bzr create-thread test
[06:13] <seb_kuzminsky> # hack, hack
[06:13] <seb_kuzminsky> bzr commit
[06:14] <seb_kuzminsky> bzr combine-thread
[06:14] <lifeless> ah, yes, you misunderstand :P
[06:14] <seb_kuzminsky> now my loom has just the original thread, and it doesnt have the change from the test thread
[06:14] <seb_kuzminsky> oh good :-)
[06:14] <lifeless> combine-thread is used to remove a thread from the list :P
[06:14] <seb_kuzminsky> ah
[06:14] <lifeless>   Use combine-thread to remove a thread which has been merged into upstream.
[06:14] <seb_kuzminsky> hm, just like the --help says...
[06:14] <seb_kuzminsky> right
[06:14] <lifeless> (the help describes exactly what it does)
[06:15] <seb_kuzminsky> so i should bzr push before i combine-thread?
[06:15] <seb_kuzminsky> then up in the bottom thread?
[06:15] <Peng_> 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] <lifeless> seb_kuzminsky: so, the general use case would be
[06:15] <lifeless> Peng_: oh, hmm, gues snot
[06:15] <seb_kuzminsky> (my branch is bound to an svn repo)
[06:15] <lifeless> seb_kuzminsky: a trunk, at URL $TRUNK (your svn repo in this case)
[06:15] <seb_kuzminsky> sorry, unbound but parent is an svn repo
[06:16] <lifeless> seb_kuzminsky: a developer with a loom, containing a bottom thread 'trunk' (or similar)
[06:16] <lifeless> 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] <lifeless> 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] <Peng_> Hmm, I could change the location by setting os.environ['BZR_LOG'[, right?
[06:17] <Peng_> Err, minus the syntax error. :P
[06:17] <seb_kuzminsky> lifeless: i see
[06:17] <lifeless> seb_kuzminsky: so yes, you should push the thread you've finished into svn before removing it :P
[06:18] <seb_kuzminsky> heh, that might help :-)
[06:18] <lifeless> 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] <seb_kuzminsky> i think the "combine" in combine-thread threw me off
[06:18] <seb_kuzminsky> if i'd read your docs i would have understood
[06:19] <seb_kuzminsky> thanks for teaching me :-)
[06:19] <lifeless> seb_kuzminsky: theres been some talk of renaming it
[06:19] <lifeless> this is evidence towards doing that
[06:19] <seb_kuzminsky> drop-thread or delete-thread maybe?
[06:19] <lifeless> yah
[06:19] <seb_kuzminsky> or evidence i should read tfm
[06:19] <lifeless> :P
[06:19] <fullermd> drop-thread is a fast version of down-thread   :p
[06:19] <lifeless> knowing the tool is good; reducing the learning curve is also good
[06:20] <Peng_> If I do "from bzrlib import trace; trace.push_log_file(...)", will anything have been logged yet?
[06:22] <seb_kuzminsky> lifeless: when should i record?
[06:22] <spiv> Peng_: there was a patch about this to the list recently
[06:24] <spiv> Peng_: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C418c22640809141502o187ee0det95166e025836aba%40mail.gmail.com%3E
[06:24] <lifeless> seb_kuzminsky: whenever you like; the main reason for record is to allow collaboration on a loom-scale between loom-users
[06:24] <spiv> (Which oddly was approved by John, but not merged...)
[06:25] <lifeless> 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] <seb_kuzminsky> dont need to record at all?
[06:25] <lifeless> seb_kuzminsky: otherwise, if you are sharing them, or are publishing your loom, record before you push
[06:25] <lifeless> seb_kuzminsky: yes, I made a typo :)
[06:25] <seb_kuzminsky> ok i get it :-)
[06:26] <seb_kuzminsky> i got a backtrace just now
[06:26] <seb_kuzminsky> i'll pastebin it
[06:26] <lifeless> seb_kuzminsky: (before you push the /loom/ as opposed to pushing a thread into svn or something similar)
[06:26] <lifeless> seb_kuzminsky: thanks
[06:27] <seb_kuzminsky> http://pastebin.ca/1210326
[06:28] <spiv> 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] <seb_kuzminsky> i tried to change the nick of a loomified branch
[06:28] <seb_kuzminsky> afterwards (now), show-loom shows no active thread, and it keeps leaving the lock around
[06:28] <markh> 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] <lifeless> seb_kuzminsky: oh, put the nick back to the name of the thread you were on
[06:28] <spiv> Peng_: if you do get logging set up to your satisfaction, please mail the list with details of how you did it :)
[06:29] <lifeless> seb_kuzminsky: the nickname is managed by loom automatically when you switch threads (bzr up-thread, bzr down-thread, bzr switch)
[06:29] <lifeless> markh: yes, see cmd_add for example, for instance
[06:29] <seb_kuzminsky> indeed!  thanks!
[06:30] <igc> lifeless: usertest is upgraded now as requested
[06:30] <lifeless> igc: thanks :P
[06:30] <seb_kuzminsky> i'm gettin me all kinds of learning tonight :-)
[06:33] <seb_kuzminsky> thanks lifeless, see you later
[06:35] <markh> lifeless: revert, status and diff seem not to - is that a bug?
[06:36]  * beuno stabs beuno_ 
[06:36] <markh> dir
[06:36] <markh> heh
[06:38] <lifeless> markh: I'd say its a bug, yes
[06:41] <Peng_> 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] <spiv> Peng_: ah, crummy.
[06:42] <Peng_> 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] <spiv> Yeah, the stderr handler doesn't sound like a good idea :)
[06:44] <markh> 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] <Peng_> I might just copy parts of enable_default_logging().
[06:45] <lifeless> markh: I don't like broadening bugs
[06:45] <markh> so add 4 new bugs all identical except for the specific command?
[06:45] <lifeless> markh: because it marks it harder to ever actually close it; unless you think there is a simple fix-for-all-commands
[06:46] <markh> well yeah, the same fix would be used for all, but possibly need to be applied for each commaand
[06:46] <spiv> 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] <lifeless> 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] <spiv> markh: so when in doubt it's probably best to default to filing multiple bugs.
[06:46] <markh> even easier to avoid it if possible, hence my question ;)
[06:46] <spiv> Well, true :)
[06:46] <spiv> Unless you count asking questions as hard work ;)
[06:47] <lifeless> 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] <markh> :) 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] <lifeless> markh: just wrte the code, tell the bug you have a branch, and bingo its done :)
[06:47] <markh> I'm not proposing to fix it ;)
[06:47] <markh> heh
[06:47] <markh> then we spend 5 weeks debating the style, remember ;)
[06:48] <lifeless> mmmm, I don't think we do. But YMMV
[06:49] <markh> the bug actually notes a fix was previously submitted but resubmission was requested multiple times, according to the bug anyway
[06:49] <Peng_> 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] <markh> ditto for my "update -r" bug I must get back to
[06:50] <Peng_> markh: I think someone sent a patch for that. Was it you?
[06:50] <markh> "update -r" - yeah
[06:51] <markh> 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] <vila> hi all !
[07:07] <vila> fullermd, ReachingFarr (actually he seems to be gone :-/): on that particular one (65 data rewind), I think spiv knows more than me
[07:09] <vila> I've never reproduced it so I don't know where to lookt at
[07:11] <Peng_> spiv: OK, I've got it set up to my satisfcation (as far as I can tell)
[07:43] <pysquared> 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] <beuno> pysquared, you can't currently, no
[07:44] <pysquared> Shame
[07:45] <pysquared> Any plugins to do this that you know of?
[07:45] <pysquared> Is there a feature request for this (that I have not found yet), or shall I add one?
[07:45] <beuno> no, I don't think you can do that currently
[07:46] <beuno> feel free to add it
[07:48] <Peng_> 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] <beuno> that's very appropriate
[07:49] <pysquared> Ah, just found a note about it on jam's blog - http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html
[07:49] <pysquared> Should I file a feature request anyway?
[07:49] <beuno> pysquared, yeap, go for it
[07:52] <LarstiQ> if there isn't already one
[07:54] <pysquared> Ahah, I spent ages searching for something before.  Found this: http://bazaar-vcs.org/FilteredViews
[07:54] <pysquared> It was linked from http://www.infoq.com/articles/dvcs-guide
[07:54] <lifeless> night all
[07:55] <beuno> g'night lifeless
[07:55] <beuno> AFAIK filtered views still bring in the full repo
[07:55] <beuno> I may be wrong
[07:55] <beuno> igc is working on it
[07:55] <lifeless> they always will in the current designs
[07:56] <lifeless> anyhow, /gone
[08:08] <tvainika> 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] <beuno> 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] <beuno> the last two NEW have your name on it  :)
[09:10] <Peng_> spiv: There's a typo in your -Eallow_debug patch. It should be "sanitisation", not "santisation".
[09:11] <fullermd> That hardly sounds sanitized   :p
[09:11] <Peng_> Oh, my email client unfroze now.
[09:11] <spiv> Peng_: d'oh, thanks.
[09:12] <Peng_> :)
[09:14] <spiv> vila: how's your patch to remove SmartClientMedium from RemoteTransport's set of base classes doing?
[09:15] <vila> waiting review :)
[09:15] <spiv> 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] <spiv> Hmm, I don't see it in my bundle buggy queue.
[09:16] <vila> my fault wrong subject it appears
[09:16] <vila> it's part of the python-2.6 compatibility RFC
[09:17] <vila> the patch includes caching the medium created so that should address your concern
[09:17] <vila> The controversial bit is that I use weakref to avoid a circular dependency
[09:18] <spiv> Huh, interesting.
[09:18] <spiv> What's wrong with a circular reference?
[09:19] <spiv> Because the medium has a __del__ it causes uncollectable cycles?
[09:19] <vila> no more gc ?
[09:19] <vila> __del__ will never be called if the ref never reach zero, the medium references the transport
[09:20] <vila> and is an attribute of the transport
[09:21] <vila> so I made the transport attribute a weak ref in the medium
[09:21] <vila> all of the above applies to SmartClientHTTPMedium only of course
[09:21] <spiv> I suspect it's possible to find a more elegant solution.
[09:21] <spiv> But I don't think it's worth wasting the effort to find it :)
[09:22] <spiv> Thanks for the update.
[09:22]  * spiv goes swimming
[09:22] <spiv> (idea: maybe the HTTP transport and HTTP medium could share a reference to an HTTP channel, rather than to each other?)
[09:23] <vila> 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] <vila> so while the http 'channel' can be shared between transport/medium pairs, the base must be shared by each pair
[09:25] <vila> and this sounds is a bit complicated for what we want to achieve
[09:25] <vila> I don't have problems with weakref per se but I'm not sure this is view shared by everyone
[09:27] <vila> 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] <vila> 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] <poolie> vila, hi
[09:40] <poolie> how are you going?
[10:46] <strk> so, I have these two branches on two machines being both parented to the online one
[10:47] <strk> how can I avoid a double network activity to bring them both in sync with the online one ?
[10:47] <strk> ie: can I have hostA pull from hostB on a case-by-case basis ?
[10:48] <strk> case-by-case means: sometime I want hostB to pull from hostA
[10:54] <Peng_> 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] <jonnydee> hi, i need help: "bzr revert" returns 'bzr: ERROR: Could not acquire lock "D:/duscher/docs/ProjektM/dev/.bzr/checkout/dirstate"'
[11:17] <jonnydee> I am using bzr.dev on windows
[11:17] <jonnydee> break-lock does not help
[11:21] <jonnydee> re-checkingout the branch produces the same error in the new branch
[11:31] <jonnydee> 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] <Peng_> 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?
[11:53] <poolie> night all
[11:53] <poolie> jonnydee: probably there is still a bzr process running somewhere
[11:53] <poolie> kill it off and you should be ok
[11:53] <poolie> if all else fails :-( reboot
[11:54] <poolie> hth
[14:04] <pysquare1> Hello.  Is there a way to reconfigure a shared repository to have the --no-trees option?
[14:06] <spiv> pysquare1: touch .bzr/repository/no-working-trees
[14:06] <spiv> I don't think there's a nice way to do it with the 'bzr' command line, although there ought to be.
[14:08] <pysquare1> 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.
[14:32] <_dereine> hi, are there any private bazaar hosting services?
[14:32] <LeoNerd> Anything with a webserver I should think
[14:32] <LeoNerd> You don't need a special server.. anything you can (s)ftp to and http from is sufficient
[15:29] <Lo-lan-do> Hi all
[15:29] <Lo-lan-do> I apologise in advance for being rude, but is there work done on performance these days?
[15:29] <Lo-lan-do> Specifically, start-up time?
[15:30] <james_w> hey Lo-lan-do
[15:30] <james_w> there was a discussion on the list just recently about that very topic, discussing where and how to reduce start-up time
[15:30] <Lo-lan-do> Goody :-)
[15:31] <Lo-lan-do> Has it been suggested that maybe not all of bzr needs to be loaded and initialized for each invocation?
[15:32] <Lo-lan-do> 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] <Lo-lan-do> 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] <siretart> Lo-lan-do: if that script is in python, you could use bzrlib directly
[15:35] <Lo-lan-do> It's shell so far.
[15:35] <Lo-lan-do> Maybe "bzr shell" could help?
[15:38] <siretart> maybe, but I'm not familiar with 'bzr shell'
[15:39] <siretart> 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] <Lo-lan-do> Yes, and I think bzr shell does approximately that.
[15:40] <Lo-lan-do> Except it behaves as a shell, with extra (or overridden) commands such as status, merge, cat, info, nick and so on.
[15:40] <siretart> is your script for package maintenance?
[15:40] <Lo-lan-do> More or less.  I use it to prepare packages of patched apps for clients.
[15:41] <siretart> hm. in that case, you could perhaps add some more magic into the bzr-builddeb plugin
[15:41] <Lo-lan-do> I'd rather keep it generic.
[15:42] <Lo-lan-do> 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] <thrope> is there any documentation for bzr-svn? I have having trouble finding anything except the faw
[15:47] <thrope> 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] <Lo-lan-do> Besides, I would honestly prefer keeping my shell script and have it run faster :-)
[15:47] <Lo-lan-do> thrope: bzr viz, in the gtk plugin
[15:48] <Lo-lan-do> As for bzr-svn, it's supposed to be "transparent"
[15:48] <thrope> Lo-lan-do: ah - how to i 'activate' the plugin (I installed it but get error with bzr viz)
[15:48] <thrope> 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] <bob2> bzr push svn//url
[15:49] <thrope> oh - it won't store it anywhere?
[15:49] <bob2> push doesn't default the url the branch was branched from
[15:49] <bob2> it will once you specify it once
[15:49] <thrope> oh
[15:49] <thrope> right
[15:49] <bob2> (this is a debated feature)
[15:49] <Lo-lan-do> I use a checkout (bound branch) for that.
[15:50] <Lo-lan-do> But that's nothing to do with svn :-)
[15:50] <thrope> any idea what this means? http://pastebin.com/m646013ae
[15:51] <thrope> and how can I activate bzr viz?
[15:52] <bob2> you don't activate plugins
[15:52] <bob2> just install them
[15:53] <bob2> (ie put or symlink the dir into ~/.bazaar/plugins)
[15:54] <thrope> ah - i thought it was in bzrtools package but its in bzr-gtk... I'm on a mac so it's kind of a pain to install all of gtk - is there no console tool?
[15:55] <thrope> re: the error - when I try and rebase it says "no revisions to rebase"
[15:56] <bob2> did you find the bz-svn page on the wiki?
[15:56] <thrope> bob2: yes but it doesn't have much info - just about installation
[15:58] <awilkins> bzr-curses might be welcomed by some, I suppose
[15:59] <awilkins> How about qbzr, thrope?
[15:59] <awilkins> Is Qt4 hard to get on Mac?
[15:59] <awilkins> qlog is arguably much nicer than viz
[15:59] <thrope> its easy enough to get stuff through macports - it just takes ages to compile
[16:00] <Verterok> heya
[16:00] <awilkins> Isn't there a mpkg for qt though ?
[16:00]  * awilkins has no mac
[16:00] <Verterok> thrope: there is no need to compile Qt4
[16:01] <thrope> anyway it doesn't really matter if I can't use it with svn - I'm just playing to try it out but can't seem to commit anyc hanges made in bazaar to a svn repo
[16:02] <thrope> no one has any idea what that error means?
[16:02] <awilkins> jelmer is the expert
[16:03] <thrope> i just made a toy repo for testing - checked out in bazaar, made some changes, meanwhile made some changes in svn and commited - and now I'm stuck
[16:04] <awilkins> I think it's probably the "toy" nature of the repo - is all the content in the root?
[16:04] <awilkins> I think it works best with a project/trunk;tags;branches layout
[16:04] <thrope> yeah
[16:04] <thrope> all content in root
[16:06] <Verterok> thrope: did you tried with dpush?
[16:06] <thrope> no - what is dpush
[16:06] <thrope> rats i just deleted the dir to try with trunk/tags/branch etc
[16:07]  * Verterok is not an bzr-svn expert :)
[16:07] <Verterok> thrope: a command provided by vzr-svn
[16:07] <Verterok> bzr-svn
[16:09] <quicksilver> Would be nice if you could re-merge into an uncommited merge
[16:09] <quicksilver> (to merge another revision)
[16:11] <thrope> seemed to work now - don't know what went wrong the first time
[16:11] <thrope> maybe it was being the root of the repo
[18:06] <seb_kuzminsky> what did i just do to my svn repo...
[18:06] <seb_kuzminsky> i'm using bzr, bzr-svn, and loom, all on intrepid
[18:06] <seb_kuzminsky> i've branched a big svn repo into a local bzr repo
[18:07] <seb_kuzminsky> i loomified my local branch and hacked for a while
[18:07] <seb_kuzminsky> meanwhile others were committing to the svn repo
[18:07] <seb_kuzminsky> finally i went down to my bottom thread and ran bzr pull to get their commits
[18:08] <seb_kuzminsky> then i went up on thread, and it showed all their commits as M - modified files (ie, it looks like a merge, not a pull)
[18:08] <seb_kuzminsky> i committed in the next-to-bottom thread and pushed....
[18:08] <rockstar> seb_kuzminsky, yea, so you'll have to merge those into your thread.
[18:09] <seb_kuzminsky> now when i look at the svn repo (with the svn program, not bzr), it looks like all the other peoples' commits are gone, and instead is the merge i did in my thread...
[18:10] <seb_kuzminsky> all their commits replaced by one commit of mine, with the log message "merge"...
[18:15] <seb_kuzminsky> svn thinks /trunk got replaced (svn log shows "R /trunk") at the place where my first thread-commit went in
[18:18] <seb_kuzminsky> guess i'll open a bug report
[19:22] <bpierre> hi
[22:26] <lifeless> jelmer: there is a thread on list you should read :P - 'lost commits in our repo' (its bzr-svn w/ bzr-loom)
[22:30] <seb_kuzminsky> i'm the OP on that thread, i'm here and i can answer questions about the problem for the next few minutes before i have to leave
[22:31] <seb_kuzminsky> lifeless: you didnt think you were rid of me did you :-P
[22:36] <lifeless> seb_kuzminsky: I hoped not :>
[22:36] <lifeless> jam: btw the pyrex iter_changes merge blocks the other too
[22:36] <lifeless> s/too/two/
[22:36] <lifeless> jam: do you want to review the __next__, or would you rather I nag someone to review that part?
[22:38] <jam> lifeless: yeah, I know that. I just got to the easy ones. My son has an ear infection so I got little sleep and I'm maybe 50% time working today
[22:38] <jam> depends when he sleeps
[22:38] <jam> I do have it on my TODO
[22:38] <lifeless> jam: thanks; I'm not meaning to pressure, just didn't want to be nagged about the approved ones either :P
[22:40] <jam> spiv: if you are interested, my personal vote on "thing to do next" is "bzr up" over bzr+ssh. Even when it is a no-op it takes like 10s here to Launchpad.
[22:40] <jam> which is a bit of a pain for the packaging. It could just be LP handshaking being slow
[22:47] <jam> uh-oh.... something we did recently broke "bzr revert" on win32
[22:47] <jam> I now *always* get "Could not acquire lock"
[22:48] <jam> And I can't reallly revert to find out when that happened :)
[22:49] <AfC> jam: not to worry. There's always reformatting the drive... :)
[22:49] <jam> AfC: I have about 10 copies of bzr on this machine, I can just switch :)
[22:50] <jam> not to mention "bzr branch" still works
[22:50] <jam> just odd
[22:51] <jam> ok, weird. Doing plain "bzr revert" fails, but "bzr revert -r -1" works, at least that gives me somewhere to point to
[22:54] <lifeless> jam: bet you its taking out a lock earlier
[22:54] <jam> luks: It seems to be your fault :)
[22:54] <jam> lifeless: yeah, rev 3733: fix bzr st -rbranch:path-to-branch (Lukas Lalinsky)
[22:55] <spm> is there a way to do a 'bzr cp'? Like 'bzr mv', but end up with two files that at some point in history were one?
[22:56] <lifeless> spm: 'bzr branch'
[22:56] <jam> lifeless: the problem is that "bzr revert" no args, is not using "tree.basis_tree()" and probably that is a DirStateRevisionTree, which is then getting ".lock_read()"
[22:56] <lifeless> spm: (no, its a desired feature, see under TIME)
[22:56] <jam> before the actual working tree is getting .lock_write()
[22:57] <spm> lifeless: ta (again :-) ). isn't a major issue, but would have been a nice touch of sugar.
[23:08] <AfC> spm: I ran into wanting that not too long ago myself.
[23:25] <jam> lifeless: best help ever: http://docs.python.org/dist/module-distutils.extension.html
[23:25] <jam> So much information there, I don't know what to do :)
[23:31] <lifeless> jam: :>
[23:31] <lifeless> jam: what are you working on?
[23:37] <abadger1999> jam: If you're not being sarcastic, that would make that the only distutils page that's helpful :-)
[23:38]  * abadger1999 is migrating all his code to paver
[23:41] <jam> abadger1999: considering it is a single line of documentation, I'm probably being sarcastic :)
[23:41] <jam> lifeless: I'm trying to review your patch, and I figured getting it *compiling* on win32 might be a good first step
[23:42] <AfC> Compile-driven development. It's the latest vogue in testing.
[23:42] <abadger1999> heh.  That figures
[23:43] <lifeless> jam: sweet
[23:44] <jam> AfC: there are some that feel if your code is statically typed enough, compiling *is* correctness :)
[23:44] <lifeless> they are wrong :P
[23:45] <jam> typedef one int; typedef two int; ...
[23:45] <jam> :)
[23:47] <poolie> hello all
[23:48] <jam> Isn't  Verterok == Guillermo Gonzales?
[23:48] <jam> I'm trying to answer https://answers.edge.launchpad.net/bzr/+question/46326
[23:48] <lifeless> jam: yes
[23:48] <jam> And ISTR that it was supposed to be fixed in xmloutput
[23:48] <jam> poolie: morning