[00:08] Peaker: When you pull into a branch where you've been making changes, your changes stop being shown as the mainline. We don't think this is a good default. === mw is now known as mw|out [00:12] abentley: I am not sure what you mean, I was just wondering about the best method to review someone's changes [00:12] to accept/reject them [00:14] I would generally merge them, then use diff or cdiff. [00:14] That is, if they haven't sent you a merge directive. [00:15] merge directive? [00:46] Merge directives are recipes for merging someone's changes. They are created by the "send" command. [00:47] They typically include a bundle of revisions in case you don't have them. [00:47] Unless you make them with bundle --no-bundle! :> [00:49] fullermd: I wish you wouldn't be so snarky. [00:51] Eh. That was more whistling in the dark. I'm too tired this week to work up good snark :| [00:55] Well, I put in a lot of thought and effort, and it's not fun having you be constantly critical of my work. [00:56] I wasn't aware that I was. I didn't intend to be. [00:57] I always found it mildly amusing that you were so against that command combo; that's the sort of vague nonsense I always find fun in tools. [00:57] You go on and on about rollup formats. Now you mock the bundle --no-bundle thing. And there are others I don't remember right now. [01:09] what is rspush good for? [01:09] (in bzrtools) [01:10] Most of the time, not much. [01:10] There are a few users, so I'm actually updating it right now. [01:10] But you're generally better off with push. [01:11] Unless rsync is the only supported protocol. And even then, it doesn't work with shared repositories. [01:11] It does push WT's though, right? I think that's the big thing people want from it... [01:12] Or was that the other rsync-push plugin? [01:12] why is send/bundle useful? Why not merge locally and push? [01:12] fullermd: You're right, it does do trees by default. [01:13] Yeah, that's a plus. Sadly, it seems like there are a surprising number of people who come in here asking for tree-pushing, when they only have FTP access. It's like waking up in the middle ages. [01:14] push requires you to publish a branch, which is a higher barrier than just sending an email. Send works especially well with email, so it's great for mailing lists. [01:15] abentley: so its basically a way to allow bzr over email? [01:15] how does it generate the merge directive? Do you first merge, and then send instead of commit? [01:17] You run "bzr send --mail-to email@example upstream_branch". You don't need to merge in advance. [01:18] it will work under the same predicate as push would, and then it generates the diff? if not, how does it resolve the merges required? [01:18] also, is this how you ask pqm to merge things? [01:21] is "bzr patch" smarter than patch? Looks at metadata for extra information? [01:30] Peaker: No, the upstream_branch is the branch that you want someone else to merge your changes into. [01:30] For me, this is typically http://bazaar-vcs.org/bzr/bzr.dev [01:30] But I use a local mirror, of course. [01:31] bzr patch is not smarter in the way you're thinking. [01:32] It's better because it auto-detects the branch root and applies the changes there, and because it can download a patch from a URL. [01:33] PQM does not use merge directives yet, but we plan to update it. [01:34] You apply a merge-directive with "bzr merge" or "bzr pull". The machine-readable portion of the merge directive is used for merging. The patch is mainly for human eyes. [01:51] Hi all [02:35] lifeless: Thanks for the tarball. Grabbing it now. [04:56] hi! lifeless here? [04:56] it seems like PQM is not working [12:58] a/away [12:58] bleh [12:58] moin [13:07] abentley: thanks, I was already in bed by the time you replied there :) [13:36] Hi! [13:37] Is is possible to use a bazaar branch directly from easy_setup like in svn? (http://....#egg=...) ? [13:38] ree: you'd probably have to extend setuptools somehow.. [13:38] i was actually thinking of patching setuptools and some buildout recipes to try and use bzr to checkout svn repos with bzr-svn.. [13:39] allright... there is setuptoolsbzr that allows easysetup to use bazaar branches in dependency_links [13:39] really? i'll have to check that out.. [13:40] but that indeed does not help with buildout [13:40] it's on launchpad [13:40] well, the buildout recipes i've seen are just calling svn command [13:40] so i say start there, just call bzr command, then when you have time, go back and try to use the python apis directly [13:41] with buildout I've seen it done with Makefile, that uses bzr directly. but the ideal would be if setuptools could use a bzr source directly [13:41] svn isn't written in python, but it's not like there aren't python apis. nothing wrong with os.system() in a buildout recipe.. [13:41] yesh that would be ideal.. [13:41] ah you want it for eggs, duh [13:41] os.system->subprocess.call :-) [13:41] * bitmonk salutes [13:43] bitmonk, if it worked for setuptools, it would natively work with buildout without need to support it fromwithin [13:43] [13:43] yeah [13:43] i'm thinking like plone.recipe.bundlecheckout [13:43] or .distros maybe [13:45] which are sort of lazy, b/c they are doing Product checkouts [13:46] anyway, let me know how your journey with setuptools and bzr goes, esp if i can help test.. [13:46] maybe once i finish this server migration i'll take a look at setuptoolsbzr at least [14:56] is anyone other than bzr using patience diff? [15:01] I wish they would. [15:02] I think someone else was. [15:03] cdv, maybe. [15:03] Oh, yeah, it probably does, since Bram Cohen invented them both. [15:04] Anyone know how to get 'python -m bzrlib.patiencediff' to run on a directory instead of just a file? [15:59] Peng: adding a --recursive flag to patiencediff.py wouldn't be too hard, or you could just do it with shell tricks [16:01] Yeah, it would probably be pretty easy with some shell trick, but I haven't wanted to bother. [16:04] It would have to be modified to accept a file existing in one directory and not in the other, wouldn't it? [16:04] well, you would have to write some loops that recurse through the directories [16:04] and that is where you would look for one-side but not the other [16:05] oh, if you mean in shell... yeah [16:05] It would be tricky to get it right in shell, and have it detect present/missing on both sides [16:05] I didn't mean in the shell. [16:05] we really need a page of 'compelling reasons to use bzr' instead of git/hg... patience diff should go on there! [16:06] Well, once patiencediff.py is changed to support directories, it could be used by hg's extdiff extension. That's the reason I'm interested in it. :P [16:06] * Peng hides. [16:07] peng, why hg instead of bzr? [16:10] keir: I personally use it over bzr because of speed. Bzr has recently caught up, but I don't want to go through the hassle of switching back. Also, I doubt bzr's network performance is up to hg's. [16:10] keir: Even if I didn't, there are projects I'm interested in that use hg, so it would be nice to have a non-sucky diff algorithm there. [16:12] (It takes like 2 minutes to pull a dozen new revisions of bzr.dev. Yikes. It'd probably take 3 seconds with hg. But that's with a dumb server.) [16:12] Peng, no argument there. packs help that. [16:12] Peng, the next pack refresh should have a smarter dumb protocol index too [16:14] heh, yup, 41 seconds for 11 revs on bzr.dev [16:15] Smarter index access sounds good. How much does it have to transfer to find the new revisions? [16:35] Peng: well, hg does not use a dumb transport. [16:38] dato: Yeah, that's what I meant. [16:38] dato: I didn't contruct the sentences well, but that's what I meant. hg has the benefit of a smart server. [17:07] s/benefit/advantage/ [17:17] ree: setuptools can use bzr [17:46] Hi, i use bzr and bzrtools on Ubuntu. My problem: bzr is always released well before bzrtools, so apt wants to upgrade bzr and remove bzrtools. Is there any way to solve this? [17:48] I haven't seen bzr get released before bzrtools. [17:48] Except for bzr 0.92rc1 being out for a like week before bzrtools 0.92.0, but 0.92rc1 is only a release candidiate. [17:49] Well, anyway, this isn't helpful. [17:59] Peng: Well, apt-get tells me the following: http://paste.ubuntu-nl.org/43030/ [18:00] I guess Ubuntu upgrades bzr more quickly than bzrtools. [18:02] Peng: it is an exception this time hopefully. [18:02] the aim is to upload them together, but this time bzrtools was later than the rc, and other things have now got in the way. [18:03] (not ruling out exceptions being the norm up to this point). [18:03] mneisen: you should just wait. [18:04] james_w: Will do. [18:04] great. [18:04] james_w: Thanks for the info. [18:04] james_w: Any guess when bzrtools will be out? [18:04] no problem. You can expect bzrtools to be updated on tuesday or wednesday hopefully. [18:04] james_w: Alternatively: Is there a way to "block" updates in apt-get? [18:04] you can pin the package. [18:05] google for "apt pinning", I can't remember how to do it now. [18:05] james_w: Thanks again. [18:05] alternatively you can use aptitude and put the package on hold. [18:08] Using saved location: bzr+ssh://anmaster@bazaar.launchpad.net/~anmaster/envbot/module-help/ [18:08] No handlers could be found for logger "bzr" [18:08] bzr: ERROR: Could not acquire lock "(remote lock)" [18:08] sigh, what is going on, #launchpad ppl redirect me here [18:08] damn, I was going to point you there. [18:08] I don't have any problem with other servers [18:09] The "No handlers" thing is known and shouldn't cause this issue. [18:09] james_w, well, I can push with bzr+ssh just fine to other servers [18:10] and since I got redirected here.... [18:10] can you run using "bzr -Derror" please? [18:10] sure [18:10] and paste the result. [18:10] just that or the push bit too? [18:11] sorry? [18:11] bzr -Derror push or just bzr -Derror ? [18:11] 'bzr -Derror -Dhpss -Dlock push' please [18:11] ah ok [18:12] that should tell us what is happening [18:12] sure will pastebin [18:12] -Dwhatever turns on debugging output of a certain type. [18:12] it takes a while before it errors out [18:12] maybe 5-10 minutes [18:12] between the "No handlers could be found for logger "bzr"" [18:12] and the next line [18:14] that's fine. I'm going anywhere. [18:14] nor am I [18:19] ah [18:19] http://pastebin.ca/758938 [18:19] james_w, ^ [18:27] james_w, well? [18:50] guess I won't get help then [18:52] AnMaster: no need to be like that. [18:53] ok :) [18:53] problem is I got to leave soon :/ [18:53] sorry for ignoring you though. [18:53] It is raising LockContention, suggesting the lock is held. [18:53] Is anyone else going to be pushing? [18:54] no, it is your branch I see.# [18:54] so you can try 'bzr break-lock URL'. [18:55] also if you could post the end of '~/.bzr.log' that would allow me to confirm. [18:55] james_w, can't be anyone else as far as I know, it is a private branch but I will try [18:56] ouch that file is nearly 50 MB, that is nasty [18:56] james_w, break-lock reported 2 locks that I broke [18:56] but why is '~/.bzr.log' so huge [18:56] for another account it is over 250 MB [18:57] james_w, any way to turn off the ~/.bzr.log, I can't afford that space [18:58] james_w, but here is the end of it http://pastebin.ca/758981 [19:00] I'm not sure about turning it off, it is limited in size, but I am not sure about the size. [19:01] james_w, well for another account it was 250 MB [19:01] doesn't seem limited to me [19:01] Yeah, it should auto-rotate long before it gets near that big. [19:01] * AnMaster symlinks to /dev/null for now [19:01] Weird. But yah, I've got it /dev/null linked in some places too. [19:03] AnMaster: you should be ok now then, I'll file some bugs for you. === asak_ is now known as asak [19:15] If he is pushing to launchpad, the "no loggers found" is actually an LP smart server bug [19:15] it means the bracnh is already locked [19:15] New bug: #159589 in bzr "LockContention has unhelpful text" [Undecided,New] https://launchpad.net/bugs/159589 [19:15] unfortunately it isn't being sent to the user [19:17] ah, thanks jam-laptop [19:17] if size <= 4 << 20: [19:17] that seems rather large [19:18] james_w: it rotates when it gets to 4MB [19:18] but it only rotates at the beginning [19:18] so if a single bzr action builds 250MB then it takes 2 rotations to go away [19:18] (It goes to .old [19:18] and then then new one overrwrites .old) [19:19] Some actions log more than others. [19:19] Off-hand i think "bzr add + bzr commit" might print out a line for each file [19:20] If you run a converter... that is one of the bigger ones [19:20] I'm not sure about bzr-svn [19:20] lifeless: any chance you could check on pqm? It seems to be stopped [19:23] jam-laptop: not sure about what? [19:23] jelmer: how much stuff it dumps in ~/.bzr.log [19:23] Especially on first push/pull [19:24] jam-laptop: less than 10 lines during connect, etc [19:24] Nothing about what files it finds, or revision, etc? [19:24] jam-laptop: and one line for special cases when pulling changes [19:24] jam-laptop: what branching scheme it's going to use mainly [19:25] more verbose data can be enabled using -Dtransport and -Dcommit [19:25] not a big deal. I just know that my converters would spew quite a bit into ~/.bzr.log, and it might be something to consider about bzr-svn [19:25] -Dcommit for push/pull [19:25] (well, *not* spitting out a lot) [19:25] jelmer: is -D printing to the screen, or only to the log [19:26] jam-laptop: only to the log [19:26] to the screen would mess with the progress bar [19:26] jam-laptop: sure === tchan1 is now known as tchan [19:27] jam-laptop: looks ok [19:27] hmm.. both bialix and vila have had problems submitting [19:27] I haven't tried anything myself [19:28] ok, found the issue [19:28] it's being rectified by is now. [19:28] upstream ISP did naughty stuff to our network [19:28] thanks [19:28] ouch [19:29] didn't like you using 7GB/s for so long? [19:29] well, that is probably 7Gb/s [19:29] plugged a cable where it shouldn't be; knock on effects lead to our mail feedb being disabled. [19:31] jam-laptop: I'm offline again for some time LEAN traininig; please phone me or poolie on further issues. [19:31] k [19:40] Woah, I have 65 messages from the mailing list in my inbox from after I signed up but before I set up procmail to filter it to another folder. Whee, something to read. [19:48] jelmer: thanks for fixing bug #159111 [19:48] Launchpad bug 159111 in bzr-svn "bzr-svn can't push, commit to rebound SVN repository" [High,Fix released] https://launchpad.net/bugs/159111 [20:22] Peng: I think you'll find you get more than enough to read from the bazaar mailing list [20:23] I currently have 4.4k messages since 8/1 === asak_ is now known as asak [20:27] and 31,376 in my "archive" folder that goes back to 2005-05-08 [20:34] I currently have...167. [20:34] That's close to 31,376. [20:34] I didn't know the list was nearly this busy. [20:34] usually less than 2,000 messages per month, 1k is probably average [20:34] Well, this is the week to catch up, while half the list members are off being meetingly. [20:35] fullermd: next week will be even more so [20:35] As I go to the conference [20:35] This week was UDS [20:35] next week is AllHands [20:35] Peng: and that doesn't count the "bazaar-commits" list, or the bug list [20:35] I don't archive the bug list [20:35] Yeah, so next week there will be about 6 mails. The whole week :p [20:35] but sometimes it can be as active as bazaar@ [20:36] Fortunately, I'm on enough other lists to sustain me through these hard times, when I run out of mail reading and have nothing to do but get work done. [20:37] fullermd: yeah, I used to be on a whole bunch of lists, until it just became too much [20:37] having BundleBuggy actually contributes to a bit of bloat for number of emails [20:38] as it likes to send at least 1 extra email per submission [20:38] Handy for traffic analysis, though. [20:38] I've got an xbuffy watching my bzr mailbox, and when it suddenly jumps by 2 in a sample period (30 seconds), I know somebody posted a [merge]. [20:39] well http://dir.gmane.org/gmane.comp.version-control.bazaar-ng.general is a nice graph of it [20:40] peaking at close to 60 per day [20:41] I have the feeling that the last dip was when I was on paternity leave [20:45] I'm completely wrong, the dip I see was caused by our last conference [20:47] around 5/26 === cfbolz_ is now known as cfbolz [21:30] siretart: okay, found time right now to upload. I hope you don't mind I use my name for the changelog :) [21:31] siretart: btw, I'm retrospectively adding a tag for 0.91-2 :) [21:59] dato: if you're going to upload 0.92rc1, please also upload bzr-rebase 0.2 and bzr-svn 0.4.4 [21:59] if possible [21:59] jelmer: sure [21:59] I should have some minutes left for that right now [22:07] jelmer: "Depends: bzr (>= 0.92~), bzr (<< 0.92~)" <-- s/92/93/ (the second one)? [22:08] euhm, yep! [22:12] all uploaded. [22:12] dato: thanks very much [22:13] jelmer: np [22:14] jelmer: a small remark: it's considered good practice, when closing in debian/changelog upstream bugs closed in a new relesae, to say: [22:14] * New upstream release: [22:14] + no longer frobnicates your files when bar is set. (Closes: #1234) [22:15] rather than only: [22:15] * New upstream release (Closes: #1234) [22:16] * dato leaves now. [22:34] dato: Ok, I'll keep that in mind fior next time [22:34] thanks