[00:01] <lifeless> very much so
[00:05] <poolie> hello jelmer
[00:05] <poolie> and lifeless and gary
[00:05] <lifeless> hai
[00:08] <poolie> jelmer: when you use bzr-svn on a svn repo that's had changes merged from a branch into trunk
[00:08] <lifeless> jelmer: not all bugs need tags :P
[00:08] <poolie> will bzr see the history of changes to a file on the branch before they're merged in?
[00:09] <jelmer> hi poolie
[00:09] <jelmer> poolie: In what context?
[00:10] <jelmer> lifeless: It's so easy to add them now I'm trying to add some that seem relevant when possible
[00:10] <jelmer> lifeless: I find them useful when looking for dupes
[00:10] <poolie> i think it's worth adding tags about proportional to the frequency you use them
[00:10] <poolie> i didn't use them much previously, now they're a bit useful
[00:11] <poolie> jelmer, well if you run log or annotate within bzr for example
[00:11] <poolie> the specific case was
[00:11] <jelmer> being able to edit them without having to go to a different page makes them a lot more useful
[00:11] <poolie> > 1. import /trunk/foo.txt
[00:11] <poolie> > 2. branch /trunk to /branches/mybranch
[00:11] <poolie> > 3. edit /mybranch/foo.txt
[00:11] <poolie> > 4. merge /mybranch to /trunk
[00:11] <poolie> will bzr see step 3?
[00:12] <lifeless> jelmer: I think tags that are reused a lot are great
[00:12] <jelmer> poolie: depends on how (4) was done
[00:12] <jelmer> poolie: if it was a merge done using bzr and pushed using bzr-svn, then bzr will see it
[00:12] <mwhudson> jml: is bzr 1.16 in any ppa yet?
[00:12] <jelmer> poolie: otherwise, it won't, even with svn 1.5 (since it only supports tracking cherrypick merges, not "full" merges)
[00:13] <lifeless> jelmer: but when there are few bugs for that tag its no better than searching
[00:13] <jelmer> lifeless: right
[00:14] <poolie> mwhudson: "apt-cache madison bzr"
[00:14] <poolie> well, assuming you have them all added
[00:15] <lifeless> poolie: rmadison bzr
[00:15] <lifeless> oh damn
[00:15] <lifeless> ppas
[00:15] <lifeless> rmadison should be able to query ppa
[00:15] <poolie> what's rmadison?
[00:15] <mwhudson> seems not
[00:15] <poolie> remote madison?
[00:15] <lifeless> yah
[00:15] <lifeless> queries lp/debian
[00:16] <lifeless> rmadison -u debian bzr
[00:17] <poolie> jelmer: in the mail i have, the person asserts that svn can follow the distory of that file
[00:17] <poolie> maybe because it didn't exist on trunk at all before the merge?
[00:18] <poolie> so svn just represented it as a copy (speculating)
[00:18] <poolie> in that case i think bzr-svn will track it?
[00:20] <lifeless> spiv: ping
[00:20] <poolie> where should we put the ppa debs?
[00:20] <poolie> i guess we could manually maintain an archive somewhere...
[00:21] <jelmer> poolie: svn would be able to see which revisions have been cherrypicked onto trunk
[00:21] <jelmer> poolie: but bzr isn't able to deal with cherrypicks, so bzr-svn ignores that data
[00:22] <jelmer> poolie: it could do analysis to see if a range of merged revisions is a "full" merge and then add the appropriate parents, but I'm worried about the performance of that analysis if it has to be done for each revision and it seems like it'd just be a stopgap until proper cherrypicking tracking is in place
[00:24] <poolie> right
[00:30] <garyvdm> Hi poolie
[00:33] <poolie> spiv, any ideas about bug 389087?
[00:35] <lifeless> jml: mwhudson: thumper: is https://bugs.edge.launchpad.net/bzr/+bug/372881 still affecting you ?
[00:37] <jml> lifeless, I couldn't say.
[00:38] <mwhudson> lifeless: haven't heard anyone complain about it for a while
[00:39] <jrwren> jam: i'm back to where I was at 16:45 EDT.  what is this trace class of which you speak for me to trace.mutter ?
[00:40] <jrwren> nvm, google first.
[00:40] <thumper> lifeless: not me personally
[00:48] <jrwren> will mutter messages always been output to STDOUT or STDERR?
[00:49] <jelmer> jrwren: only to ~/.bzr.log afaik
[00:49] <RenatoSilva> If I have two different features to implement and propose for merging, should I use one branch for each one, or one single branch?
[00:50] <jrwren> i don't have that file, do I need to touch it?
[00:50] <jrwren> or maybe on windows it goes to that APPDATA place?
[00:50] <Peng_> RenatoSilva: Two branches, if it makes sense. Obviously, if one depends on the other, that'd be harder.
[00:50] <Peng_> Could still use looms, I suppose.
[00:51] <RenatoSilva> Peng_: the problem is that the branch is a bzr plugin, and I'm using both modifications locally. They don't rely on each other, but I do reply on both of them :)
[00:53] <RenatoSilva> Peng_: maybe I could have 3 branches locally, 2 of them for development, and one for local use. I would merge the 2 branches into the thrid one once in a while. How about it?
[00:54] <Peng_> RenatoSilva: Sure.
[00:54] <RenatoSilva> ok, thanks
[01:01] <spiv> lifeless: pong
[01:02] <lifeless> network deltas
[01:02] <lifeless> I'm blocked on check, and picking the next thing to do
[01:03] <ebroder> How do people usually submit one-line patches to LP projects? Branch it and request a merge? Just file an LP bug?
[01:04] <lifeless> #launchpad might have a better answer; I'd say branch and submit a merge (without doing that its rather hard to test :P)
[01:04] <lifeless> but if its just a typo or something, sure  abug with a diff inline
[01:05]  * ebroder nods
[01:05] <lifeless> whatever gets the devs attention and is appropriate for the ammount of work really
[01:05] <ebroder> *shrug* I'm used to the amount of prep work for a fix being disproportional to the fix itself :)
[01:06] <spiv> poolie: regarding that AbsentContentFactory bug, it's almost certainly a dupe of 354036, those are both stacked branches that were created before 1.14.1.
[01:06] <spiv> (and I see it's already been marked as a dupe)
[01:07] <lifeless> spiv: 'network deltas' wass in reply to your pong
[01:10] <poolie> spiv, lifeless, thanks, i thought it probably was
[01:10] <lifeless> poolie: 'bzr info <branch>' is a fast way to check if branches are stacked
[01:11] <spiv> lifeless: network deltas would be great to do, I still haven't got to them :(
[01:13] <poolie> lifeless: i know, why?
[01:13] <poolie> i mean, why do you mention that?
[01:14] <lifeless> poolie: just seemed like the time to handoff that bug was about the same as doing a quick check and duping
[01:16] <RenatoSilva> Peng_: optionally, I can merge the 2 branches to the 3rd one, and keep the merge uncommitted. When I have new changes in the 2 branches, I just bzr revert and merge again. I think it's the easiest way...
[01:17] <poolie> sigh
[01:17] <lifeless> poolie: it was just a though
[01:17] <lifeless> t
[01:17] <poolie> if you actually mean to say "checking that it's stacked is a 100% reliable way to know it's a dupe" then that i didn't know
[01:17] <poolie> and i'm not sure i believe it
[01:18] <lifeless> poolie: its extremely high probability. In this particular case I know 100% that the current branch was a dupe, because I ran the fixer and it found missing inventories.
[01:18] <poolie> ok
[01:18] <lifeless> poolie: the lp-code people have not yet run the fixer across launchpad stacked branches
[01:18] <RenatoSilva> humm I can't merge twice without commiting the first merge :(
[01:18] <lifeless> RenatoSilva: you can by passing --force to merge; but its unusual to do this.
[01:19] <poolie> jam, are you still around? want to talk sometime?
[01:19] <RenatoSilva> lifeless: I'm afraidn you're following the discussion, but I think it's a good solution in my case, I'll try --force, thanks!
[01:20] <RenatoSilva> clear
[01:20] <lifeless> I did follow it.
[01:20] <RenatoSilva> clear
[01:20] <RenatoSilva> lifeless: ok
[01:21] <AfC> Is there a technical reason why the text metadata in a bundle all has to come at the beginning, _above_ the patch? Could we not have a one or so line header
[01:21] <RenatoSilva> the 3rd branch is read-only
[01:21] <AfC> # Bazaar merge directive format 3 (Bazaar 1.17)
[01:21] <AfC> and then the patch
[01:22] <AfC> and then the revision id crap?
[01:22] <AfC> or better yet,
[01:22] <poolie> AfC: probably not a good reason
[01:22] <poolie> possibly showing the target branch there is useful
[01:22] <lifeless> RenatoSilva: that doesn't make a difference AFAICT
[01:23] <lifeless> RenatoSilva: doing merge,commit,merge,commit and merge,merge--force,commit is not altered by the read state of the third branch
[01:23] <AfC> poolie: oh, still showing it (if necessary) but down below, after the patch, above the base64 [or whatever] blob of data
[01:23] <poolie> jam, nice work on bug 345998
[01:24] <RenatoSilva> lifeless: I mean that I won`t deliver the 3rd patch
[01:24] <RenatoSilva> lifeless: If I want to change something, I will do it in the other branches
[01:25] <RenatoSilva> lifeless: s/3rd patch/3rd branch
[01:35] <lamont> lifeless: how soon do you think 1.16 will be released?  (as in installable on an ubuntu box)
[01:35] <lamont> s/lifeless/poolie/
[01:35] <RenatoSilva> clear
[01:37] <lifeless> lamont: PPA should be up shortly
[01:37] <lifeless> johnf is reasonably prompt
[01:37] <lamont> yay
[01:38] <lifeless> he offers a two day SLA
[01:38] <lifeless> but - 1.16rc1 is pretty close to 1.16.
[01:38] <lamont> actually, there's a 1.16-1 in debian, I assume that should just work, no?
[01:38] <lifeless> and thats alrady in the ppa
[01:38] <lifeless> I'd expect so,yes
[01:38] <lifeless> just get it synced()
[01:38] <lamont> lifeless: I'm pretty sure you know why I'm asking, and what the rules are for me to live within.
[01:39] <lifeless> lamont: wasn't, but just noticed now.
[01:44] <lifeless> jam: are you still around at all?
[01:46] <lifeless> jelmer: help me understand https://bugs.edge.launchpad.net/bzr/+bug/386079
[01:49] <jelmer> lifeless: as far as I've understood it the problem is that if there's other svn dlls in directories in PATH those get used rather than the DLLs that subvertpy was linked against
[01:51] <jelmer> lifeless: so it's probably not important enough to be critical, but John would be better able to tell you
[01:53] <lifeless> thanks
[01:57] <garyvdm> lifeless: I got my widget to load lazily :-) And so for working trees, I only create copies of items that are shown.
[01:59] <lifeless> james_w: if you're around, is there a good link on bzr packaging at the moment?
[02:00] <lamont> lifeless: in the painful case, it's a merge of the diffs in 1.15->1.15-x to s/5/6/g
[02:00] <lifeless> there are diffs?
[02:00] <lamont> which is part of why I got out of that business
[02:01] <lamont> apt-get source is your friend
[02:01] <lamont> some of them are only a diff in debian/changelog
[02:01] <lifeless> garh
[02:01] <lamont> others have debian/control and debian/rules changes
[02:01] <lamont> others... well, ISTR one setup.py patch one time
[02:02] <poolie> jml, lamont suggests not doing the announcement mail until we have installers for say ubuntu and windows at least
[02:02] <poolie> interesting idea
[02:03] <lifeless> I don't like it
[02:03] <lifeless> because redhat + bsd + suse etc
[02:04] <lifeless> unless we want to take responsibility for building all of them too
[02:04] <lamont> lifeless: I do.  makes it get done before I get the privilege of explaining that it's not out to people who think I should install it NAO
[02:04] <lamont> lifeless: you could block on $everyplatform - that'd be more software industry standard
[02:04] <jml> poolie, for that to work & still have time-based releases, building those installers would have to be the RM's job, I think.
[02:04] <lifeless> lamont: the people in question should know better :)
[02:04] <poolie> well, making sure that someone builds it
[02:05] <jml> poolie, which would mean that building those installers would have to be as easy as falling off a log.
[02:05] <poolie> it tends to make the RM's job bigger
[02:05] <thumper> if I have a light weight checkout, can I just switch the underlying repository format under it?
[02:05] <poolie> which is undesirable
[02:05] <poolie> thumper: probably yes
[02:05] <lifeless> thumper: yes
[02:05] <thumper> move my packs repo out of the way, move 2a in and have it work
[02:05] <thumper> cool
[02:05] <lifeless> oh
[02:05] <jml> poolie, making sure someone builds it drags out the process further, because of hand-offs & TZ issues.
[02:05] <lifeless> actually 'no'
[02:05] <lifeless> thumper: the root data in the dirstate will be invalid
[02:05] <thumper> lifeless: why?
[02:06] <lifeless> of course, its likely that I've just realised that 'bzr upgrade' has a critical bug with respect to rich root changes
[02:06] <thumper> :(
[02:08] <lifeless> thumper: recreate the tree
[02:08] <thumper> ok
[02:08] <lifeless> thumper: you should do this for all trees when you upgrade the repo across a model change (non-rich-root to rich-root)
[02:08] <thumper> ok
[02:09] <lamont> lifeless: if the announcement said "we'll have binaries shortly" or some such, that'd help.
[02:09] <poolie> i think it normally does
[02:09] <lamont> right now, if I go to bazaar-vcs.org and click on what appears to be the link to go get ubuntu install info for 1.16, I get.... 1.15-1
[02:09] <lamont> which is kinda confusing to a newbie
[02:09] <poolie> which link?
[02:10] <lamont> Downloads and installation instructions
[02:10] <lamont> then  	
[02:10] <lamont> ppa repository,
[02:10] <lamont> downloads and install being a link under 1.16
[02:12] <lamont> which, of course is one of 2 ways that I check to see if it's out already.
[02:12] <lamont> the other being apt-get update; apt-get showsrc bzr | grep Version
[02:13] <thumper> lifeless: branching from my server to my laptop where both repos are 2a over bzr+ssh I'm getting CPU maxing on the server, and very little network traffic
[02:13] <thumper> lifeless: fetching revisions
[02:13] <RenatoSilva> clear
[02:14] <lifeless> thumper: is it an initial branch?
[02:14] <lifeless> thumper: that is, is the target repo empty?
[02:14] <lamont> anyway, family time gluing a floor down.  later.
[02:14] <thumper> lifeless: yes
[02:14] <lifeless> ciao lamont
[02:15] <lifeless> bug 388269
[02:15]  * thumper nods
[02:15] <thumper> ok
[02:16] <thumper> we probably want this fixed before everyone tries to grab LP :)
[02:17] <lifeless> not going to happen
[02:17] <lifeless> theres a bunch of stuff we /have/ to get done which if we don't things will be consistently bad much more often
[02:18] <lifeless> and you have a fixed date for the LP code; I don't see us getting through everything for 2 before then; *if* we do then perhaps - but this isn't a regression
[02:18] <lifeless> its been like this for a long time, and the LP code base is no worse than mysql's, AFAIK
[02:33] <Peng_> lifeless: ...I totally didn't know about merge --force. I'll have to remember that!
[03:20] <lifeless> igc1: ping
[03:22] <lifeless> jelmer: hi
[03:22] <lifeless> jelmer: I have a small request for you while you are touching bugs
[03:22] <ahn> I'm new to bzr and am trying to figure out a way to merge converted repositories.
[03:22] <Peng_> ahn: What exactly do you mean?
[03:23] <lifeless> jelmer: as you qualify as a dev, perhaps you could try to move the bug forward a step at the same time?
[03:23] <ahn> I have a bzr repository A, which is a conversion from CVS with full history, that includes versions from say 2000-2005.
[03:23] <ahn> I have a bzr repository B, which a conversion from darcs with full history, that includes version from say 2006-2009.
[03:23] <ahn> I'd like to know if there is a way to essentially "concatenate" the two repositories so that the histories are in series.
[03:24] <lifeless> jelmer: specifically, after you touch it, it should be either incomplete needing more info, waiting for someone more knowledgable than you to comment/analyse, or ready-to-code.
[03:24] <lifeless> jelmer: ^ not a requirement, but if you can, its actually more useful than merely categorising many bugs to do that to a smaller number of bugs
[03:25] <lifeless> ahn: what you may find works best is to export B as a fast-export and use fast-import to append it to A
[03:25] <ahn> lifeless: fast-import appends to an existing repository while preserving full history?
[03:26] <lifeless> I'm fairly sure it can
[03:26] <lifeless> of course, work on a backup until you've got the process tuned for you
[03:26] <lifeless> fast-export and fast-import are in the bzr-fast-import plugin
[03:26] <ahn> I will investigate, thanks.
[03:47] <Peng_> jelmer: FYI, you had a revision of bzr-rebase's trunk that marked it as compatible with bzr 1.16 and 1.17, but it's been replaced by the 0.5.1 release.
[04:34] <treeform> i am trying to get another project member using bzr
[04:34] <treeform> he he is running into all sort of porblems like this
[04:34] <treeform> http://pastebin.com/d58e1f99
[04:34] <lifeless> treeform: use a newer version, that bug was fixed
[04:35] <treeform> lifeless: thanks!
[04:36] <treeform> lifeless: hmm there is no 1.1.6 windows build yet
[04:36] <treeform> 1.1.6*
[04:36] <treeform> grr
[04:36] <treeform> 1.16*
[04:37] <lifeless> should be a 1.15.x one though
[04:37] <treeform> no they got new on up in another place
[04:38] <jml> https://edge.launchpad.net/bzr/1.16/1.16 has windows builds
[04:38] <treeform> thanks
[04:38] <treeform> but its not main link at the site
[04:40] <igc> hi all
[04:40] <igc> pong lifeless
[04:40] <treeform> sup igc
[04:41] <lifeless> igc: iter_changes; are you blocked/its on the shelf/its all done vis-a-vis commit?
[04:41] <lifeless> igc: if its on the shelf I may do it next week
[04:42] <jml> treeform, is now :)
[04:42] <igc> lifeless, it's on the shelf for at least a few more days
[04:42] <jml> (yay wikis)
[04:42] <igc> igc: if you got to it, that would be really great
[04:42] <igc> lifeless: ^^
[04:42] <lifeless> igc: ok. Monday I'll page it in and make a call about doing it/not.
[04:42] <treeform> jml: i love open source :)
[04:43] <igc> lifeless: sweet. I did put a fair amount into it but nothing beyond my initial terrible-to-ok-but-not-great patch that's worth sharing
[04:43] <lifeless> igc: kk
[04:49] <treeform> "bzr: ERROR: Unable to look up default port for ssh" ?
[04:49] <treeform> hmm its 20 or 22?
[04:50] <treeform> should bzr know that?
[04:50] <treeform> 22 wins!
[04:50] <lifeless> never seen that error before
[04:50] <lifeless> you might like to file a bug
[04:51] <treeform> http://pastebin.com/d79ccb48f
[04:51] <treeform> i think his problem is that
[04:51] <treeform> he cant break lock
[04:51] <treeform> because of this stupid ssh error
[04:51] <treeform> and he cant rebind
[04:51] <treeform> because of the stupid lock
[04:51] <lifeless> if you run with -Derror you will get a backtrace that may help debugging
[04:52] <treeform> is there a way to break lock manually?
[04:52] <lifeless> I'm not sure why you have a lock that needs breaking anyway
[04:52] <lifeless> that should be very rare
[04:52] <spiv> treeform: have you tried "bzr break-lock bzr+ssh://host:22/..." ?
[04:52] <treeform> no
[04:52] <treeform> there is no lock on the server
[04:52] <treeform> its local
[04:52] <treeform> i ran bzr break-lock on the server
[04:52] <treeform> nothing cameup
[04:53] <lifeless> run bzr unbind; bzr break-lock; bzr bind
[04:54] <spiv> Also, maybe your %SYSTEMROOT%\System32\Drivers\Etc\Services
[04:54] <spiv> needs fixing?
[04:54] <spiv> (that's just a wild guess, though)
[04:54] <lifeless> the backtrace will tell us
[04:56] <treeform> hmm
[04:56] <treeform> how to disable default bzr-tortouze stuff on windows?
[04:56] <treeform> his computer is lagging like hell because of it
[05:38] <lifeless> treeform: I'm not sure
[05:44] <treeform> i think i found it
[06:33] <RenatoSilva> any bzr-eclipse folk here?
[06:42] <johnjosephbachir> hey folks
[06:43] <johnjosephbachir> workflow question: i'm working on some code, i want to merge in upstream changes. i get the message "ERROR: Working tree "blah blah/" has uncommitted changes"
[06:43] <johnjosephbachir> what are my reasonable options here?
[06:43] <lifeless> either commit before merging, or shelve before merging
[06:44] <lifeless> merging changes your tree and then you need to commit what you merged
[06:45] <johnjosephbachir> what i want to do, is bring in the new changes, and then carry on with what i was doing.
[06:45] <johnjosephbachir> to do that, do i shelve, merge, unshelve?
[06:45] <lifeless> shelve; merge; commit; unshelve
[06:45] <johnjosephbachir> ahhhh
[06:45] <johnjosephbachir> okay
[06:45] <johnjosephbachir> thanks!
[06:45] <lifeless> or
[06:45] <lifeless> commit; merge; commit
[06:46] <lifeless> depending on whether you have reached a suitable point to commit your own changes
[06:46] <johnjosephbachir> yeah, i haven't
[06:47] <johnjosephbachir> okay, i just did bzr shelve, and then y y y y
[06:47] <johnjosephbachir> but bzr status still shows modified files
[06:47] <johnjosephbachir> do i need to manually rever them?
[06:47] <johnjosephbachir> by manually i mean, explicitely, with bzr
[06:47] <lifeless> uhm
[06:47] <johnjosephbachir> and/or: won't merge still complain?
[06:48] <lifeless> 'bzr shelve --all' should save everything such that 'bzr st' will show no changes
[06:48] <johnjosephbachir> okay
[06:48] <lifeless> if it doesn't, what bzr version are you using?
[06:53] <johnjosephbachir> --all did it
[06:53] <johnjosephbachir> i wonder if i was hitting y / return so fast that it missed a couple ys
[06:55] <lifeless> johnjosephbachir: I'd say so ;)
[06:55] <ttyType> hi people
[06:55] <ttyType> my kitteh just managed to catapult my spoon out of my cereal bowl, so my monotor was covered in soy milk spatter
[06:55] <ttyType> (it's a lappy)
[06:56] <ttyType> it looked like someone has been looking at pr0n
[06:56] <ttyType> *monitor
[07:19] <poolie> anyone want to comment on the proposed phrasing in bug 346677?
[07:41] <spiv> poolie: commented
[08:27] <poolie> thanks spiv
[08:39] <treeform> hmm lifeless, jml  windows bzr just not working for us... the guy i was working with gave up
[08:40] <jml> treeform, that sucks.
[08:40] <treeform> i dont know what to do
[08:40] <treeform> i been using bzr for so long
[08:41] <treeform> but when other people try to use it it just breaks for them
[08:41] <jml> treeform, there's a couple of things I can think of.
[08:42] <treeform> part of the problem might be that the bzr repo is 1GB of data
[08:42] <jml> treeform, the first is look for the failures in Bazaar's bug tracker: https://bugs.launchpad.net/bzr
[08:42] <treeform> and we dont have great network connectsion
[08:42] <treeform> so its always a bother pushing this much data around
[08:43] <treeform> jml: i have opend some bugz in that list
[08:43] <jml> treeform, although my mental powers are to be greatly feared, they do not extend to mind-reading.
[08:44] <vila> hi all
[08:44] <treeform> well what do you want me to do?
[08:44] <jml> treeform, explicitly describing the observed failures is often half the battle.
[08:45] <treeform> yeah
[08:45] <jml> vila, hi :)
[08:45] <lifeless> treeform: where did you get stuck with your friend?
[08:45] <treeform> when working with some one who is not verly technical its a real pain
[08:45] <vila> jml: hey !
[08:45] <lifeless> I'm not really here right now
[08:45] <lifeless> but I'd say
[08:45] <lifeless> be sure they don't run random commands, if they are having trouble flailing will make it worse.
[08:45] <lifeless> if bzr gives an error that you don't recognise file a bug etc
[08:46] <treeform> well it started out with sftp
[08:46] <treeform> basically i did an update
[08:46] <treeform> it did a repack
[08:46] <treeform> and it when redownloading everything
[08:46] <treeform> so i say
[08:46] <treeform> hmm
[08:47] <treeform> ok lets switch to bzr+ssh
[08:47] <treeform> just kill the update
[08:47] <treeform> which was running now for 2 hours
[08:47] <treeform> so he broke it
[08:47] <treeform> now lets rebind
[08:47] <treeform> cant
[08:47] <treeform> its locked
[08:47] <treeform> lets break lock
[08:47] <treeform> cant break lock
[08:47] <treeform> then you guys suggested to update
[08:47] <treeform> ok we update
[08:47] <treeform> still cant break lock
[08:48] <treeform> because now we cant ssh
[08:48] <treeform> so another thing broke during update
[08:48] <treeform> on the other hand i cant really blame bzr
[08:48] <treeform> because its turning more into people problem then a software problem
[08:48] <treeform> --- end of rant --- sorry
[09:05]  * igc dinner
[09:17] <jml> treeform, the situation certainly sounds complex.
[09:17] <jml> treeform, maybe sending an email to the bazaar list is your best bet.
[09:18] <treeform> bzr is being blamed for making computer run really really slow
[09:18] <treeform> it can be a virus
[09:18] <treeform> he is uninstalling to conform
[10:09] <jtv> jml: more bzrlib complications...  I think I need to get a trans-id for a directory in my revision tree.
[10:09] <jtv> I know how to get its id, but not its trans id.
[10:11] <lifeless> doesn't exist
[10:11] <lifeless> trans-ids only exist during a tree transform, they are transient
[10:11] <lifeless> why do you think you need it
[10:11] <lifeless> ?
[10:16] <jtv> lifeless: nm, I've got it now, from the transform preview.
[10:16] <jtv> lifeless: this is still for the direct-commit-to-branch stuff.
[10:56] <poolie> spiv, lifeless, bug 389413 is strange
[10:57] <poolie> is that a dupe maybe?
[10:57] <lifeless> poolie: are you burning out? logoff :)
[10:57] <poolie> mm, why?
[10:57] <poolie> should i know what it is?
[10:57] <spiv> I think he's saying it's nearly 8pm :)
[10:57] <lifeless> no, uhm have you seen Jono's talk on burnout?
[10:58] <spiv> (I'm certainly about to logoff...)
[10:58] <poolie> i believe it is that time in the northern suburbs too :)
[10:58] <poolie> i am too actually
[10:58] <poolie> i'm staying on because i'm enjoying it
[10:58] <lifeless> I'm online, but doing personal stuff
[11:00] <spiv> poolie: if it's a recent regression, the traceback suggests it may be fallout from my get_rev_id_for_revno patch.
[11:01] <poolie> mm i thought so
[11:01] <spiv> In which case I'd guess cmd_diff isn't locking early enough...
[11:01] <poolie> it should go without saying you don't need to fix it tonight :)
[11:01] <poolie> i was just wondering
[11:02] <poolie> otoh launchpad seems pretty fast after the 1.16 rollout
[11:03] <LarstiQ> moin
[11:03] <spiv> Yeah, I won't fix it tonight :)
[11:03] <spiv> cmd_diff isn't exactly trivial ;)
[11:03] <spiv> Well, it is, but the helper it calls isn't...
[11:05] <spiv> G'night all :)
[11:06] <lifeless> spiv: more likely a remote.py bug
[11:06] <lifeless> unless its using --old or something
[11:06] <spiv> lifeless: maybe, either way it's my fault ;)
[11:07] <lifeless> :P just trying to aim things :)
[11:07] <lifeless> as pack_repo is very strict on locks itself
[11:11] <poolie> ok, good night
[11:25] <vxnick> hi guys - I'm getting the following error when trying to commit: bzr: ERROR: No such file: '/home/vxnick/bzr/repo_name/trunk/.bzr/branch/last-revision': [Errno 2] No such file. This happened after I had to break-lock because bzr commit was hanging
[11:26] <vxnick> this is also a remote repo
[11:26] <lifeless> you shouldn't ever need to break-lock
[11:26] <lifeless> unless bzr advises you to
[11:27] <lifeless> have a look in that directory, see if there is a last-revision.* - some sort of tem file
[11:27] <lifeless> temp
[11:27] <vxnick> yeah there is
[11:28] <vxnick> there's two - one with a prefix of tmp and one with a suffix of tmp
[11:28] <lifeless> check the datestamps
[11:28] <lifeless> and/or the contents
[11:28] <lifeless> one will will have higher revno and be newer
[11:28] <lifeless> rename that to last-revision
[11:28] <lifeless> why did you think commit had hung?
[11:29] <vxnick> I think my connection to the server was dodgy
[11:29] <vxnick> it took 6 minutes to commit a couple of lines
[11:29] <lifeless> are you using sftp ?
[11:29] <vxnick> yeah
[11:29] <lifeless> ok, that could explain it; with sftp we cannot do atomic operations so we emulate
[11:30] <vxnick> I've been looking at using the bzr server but am unsure as to how stable it is atm
[11:30] <lifeless> that should be the only oddity you'll have; if you can use bzr+ssh it will be faster and more robust
[11:30] <lifeless> we're still evolving it but as a user you shouldn't notice that.
[11:31] <vxnick> is "bzr serve" the same as SmartServer?
[11:31] <lifeless> yes
[11:31] <vxnick> thanks
[11:31] <lifeless> you can just install bzr on the server
[11:31] <lifeless> and then replace sftp with bzr in your urls
[11:31] <vxnick> I need to use ~/.bazaar/authentication.conf for the server don't I?
[11:31] <lifeless> unless you have /~/ in your url, in which case you need to change that to an absolute path
[11:31] <fullermd> ITYM "with bzr+ssh".
[11:31] <lifeless> sorry, as fullermd says, with 'bzr+ssh'
[11:32] <lifeless> vxnick: no, it uses ssh, same as sftp
[11:32] <vxnick> gotcha
[11:32] <lifeless> vxnick: there should be no need to change anything else.
[11:33] <fullermd> vxnick: The smart server actually has 3 different interfaces, but you can ignore two of them and just use bzr+ssh (no need to config anything on the server beyond having bzr installed and in $PATH)
[11:33] <vxnick> it's more efficient than using sftp right?
[11:33] <fullermd> In general, it's somewhat more efficient.  Occasionally, it's mind-zonkingly more efficient.
[11:33] <vxnick> :)
[11:35] <vxnick> lifeless: thanks for your help with the last-revision, it seems to be working now :)
[13:52] <vila> jam: Pping
[13:53] <vila> err, ping I meant
[13:58] <ddaa> Hey. Where can I read about bzr new shiny beta branch format?
[13:58] <ddaa> ("in the mind of bzr devs, Spock-style" is not an acceptable answer)
[14:16] <vila> ddaa: ML archives, doc/developers, sources :)
[14:17] <ddaa> vila: can you give me a single URL?
[14:17] <ddaa> I stopped reading the ML eons ago because I want to have other sources of informations and still do something in my day.
[14:17] <vila> ddaa: bazaar-vcs.org has docs online AFAIR
[14:21]  * LarstiQ has a look
[14:22] <LarstiQ> ddaa: http://doc.bazaar-vcs.org/latest/developers/improved_chk_index.html is not what you're looking for I suppose
[14:23] <LarstiQ> ddaa: http://doc.bazaar-vcs.org/latest/developers/development-repo.html
[14:23] <ddaa> definitely interesting, I'll put it on my reading list, but a weeeee bit too detailed.
[14:23] <LarstiQ> yes
[14:23] <LarstiQ> and the later one is a bit stingy on details
[14:24] <ddaa> the later one appearst to be a process document
[14:24] <ddaa> not a technical summary
[14:25] <LarstiQ> ddaa: sorry, at the very end
[14:25] <LarstiQ> ddaa: http://doc.bazaar-vcs.org/latest/developers/development-repo.html#format-details
[14:25] <ddaa> Right, thanks.
[14:26] <ddaa> So in summary: 1. groupcompress delta 2. CHK inventory store
[14:27] <bialix> jam: hi
[14:27] <ddaa> could use something intermediate between that and the chk_index spec :)
[14:37] <vila> ddaa: patches welcome :)
[14:37] <ddaa> I'll just wait for the bargraphs
[14:38] <ddaa> sooner or later jam will generate new ones because they are known to make Mark happy :)
[14:40] <bialix> ифкпкфзры,
[14:40] <bialix> bargraphs?
[14:52] <vila> bialix: graphics  with bars to show results (sales, performances, etc)
[14:57] <bialix> sales... sounds good
[15:03] <LarstiQ> bialix: the ones jam makes are usually about performance :)
[15:03] <jam> hi bialix, ddaa
[15:04] <bialix> jam: hi
[15:04] <jam> ddaa: http://jam-bazaar.blogspot.com/2009/03/brisbane-core.html ?
[15:04] <ddaa> jam: hi
[15:04] <bialix> LarstiQ: vila knows better ;-) I guess
[15:04] <jam> vila: pong
[15:04] <ddaa> jam: thanks, readitlatered
[15:06] <bialix> jam: I think the size of imageplugins could be dramatically reduced
[15:06] <bialix> I'm just not sure how to write the support for bundling them into bzr.exe
[15:06] <bialix> what version of PyQt4 you have installed on your build machine?
[15:06] <vila> jam: The needds fixing was about gdfo to be declared as long right ?
[15:07] <vila> jam: auddenly I had a doubt about 'Needs Fixing' == 'tweak'
[15:07] <jam> vila: and generally pyrex improvements
[15:07] <jam> vila: which I was willing to work on before we land
[15:07] <vila> ha, so I don't submit then ?
[15:07] <jam> I have no idea what is "tweak" versus what is "resubmit"
[15:08] <jam> bialix: I'll check
[15:08] <vila> jam: resubmit exists as such...
[15:10] <jam> vila: resubmit actually *resubmits* the request
[15:10] <jam> as in, start a new merge request
[15:10] <jam> not, "come back later with a new one"
[15:10] <jam> more "I updated my branch, here is a resubmitted version"
[15:10] <jam> bialix: py -c "import PyQt4.QtCore; print PyQt4.QtCore.qVersion()" gives
[15:11] <jam> '4.4.1'
[15:13] <bialix> thx
[15:14] <abentley> jam, there's a bug in reconcile that's affecting mars.  Any chance you can take a look at it? https://pastebin.canonical.com/18735/
[15:15] <jam> abentley: I think that is the wrong paste
[15:15] <jam> that is a 'bzr info' one
[15:15] <abentley> jam: Sorry, it's a bit hectic in #launchpad-code today.  https://pastebin.canonical.com/18733/
[15:16] <abentley> jam: We upgraded to the 2a format overnight.
[15:16] <jam> ah
[15:17] <jam> abentley: .... the traceback makes no sense
[15:17] <jam> build_details is a dict
[15:17] <jam> but "iteritems" is just a method
[15:17] <abentley> jam: could it be a mismatch between the .py and the .pyc?
[15:17] <jam> abentley: possibly
[15:18] <jam> certainly _get_components_positions() is used all the time
[15:18] <jam> and not just for reconcile
[15:18] <jam> I wonder if there might be a bug in the compiled extensions.
[15:18] <jam> He might try without them
[15:18] <jam> (at least that random of an error makes me wonder about random memory corruption.)
[15:26] <mars> hi jam
[15:26] <mars> jam, would you be able to tell me how I would go about running bzr without the extensions?
[15:43] <jam> mars: well, the easiest is to grab a tarball of bzr, extract it into a folder
[15:43] <jam> and then run from there
[15:44] <jam> without running 'make' first
[15:44] <jam> https://edge.launchpad.net/bzr/1.16/1.16
[15:44] <jam> you can just do "~/path/to/bzr reconcile"
[15:44] <jam> (we support running directly from the source tree)
[15:44] <jam> sorry, I'll be a bit in and out for the next couple of hours
[15:45] <mars> jam, ok, I'll give that a try
[15:46] <vila> jam: if you intend to work on it, be sure to grab the latest from lp:~vila/bzr/gdfo-heads/
[15:46] <jam> mars: As an added bonus, that makes it easier for us to tweak things and see what works
[15:46] <jam> if it *does* work that way
[15:46] <jam> then try running "make"
[15:46] <jam> mars: (first copy your repo)
[15:46] <jam> and see if "bzr reconcile" breaks after "make"
[15:47] <jam> (well, "~/path/to/bzr")
[15:47] <mars> right
[15:56] <vila> Oook ?
[15:57] <vila> abentley:     from bzrlib.plugins.bzrtools.tests import test_fetch_ghosts
[15:57] <vila> ImportError: cannot import name test_fetch_ghosts
[15:57] <vila> abentley: I was so sure you fixed that 8-/
[15:58] <abentley> vila: Should be there as of revno 709
[15:58] <mars> abentley, before running the bzr reconcile, should I reset the repository state?  Perhaps by copying backup.bzr to .bzr, or something similar?
[15:58] <vila> 715...
[16:00] <abentley> mars: I'm not clear whether reconcile creates backup.bzr
[16:00] <vila> abentley: eeerk ! system-wide plugin ! Sorry for the noise
[16:00] <mars> abentley, ah, right, it could have been the 1.6 upgrade
[16:00] <abentley> vila: np
[16:42] <visik7> hi
[16:42] <visik7> a question
[16:43] <visik7> if A commit to revision 1 than B commit to revision 2 than A modify a file and update to rev 2
[16:43] <visik7> does the file get a conflict ?
[16:45] <mars> hmm.  if bzr reconcile runs the disk out of space, it doesn't clean up after itself after aborting, thus cleaning up the space it used :(
[16:47] <luks> visik7: that depends on the changes
[16:48] <visik7> luks: in which sense ?
[16:48] <luks> visik7: they might conflict or not :)
[16:48] <luks> if they change the same code in a different way, it will report a conflict
[16:49] <luks> but if they change e.g. different function, it will not
[16:53] <visik7> no wait
[16:53] <visik7> A put a revision 1
[16:53] <visik7> with 2 files
[16:54] <visik7> for example with main.c and functions.c
[16:54] <visik7> B commit rev 2
[16:54] <visik7> modifying file function.c
[16:54] <visik7> now A modify main.c
[16:54] <visik7> and before commit he run an update
[16:55] <visik7> the conflict should not happen, right ?
[16:55] <luks> right
[16:57] <visik7> ok now I'm going to check why it had happen
[17:05] <mars> abentley, found a new bzr reconcile issue using the tarball, san-extensions, as jam suggested: SHA1KnitCorrupt: https://pastebin.canonical.com/18752/
[17:07] <abentley> mars: I'm not sure what to do about that.
[17:08] <jam> abentley: given that this is an inventory, and that it is mismatching the raw content, I'm guessing its our old friend
[17:08] <jam> inventories not consistent with inconsistent ghosts
[17:08] <jam> it is also failing on the Knit side
[17:09] <jam> not the GC side
[17:09] <jam> certainly that is a different error, but I don't understand why you would ever be getting the first one
[17:09] <jam> hmm... maybe in an exception clause, let me check
[18:33] <flacoste> I'm trying to move a LP branch from my old repo to a 2a repo
[18:33] <flacoste> and i get this error:
[18:33] <flacoste> KnitCorrupt: Knit <bzrlib.groupcompress._GCGraphIndex object at 0x7f925da0e510> corrupt: inconsistent details in add_records: ('53507751 66036 91238 118445', ((('01creation.txt-20071122132843-ajpxh023ndwrzebk-2', 'kiko@canonical.com-20080801032521-84uzp66nlpu511ur'), ('01creation.txt-20071122132843-ajpxh023ndwrzebk-2', 'abel.deuring@canonical.com-20090612090543-dz2kjihx7jnbj0f6')),)) ('65 580329 1680183 1707390', ((('01creation.txt-
[18:33] <flacoste> 20071122132843-ajpxh023ndwrzebk-2', 'abel.deuring@canonical.com-20090612090543-dz2kjihx7jnbj0f6'),),))
[18:34] <flacoste> i did run bzr reconcile in the old repo beforehand
[18:43] <jam> flacoste: weird. for the file "01creation.txt" in a given revision
[18:43] <jam> one side claims 2 parents
[18:43] <jam> the other side claims only a single parent
[18:44] <jam> both claim "abel.deuring..." but the first claims "kiko@canonical"...
[18:44] <flacoste> unfortunately, i have no idea on why this is happening
[18:44] <jam> so... you *do* have inconsistent information for that entry... but I couldn't tell you why
[18:44] <jfroy> jelmer: thanks for the two bug fixes
[18:44] <flacoste> jam: anything i can do about it?
[18:44] <jam> flacoste: well, other than cry?
[18:44] <flacoste> jam: or should I just recreate a new branch and apply a diff?
[18:45] <flacoste> ok!
[18:45] <jam> flacoste: how big is the branch?
[18:45] <jam> how important?
[18:45] <flacoste> it's trivial to recreat
[18:45] <jam> We can try, but it would take time and effort
[18:45] <flacoste> e
[18:45] <flacoste> not even a 100 lines
[18:45] <flacoste> i'm reporting it more as part of the dogfood effort
[18:45] <flacoste> and making it a super experience for everyone else
[18:46] <flacoste> i think it points either to a bug in reconcile
[18:46] <flacoste> or in the uprade to 2a
[19:33] <jelmer> jfroy: can you still reproduce bug 269669?
[19:34] <jfroy> jelmer: I have not seen that bug again
[19:34] <jfroy> I doubt I can reproduce it either.
[19:34] <jfroy> Closing as invalid.
[19:34] <jelmer> jfroy: thanks
[19:35] <jfroy> For the record, Invalid is a lame status :p
[19:35] <jfroy> I'd prefer "No to be fixed" or "Works as designed™"
[19:35] <bialix> jelmer: did you saw bzr-svn test.log @ win32?
[19:36] <jelmer> bialix: no, where was that?
[19:37] <bialix> yesterday
[19:37] <bialix> http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/59156
[19:37] <jelmer> bialix: thanks
[19:38] <bialix> maybe you need to persuade jam to get tdb bundled into bzr.exe
[19:39] <jelmer> I doubt it builds on windows
[19:40] <bialix> ah
[20:13] <johnjosephbachir> how do i view the differences between my local committed code, and the code in the remote repo to which i push?
[20:14] <beuno> johnjosephbachir, I use:  bzr send REMOTE_BRANCH -o review.diff
[20:14] <johnjosephbachir> beuno: muy bueno, thanks, i'll read the docs on send and the -o flag
[20:15] <dash> hm, i think the other way is "bzr diff -rsubmit:"
[20:21] <bialix> bzr diff -rbranch::push
[20:22] <dash> hah, ok. I didn't know about :push
[20:23] <bialix> there is a few of them
[20:23] <bialix> :parent, :submit
[20:23] <bialix> I'm not sure where these aliases actually documented
[20:24] <bialix> but I'd stick to beuno reciepe
[20:25] <fullermd> I'm pretty sure they're not.
[20:25] <jskulski> hey I'm using bzr-svn to work with a svn repository (initially i bzr branch file://var/svn..) now I am trying to get updates from that repository, bzr update says i am updated, bzr pull and merge fail saying I have uncommited changes
[20:26] <jskulski> can anyone give me some direction
[20:26] <dash> 'bzr update' just makes sure your working tree is in sync with your local branch
[20:27] <bialix> look what `bzr status` says
[20:27] <dash> jskulski: you can't bring in new changes from a remote branch (your svn repo) if you have uncommited changes to your working copy
[20:27] <Tak> what? since when?
[20:27] <dash> jskulski: what I usually do in that case is 'bzr shelve' if it's changes I want to keep
[20:27] <jskulski> dash is that just part of the bzr workflow? (I am new to bzr and DVCS in generall)
[20:27] <jskulski> bialix i have a few unknown files and one modified
[20:27] <bialix> dash: I think pull should work even if you have uncommitted changes
[20:27] <dash> jskulski: yes
[20:28] <bialix> try bzr pull
[20:28] <bialix> bzr pull ~= svn update
[20:28] <Tak> pull Works For Me when I have uncommitted changes - I do this all the time
[20:28] <dash> oh, true. pull works
[20:28] <dash> i got confused :)
[20:28] <jskulski> i get
[20:28] <jskulski> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[20:29] <bialix> I suspect this
[20:29] <dash> right. so in that case you _do_ need to shelve or commit (or revert) your changes until the merge is done
[20:29] <bialix> you can bzr merge --force
[20:29] <bialix> but better if you to do as dash said
[20:30] <Tak> if you commit changes, you'll still have to merge
[20:30] <dash> well. no matter what you'd still have to merge
[20:30] <bialix> jskulski: you can compare 2 branches with `bzr missing` and you'll see what the difference in histories
[20:31] <jskulski> yaya
[20:31] <bialix> naturlich
[20:32] <jskulski> i shelved my changes and bzr merged, it pulled it changes, and unshelved
[20:32] <jskulski> thanks bialix Tak dash
[20:32] <jskulski> !
[20:32] <dash> <3
[20:32] <bialix> it was easy
[20:33] <jskulski> yeah
[20:33] <bialix> dash: what it means? (<3)
[20:33] <jskulski> <3
[20:35] <bialix> interesting...
[20:36] <dash> bialix: it is supposed to be a heart shape.
[20:37] <bialix> and?
[20:39] <bialix> igc made incredible work with bzr explorer
[20:44] <jfroy_> jelmer: do you foresee problems with doing uncommits?
[20:44] <jfroy_> on a local branch of a svn branch
[20:44] <fullermd> bialix: Oh, BTW, since I got my new workstation up, I finally got to try out qlog.  Pretty nifty.
[20:45] <bialix> fullermd: kudos to garyvdm
[20:46] <fullermd> I did come across one or two wishlist items...
[20:47] <bialix> about?
[20:48] <fullermd> I'd like to be able to 'expand all' on the merge revs.
[20:48] <bialix> yep, sometimes me too
[20:49] <fullermd> And maybe set the diff window to default to unidiff mode rather than SxS.
[20:49] <bialix> you can send your feedback to qbzr ml, or file a bugs
[20:49] <bialix> qdiff should be controlled via command-line options
[20:50] <bialix> or you talking about invoking qdiff from qlog?
[20:50] <fullermd> From qlog, yah.
[20:50] <bialix> yep
[20:51] <bialix> bug a file
[20:52] <johnjosephbachir> how can i see the results of bzr revert?
[20:52] <beuno> johnjosephbachir, bzr diff
[20:52] <johnjosephbachir> beuno: okay, i'll check that out... but what about, just simply obvserving the basic state of my repo?
[20:52] <johnjosephbachir> i.e., what i have reverted back to?
[20:53] <bialix> bzr cat?
[20:53] <johnjosephbachir> haha
[20:53] <dash> 'bzr log -l1' maybe
[20:54] <johnjosephbachir> dash: exactly-- that does NOT change after i run revert
[20:54] <dash> not sure i understand the question
[20:54] <bialix> johnjosephbachir: your question is also haha
[20:54] <fullermd> johnjosephbachir: revert doesn't change anything in the branch/repo; it only affects your working tree.
[20:54] <dash> yeah i was just thuinking that
[20:54] <dash> thinking
[20:54] <fullermd> So it would never affect log or like commands.
[20:55] <johnjosephbachir> okay
[20:56] <johnjosephbachir> bzr diff has no output.
[20:57] <bialix> anybody knows how can I made good looking screenshot page at http://bazaar-vcs.org/BzrExplorer/Screenshots?
[20:57] <bialix> for some reason moin stretch the images
[20:58] <johnjosephbachir> bialix: when you suggested cat, i was hahaing my own ineptness at presenting my question
[20:59] <johnjosephbachir> fullermd: after i run revert, how can i then observe the changes that it made to my working tree?
[20:59] <bialix> if you revert then you lost your changes
[20:59] <Tak> bzr time-machine?
[21:00] <dash> johnjosephbachir: are you talking about 'bzr revert -r somerev'?
[21:00] <johnjosephbachir> dash: i thought revert went back a changeset at a time with each invocation
[21:00] <dash> no
[21:00] <fullermd> Well, it'll [under some circumstances] make backups of the files it changes named like $FILE.~1~.  That's not necessarily reliable across multiple reverts though, and it doesn't tell you anything about renames etc. that it reverted.
[21:01] <johnjosephbachir> Tak: lol
[21:01] <dash> johnjosephbachir: with no args, revert just removes existing differences with the branch tip from the WC
[21:02] <johnjosephbachir> dash: Oh. Okay. That sounds very subversion-like. for some reason i thought it was different. so revert is still the best way to roll back changesets, right? (with the -r flag)
[21:03] <bialix> no, you need uncommit for this
[21:03] <fullermd> I think a much more precise definition of "roll back changesets" is needed to answer that...
[21:03] <dash> yeah, this is different from svn, 'bzr revert -r X' is equivalent to 'svn up -r X'
[21:03] <johnjosephbachir> bialix: fullermd: dash: okay, that clears everything up -- thank you!
[21:04] <fullermd> Not exactly it's not...
[21:04] <dash> so if you want to create a new revision that undoes the changes of a previous one, sure. 'bzr revert -r X', 'bzr ci'
[21:04]  * bialix nods
[21:04] <dash> fullermd: i should have said "analagous to"
[21:04] <dash> since bzr and svn are obviously different. :)
[21:05] <johnjosephbachir> bialix: yeah i was thinking of uncommit dash: right, so that is the svn way, but uncommit is the bzr way (more or less)
[21:05] <dash> johnjosephbachir: eeeeh
[21:05] <fullermd> But that doesn't undo [X+1], it commits the state exactly as of X.  So it would undo _any_ changes you made post-X, not just those in [X+1].
[21:05] <dash> johnjosephbachir: uncommit actually removes commits from your branch
[21:05] <johnjosephbachir> dash: yep, that's what i want in this case.
[21:06] <dash> johnjosephbachir: the main use case for that is when you check stuff in, and befor you push, realize you made a mistake
[21:06] <johnjosephbachir> yeah
[21:06] <johnjosephbachir> exactamente
[21:06] <dash> if you've already shared this revision with other people, it's often a good idea to not do that. :)
[21:07] <Tak> hmm, if you uncommit, it tells you the branches diverged when you try to push, doesn't it?
[21:07] <dash> Tak: if you uncommit stuff that's in the remote branch, yes
[21:08] <bialix> push --overwrite can do magic
[21:08] <dash> "do magic" means "break things" ;-)
[21:10]  * fullermd grabs a Dremel and does magic.
[21:10] <bialix> rats
[21:10] <bialix> this moinmoin made me crazy
[21:12] <bialix> what's wrong with my png?
[21:13] <bialix> pheww
[21:13] <bialix> firefox increase images
[21:15] <johnjosephbachir> grrr. my ports system doesn't have bzrtools up to date for my version of bzr
[21:16] <johnjosephbachir> so i can't use clean-tree
[21:17] <fullermd> Which ports system?
[21:17] <bialix> install by hands, no?
[21:17] <johnjosephbachir> macports
[21:17] <fullermd> What versions does it have?
[21:18] <johnjosephbachir> bzr 1.15, bzrtools 1.13
[21:19] <johnjosephbachir> i'm installing from source now... does the main source distribution have bzrtools or do i have to install that separately?
[21:20] <fullermd> Well, the quick short solution would be to grab the bzrtools 1.15 tarball and stick it in your ~/.bazaar/plugins/.
[21:20] <fullermd> That saves you from doing any system-wide screwing around.
[21:21]  * fullermd grumbles at the wiki.
[21:21] <johnjosephbachir> fullermd: ah okay-- fantastic
[21:22] <johnjosephbachir> fullermd: worked perfectly, thank you so much, you saved me 30 minutes of pain
[21:23] <fullermd> You'll get my bill in the mail   ;)
[22:08] <johnjosephbachir> bzr is throwing an exception when i try to unshelve something... is there any way i can save my shelved changes?
[22:09] <dash> they're in .bzr/checkout/shelf
[22:11] <johnjosephbachir> yay
[22:11] <dash> what's the exception?
[22:11] <johnjosephbachir> https://bugs.launchpad.net/bzr/+bug/389674
[22:13] <dash> Oh dang
[22:13] <dash> that's not happy
[23:42] <mwhudson> jelmer: hi, do you know anything about this failure? https://code.edge.launchpad.net/~vcs-imports/mnemosyne-proj/maemosyne
[23:54] <lifeless> wow, odd to have maemosyne in git... mnemosyne is bzr