[00:20] <foxbuntu> can someone give me a hand with this mess: http://paste.ubuntu.com/19747/
[00:22] <bob2> do you have a /.bzr dir or something?
[00:23] <foxbuntu> bob2, where?
[00:23] <bob2> in /
[00:24] <foxbuntu> of the branch...yes
[00:25] <foxbuntu> this branch has been fine until tonight
[00:25] <bob2> no, in /
[00:25] <foxbuntu> oh
[00:25] <foxbuntu> nope
[00:25] <bob2> or does ~/Desktop/mythbuntu_branches/mythbuntu-apple-trailers contain etc?
[00:26] <foxbuntu> it used to, I removed it
[00:26] <bob2> did you touch anything in  ~/Desktop/mythbuntu_branches/mythbuntu-apple-trailers/.bzr?
[00:27] <foxbuntu> nope
[00:37] <bob2> dunno, sorry - perhaps try the list?
[00:46] <foxbuntu> bob2, I resolved it, I must have broken it somehow, I just pulled the lastest copy of the branch and it works now
[02:07] <jml> I often find myself wanting to switch to the top thread of a loom or to the bottom thread.
[02:07] <jml> What would be a good command line syntax for this?
[02:10] <lifeless> hmm
[02:10] <lifeless> switch top: switch bottom: I guess
[02:10] <lifeless> if you mean switch and not up-thread
[02:13] <jml> I do mean switch.
[02:26] <lifeless> k
[02:38] <jml> who do I speak to if I want to get my blog syndicated to Planet Bazaar?
[02:41] <lifeless> pooolie
[02:42] <mkanat> Hey hey.
[02:42] <mkanat> How do I exclude a particular directory from a "bzr diff"?
[02:42] <lifeless> bzr diff | filterdiff -x dir
[02:42] <lifeless> is what comes to mind
[02:43] <mkanat> lifeless: Okay.
[02:43] <mkanat> I assume that's part of patch-utils.
[02:43] <lifeless> diffutils I think, but yeah
[02:43] <mkanat> Ah, yeah.
[02:45] <mkanat> lifeless: I tried diff-options="--exclude" once, but that didn't work.
[02:46] <lifeless> probably need "--exclude old/PATH"
[02:46] <lifeless> but we call diff individually, not sure it would honour it in that case
[02:47] <mkanat> Ahh, hmm.
[02:48] <mkanat> I'll try.
[02:51] <lifeless> wow, http://andrew.puzzling.org/ is a little borked. or something
[02:51] <mkanat> lifeless: filterdiff doesn't work.
[02:52] <lifeless> mkanat: no?
[02:52] <lifeless> mkanat: I find I usually need to tweak the pattern a little to make it happy then it plays nice
[02:52] <mkanat> bzr diff -rancestor:bzr://bzr.everythingsolved.com/bugzilla/3.2 | filterdiff -x extensions/ > ~/diff
[02:53] <mkanat> I tried it without the / too.
[02:53] <lifeless> mkanat: also, please do file a bug, -x is reasonable to have
[02:53] <mkanat> Does it need a * or something?
[02:53] <mkanat> lifeless: Okay. :-)
[02:53] <lifeless> mkanat: try new/extensions
[02:53] <mkanat> lifeless: Okay.
[02:53] <lifeless> (and variations). or old / - see thhe path in the diff header
[02:53] <mkanat> [02:53] <mkanat> --- extensions/launchpad/code/install-before_final_checks.pl    1970-01-01 00:00:00 +0000
[02:53] <mkanat> +++ extensions/launchpad/code/install-before_final_checks.pl    2008-06-12 21:24:07 +0000
[02:53] <bob2> lifeless: a.p.o -> displaying mashed up text snippets of the entries?
[02:53] <lifeless> bob2: yeah
[02:54] <lifeless> like apache had a bad day
[02:54] <lifeless> spiv: ^
[02:54] <lifeless> mkanat: oh. emm, try "extensions/**" then I guess
[02:54] <mkanat> lifeless: Ahh, good idea. :-)
[02:54] <mkanat> lifeless: Ahh, yep. :-)
[02:55] <mkanat> I did it with just * but that worked.
[02:55] <bob2> some weird firefox/backwards interaction
[02:55] <lifeless> bob2: it works with other thing?
[02:55] <lifeless> spiv: ping
[03:04] <lifeless> reconcile on knits of launchpad -> pain
[03:08] <cara> Hi all
[03:11] <lifeless> hi
[03:14] <poolie> hi lifeless
[03:14] <poolie> i'm going to read "stackable branch ui 2"
[03:14] <cara> I'm having an issue with bzr where it gives me this error message. bzr: ERROR: Path(s) are not versioned: These are the steps I took to get this error message:
[03:14] <cara> 1) bzr init <directory>
[03:14] <cara> 2) cd <directory>
[03:14] <cara> 3) bzr branch <url-to-branch/trunk>
[03:14] <cara> 4) bzr branch <url-to-branch/trunk> mybranch
[03:14] <cara> 5) cp /files/I/needed/for/mybranch /path/to/mybranch
[03:14] <cara> 6) cd /path/to/mybranch
[03:14] <cara> 7) bzr commit /path/to/files/in/mybranch
[03:14] <cara> whoa lag
[03:14] <poolie> cara: you need to bzr add the new files
[03:15] <cara> ooo
[03:15] <poolie> cara, 'bzr add' in the root of the branch should be enough
[03:15] <cara> hehe
[03:15] <cara> for the files I copied over?
[03:15] <cara> or do I copy them over that way?
[03:15] <mkanat> lifeless: bug 53992 was already there.
[03:15] <lifeless> cool
[03:15] <poolie> after you've copied them in
[03:16] <cara> do I still have to commit them?
[03:18] <poolie> yes
[03:18] <poolie> add tells bzr to track them
[03:18] <poolie> commit actually takes a snapshot
[03:19] <cara> oh
[03:19] <cara> ok
[03:19] <cara> thanks poolie
[03:19]  * cara hugs poolie
[03:19] <cara> you're such a sweetie
[03:19]  * cara would have been up all night trying to figure out what the heck was going on 
[03:20] <cara> I kinda just jumped into the bzr thing.
[03:21] <poolie> you're welcome
[03:24] <cara> you just don't know how happy I am right now lol
[03:24] <poolie> i'm really happy to hear that then :)
[03:24] <poolie> please do ask if there's anything else confusing
[03:45] <cara> oh yeah.. How do I remotely remove a branch I created?
[03:46] <cara> would I have to literally log onto the server and delete the branch? I actually pushed the branch
[03:53] <mneptok> cara: IIRC, bzr remove-tree protocol:/path/to/branch
[03:54] <RAOF> mneptok: That's not actually going to remove the branch, though, just the working tree, right?
[03:54] <mneptok> RAOF: yeah.
[03:54]  * mneptok pouts
[03:58]  * RAOF :P
[04:06] <thumper> can't you just use ssh to remove it ?
[04:07] <thumper> cara: it depends on what access you have to the remote machine
[04:13] <jml> cara: is this on Launchpad?
[04:15] <cara> launchpad?
[04:15] <cara> thumper: I don't know
[04:15] <thumper> cara: where did you push the branch?
[04:16] <thumper> cara: and what command did you use?
[04:16] <cara> bzr push bzr+ssh http://link.to.branch
[04:16] <lifeless> yay tshirt
[04:17] <cara> err
[04:17] <cara> bzr push bzr+ssh http://link.to.branch cara or something
[04:17]  * cara is sleepy
[04:17] <thumper> lifeless: I got one too :)
[04:18] <thumper> cara: perhaps best to come back when not sleepy :)
[04:18] <thumper> cara: or do you really need to get rid of it now?
[04:19] <cara> nah I will come back later thanks thumper
[04:19] <cara> hey thumper do you use gentoo?
[04:19] <thumper> cara: nope, kubuntu
[04:19] <jml> lifeless: yeah, mine arrived yesterday
[04:20] <cara> hehe I use kubuntu too :)
[04:20] <lifeless> so, is this inversely proportional to code written or something
[04:20] <cara> I thought I seen you in a gentoo channel looooooooooooooooooooooooooooong time ago
[04:20] <mwhudson_> i got mine yesterday too
[04:21] <cara> been trying to figure out how set the time
[04:21] <cara> everything is grayed out
[04:22] <thumper> cara: right click on the clock applet and click on "set date and time"?
[04:23] <thumper> cara: s/set/adjust/
[04:29] <jml> lifeless: if it were inversely proportional, I would have got mine five years ago.
[04:29] <mwhudson_> :)
[04:40] <lifeless> jml: order not dates
[04:41] <lifeless> loonch time
[04:59] <poolie> cara: you need to press the 'unlock' button in that window
[04:59] <poolie> it's a bit unobvious
[05:00] <poolie> it's meant to be like the mac idiom of showing things readonly until you authenticate
[05:00] <poolie> which is not a bad idea, but doing it just in one place in confusing
[05:00] <poolie> hth
[05:12] <beuno> got a the tshirt today too  :)  (evening)
[05:15] <poolie> oh great
[05:15] <beuno> thanks poolie
[05:15] <lifeless> beuno: I've pushed the change I was mentioning yesterday
[05:15]  * poolie takes a deep breath
[05:16] <poolie> ok seriously into your collossal patch now
[05:16] <lifeless> sorry :)
[05:16] <bob2> haha
[05:16] <lifeless> bob2: 17K lines.
[05:16] <beuno> lifeless, ah, just pulled revision 29
[05:16] <beuno> si it won't break on re-indexing now?
[05:16] <lifeless> right
[05:16]  * beuno goes look at the code
[05:16] <lifeless> should a second or two to index a new commit too
[05:18] <bob2> heh, net negative lines of code, tho
[05:18] <lifeless> yah
[05:19] <beuno> lifeless, so. Get the current list of revids, and go one by one through the revids in the branch, and stop when you find a match?
[05:20] <lifeless> get the current index (lazy load - no IO at that point), then yes. Oh, I forgot to stop the search, thats why its slow.
[05:20] <beuno> :)
[05:20] <beuno> I was going to ask how you did that part
[05:21] <lifeless> $ time bzr index
[05:21] <lifeless> real    0m1.257s
[05:21] <lifeless> user    0m0.792s
[05:21] <lifeless> sys     0m0.184s
[05:21] <lifeless> incremental on bzr.dev
[05:21] <lifeless> still too slow
[05:22] <bob2> is the ideal for it to be fast enough to run it automatically when the branch is altered?
[05:22] <lifeless> I want a tip_change hook for it
[05:22] <lifeless> then my branches can be indexed
[05:22] <bob2> spiffy
[05:22] <lifeless> and I can forget its installed
[05:23] <beuno> that would be cool
[05:23] <beuno> and fairly easy I suppose
[05:23] <lifeless> lsprof-file ftw
[05:29] <lifeless> oh well, I guess it can fork()
[05:29] <lifeless> 81% in bzrlib.index.GraphIndex.iter_entries()
[05:29] <lifeless> I have to fix that, but not today.
[05:30] <lifeless> oh heh. that explains why its slow.
[05:30] <lifeless> I'm reconciling knit based launchpad in another window, and I forgot.
[05:30] <beuno> lol
[05:30] <lifeless> still: just did a pull() on bzr.dev:
[05:30] <lifeless> $ time bzr index
[05:30] <lifeless> real    0m8.902s
[05:30] <lifeless> user    0m6.540s
[05:30] <lifeless> sys     0m0.312s
[05:31] <beuno> yeah, 8sec may be a too slow for a handful of revisions
[05:31] <lifeless> thats with reconcile in background
[05:31] <lifeless> I'm not unhappy :)
[05:31] <lifeless> will try later and see
[05:35] <beuno>                                                                                                                                                             
[05:35] <beuno> real	2m26.834s
[05:35] <beuno> user	2m19.133s
[05:35] <beuno> sys	0m0.888s
[05:35] <beuno> new index on bzr.dev
[05:35] <lifeless> :)
[05:35] <lifeless> not bad
[05:35] <lifeless> should be subsecond to run again
[05:36] <lifeless> oh, let me push
[05:36] <beuno> and
[05:36] <beuno> beuno@beuno-laptop:~/bzr_devel/bzr.dev$ time bzr index
[05:36] <beuno> real	0m5.908s
[05:36] <beuno> user	0m5.756s
[05:36] <beuno> sys	0m0.160s
[05:36] <beuno> after pulling and re-indexing
[05:36] <beuno> ~3 seconds when there is nothing to index
[05:36] <lifeless> you want revno 30, pushing up now
[05:38] <beuno> :)
[05:38] <beuno> 0.2sec
[05:39] <lifeless> yeah
[05:39] <lifeless> so that should be 3 seconds to index new revs above, not 6
[05:40] <beuno> yeah, shaved off those 3 seconds to compare
[05:40] <beuno> stopping the iteration and only removing NULLs if there actually are any
[05:40] <beuno> this is shaping up nicely!
[05:40] <mwhudson> hello again beuno
[05:41] <beuno> hi again mwhudson
[05:41] <mwhudson> beuno: is https://code.edge.launchpad.net/~beuno/loggerhead/zpt.cleaner_urls up to date?
[05:42] <beuno> let me check
[05:42] <beuno> mwhudson, yes. It's missing the navigation links fix, which is what I was starting now
[05:42] <mwhudson> ok
[05:43] <bob2> lifeless: should index lock the branch?
[05:44] <lifeless> bob2: it read locks it
[05:44] <bob2> ah
[05:44] <lifeless> bob2: oh, during the what-to-index lookup
[05:44] <mwhudson> beuno: i don't think you need to pass the revno into the revisioninfo template function
[05:44] <lifeless> it does
[05:45] <mwhudson> beuno: doesn't the change parameter have a revno attribute?
[05:45]  * beuno checks
[05:46] <beuno> mwhudson, do you mean the revid?
[05:46] <mwhudson> ah uh one moment
[05:46] <mwhudson> the way loggerhead does urls makes me so sad :(
[05:47] <beuno> good, I like it when we hate the same things
[05:47] <beuno> makes it more probable to get rid of it
[05:47] <beuno> I had to add that to display the revid in the revision view
[05:47] <beuno> because we didn't show it before, which I think is dumb
[05:47] <mwhudson> isn't there change.revid then?
[05:48] <mwhudson> yes, that's an improvement
[05:48] <beuno> well, we don't pass change to revid AFAIK
[05:48] <beuno> ah, wait
[05:48] <beuno> maybe we do
[05:48] <mwhudson> ... of course, after we've got rid of the revision cache we should just be passing bzrlib Revision objects around ...
[05:49] <beuno> yes please  :)
[05:49] <beuno> revision cache is my next target
[05:49] <mwhudson> sweet
[05:49] <mwhudson> i guess it will be a two phase thing
[05:49] <mwhudson> delete the cache
[05:50] <mwhudson> get rid of these bizaare change/entry things
[05:50] <mwhudson> though we may need to be slightly clever to carry revnos around
[05:50] <beuno> mwhudson, we don't pass change
[05:51] <mwhudson> -def revisioninfo(url, branch, entry, modified_file_link=None):
[05:51] <mwhudson> +def revisioninfo(url, branch, entry, revid, modified_file_link=None):
[05:51] <mwhudson> what is entry here then?
[05:51] <mwhudson> but well, ok :)
[05:52] <beuno> it doesn't have revid for some reason  :/
[05:53]  * beuno is confused now
[05:53] <beuno> ok
[05:54] <beuno> I *do* have change
[05:55] <mwhudson> the -history.get_revno(entry.revid)+entry.revno stuff is kinda funny
[05:59] <beuno> funny as in...?
[05:59] <beuno> it seemed unnecesary to go get that info when we already have it
[06:00] <mwhudson> funny as in "ha ha how bad is loggerhead"
[06:01] <beuno> heh, yes. There seem to be a few layers of randomness on it
[06:01] <beuno> fixed and pushed my revid nonsense
[06:02] <beuno> and I missed something, revision 245 coming up
[06:08] <beuno> hm, loggerhead is playing with my head
[06:13] <mwhudson> it does that
[06:13] <beuno> ok, no 245, loggerhead just has the habit of not dying when I tell it to
[06:13] <beuno> so *I* was right, not *it*
[06:13] <mwhudson> the proper thing to remember is that the answer to the question "is there a reason for it doing this particular thing this odd way" is usually "no"
[06:14] <beuno> heh, yes, I learned that the hard way
[06:14] <mwhudson> me too :)
[06:14] <beuno> I spent quite a few hours looking at code, thinking I was missing something
[06:14] <beuno> we should add that to the README  :p
[06:15] <mwhudson> we seem to be making great strides on replacing the entire code base
[06:15] <mwhudson> which should alleviate the need for that :)
[06:16] <beuno> yes, that's a more optimistic way of looking at it
[06:16] <beuno> I'm just mad at it for making me go in circles for 10 minutes
[06:16] <beuno> now, let's get revnos into navigation links working properly...
[06:17] <mwhudson> beuno: at some point (probably not right now) we should have a think about what we _want_ loggerhead's urls to look like
[06:18] <beuno> mwhudson, absolutely. Have a plan rather than a mashup of things. I'll give it some thought
[06:19] <mwhudson> any kind of plan, no matter how insane, would probably be progress
[06:19] <beuno> I kinda like the idea of mimicking bzr commands
[06:19] <beuno> like log/revno
[06:20] <beuno> may be more intuitive for everyone, users and developers
[06:20] <poolie> lifeless: cstringio has some kind of limitation wrt binary data but i can't remember precisely what it is
[06:20] <poolie> do you know?
[06:20] <poolie> is it only if you give it unicode objects?
[06:21] <mwhudson> yes, don't give cStringIO unicode
[06:21] <mwhudson> very strange things happen if you do
[06:21] <mwhudson> it really should be 8 bit clean though :)
[06:22] <lifeless> poolie: yes
[06:22] <lifeless> poolie: StringIO(u'foo').getvalue() returns bytes such that decode('UCS4') works :{
[06:23] <lifeless> (e.g. the native internal representation of u'' strings is coerced into a plain string
[06:23] <lifeless> mwhudson: they are not strange, very predictable
[06:25] <mwhudson> lifeless: well
[06:25] <mwhudson> i don't think strange and predictable are necessarily in opposition
[06:25] <lifeless> :)
[06:25] <mwhudson> 'suprising'
[06:26] <lifeless> sure
[06:26] <lifeless> 'not inferrable until seen'
[06:26] <lifeless> does 3K fix this
[06:26] <lifeless> if not someone needs bitchslapped
[06:28] <mwhudson> beuno: brain too fuzzed to review the branch properly i think
[06:28] <mwhudson> i'll get to it over the weekend or monday morning
[06:29] <beuno> mwhudson, sure, no problem. I'll push the navigation changes in a while, so you can do a complete review
[06:29] <mwhudson> cool
[06:30] <beuno> And wrap up the theme tomorrow. At least the changelog and generic stuff
[06:30] <beuno> still working on the diff view to get the html/css *just* right
[06:45]  * mwhudson stops for the day
[06:45] <beuno> mwhudson, navigation links fix pushed
[06:45] <beuno> ah, well, have a good weekend then  :)
[06:45] <mwhudson> you too!
[06:45]  * beuno is one day behind so still has friday  :p
[06:46] <beuno> so that means I may still get bzr-search into an experimental branch  :)
[07:02] <beuno> that's it for me today too
[07:02] <beuno> g'night
[07:05] <lifeless> beuno: gnight
[07:17] <Tsmith> hey
[07:18] <lifeless> hi
[07:22] <Tsmith> i'm trying to uncommit a revision, but i keep getting the message "Unable to obtain lock file:///var/bzr/blinds.com/.bzr/branch/lock
[07:22] <Tsmith> held by tsmith@blinds.com on host 5200MHz.xmule.ws [process #11135]
[07:22] <Tsmith> locked 7 hours, 25 minutes ago
[07:22] <Tsmith> "
[07:22] <lifeless> well, is that process still alive ?
[07:22] <lifeless> (if thatis your host, check with ps ax/top)
[07:23] <Tsmith> i guess i should check both hosts
[07:23] <Tsmith> 11135 is not an active process
[07:23] <lifeless> if its not alive anymore, try bzr break-lock
[07:24] <Tsmith> is that the same thing w/ CVS locking up and me requiring a sourceforge ticket?
[07:25] <lifeless> not really
[07:25] <lifeless> cvs is broken-by-design in this area
[07:25] <Tsmith> ha
[07:25] <lifeless> you can break your own lock
[07:25] <Tsmith> i read a fictional story today about dvcs changing a woman's life
[07:25] <lifeless> we can't avoid stale locks completely - network interruptions/power failures etc
[07:25] <Tsmith> but i really do feel like bzr changed my life
[07:26] <lifeless> cool!
[07:26] <Tsmith> <-- my wifi scrwed up
[07:26] <Tsmith> when the lock happened
[07:26] <lifeless> yah
[07:27] <Tsmith> (i'm not crazy, but using BZR after 10 years of CVS or SVN (the last year) produces feelings in me akin to when i saw the grand canyon for the first time)
[07:27] <Tsmith> esp when i bzr switch branches ;o
[07:27] <lifeless> :)
[07:27] <jamesh> vertigo?
[07:27] <Tsmith> yeah exactly
[07:28] <Tsmith> now i'm just wondering if there's a place i can plunk down a few hundred to inspire someone to create bzr up -r functionality
[07:29] <lifeless> I believe there is a crude patch
[07:29] <lifeless> needs some love
[07:29] <Tsmith> i specifically need it to update files based on datetime diffs
[07:29] <Tsmith> like svn up -r {2008-06-10}
[07:29] <Tsmith> i find bugs all the time ni a codebase of 1.5 million lines
[07:29] <Tsmith> i have to do a LOT of sleuthing by date
[07:30] <lifeless> ah. bisect doesn't help ?
[07:30] <lifeless> hmm, this is the sort of case bzr-search _might_ help with
[07:30] <Tsmith> i do not see that command bzr help commands
[07:30] <lifeless> bisect is a plugin
[07:31] <Tsmith> the company i work for, i'm the lead "fixit" guy
[07:31] <Tsmith> we have a 4-server dev cycle; code on your box, up to dev server, up to UAT, up to prod
[07:31] <Tsmith> the problem is, the lead of each site ups all the code to the prod server for htat site
[07:31] <Tsmith> they do this using svn
[07:31] <Tsmith> by hand
[07:32] <Tsmith> like svn diff -r100...101 > changes.diff; patch -p0 < changes.diff
[07:32] <Tsmith> there's no branching
[07:32] <Tsmith> there's no tagging
[07:32] <Tsmith> it's actually pretty sad; for every 3 bugs fixed, 5 more are created, 3 alone by this very merge process; and there's no way to revert
[07:33] <Tsmith> the main pusher for the main website in March, for instance, accidentally svn up'd in the root of the prod, and we spent 2 months cleaning up the damage
[07:33] <Tsmith> lol
[07:34] <lifeless> ouch
[07:34] <Tsmith> so i'm in charge of www.blinds.ca
[07:34] <Tsmith> i am responsidble for all the pushes
[07:34] <Tsmith> what *I* do is i have a bzr repository w/ branches that mirror my local box, dev, uat, and prod
[07:35] <Tsmith> and i run rsync against the prod before i do a commit, so i can revert the commit if there are any problems
[07:35] <Tsmith> cuz every one uses svn and management is very hostile towards positive change (they love negative change, incidentally)
[07:36] <lifeless> erg
[07:36] <lifeless> you have my sympathy
[07:37] <Tsmith> nah man bzr saves me lol
[07:43] <mtaylor> lifeless: real	32m52.967s
[07:43] <lifeless> mtaylor: thats significantly faster. woo
[07:44] <mtaylor> yup. woo indeed!
[07:44] <lifeless> mtaylor: also, it will auto-update if you grab the latest code
[07:44] <mtaylor> the index will?
[07:44] <mtaylor> good
[07:45] <Tsmith> lifeless: bzr bisect is exactly what i need; awesome!
[07:45] <lifeless> Tsmith: cool
[07:46] <Tsmith> gosh
[07:46] <Tsmith> i think some of the people in this channel need to give me thier paypal addresses (lloks @ lifeless)
[07:46] <jml> Tsmith: lifeless's paypal address is jml@mumak.net
[07:47]  * jml whistles innocently
[07:47] <lifeless> jml: thank you for proxying my due
[07:47] <lifeless> (I don't use paypal)
[07:47] <mtaylor> Tsmith: mine is monty-paypal@inaugust.com
[07:47] <mtaylor> Tsmith: but I didn't write any of bzr
[07:47] <lifeless> Tsmith: seriously though, there's no need - I am partly-paid, partly scratching-my-own-itch for what I do on bzr.
[07:48] <lifeless> Tsmith: if we are ever in the same city, all I would say is 'buy me a beer'
[07:48] <Tsmith> ha what city are you in/
[07:48] <lifeless> Sydney for most of the year
[07:48] <Tsmith> sorry i dont think that's in my path ;p
[07:49] <lifeless> but work has me travel frequently - I'm at UDS for example
[07:49] <lifeless> We'll likely be in the US again late this year
[07:59] <AfC> Rebase creates new revisions with different parents and thus the potential for later merge conflicts, right?
[07:59] <AfC> Is `bzr merge [--force] ../other-branch/path/to/file` or `bzr merge -r 526..527 ../other-branch` any different?
[08:01] <mwhudson_> i think rebase basically does bzr merge -r N..N+1 over and over again, doesn't it?
[08:01] <AfC> mwhudson_: {shrug}
[08:02] <AfC> I'm more interested about whether either preserves *any* information in super secret revision properties that might someday in the glorious future be useful to construct better histories / merges. If so, then that would be the technique to prefer, I would have thought.
[08:03] <AfC> ﻿/me is attempting to cherry pick. What an surprise.
[08:07] <AfC> [Robert has been so adamant over the years that rebase is evil that I don't even have the plugin installed]
[08:11]  * mtaylor doesn't understand the need for rebase
[08:20] <lifeless> anecdotally, re rebase-is-bad http://blog.red-bean.com/sussman/?p=96
[08:23] <bob2> linus is mostly anti-rebase for more pragmatic reasons
[08:24] <matkor> http://bundlebuggy.vernstok.nl/bzr-gtk/ dead ?
[09:04] <vila> lifeless: excellent blog entry ! I sooo agree...
[12:48] <lifeless> gnight all
[13:06] <fdv> Hi. I'm getting the following slightly cryptic error from bzr rspush: "bzr: ERROR: Unprintable exception NotStandalone: dict={'_preformatted_string': None, 'location': 'file:///local/bzr/main/main/'}, fmt=None". Does anybody know what this means?
[13:11] <james_w> hi fdv
[13:11] <james_w> that's a bug in the exception class that is causing it to print that garbled message
[13:12] <james_w> as to the real meaning is should be displaying something like "bzr: ERROR: Something about the branch not being standalone: file:///local/bzr/main/main/"
[13:12] <fdv> james_w: ok..
[13:14] <james_w> apparently rspush only works if you have a standalone branch, not using a shared repository
[13:14] <fdv> but what does standalone really mean here?
[13:14] <james_w> fdv: if you could file a bug against bzrtools for the first bit that would be great
[13:14] <fdv> I'll try :)
[13:15] <james_w> a branch is not standalone if it is using a shared repository, or it is bound somewhere else. Are either of those true here?
[13:15] <fdv> I've branched from an svn repo
[13:15] <fdv> but I don't think it's bound
[13:16] <fdv> that'd mean I'd either have had to do a checkout or a bind, right?
[13:16] <james_w> yup
[13:16] <james_w> are you using a shared repository?
[13:16] <fdv> ehrm..
[13:16]  * fdv feels kind of stupid :p
[13:16] <fdv> what's a shared repo? :)
[13:16] <james_w> ah
[13:17] <james_w> it's what you get with the "init-repo" command
[13:17] <fdv> really?
[13:17] <james_w> it's an area where branches can share their revision storage to reduce disk space usage, and to speed up branching and fetching operations
[13:17] <fdv> I've done bzr init-repo --rich-root-pack; svn branch <svn repo>; svn pull <svn repo>
[13:18] <james_w> yup, you've got a shared repo then
[13:18] <fdv> aw, right
[13:18] <gour> what's wrong with svn?
[13:18] <james_w> you could also ask for the error message to be improved in the bug report.
[13:18] <fdv> james_w: I'll do that
[13:19] <fdv> thanks
[13:19] <fdv> gour: what do you mean?
[13:19] <james_w> no problem
[13:19] <gour> 11 RCs with "...It contains
[13:19] <gour> a couple of critical bugfixes implemented since the release of
[13:19] <gour> 1.5.0-rc9"
[13:19] <gour> it's better to throw white towel into DVCS ring
[13:20]  * gour is waiting for svn-1.5 to use bzr-svn. bloody deps on that bindings :-/
[13:21] <fdv> gour: will it be easier to use bzr against svn 1.5?
[13:21] <gour> fdv: yes, no need to patch as with 1.4 (memory leaks)
[13:21] <fdv> gour: right
[13:22] <fdv> gour: I did incremental pulls, that seemed to work somehow
[13:22] <gour> fdv: i need svn only for pandoc, nothing else, neither i want to have it ;)
[13:23] <fdv> :)
[13:24] <gour> i'm told that next release of bzr-svn won't depend on svn's (python) bindings
[13:27] <fdv> right
[14:33] <nevans> so... now that bzr is super duper fast, when are we gonna get good cherry-picking support and nested branches?  ;-)
[14:33] <nevans> more to the point, is there some way to tease the current milestone priorities out of launchpad?
[14:34] <nevans> or is there some way that someone (like me) with very limited python experience and time can help push those things forward?  :)
[14:43] <james_w> hi nevans
[14:44] <james_w> I think the best way to help at the moment would be to test stacked branches and help shake out any bugs so that we can release 1.6 with fewer bugs
[14:44] <james_w> once that's shaken out then some of the other features will have more chance to get worked on
[14:46] <nevans> testing I can do.  :)
[14:47] <nevans> (although I've occasionally had to hold back at older versions because of bzr-svn regressions, and I need to use bzr-svn for my day job)
[14:50] <james_w> ah, I don't know if bzr-svn is compatible with what will be 1.6 yet.
[14:51] <jelmer> the 0.4 branch is
[14:52] <james_w> hi jelmer
[14:52] <james_w> good to know
[14:52] <nevans> jelmer: you're awesome.  ;-)  I'm using 0.4 -r1219 at the moment.
[14:52]  * james_w remembers to go and merge jelmer's patch
[15:00] <nevans> james_w: should a bzr client (<1.6) be able to access stacked branches via bzr:// (presumably the server is at 1.6)
[15:01] <james_w> nevans: no, I don't think that will work, I'm not sure though.
[15:39]  * gour just converted (with tailor) one darcs project file and now start serious use of bzr :-)
[15:39] <gour> *starts
[15:53] <gour> i need to push changes from my laptop to the desktop...with darcs i went via ssh. what to use with bzr?
[15:53] <gour> (there is no web-access to the desktop, only ssh)
[15:54] <pickscrape> ssh?
[15:54] <Verterok> gour: bzr push sftp://desktop/path/to/branch
[15:55] <Verterok> or bzr push sftp://gour@desktop/path/to/branch
[15:58] <gour> Verterok: thanks, the 2nd one worked. what would be required to use bzr+ssh ?
[15:59] <bob2> just need to have bzr in your PATH on the remote side
[15:59] <gour> i've bzr on remote side in PATH
[16:00] <gour> is the syntax same as with sftp?
[16:00] <bob2> just need to use bzr+ssh:// instead of sftp
[16:02] <gour> cool. i had problem with the syntax earlier ;)
[16:03] <gour> bzr+ssh is probably recommended for such usage..
[16:31] <toyto1> gour: with bzr+ssh, the server must have an installed bzr?
[16:31] <gour> toyto1: it has. it's my desktop machine
[16:34] <toyto1> gour: ah :) thanks gour. We use sftp but it's okay for now, but does bzr+ssh would be faster than just sftp? or with bzr in the server would be the choice if speed is a concerned?
[16:38] <gour> toyto1: it must be faster
[16:39] <gour> toyto1: yes, bzr+ssh needs bzr on the server-side
[16:40] <toyto1> gour: thanks for sharing gour :)
[16:41] <gour> toyto1: you're welcome
[17:19] <LEW21> Hi! Is it possible to use $Id$, $Rev$ etc. in Bazaar?
[17:19] <james_w> LEW21: no, not yet, sorry.
[17:19] <james_w> hopefully in the next couple of releases.
[17:20] <LEW21> Ok, thanks
[20:07] <dpm> is there a way to make 'bzr commit' ignore files which differ only on their timestamp (i.e. they are binary identical)?
[20:09] <fullermd> We call that 'bzr commit'   8-}
[20:10] <dato> dpm: commit does that by default
[20:11] <dpm> hmm, I might have misread the diff on my last commit, then. I could have sworn that the two files were identical.
[20:11] <dpm> thanks for the info
[20:12] <fullermd> That's one behavior I *SO* don't miss from CVS...
[20:16] <fredreichbier> hm, how do i exclude a file from a commit although it changed?
[20:29] <dato> dpm: maybe the executable bit was changed?
[20:29] <dato> well, 5 min was enough for mr. fredreichbier
[20:30] <dato> fullermd: what?!
[20:31] <fullermd> dato: Well, it doesn't actually make a new revision, but the file shows up for commit forever when the timestamp is changed.
[20:31] <dpm> ok
[20:46] <abentley> ﻿fredreichbier:﻿ specify all the files you *do* want to commit.
[20:47] <dato> abentley: he left (hence my comment)
[20:48] <abentley> dato: How dare he! :-)
[20:58] <ddaa> jelmer: ahoy
[23:46] <jelmer> ddaa: hi!
[23:47] <gmpff> I need to decide on a distributed VCS.
[23:47] <gmpff> What's the biggest advantage of bzr above the rest (i.e. hg, darcs, git, monotone) ?
[23:53] <lifeless> jelmer: just missed him :)
[23:53] <lifeless> gmpff: its nice to use ?
[23:53] <gmpff> lifeless: That sounds reasonable.
[23:56] <metajack> has anyone gotten bzr-svn to work on osx leopard with recent subversion trunk without segfaulting?  I followed instructions in the wiki, but it just crashes trying to fetch from an https url, and for svn+ssh it hangs.
[23:56] <lifeless> metajack: I don't know either way. jelmer: might
[23:57] <jelmer> metajack, does it hang for svn+ssh or is it just slow?
[23:57] <metajack> i thought it was just slow, but i let it run for quite a while. it was not chewing up memory or anything.
[23:57] <lifeless> gmpff: seriously, we're reasonably fast (and improving). For most things you want to do there is a way to do it in all of (dvcs*). There are some unique things in each dvcs,
[23:58] <gmpff> lifeless: I]
[23:58] <jelmer> metajack: If you run with -Dtransport it will write debug output into ~/.bzr.log
[23:58] <metajack> jelmer: ok, i'll do that quick.
[23:59] <gmpff> lifeless: I'm not too concerned about speed. More about easy branching and merging, seamless disconnected operation and serverless sharing.
[23:59] <lifeless> we have had a focus on doing the right thing, being truely lovable, from day 1. And we have an inode abstraction which gives us true renames (as far as I know that is unique to darcs and bzr)
[23:59] <lifeless> we have _very_ robust serverless sharing
[23:59] <lifeless> and branching is easy, as is merging