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