[00:46] <lifeless> jam: the scanner dump just finished :)
[00:48] <lifeless> jam: 6.4G 2009-09-05 09:46 foo.json
[00:49]  * lifeless goes again
[02:07] <BasicOSX> bzr check, what does "inconsistent parents" mean?
[02:13] <poolie> BasicOSX: hi, it means there's a difference between the graph index and the parents recorded in the revisions
[02:13] <poolie> reconcile should fix it
[02:16] <BasicOSX> https://bugs.launchpad.net/bzr/+bug/418492 is bug I opened on it, I'll try with latest pull
[02:25] <Stavros> hello
[02:25] <Stavros> how can i change the name of a commit?
[02:25] <Stavros> it's the last commit i made
[02:25] <Stavros> err, name = commit message
[02:27] <Stavros> can i remove just the commit but leave all my changes in my working copy?
[02:36] <AfC> Stavros: for the _very last_ commit
[02:36] <AfC> Stavros: you can simply use
[02:36] <AfC> $ bzr uncommit
[02:37] <AfC> Stavros: or strictly the last 𝑛 commits
[02:37] <AfC> $ bzr uncommit -r -𝑛
[02:37] <AfC> [I think]
[02:38] <AfC> Stavros: if you uncommit then is goes back to everything showing changed when you do `bzr status`
[02:39] <Stavros> AfC: that deleted my changes, though
[02:39] <fullermd> Basically, uncommit does what the name suggests; it does the opposite of commit.  Shuffles you back to the previous rev, but leaves your WT alone; any pending edits, adds, mv's, etc, are still sitting there pending.
[02:39] <Stavros> it didn't leave them in my working copy
[02:39] <Stavros> i managed to shuffle things around
[02:39] <Stavros> maybe i broke things, though
[02:39] <AfC> Stavros: your working tree would only change if you did
[02:39] <AfC> $ bzr revert
[02:39] <AfC> after the uncommit
[02:40] <Stavros> that won't revert to anything, since the uncommit already reverted
[02:41] <fullermd> That seems unlikely.  It's never been meant to, doesn't in testing here, and I don't recall seeing a bug about it ever.
[02:42] <Stavros> fullermd: about what?
[02:42] <fullermd> uncommit making changes to the WT.
[02:43] <Stavros> hmm
[02:43] <Stavros> what does "bzr uncommit; bzr status" show?
[02:44] <fullermd> Just what's expected; a big ole pile of changes.
[02:44] <fullermd> (I make a throwaway branch of an existing project and uncommitted about a hundred revs.  Few minor things happened in that time...)
[02:44] <Stavros> that's odd
[02:44] <Stavros> hmm
[02:44] <Stavros> well, thanks for your help, i'll pull and redo it
[02:47] <fullermd> Certainly if it really IS touching the WT, that would be a bug.  It just seems an unlikely one.
[02:48] <Stavros> nah, it's probably my fault, thanks
[03:02] <fullermd> Oh, nice.  Annotate fakes up revnos that can't be used.
[03:35] <jam> fullermd: but if you did 'bzr commit' they would work
[03:38] <lifeless> jam: so; the json file is 6G :P
[03:38] <jam> lifeless: probably a bit of duplication in there but yes
[03:39] <jam> the json is usually ~= the size of memory
[03:39] <jam> and ~ the same size when you load it back
[03:39] <jam> a little smaller
[03:39] <lifeless> so, is there anything that can give a half decent picture on this, without needing 6G or working set ? ;P
[03:40] <fullermd> Sure, but that would defeat the purpose of _reviewing_ the merge   :p
[03:40] <jam> fullermd: you always have uncommit
[03:40] <jam> lifeless: unix tools tend to do a decent job with a bit of grep/sed fu
[03:41] <lifeless> so, looking at the file
[03:41] <lifeless> Am I wrong, or its not json? its a series of separate json elements... ?
[03:41] <fullermd> Difficult tool to use at times.
[03:42] <jam> lifeless: right, I think we technically should have a [ ] around everything
[04:18]  * fullermd blinks.
[04:19] <fullermd> info's "first revision" seems to be really eager to get back to null.
[05:01] <jam> lifeless: I should also mention the 'strip_duplicates.py' script in py_memory_dump, which is a cheaper way to do "sort -u" or whatever to get duplicate lines removed
[05:02] <jam> It just keeps a lightweight set object in memory of the object addresses, and doesn't keep the rest of the details
[05:03] <jam> anyway... off to bed
[05:05] <lifeless> gnight
[05:06] <lifeless> jam: I'll chat with igc about fastimport on monday
[11:10] <CameronP_> Hi All
[11:18] <vila> lifeless: http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/13 captures many ideas I have about concurrency, among others, the idea that many places can be made concurrent (replace queues with iterators in that article) without adding complexity to the code
[11:18] <vila> lifeless: you may need to read a bit before, but that page is the key one IMO
[11:22] <CameronP_> Hi vila, thanks a lot for that help the other day, a lot of the problems seem to be because the upload plugin is for use against the current  devel version of bzr
[11:22] <CameronP_> I was trying to use it agains stable
[11:22] <CameronP_> Few bug reports have popped up over the last few days which were the problems I were having
[11:23] <vila> CameronP_: sorry about that, indeed I made use of a recent addition in the API and I should address that before releasing 1.0
[11:23] <vila> were you able to upgrade to a more recent bzr version ?
[11:24] <vila> Can you remind me what os/version you're using ?
[11:25] <vila> CameronP_: ^
[11:31] <CameronP_> Sorry was afk
[11:31] <CameronP_> At the moment Im using stable (1.17?) and centos 5
[11:32] <CameronP_> what version would you recommend to upgrade to?
[11:32] <vila> ha ok. Use 'bzr version' to check
[11:32] <CameronP_> yeah 1.17
[11:34] <vila> I don't have a general recommendation, it varies greatly depending on *your* constraints, like how easy it is for you to upgrade, can you run from sources, are you willing to run from sources (you'll need to install a bit more packages to be able to build the extensions, etc)
[11:34] <vila> Also, are you blocked on that bug in bzr-upload ?
[11:36] <CameronP_> well it still seems to work it just throws errors
[11:36] <vila> Are you using the --auto feature ?
[11:36] <CameronP_> and im trying to get a system set up for a whole lot of noob developers
[11:36] <CameronP_> i had to turn that off
[11:36] <CameronP_> does it work on the later versions?
[11:37] <CameronP_> that may fix all of my problems
[11:37] <CameronP_> i installed it from source last time
[11:37] <CameronP_> for the stable
[11:37] <vila> bzr-upload or bzr itself ?
[11:37] <CameronP_> both
[11:38] <vila> oh, then you can safely upgrade to bzr-1.18, read the topic of this channel :-D
[11:38] <vila> 1.18 is really around the corner, days
[11:38] <vila> not weeks
[11:38] <vila> source code freeze was week[s] ago
[11:38] <CameronP_> cool, that that should fix some of the issues with upload hey?
[11:39] <vila> it should, it it doesn't please comment on the bug
[11:39] <vila> you have windows users too right ?
[11:39] <CameronP_> yeah...
[11:40] <vila> there are installers ready for them too :)
[11:40] <vila> https://launchpad.net/bzr/
[11:40] <vila> in fact the only thing missing for 1.18 to be officially released is... announcing it I think :)
[11:43] <CameronP_> heh cool, so should I uninstall 1.17 first, before upgrading?
[11:44] <CameronP_> will  that affect my current repository?
[11:44] <vila> CameronP_: uninstall: no idea, depends of your distro
[11:44] <vila> CameronP_: affect the repo: surely not
[11:46] <vila> CameronP_: The closer you come to 2.0 the easier it will be to use the 2a format, you can even start to use it now, but there are a few gotchas in the upgrade process in some cases
[11:47] <vila> CameronP_: If you're happy with the size of your repos and the performance you get today, you may prefer to just wait
[11:48] <CameronP_> yeah it will be fine for us now... performance seems pretty good and im not dealing with large projects..
[11:52] <CameronP_> ok running 1.18 now...lets see how to goes ;)
[12:03] <CameronP_> vila: everything works fine apart from --auto now vila
[12:04] <CameronP_> ill just write some scripts so that they can call it manually
[12:04] <vila> what is breaking with --auto ?
[12:04] <CameronP_> it just returns text back to tortoise bzr (which then says its an error)
[12:05] <CameronP_> but it just looks like the stdout ouptput
[12:05] <CameronP_> of the auto doing its job
[12:05] <vila> CameronP_: Have you tried setting upload_auto_quiet to True in one .conf file as indicated in the README ?
[12:05] <CameronP_> NO, arg... i didnt know there was a README! sorry about that
[12:05] <CameronP_> that iwll probably fix it
[12:06] <vila> CameronP_: there is another critial bug about that README being hard to find :-)
[12:06] <CameronP_> heh... i guess these are all good things to get sorted out as new users like myself start using it...
[12:06] <vila> Have you read 'bzr upload --help' ? Or more broadly, what did you read ?
[12:07] <CameronP_> yeah i saw the -q otpion there initally
[12:07] <CameronP_> but couldnt work out how to set it in a conf file..
[12:07] <CameronP_> well didnt know you could
[12:07] <CameronP_> so stopped there
[12:07] <CameronP_> if that makes sense
[12:07] <vila> the option is new and came after *you* reported the problem :)
[12:08] <CameronP_> lol..
[12:08] <vila> yes, you make sense, great sense, thanks
[12:10] <gimbal> hey folks; does anyone know a foss-project-hosting service that supports bzr? not seeing it listed for any of the open ones listed at http://stackoverflow.com/questions/10490/best-open-source-project-hosting-site
[12:10] <vila> gimbal: launchpad.net ?
[12:11] <gimbal> gimbal: really; i didn't know launchpad was available for non-bzr-central projects; cool
[12:11] <gimbal> now does anyone know about a bzr plugin for doing sccm on the contents of hte (afaik) 'zip' compressed openoffice document files?
[12:12] <gimbal> trying to find one; maybe it's a pipe dream.... would like to manage all the document-sccm through the project sccm system, along with the code for a project
[12:12] <vila> gimbal: none that I know of, but several people expressed interest, it's doable
[12:12] <gimbal> i see
[12:13] <vila> I eman, it can be done by hooking at the right places, nobody found the time to start it yet
[12:13] <gimbal> ja gern ^x^
[12:13] <vila> but given openoffice python support, it's bound to occur :)
[12:14] <gimbal> ahh, i see.... yeah making it integrate with ooo that could help i bet....
[12:14] <gimbal> i mean, afaik, there's probably some sort of sccm-tooling system in ooo already
[12:14] <gimbal> not as if I can jump on the coding for it, myself, but hey while it's up might as well draw on the whiteboard heheh
[12:15] <gimbal> i just might stick with docbook, anyway
[12:16] <gimbal> i mean, the only thing i don't like about it is editing project documentation in xemacs, but I can get over that ^-^
[12:16] <gimbal> hey not to get political or anything, but my final question I guess ^-^ is about like so: Wasn't bzr based on Tom Lord's Arch originally?
[12:21] <gimbal> I mean, in the thought of giving credit about it...
[12:44] <CameronP_> vila: config works! running like a dream now
[12:44] <CameronP_> auto working perfectly
[12:44] <vila> CameronP_: great
[12:45] <vila> gimbal: hmm, I think the history is a bit more complex than that, google could certainly hep you there
[12:47] <gimbal> villa: well I wish it could; tried this search, it didn't come up with much: bzar "tom lord's arch"
[12:47] <gimbal> er .. bzr; didn't typo in the search query phrase, there, either
[12:48] <vila> gimbal: baz cames before bzr and after tla/arch (blurry there) search for that maybe
[12:48]  * vila lunch
[12:52] <gimbal> yeah, baz now I remember that command name
[13:12]  * gimbal hopes Tom Lord is doing alright, today; gnuarch.org seems to be nonresponsive. maybe his work didn't get the full attention that was due
[13:13] <gimbal> that said, I'd like to close my session here by mentioning: We can write all the nifty code we'd like to, but it doesn't write itself originally. If Tom Lord's work had anything to do with the evolution of bzr, I think it would be a fair thing for someone to describe, online, hopefully without getting political about - just honest\
[14:26] <lvh> hi
[14:27] <lvh> how many releases are to be expected more or less before 2.0 final?
[14:27] <lvh> or is 2a just the new format, not related to the bzr format 2.x
[14:33] <vila> lvh: 1.18 is due soon, then there will be 2.0 for which rc1 is already out and rc2 is also close
[14:33] <lvh> Cool!
[14:34] <vila> 1.18 is almost out, installers are ready, it also miss the official announcement
[14:34] <vila> 2a becomes the default format with 2.0, but is available from 1.16
[14:34] <vila> 1.16.1
[14:59] <lvh> Seems like only last week 1.17 was released.
[14:59] <lvh> Be right back :-)
[15:00]  * fullermd can't help feeling that "1.18 due soon" takes on the quality of a poor joke.
[15:11] <moldy> hi
[15:12] <moldy> how do i tell bzr not to create those ~1~ files all over the place?
[15:13]  * vila sadly agrees :-/
[15:14] <vila> moldy: do you know what they are for ?
[15:14] <moldy> vila: no idea, i only know that they are confusing setuptools, it ends up including them in SOURCES.txt
[15:14] <vila> moldy: they are the backups created when you use 'bzr revert'
[15:15] <moldy> vila: ah, thanks. aliasing bzr revert to bzr revert --no-backup :)
[15:15] <vila> moldy: the only way to lose your changes ! :-)
[15:15] <vila> moldy: you know that right ?
[15:16] <vila> echo "super important modification worked on for weeks" >>some_file
[15:16] <vila> bzr revert --no-backup
[15:16] <vila> Errrrk, damn bzr ! You kill my job !
[15:17] <moldy> i don't work on anything that long without committing :p
[15:17] <vila> moldy: good, just wanting to make you know the risks
[15:17] <vila> moldy: good, just wanting to make sure you know the risks
[15:42] <vila> fullermd: what is the freebsd equivalent of: '/etc/init.d/network restart' ?
[15:43] <vila> fullermd: rc.d/netif stop; netif start ?
[15:44] <vila> rebooting just in case
[15:44] <vila> >-/
[16:27] <SamB_XP> jelmer: hmm, is it possible to use svn-import to import into a subtree of a shared repository?
[16:32] <fullermd> vila: Not sure what that does...
[16:32] <vila> fullermd: np, next question, how do you activate something in rc.conf (avahi is my target) ?
[16:34] <fullermd> vi   :)
[16:34] <fullermd> (emacs totally doesn't work.  OS has standards, y'know)
[16:34] <vila> fullermd: no need for that, emacs is already installed :)
[16:34] <vila> fullermd: lier :-P
[16:34] <fullermd> You can glance at the script to see what the var basename is, but it's probably 'avahi'
[16:35] <vila> err, what script ? And is there a magic rule to infer variable names in rc.conf ?
[16:35] <fullermd> Hm, well, I see an avahi_daemon and avahi_dnsconfd on my system (not enabled); not sure which is what.
[16:36] <fullermd> Usually the var name is similar to the script name (in /usr/local/etc/rc.d/).  Sometimes it's not, and you'd have to glance at the first few lines.
[16:36] <fullermd> But the vars end up as ${BASENAME}_enable to flip it on and off.
[16:36] <fullermd> So grep _enable /usr/local/etc/rc.d/WHATEVER will probably show it.
[16:36] <fullermd> Then just set it to YES in rc.conf.
[16:37] <vila> ha ! usr/local/etc ,of course, silly me
[16:38] <fullermd> Actually, I think there's some arg...
[16:39] <fullermd> Ah, rcvar.
[16:39] <fullermd> % /usr/local/etc/rc.d/avahi-daemon rcvar
[16:39] <fullermd> # avahi_daemon
[16:39] <fullermd> avahi_daemon_enable=NO
[16:39] <fullermd> So you could "/usr/local/etc/rc.d/avahi-daemon rcvar >> rc.conf" and edit from there.
[16:39] <fullermd> Until you mess up one time and > instead of >>'ing, anyway.
[16:39] <fullermd> (but hey, that's why rc.conf is in a bzr branch  ;)
[16:40] <vila> err, wait, you mean I should add the whole avahi-daemon file to /etc/rc.conf ?
[16:41] <fullermd> No, juset that var.
[16:41] <vila> ha, ok, done
[16:41] <fullermd> (rc.conf being just a shell script that's sourced to set them, though of course being a script you COULD do all sorts of really bad evil stuff in it)
[16:41] <vila> fullermd: what do you use to restart the network modules ?
[16:42] <vila> source by who when ?
[16:42] <fullermd> Sourced by rc scripts when they run.
[16:42] <fullermd> "the network modules" doesn't really mean anything, I don't think...
[16:42] <vila> ok at boot time then.
[16:42] <fullermd> Or whenever you run them.
[16:43] <vila> hmm, what if... you plug a network card say
[16:43] <vila> no...
[16:43] <fullermd> If you `/usr/local/etc/rc.d/avahi-daemon start` it sources rc.conf to figure what to do.
[16:43] <fullermd> (and does nothing if _enable isn't YES'd)
[16:44] <vila> and how do I know that usr/local/etc/rc.d/xxx is taken into account ? All are tried and act depending on the _enable vars ?
[16:44] <fullermd> devd should notice interfaces being plugged in (USB, say) and config them as rc.conf says.  I dunno if there's some way to 'restart' them based on rc.conf changes; I always just re-ifconfig manually.
[16:44] <vila> ifconfig down; ifconfig up ?
[16:44] <fullermd> Right.  Every rc.d scripts in the various dirs checked is run during boot; only those _enable'd (or those antisocial or special that don't check an _enable) do anything.
[16:45] <vila> ok, good,
[16:45] <fullermd> `ifconfig $INT inet 1.2.3.4/5 alias` or whatever I'm doing.
[16:45] <fullermd> (that way I can do it BEFORE I encode it in the script, so if it turns out to be a horrible mistake, I can reboot and it'll be gone ;)
[16:45] <fullermd> I mean, not that I ever make horrible mistakes.  But some less perfect people do, so I hear.
[16:46] <vila> yeah, I always do all kind of horrible mistakes :)
[16:46] <vila> That's why I so love virtual machines :)
[16:47] <fullermd> rc(8) described the standard args to rc.d scripts.  Basically start, stop, and restart are the main ones you touch.  rcvar as above gives you hints about the enable var name.
[16:47] <fullermd> force{start,stop} ignore _enable and always {start,stop}.
[16:47] <vila> the bad news in my case is that freebsd is not that well supported by virtualbox, so I can't run X (summarized to the caricature)
[16:47] <fullermd> Some scripts add other args.  The pgsql script has an 'initdb' arg to init the database, for instance.
[16:48] <vila> ok, usual boilerplate then s/init.d/rc.d/ and a lot of knowledge can be reused, thanks for the hint (again, but saying s now, just in case :)
[16:48] <vila> s/s now/so now/
[16:49] <fullermd> No prob  :)
[16:49] <fullermd> And {en,dis}abled by vars in a conf file, rather than being symlinked off into some other dir with magical names.
[16:50] <vila> ha ha ! I can ping freebsd.local !
[16:50] <vila> fullermd: yeah, but how do you address the ordering ?
[16:50] <vila> oh, let me guess, PROVIDE and REQUIRE ?
[16:51]  * fullermd nods.
[16:51] <vila> hmm, closer to launchd on OSX then
[16:51] <fullermd> `/sbin/rcorder /etc/rc.d/* /usr/local/etc/rc.d/*`
[16:52] <vila> I can run that ? Just display things ?
[16:52] <fullermd> Builds up the graph.
[16:52] <fullermd> Yah, that just prints the list.  rc does that and then iterates it.
[16:52] <vila> whoohoo, save me hours !
[16:53] <fullermd> There are advantages to an OS developed by people who overthink everything  ;)
[16:53] <vila> Is there a way to configure the console with more than 25x80 ?
[16:54] <fullermd> Yah, there are some VESA modes available.  Lemme see if I can remember how to get at 'em...
[16:54] <vila> It's kind of funny, for years I searched to minimize the time spent on administering my systems, yet, I keep learning along the way... and suddenly it pays off :)
[16:55] <vila> well, that and you understanding the questions and giving the right answers :)
[16:55] <fullermd> 'k, the rc.conf(8) manpage lists [most of] the base system config vars.
[16:55] <fullermd> allscreens_flags set options to run vidcontrol(1) with.
[16:56] <fullermd> And vidcontrol(1) has modesetting.  I haven't messed with it in probably 10 years, but the manpage and my memory say that `vidcontrol $MODE` is all you need.  It lists the choices of modes in the manpage.
[16:56] <fullermd> Are you running i386 or amd64?  I thought I remembered hearing that VESA and amd64 don't get along, but I'm not sure.
[16:56] <vila> amd64 I think, let me check
[16:57] <vila> yeah, I started with: 7.2-RELEASE-amd64-dvd1.iso
[16:57] <fullermd> Well, if it doesn't work, it'll yell at you; would be surprised if it tried and screwed something up.
[16:58] <fullermd> Hm, I seem to only have 80x25 on my amd64 system...
[16:58] <vila> operation not supported by device
[16:58] <fullermd> (`vidcontrol -i mode` lists 'em; my i386 has thirty-some)
[16:59] <vila> same here, 80x35 only
[16:59] <vila> I can live with that, the aim is to configure a slave for the test botnet
[16:59] <fullermd> Yeah, I think it's something about VESA modeswitching requiring hooks into vm86 pseudo-real mode, and you can't do that when you're in long (amd64) mode.
[17:00] <fullermd> Just get it well enough to boot, then ssh in from nice big xterms   ;)
[17:01] <vila> so, how do I authorize root to log via ssh ?
[17:01] <vila> I got PAM auth error
[17:01] <vila> forget it, will install sudo
[17:02] <fullermd> Yah.  You can enable it in the sshd config, but su/sudo is Better(tm) anyway.
[17:02] <vila> find . -name sudo -print
[17:02] <vila> oops, wrong window :)
[17:02] <fullermd> I've long forgotten the root passwords to half the boxes I run (and I was the only one who ever knew most of 'em), thanks to sudo   ;)
[17:02] <fullermd> ports/security/sudo
[17:03] <fullermd> Note that if you have portupgrade installed, its `portinstall` command can do the searching for you, and a guess at the name is usually right enough.
[17:03] <fullermd> (e.g., `portinstall sudo`)
[17:03] <vila> ooooh 9-)
[17:04] <fullermd> But that means letting it install one of those weird niche languages, portupgrade being written by wackos...  ;)
[17:04] <vila> I was doing like instructed: cd <package> ; make all install clean :)
[17:04] <fullermd> Yah, 's what portinstall does.  But saves you a touch of typing.
[17:04] <vila> I was already instructed to install it anyway :)
[17:06] <fullermd> Ooh, I didn't know my instructions were followed so closely.
[17:06] <fullermd> Now you will dance for me!
[17:06] <vila> Wow, sudoers (in /usr/local, got it ;-) is read only !
[17:07] <vila> hehe, wanna see my notes ? :-)
[17:07] <fullermd> Sure, you're supposed to use visudo on it   ;)
[17:07] <vila> ooooh
[17:07] <fullermd> (just like you use vipw instead of vi /etc/master.pa<TAB>)
[17:07] <vila> One day I will learn vi :)
[17:08] <vila> emassu<TAB> rats :)
[17:08] <fullermd> vi$WHATEVER should obey $VISUAL/$EDITOR
[17:08] <fullermd> (an advantage of visudo is that it does syntax checks when you exit so you get less chances for foot-shooting)
[17:08] <vila> mah, I didn't set that (mixing my gentoo attempt :-/)
[17:09] <LarstiQ> set it to cat!
[17:09]  * fullermd quickly checks to make sure AfC isn't around...
[17:10] <vila> I'll retry later with gentoo anyway
[17:10] <fullermd> Anyway, I need to get going; gotta go help some friends of mine lay a patio before it starts raining.
[17:10] <vila> unless Afc can point me to a virtualbox image ready to be reused, but I doubt that match gentoo philosphy
[17:11] <vila> fullermd: sure, enjoy your week-end, your help was invaluable (which is why I can't pay you :-)
[17:11] <fullermd> I think there's a ##freebsd here on freenode that may help if you have other troubles.  I've never been in it, so I dunno how helpful it is.
[17:11]  * fullermd has his uses   8-}
[17:12] <vila> fullermd: but a beer anytime we meet !
[17:12] <vila> fullermd: or even champagne if it's near my home :)
[17:12] <fullermd> (BTW, did you read my infamous BSD/Linux rant?  It may help you over philosophical humps; that's what I was really aiming at in writing it)
[17:13] <vila> not sure, not recently at least, sounds like the perfect moment to read it though...
[17:13] <vila> http://www.over-yonder.net/~fullermd/rants/bsd4linux/bsd4linux1.php ?
[17:13] <fullermd> Yah.  Just follow the trail of smoke from the flamefests it ignited.
[17:13] <vila> google rules...
[17:14] <fullermd> I really should update it, along with the rest of my site.  But most of it is on mindset, so it doesn't really change much.  Just calls for tweaking and clarifying here and there.
[17:16] <fullermd> (I wrote it as a draft, sent it to some people I knew for reviews and opinions.  2 days later, I woke up to my DSL line smoking and a link from slashdot...   fun times)
[17:17] <fullermd> One of the posts about it said something like "Wow, this guy is an arrogant, condescending asshole."  I didn't know I came through so well in writing   ;)
[17:22]  * fullermd waves and scampers off.
[17:22] <vila> heh, reading
[18:04] <SamB_XP> huh ... I would have expected "bzr pull -r 10000" to pull in revision 9998, if that was the last one ...
[18:04] <SamB_XP> but it didn't!
[18:04] <vila> Now you knwo
[18:05] <vila> Now you know (I HATE ruining joke typos)
[18:05] <SamB_XP> well, I really think it ought to do that *and* tell you that there actually isn't a revision 10000
[18:05] <vila> file a bug when your expectations are fresh in your mind
[18:06] <vila> \but the short answer is that if you want the latest you just 'bzr pull'
[18:06] <vila> if you want to *know* the latest 'bzr revno'
[18:07] <vila> revnos have a defined semantic in a branch,  some persistence across related branches for old revnos, but at the base it's a branch-centric concept, throwing revnos in the wild doesn't really make sense
[18:31] <SamB_XP> vila: I was just pulling in spurts of 1000 or so so I wouldn't lose everything if my machine rebooted mid-pull
[18:32] <vila> SamB_XP: I'm pretty sure pull itself is resumable these days
[18:33] <SamB_XP> hmm, and possibly launchpad should have some kind of fallback for the series display ...
[18:33] <SamB_XP> ... the canvas element doesn't work too good in Links ;-P
[18:34] <LarstiQ> vila: resource consumption would be my reason to pull per 1000
[18:34] <SamB_XP> yeah, that's the other thing
[18:34] <SamB_XP> that also seems to correlate somehow with my random reboots
[18:34] <vila> LarstiQ: same answer, we shouldn't consume more or that's a bug
[18:35] <vila> urgh, we really shouldn't cause reboots !
[18:35] <SamB_XP> it's not bzr's fault
[18:35] <vila> I hope it's not tha case
[18:35] <vila> pfew
[18:35] <SamB_XP> just about anything can do it for me
[18:35] <SamB_XP> it was just a contributing factor
[18:35] <vila> Is your nick an indication of the OS you use ?
[18:35] <SamB_XP> the one I'm IRCing from, yes
[18:36] <SamB_XP> but I'm using bzr on my other one
[18:36] <LarstiQ> what is a "SamB" OS?
[18:36] <SamB_XP> LarstiQ: XP is the OS ;-P
[18:36] <SamB_XP> SamB runs Debian
[18:36] <vila> Simple And Mostly Booting ?
[18:38] <mneptok> Swap Ate My Battery
[21:08] <chrispitzer> so I have a repo with a dozen or so revisions in it.  I want to pull a given past revision out into a different directory... how do I do this?