| lifeless | jml: hi | 00:01 |
|---|---|---|
| * jml waves hello | 00:07 | |
| jml | lifeless: are you waiting on anything from me for the testresources merge? | 00:08 |
| lifeless | no | 00:09 |
| lifeless | just time | 00:09 |
| jml | ok. | 00:09 |
| lifeless | jam: ping | 00:14 |
| poolie | re.search(r'^(?!Bazaar)', 'Bazaar') | 00:23 |
| 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:24 |
| 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:25 |
| lifeless | so | 00:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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 | 00:34 |
| lifeless | chore to run, brb | 01:18 |
| abentley | poolie: Do you want to talk about reivews now? | 01:25 |
| jam | lifeless: ping for great justice | 01:35 |
| poolie | abentley, sure, if you want to | 01:43 |
| abentley | poolie: I think this is the day we planned to. So let's. | 01:43 |
| lifeless | jam: I've replied in mail | 01:44 |
| jam | lifeless: yeah. It sure looks like you wanted to vote in there :) | 01:44 |
| jam | lifeless: I replied to you. And basically I think we are in agreement. | 01:45 |
| lifeless | jam: ok, cool then | 01:47 |
| lifeless | I'd approved previously, consider it reinstated | 01:47 |
| === dereine is now known as dereine[afk] | ||
| lifeless | igc: you should upgrade http://bazaar.launchpad.net/%7Eian-clatworthy/bzr-usertest/trunk/. | 03:11 |
| lifeless | abentley: around ? I'd like to run an idea past you | 03:36 |
| abentley | lifeless: okay | 03:37 |
| lifeless | this is about rich roots. | 03:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| lifeless | abentley: uhm, wasn't that your idea though? | 03:43 |
| 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:45 |
| 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:46 |
| abentley | So would you have any hesitation about making 1.6-rich-root our next default format? | 03:47 |
| lifeless | abentley: my set of concerns is ([has-the-sha1-thing-been-fixed, how-will-users-find-the-change]) | 03:48 |
| 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:49 |
| lifeless | abentley: there is an outstanding patch of yours; I'll poke around at the sha1 code in the near future and see | 03:50 |
| 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:51 |
| 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:53 |
| 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:54 |
| lifeless | we have that shiny new machien | 03:55 |
| abentley | So possibly a torture-test would be useful. Bazaar itself was pretty tortuous. | 03:58 |
| 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. | 03:59 |
| abentley | This doesn't prevent revisions with bad sha1s from being fetched, of course. | 04:01 |
| abentley | Does that remove your concerns about correctness? | 04:03 |
| abentley | lifeless: ^^^ | 04:03 |
| 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:11 |
| 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:33 |
| lifeless | abentley: which basically means that any file we write we usually can't put in the stat cache | 04:34 |
| abentley | lifeless: do renames update the stat values used? | 04:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:41 |
| 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:42 |
| lifeless | abentley: possibly just make _observed_sha1 take a list of tuples | 04:43 |
| 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:15 |
| Peng_ | ReachingFarr: That's exactly what the "push" command is for. | 05:16 |
| Peng_ | ReachingFarr: Have you been reading a tutorial? | 05:16 |
| 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:17 |
| 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:18 |
| 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:20 |
| fullermd | 1.5 isn't that old. I'm not sure much has changed in auth since then. | 05:24 |
| fullermd | (updating is a good idea in general, of course. But I don't think it'll fix this) | 05:25 |
| Peng_ | ReachingFarr: Do you have FTP or SFTP access to your server? That might be easier to use than HTTP auth. | 05:27 |
| 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:28 |
| fullermd | Dreamhost? You can set up the smart server on Dreamhost? | 05:29 |
| Peng_ | fullermd: I wouldn't recommend it due to procwatch. | 05:29 |
| Peng_ | ReachingFarr: Well, DH offers SFTP access, but your user may not be configured to allow it. Try it, or ask your friend. | 05:30 |
| fullermd | Well, that was somewhat my point... | 05:31 |
| 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:32 |
| 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:38 |
| seb_kuzminsky | what i mean is, is it possible? | 05:40 |
| Peng_ | seb_kuzminsky: Check out the bzr-svn plugin. But yes, you're probably crazy. :P | 05:45 |
| 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:46 |
| Peng_ | Sounds about right. | 05:47 |
| seb_kuzminsky | i branched locally, checked out, and loomified and we'll see what happens next ... | 05:47 |
| ReachingFarr | fullermd: http://pastebin.com/d5317e471 | 05:50 |
| fullermd | Well, that's pretty wacky. | 05:51 |
| fullermd | vila: ^^^ | 05:51 |
| 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:52 |
| seb_kuzminsky | what does 'bzr record' do? i dont understand the --help message | 05:56 |
| seb_kuzminsky | a thread has a "tip", but what does that mean? | 05:59 |
| 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:01 |
| seb_kuzminsky | if i 'bzr push' from a thread, will it also push all the threads below it? | 06:03 |
| 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:04 |
| 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:05 |
| seb_kuzminsky | lifeless: thanks! | 06:06 |
| seb_kuzminsky | is there something like 'bzr log' for 'record'? | 06:06 |
| 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:08 |
| 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:09 |
| seb_kuzminsky | hm, i think it just ate my changes (or i'm misunderstanding how to use it) | 06:10 |
| 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:11 |
| 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:12 | |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| Peng_ | If I do "from bzrlib import trace; trace.push_log_file(...)", will anything have been logged yet? | 06:20 |
| seb_kuzminsky | lifeless: when should i record? | 06:22 |
| spiv | Peng_: there was a patch about this to the list recently | 06:22 |
| 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:24 |
| 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:25 |
| 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:26 |
| seb_kuzminsky | http://pastebin.ca/1210326 | 06:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| seb_kuzminsky | thanks lifeless, see you later | 06:33 |
| markh | lifeless: revert, status and diff seem not to - is that a bug? | 06:35 |
| * beuno stabs beuno_ | 06:36 | |
| markh | dir | 06:36 |
| markh | heh | 06:36 |
| === beuno_ is now known as beuno | ||
| lifeless | markh: I'd say its a bug, yes | 06:38 |
| 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:41 |
| 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:42 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| lifeless | mmmm, I don't think we do. But YMMV | 06:48 |
| 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:49 |
| Peng_ | markh: I think someone sent a patch for that. Was it you? | 06:50 |
| markh | "update -r" - yeah | 06:50 |
| 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... | 06:51 |
| vila | hi all ! | 07:06 |
| vila | fullermd, ReachingFarr (actually he seems to be gone :-/): on that particular one (65 data rewind), I think spiv knows more than me | 07:07 |
| vila | I've never reproduced it so I don't know where to lookt at | 07:09 |
| Peng_ | spiv: OK, I've got it set up to my satisfcation (as far as I can tell) | 07:11 |
| 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:43 |
| beuno | pysquared, you can't currently, no | 07:44 |
| pysquared | Shame | 07:44 |
| 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:45 |
| beuno | feel free to add it | 07:46 |
| 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:48 |
| 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:49 |
| LarstiQ | if there isn't already one | 07:52 |
| 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:54 |
| 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:55 |
| lifeless | anyhow, /gone | 07:56 |
| 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:08 |
| 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 :) | 08:41 |
| === dereine[afk] is now known as dereine | ||
| Peng_ | spiv: There's a typo in your -Eallow_debug patch. It should be "sanitisation", not "santisation". | 09:10 |
| === dereine is now known as dereine[afk] | ||
| fullermd | That hardly sounds sanitized :p | 09:11 |
| Peng_ | Oh, my email client unfroze now. | 09:11 |
| spiv | Peng_: d'oh, thanks. | 09:11 |
| === dereine[afk] is now known as dereine | ||
| Peng_ | :) | 09:12 |
| spiv | vila: how's your patch to remove SmartClientMedium from RemoteTransport's set of base classes doing? | 09:14 |
| 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:15 |
| vila | my fault wrong subject it appears | 09:16 |
| vila | it's part of the python-2.6 compatibility RFC | 09:16 |
| 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:17 |
| spiv | Huh, interesting. | 09:18 |
| spiv | What's wrong with a circular reference? | 09:18 |
| 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:19 |
| vila | and is an attribute of the transport | 09:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| vila | so while the http 'channel' can be shared between transport/medium pairs, the base must be shared by each pair | 09:24 |
| 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:25 |
| 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:27 |
| poolie | vila, hi | 09:40 |
| poolie | how are you going? | 09:40 |
| strk | so, I have these two branches on two machines being both parented to the online one | 10:46 |
| 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:47 |
| strk | case-by-case means: sometime I want hostB to pull from hostA | 10:48 |
| Peng_ | strk: I guess you could keep a copy of the parent on one of the machines, then have the other pull from it. | 10:54 |
| 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:17 |
| jonnydee | re-checkingout the branch produces the same error in the new branch | 11:21 |
| 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:31 |
| 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:39 |
| === dereine is now known as dereine[afk] | ||
| 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:53 |
| poolie | hth | 11:54 |
| === 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 | ||
| pysquare1 | Hello. Is there a way to reconfigure a shared repository to have the --no-trees option? | 14:04 |
| 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:06 |
| 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:08 |
| === thekorn_ is now known as thekorn | ||
| === mw is now known as mw|out | ||
| _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 | 14:32 |
| 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:29 |
| 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:30 |
| Lo-lan-do | Has it been suggested that maybe not all of bzr needs to be loaded and initialized for each invocation? | 15:31 |
| 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:32 |
| 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:34 |
| Lo-lan-do | It's shell so far. | 15:35 |
| Lo-lan-do | Maybe "bzr shell" could help? | 15:35 |
| siretart | maybe, but I'm not familiar with 'bzr shell' | 15:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| thrope | is there any documentation for bzr-svn? I have having trouble finding anything except the faw | 15:43 |
| 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:47 |
| 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:48 |
| 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:49 |
| Lo-lan-do | But that's nothing to do with svn :-) | 15:50 |
| thrope | any idea what this means? http://pastebin.com/m646013ae | 15:50 |
| thrope | and how can I activate bzr viz? | 15:51 |
| bob2 | you don't activate plugins | 15:52 |
| bob2 | just install them | 15:52 |
| bob2 | (ie put or symlink the dir into ~/.bazaar/plugins) | 15:53 |
| 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:54 |
| thrope | re: the error - when I try and rebase it says "no revisions to rebase" | 15:55 |
| 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:56 |
| awilkins | bzr-curses might be welcomed by some, I suppose | 15:58 |
| 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 | 15:59 |
| 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:00 |
| 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:01 |
| thrope | no one has any idea what that error means? | 16:02 |
| awilkins | jelmer is the expert | 16:02 |
| 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:03 |
| 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:04 |
| 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:06 |
| * Verterok is not an bzr-svn expert :) | 16:07 | |
| Verterok | thrope: a command provided by vzr-svn | 16:07 |
| Verterok | bzr-svn | 16:07 |
| quicksilver | Would be nice if you could re-merge into an uncommited merge | 16:09 |
| quicksilver | (to merge another revision) | 16:09 |
| 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 | 16:11 |
| === mw|out is now known as mw | ||
| === _dereine is now known as dereine | ||
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| seb_kuzminsky | all their commits replaced by one commit of mine, with the log message "merge"... | 18:10 |
| seb_kuzminsky | svn thinks /trunk got replaced (svn log shows "R /trunk") at the place where my first thread-commit went in | 18:15 |
| seb_kuzminsky | guess i'll open a bug report | 18:18 |
| bpierre | hi | 19:22 |
| === abadger19991 is now known as abadger1999 | ||
| === thumper_laptop is now known as thumper | ||
| lifeless | jelmer: there is a thread on list you should read :P - 'lost commits in our repo' (its bzr-svn w/ bzr-loom) | 22:26 |
| 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:30 |
| seb_kuzminsky | lifeless: you didnt think you were rid of me did you :-P | 22:31 |
| 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:36 |
| 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:38 |
| 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:40 |
| jam | uh-oh.... something we did recently broke "bzr revert" on win32 | 22:47 |
| jam | I now *always* get "Could not acquire lock" | 22:47 |
| jam | And I can't reallly revert to find out when that happened :) | 22:48 |
| 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:49 |
| jam | not to mention "bzr branch" still works | 22:50 |
| jam | just odd | 22:50 |
| jam | ok, weird. Doing plain "bzr revert" fails, but "bzr revert -r -1" works, at least that gives me somewhere to point to | 22:51 |
| 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:54 |
| 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:55 |
| 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:56 |
| spm | lifeless: ta (again :-) ). isn't a major issue, but would have been a nice touch of sugar. | 22:57 |
| AfC | spm: I ran into wanting that not too long ago myself. | 23:08 |
| 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:25 |
| lifeless | jam: :> | 23:31 |
| lifeless | jam: what are you working on? | 23:31 |
| abadger1999 | jam: If you're not being sarcastic, that would make that the only distutils page that's helpful :-) | 23:37 |
| * abadger1999 is migrating all his code to paver | 23:38 | |
| 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:41 |
| AfC | Compile-driven development. It's the latest vogue in testing. | 23:42 |
| abadger1999 | heh. That figures | 23:42 |
| lifeless | jam: sweet | 23:43 |
| 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:44 |
| jam | typedef one int; typedef two int; ... | 23:45 |
| jam | :) | 23:45 |
| poolie | hello all | 23:47 |
| 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 | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!