| 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:08 |
|---|---|---|
| === mw is now known as mw|out | ||
| 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:12 |
| 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:14 |
| Peaker | merge directive? | 00:15 |
| abentley | Merge directives are recipes for merging someone's changes. They are created by the "send" command. | 00:46 |
| 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:47 |
| abentley | fullermd: I wish you wouldn't be so snarky. | 00:49 |
| fullermd | Eh. That was more whistling in the dark. I'm too tired this week to work up good snark :| | 00:51 |
| 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:55 |
| fullermd | I wasn't aware that I was. I didn't intend to be. | 00:56 |
| 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. | 00:57 |
| Peaker | what is rspush good for? | 01:09 |
| Peaker | (in bzrtools) | 01:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| abentley | You run "bzr send --mail-to email@example upstream_branch". You don't need to merge in advance. | 01:17 |
| 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:18 |
| Peaker | is "bzr patch" smarter than patch? Looks at metadata for extra information? | 01:21 |
| 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:30 |
| abentley | bzr patch is not smarter in the way you're thinking. | 01:31 |
| 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:32 |
| abentley | PQM does not use merge directives yet, but we plan to update it. | 01:33 |
| 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:34 |
| Verterok | Hi all | 01:51 |
| coffeedude | lifeless: Thanks for the tarball. Grabbing it now. | 02:35 |
| bialix | hi! lifeless here? | 04:56 |
| bialix | it seems like PQM is not working | 04:56 |
| lifeless | a/away | 12:58 |
| lifeless | bleh | 12:58 |
| lifeless | moin | 12:58 |
| Peaker | abentley: thanks, I was already in bed by the time you replied there :) | 13:07 |
| ree | Hi! | 13:36 |
| ree | Is is possible to use a bazaar branch directly from easy_setup like in svn? (http://....#egg=...) ? | 13:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 | |
| 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:43 |
| bitmonk | which are sort of lazy, b/c they are doing Product checkouts | 13:45 |
| 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 | 13:46 |
| keir | is anyone other than bzr using patience diff? | 14:56 |
| Peng | I wish they would. | 15:01 |
| fullermd | I think someone else was. | 15:02 |
| fullermd | cdv, maybe. | 15:03 |
| Peng | Oh, yeah, it probably does, since Bram Cohen invented them both. | 15:03 |
| Peng | Anyone know how to get 'python -m bzrlib.patiencediff' to run on a directory instead of just a file? | 15:04 |
| jam-laptop | Peng: adding a --recursive flag to patiencediff.py wouldn't be too hard, or you could just do it with shell tricks | 15:59 |
| Peng | Yeah, it would probably be pretty easy with some shell trick, but I haven't wanted to bother. | 16:01 |
| 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:04 |
| 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:05 |
| 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:06 | |
| keir | peng, why hg instead of bzr? | 16:07 |
| 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:10 |
| 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:12 |
| keir | heh, yup, 41 seconds for 11 revs on bzr.dev | 16:14 |
| Peng | Smarter index access sounds good. How much does it have to transfer to find the new revisions? | 16:15 |
| dato | Peng: well, hg does not use a dumb transport. | 16:35 |
| 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. | 16:38 |
| Peng | s/benefit/advantage/ | 17:07 |
| lifeless | ree: setuptools can use bzr | 17:17 |
| 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:46 |
| 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:48 |
| Peng | Well, anyway, this isn't helpful. | 17:49 |
| mneisen | Peng: Well, apt-get tells me the following: http://paste.ubuntu-nl.org/43030/ | 17:59 |
| Peng | I guess Ubuntu upgrades bzr more quickly than bzrtools. | 18:00 |
| 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:02 |
| james_w | (not ruling out exceptions being the norm up to this point). | 18:03 |
| james_w | mneisen: you should just wait. | 18:03 |
| 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:04 |
| 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:05 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| james_w | that's fine. I'm going anywhere. | 18:14 |
| AnMaster | nor am I | 18:14 |
| AnMaster | ah | 18:19 |
| AnMaster | http://pastebin.ca/758938 | 18:19 |
| AnMaster | james_w, ^ | 18:19 |
| AnMaster | james_w, well? | 18:27 |
| AnMaster | guess I won't get help then | 18:50 |
| james_w | AnMaster: no need to be like that. | 18:52 |
| 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:53 |
| james_w | no, it is your branch I see.# | 18:54 |
| james_w | so you can try 'bzr break-lock URL'. | 18:54 |
| 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:55 |
| 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:56 |
| AnMaster | james_w, any way to turn off the ~/.bzr.log, I can't afford that space | 18:57 |
| AnMaster | james_w, but here is the end of it http://pastebin.ca/758981 | 18:58 |
| james_w | I'm not sure about turning it off, it is limited in size, but I am not sure about the size. | 19:00 |
| 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:01 |
| james_w | AnMaster: you should be ok now then, I'll file some bugs for you. | 19:03 |
| === asak_ is now known as asak | ||
| 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:15 |
| james_w | ah, thanks jam-laptop | 19:17 |
| james_w | if size <= 4 << 20: | 19:17 |
| james_w | that seems rather large | 19:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| === tchan1 is now known as tchan | ||
| 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:27 |
| 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:28 |
| 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:29 |
| 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:31 |
| 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:40 |
| 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 | 19:48 |
| jam-laptop | Peng: I think you'll find you get more than enough to read from the bazaar mailing list | 20:22 |
| jam-laptop | I currently have 4.4k messages since 8/1 | 20:23 |
| === asak_ is now known as asak | ||
| jam-laptop | and 31,376 in my "archive" folder that goes back to 2005-05-08 | 20:27 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| jam-laptop | well http://dir.gmane.org/gmane.comp.version-control.bazaar-ng.general is a nice graph of it | 20:39 |
| jam-laptop | peaking at close to 60 per day | 20:40 |
| jam-laptop | I have the feeling that the last dip was when I was on paternity leave | 20:41 |
| jam-laptop | I'm completely wrong, the dip I see was caused by our last conference | 20:45 |
| jam-laptop | around 5/26 | 20:47 |
| === cfbolz_ is now known as cfbolz | ||
| dato | siretart: okay, found time right now to upload. I hope you don't mind I use my name for the changelog :) | 21:30 |
| dato | siretart: btw, I'm retrospectively adding a tag for 0.91-2 :) | 21:31 |
| 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 | 21:59 |
| dato | jelmer: "Depends: bzr (>= 0.92~), bzr (<< 0.92~)" <-- s/92/93/ (the second one)? | 22:07 |
| jelmer | euhm, yep! | 22:08 |
| dato | all uploaded. | 22:12 |
| jelmer | dato: thanks very much | 22:12 |
| dato | jelmer: np | 22:13 |
| 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:14 |
| dato | rather than only: | 22:15 |
| dato | * New upstream release (Closes: #1234) | 22:15 |
| * dato leaves now. | 22:16 | |
| jelmer | dato: Ok, I'll keep that in mind fior next time | 22:34 |
| jelmer | thanks | 22:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!