[02:33] <quotemstr> Let's say I make commits (from Base) C1, C2, and C3 and submit them each to an upstream project as a patch. I realize there's an error in C1 and make a fourth commit, C4, to fix it. How can I generate a new patch that includes the changes of C1 and C4 without C2 and C3?
[02:33] <quotemstr> Do I just have to back everything else out and rebase?
[02:35] <lifeless> commit it in a branch just for c1+c4; merge that to trunk, send [c1,c4] as the patch
[02:36] <quotemstr> Ugh. Making a non-stacked branch takes forever.
[02:36] <quotemstr> Thanks.
[05:01] <wildintellect> so I'd like to checkout a copy of an svn repo, work on it a bunch pushing changes to a lp bzr repo, and when I'm done in a few weeks merge back into svn
[05:02] <wildintellect> http://doc.bazaar.canonical.com/latest/en/user-guide/svn_plugin.html seems close but bzr push sends to svn when I would want it to my lp repo for now
[05:03] <wildintellect> maybe I should just do an svn checkout then bzr init over the top of the same directories
[05:03] <wildintellect> using bzr to manage my branch work and when done use svn to merge it back into the svn repo?
[05:03] <wildintellect> guess that would lose the commit history
[05:05] <Kamping_Kaiser> and make it hard to merge
[05:05] <Kamping_Kaiser> wildintellect: change your push target while you work on it
[05:05] <wildintellect> I think I wasn't reading that page close enough
[05:06] <wildintellect> can I have different push locations for each bzr branch I make?
[05:06] <Kamping_Kaiser> wildintellect: check the docs for push_location and submit_branch. (parent_location should be the svn repo)
[07:55] <sobersabre> hi
[07:55] <sobersabre> Is there a way to track file permissions with bzr ?
[07:55] <sobersabre> (I know it's "metadata", but still)
[07:58] <spiv> sobersabre: not built-in.  There are tools like etckeeper though.
[08:38] <sobersabre> spiv: hmmm... nice tool. does it source current permissions into some kind of text file and then processes it to ensure the perms are intact ?
[08:44] <jelmer> sobersabre: yep, basically
[09:09] <sobersabre>  jelmer ok.
[10:26] <knittl> is bzr able to perform cross project merges?
[10:51] <knittl> ok, it can
[12:56] <jml> ed
[13:05] <jelmer> jml: old school!
[13:08] <jml> heh
[13:08] <jml> I have no idea why I typed that in this channel.
[16:22] <sobersabre> hi. where I can read about how to do something like bzr status from within python script.
[16:22] <sobersabre> I want to detect changes/additions/removals.
[16:23] <sobersabre> ther must be some kind of api aournd. right ?
[16:24] <beuno> sobersabre, yeah
[16:24] <beuno> let me dig that up for you
[16:26] <beuno> sobersabre, http://wiki.bazaar.canonical.com/Integrating_with_Bazaar
[16:26] <sobersabre> beuno: I am on windows. I have bzr installed, I tried import bzrlib, and it didn't manage.
[16:26] <beuno> has nice examples
[16:26] <beuno> and this is the api documentation: http://people.canonical.com/~mwh/bzrlibapi/
[16:27] <beuno> I don't know anything about python in windows, so can't help you there
[16:30] <mgz> sobersabre: you want to install the bazaar for your python version, not the all-in-one bundle
[16:30] <mgz> that will put it in your site-packages dir so you can import it.
[16:32] <mgz> ie 'bzr-2.2.3.win32-py2.6.exe' not 'bzr-2.2.3-setup.exe'
[16:34] <sobersabre> mgz: thanks, man. I did install the right version for "my" python (2.5)
[16:34] <sobersabre> for some reason bzrlib is not loadable.
[16:35] <mgz> does C:/Python25/Lib/site-packages/bzrlib exist? (adapt for your pythong location)
[16:35] <mgz> ...I type 'pythong' way too much.
[16:37] <sobersabre> I wear pythongs once in a while.
[16:37] <sobersabre> anyway, I have no bzrlib in the site-packages dir.
[16:38] <sobersabre> even though I did install bzr-2.2.1.win32-py2.5.exe
[16:39] <mgz> uninstall and try again, it's possible something got screwed up.
[16:39] <awilkins> sobersabre, Eclipse problems?
[16:39] <sobersabre> awilkins: what do u mean?
[16:39] <awilkins> Ah, wrong distro, sorry
[16:39] <sobersabre> it is an evening, the sun is down...
[16:39] <sobersabre> moon is visible.
[16:40] <awilkins> The exe bundle has some issues with the bzr-xmloutput plugin and hence the bzr-eclipse plugin
[16:40] <sobersabre> awilkins: hm... distro ?
[16:40] <mgz> pay attention in the installer to where it's putting the files.
[16:40] <sobersabre> oh!
[16:40] <sobersabre> hm...
[16:40] <sobersabre> I do have that plugin (but not on this computer).
[16:40] <sobersabre> is it possible I will have eclipse plugin punishment,
[16:40] <sobersabre> but not on the computer it is installed on ?
[16:40] <mgz> you might have a zombie python install somewhere, or a screwed up registry setting.
[16:41] <sobersabre> :-/
[16:41] <sobersabre> mgz any ideas what setting ?
[16:41] <sobersabre> path ?
[16:41] <awilkins> I have at least one bug for the Eclipse plugin, but it only occurs when your project folders are nested more than 1 deeper than your workspace
[16:41] <sobersabre> python* ?
[16:41] <mgz> well, just try uninstall/reinstall to start with
[16:41] <sobersabre> ok... it's scary.
[16:41] <mgz> that does a "find where python is" step, if it gets it wrong, then we can go digging
[16:48] <sobersabre> mgz: I have just rebooted. what step were you talking about?
[16:49] <sobersabre> off a webpage or something ?
[16:49] <mgz> uninstall your current bzr. then reinstall. may as well use 2.2.3 while you're at it.
[16:50] <sobersabre> beuno: about windows, as you can see "Me and you are of the same blood"
[16:50] <mgz> and look at what paths it's using in the process.
[16:50] <sobersabre> mgz: I didn't see 2.2.3 for py 2.5 on win the last time I installed...
[16:50] <mgz> it's new-ish.
[16:50] <mgz> http://launchpad.net/bzr/2.2/2.2.3/+download/bzr-2.2.3.win32-py2.5.exe
[16:52] <sobersabre> alrightie.
[16:52] <sobersabre> I used the main canonical page last time...
[16:52] <sobersabre> so where can I look at to see how to answer your 'find where python is' q ?
[16:53] <sobersabre> I know where the python is.
[16:53] <sobersabre> it's in D:\Python25
[16:54] <mgz> the installer doesn't ask you, it looks for itself.
[16:54] <sobersabre> hm, now I can practically SEE the files are being copied and compiled to D:\Python25\Lib\site-packages\bzrlib
[16:54] <sobersabre> feels good.
[16:54] <sobersabre> let's see it works too.
[16:54] <mgz> make sure it's beliefs and yours coincide
[16:55] <mgz> okay, that sounds good.
[16:55] <mgz> -' dammit.
[17:02] <mgz> sobersabre: import works now?
[17:02] <sobersabre> mgz: oh, it does!
[17:02] <sobersabre> I like.
[17:02] <sobersabre> :)
[17:03] <sobersabre> I am one happy geek now.
[17:03] <sobersabre> preparing a deployment fab.
[17:03] <sobersabre> it's my 2nd month with python at work, and I like it.
[17:03] <sobersabre> too much.
[17:05] <mgz> so, to get started, you want something like:
[17:05] <mgz> from bzrlib.workingtree import WorkingTree
[17:05] <mgz> tree = WorkingTree.open_containing(directory)[0]
[17:05] <sobersabre> mgz I don't do anything like that :)
[17:05] <sobersabre> I prefer to use the long names.
[17:06] <mgz> then you can inspect the working tree, and see bzrlib.status for what the ui does.
[17:06] <sobersabre> mgz I think it is better to use changes. it gives an iterable thing.
[17:07] <sobersabre> I will count what I want. if the counter is > 0 it's the time to act.
[17:07] <AdamDV> Any known issues with bzr doing a checkout over sftp with a password protected rsa key?
[17:07] <sobersabre> basically there's: changes.has_changed
[17:07] <sobersabre> :)
[17:08] <mgz> if that's all you need then fine, status does some more work on top of that as well.
[17:08] <sobersabre> mgz: the problem with status is its result.
[17:08] <sobersabre> I don't want to print out something.
[17:08] <sobersabre> I need to do or not do something depending on the changes.
[17:09] <mgz> I was suggesting you read the code, not used it as-is.
[17:09] <mgz> iter_changes may be all you need.
[17:10] <mgz> AdamDV: as in, does it work, or as in, are there known security issues?
[17:10] <mgz> if you just want to know if it works, try it and see.
[17:11] <AdamDV> Well, right now its looking like it does not.
[17:11] <AdamDV> Even though I've used *without* a password protected key before.
[17:11] <AdamDV> Let me pastey the errors.
[17:12] <sobersabre> AdamDV: I think you should be more asking about paramyko. I remember it did have some troubles with default values long ago.
[17:12] <sobersabre> paramyko is the module for ssh communication.
[17:12] <sobersabre> bzr is just using it.
[17:12] <sobersabre> (unless the same people who develop bzr also work on paramyko)
[17:13] <sobersabre> AdamDV: did you look at the code of paramyko you're running ?
[17:13] <AdamDV> http://pastebin.com/pvn4p8X3
[17:13] <AdamDV> I did not?
[17:13] <AdamDV> it works fine connecting to ssh.
[17:13] <AdamDV> BUt yes, it looks like a paramiko problem.
[17:14] <AdamDV> And if sftp+password key arent going to work, what other options do I have? Use a password-less key?
[17:14] <sobersabre> AdamDV: also, what kind of network media are you on with this operation ?
[17:15] <AdamDV> network media?
[17:15] <AdamDV> As in how I'm connecting?
[17:15] <sobersabre> Ethernet, WiFi, analog modem ?
[17:15] <AdamDV> I'm on WiFi in Toronto, server is on ethernet in Dallas.
[17:15] <sobersabre> AdamDV: what OS ?
[17:16] <AdamDV> I'm on Maverick, servers on Lucid
[17:16] <sobersabre> ok.
[17:16] <AdamDV> 10.04.1 is the server, to be specific.
[17:16] <sobersabre> on the client: does ifconfig show you any errors ?
[17:16] <AdamDV> Nope.
[17:16] <sobersabre> TX/RX ...
[17:16] <sobersabre> ?
[17:16] <sobersabre> sure ?
[17:17] <AdamDV> I was using this yesterday, without a password on the key. We re-imaged the server and I re-generated my key and added a password, now its not working :)
[17:17] <mgz> bug 647916 is similar, check the last comment there?
[17:17] <AdamDV> Lemme pastebin ifconfig
[17:17] <AdamDV> http://pastebin.com/2gh1VPsq
[17:18] <sobersabre> mgz: I looked at it...
[17:18] <AdamDV> Oh.
[17:18] <AdamDV> That could be it.
[17:18] <AdamDV> My shell is not bash, its actually a custom internal shell we use here.
[17:19] <AdamDV> *changes back to bash*
[17:19] <mgz> sounds likely.
[17:19] <sobersabre> AdamDV: I would not use anything non-standard to debug such problem.
[17:19] <sobersabre> and, permission denied is kinda interesting.
[17:20] <sobersabre> Are you sure the user you're using to run this has access to /home/adam/.ssh/id_rsa ?
[17:20] <sobersabre> AdamDV: is it possible it is chmodded 600, but belongs to ... a different user ?
[17:21] <AdamDV> Changing to bash on my server user fixes the problem.
[17:21] <sobersabre> AdamDV: is it possible your "supershell" uses the same UID you have as user 'adam' ?
[17:21] <sobersabre> I mean it DOESN'T use it.
[17:22] <AdamDV> As in server user id is the same as my local user id?
 Changing to bash on my server user fixes the problem. <- good good.
[17:22] <maxb> It sounds to me that AdamDV's custom shell is not supporting the invocation of sftp on the server properly
[17:22] <AdamDV> Yea. Its a 100 line shell written in PHP for the secretarys to use.
[17:22] <sobersabre> maxb: I know how this can happen:
[17:22]  * maxb runs away screaming
[17:22] <sobersabre> the "supershell" prints out too many lines of output.
[17:23] <sobersabre> I mean too many chars of output.
[17:23] <AdamDV> maxb: Yea.
[17:23] <sobersabre> AdamDV: can you make your logon shell quieter ?
[17:23] <AdamDV> ?
[17:24] <AdamDV> I'd rather use BASH anyway :)
[17:24] <sobersabre> AdamDV: if you can - do, if you cannot - make sure the shell shuts up upon invokation.
[17:24] <sobersabre> I remember having added lots of stats upon logon (with colors, etc.) this made sftp inoperable.
[17:24] <AdamDV> I have no control over the development of our shell, unfortunatly. If I did, it wouldn't exist..
[17:25] <sobersabre> I'm off, mgz thank you!
[17:25] <AdamDV> Thank you for your help mgz and sobersabre
[17:25] <AdamDV> :)
[17:26] <mgz> bye both.
[17:29]  * AdamDV idles
[19:56] <major> okay, so I may be in for a heck of a pickle... I have some fairly old Bzr repositories which where converted from TLA using baz-import .. a while ago..
[19:56] <major> was trying to work at upgrading them, and a bzr log in them claims that it can not locate an ARCH-1 revision near the end of the log
[19:57] <MTecknology> http://dpaste.com/370125/ <- any idea why this happens when I try to pull a branch?
[19:57] <jelmer> major: what version of bzr are you using? and what's the exact error message?
[19:58] <jelmer> MTecknology: the local branch doesn't support a particular feature that the remote branch uses
[19:58] <jelmer> MTecknology: you can upgrade the local branch and try again
[19:58] <jelmer> the error message could admittedly use some work..
[19:58] <MTecknology> oh.. thanks :)
[19:58] <MTecknology> works perfect now
[19:59] <major> bzr version 2.2.2
[19:59] <major> bzr: ERROR: Revision {Arch-1:email@domain--project%package--1.0^Cversion-0} not present in "KnitRepository('file:///home/user/devel/user.bzr/repository/')".
[19:59] <major> erm
[19:59] <major> erm
[19:59]  * major sighs.
[19:59] <major> that ^C shouldn't be there
[20:00] <major> it is has '--' in that spot
[20:00] <major> I tried to hide the email addresses and accidentally mangled the error a touch
[20:01] <jelmer> major: was the revision present originally?
[20:01] <jelmer> missing revisions ("ghosts") were pretty common in baz
[20:01] <major> well, it didn't used to give this error...
[20:01] <major> and the original repositories where converted from TLA
[20:02] <major> I suspect they where external archives..
[20:02] <jelmer> the original repository  (the bzr one converted from baz) doesn't give that error?
[20:03] <major> they where all TLA archives, and still are
[20:03] <major> I still have them
[20:03] <major> they where retained for historical purposes
[20:03] <major> baz was only used during baz-import, back when it was still part of the bzrtools
[20:04] <jelmer> it'd be interesting to see if that revision was actually present in baz
[20:04] <jelmer> or if it wasn't present and older baz/bzr simply didn't mention it
[20:04] <major> well, I can definately look at it
[20:04] <major> and it is definately there
[20:05] <major> it just isn't actually in the bzr repository
[20:14] <major> is there any documented way to fix ghosts like this?
[20:17] <jelmer> major: baz-import shouldn't have created a ghost if the revision was present in the original baz repository
[20:19] <major> what if the revision was in a separate tla archive?
[20:19] <major> though its location was registered
[20:19] <jelmer> major: no idea (I've never used baz)
[20:20] <major> hmm
[20:20] <lifeless> it will create ghosts
[20:20] <lifeless> it doesn't traverse archives
[20:20] <lifeless> you need to import each archive
[20:21] <lifeless> if I'm remembering correctly
[20:27] <major> hmm..
[20:27] <major> I suppose that feels mostly right..
[20:27] <major> just makes this pretty.. well .. funky
[20:28] <major> I don't suppose importing the parent repository ontop of the already converted repository will make it "just work" ?
[20:29] <jelmer> major: importing it elsewhere and then running "bzr fetch-ghosts <new-repo>" from the original repo should work
[20:29] <jelmer> where new-repo is the bzr repo created from the parent baz repo
[20:30] <major> nifty
[20:31] <jelmer> emphasis on /should/, I've never tried that before
[20:32] <lifeless> major: yes, it should just work.
[20:32] <lifeless> emphasis on the should
[20:32] <major> heh
[20:32] <major> well, I have a number of backups of this stuff already
[20:32] <lifeless> we haven't done much tla imports for about 5 years :)
[20:32] <major> yah ..
[20:33] <major> trying to revive a project that hasn't been touched in almost that long
[20:41] <lifeless> cool
[20:44] <Ramosa> does bazaar have the same issues as mercurial with tagging.. that a tag actually does an invisible commit, and that you can't edit history easily of past revisions ?
[20:50] <jelmer> Ramosa: a tag doesn't do an invisible commit, it's just a named pointer to a particular revision
[20:51] <jelmer> Ramosa: history can't be edited, but you can rewrite it
[20:51] <major> well .. it is chugging away at this, hopefully it all works...
[20:52] <major> will likely take all day to do all these repositories though
[20:52] <major> but that is better than losing the history
[20:54] <jelmer> whoa.. that's really slow :-(
[20:54] <major> well, a lot of repositories to fix, with a lot of branching inside of them
[20:58] <major> I suspect the SCM history alone could be used for an interesting white paper on development work-flow
[20:59] <jelmer> hehe
[20:59] <major> the original sources started off in RCS, later converted to CVS, then pulled into Arch via cscvs (a tool to compute change-sets within CVS)
[21:00] <major> from there a number of developers created branches from the original Arch archives, and then those where converted to bzr via baz-import
[21:00] <major> and a few developers developed from multiple locations, which in Arch gives them unique global identifiers
[21:01] <major> really not certain if it could get much more chaotic
[21:43] <poolie> hello all
[21:44] <jelmer> g'morning poolie
[21:44] <poolie> hi there jelmer
[21:51] <quotemstr> How can I write a revisionspec that means 'since this branch was forked from its parent'?
[21:51] <quotemstr> (And I mean without looking that point up beforehand, of course.)
[21:52] <quotemstr> Ah, ancestor:, maybe.
[21:52] <jelmer> quotemstr: yeah, generally ancestor:
[21:53] <quotemstr> But I still hae to type out the parent branch in that case. Ahwell.
[21:54] <quotemstr> Hrm. bzr log -r ancestor:./../trunk.. seems to not be pegging the CPU and not making any forward progress
[22:04] <mwhudson> jelmer: lp:bzr-hg seems to have a pdb.set_trace() in it
[22:08] <cbz> is there a bzr concepts/internals guide?
[22:40] <jelmer> mwhudson: oh, whoops
[22:40] <jelmer> mwhudson: I'm about to land a branch that fixes 75% of the hg imports
[22:41] <mwhudson> jelmer: \o/
[22:43] <spiv> quotemstr: ancestor::parent
[22:43]  * jelmer waves to spiv
[22:44] <spiv> Good morning :)
[22:44] <quotemstr> Thanks.
[22:44] <quotemstr> So ':parent' is magical.
[22:48] <mwhudson> it's a location alias i think the name is
[22:48] <mwhudson> there are a few
[22:48] <mwhudson> :push and :submit are others
[22:53] <quotemstr> spiv: That doesn't DTRT at all.
[22:54] <quotemstr> It gives me some random commit from today.
[23:00] <spiv> quotemstr: perhaps :parent isn't what you expect?  Check 'bzr info'
[23:00] <quotemstr> Actually, after bzr log -r ancestor::parent.., I get "bzr: ERROR: Start revision not found in left-hand history of end revision.
[23:00] <quotemstr> parent is set correctly.
[23:01] <spiv> Oh, log is fussy like that.  abentley added some new revision specs that help with that.
[23:02] <quotemstr> Wuh? Why *wouldn't* that work?
[23:02] <quotemstr> And why do you need new syntax to make it work?
[23:02] <spiv> mainline: is the revspec I'm thinking of.
[23:03] <spiv> I agree, I think log should cope, but currently it doesn't.
[23:05] <spiv> For non-trivial history exploration I tend to use 'bzr qlog' (from the qbzr plugin) or 'bzr viz' (similar thing in the bzr-gtk plugin).
[23:07] <quotemstr> Ah. Anything native for OS X or Win32?
[23:07] <quotemstr> (Well, I can use X with both. It's just a pain.)
[23:07] <spiv> qbzr looks pretty slick on Win32 at least (it and bzr-explorer and some other plugins are bundled in the bzr installer for that platform)
[23:08] <spiv> IIRC it works ok on OS X too, although there may be some fiddly dependencies that I'm ignorant of.
[23:09] <quotemstr> Thanks. I'll take a look.
[23:09] <quotemstr> I'm leery of GUIs generally though.
[23:17] <major> use a good solvent
[23:29] <mwhudson> we does my checkout of lp:loggerhead whinge about not being able to break locks when i run bzr up?
[23:29] <mwhudson> i suspect the fact that it appears to be making three connections to bazaar.launchpad.net is related
[23:30] <jelmer> ugh
[23:30] <jelmer> what's so special about it that it needs 3 connections?
[23:30] <mwhudson> don't know
[23:30] <mwhudson> the working tree is out of date with the local copy of the branch now
[23:31] <mwhudson> hm, unbind/bind fixed it
[23:31] <spiv> mwhudson: :(
[23:35] <lifeless> mwhudson: note that I'm about to push 1.18 to trunk, or something like that
[23:36] <monkey_d_luffy> how can I "fork" my project at a particular revnum?   I tried branch but then why I try to commit changes I get an error "bound branch ... is out of date".   Basically what I want is a copy-paste of everything at a chosen revnum, so that it can stay independent.
[23:37] <spiv> monkey_d_luffy: "bzr branch -r REVNO"
[23:37] <monkey_d_luffy> but that didn't work...
[23:38] <spiv> How did it go wrong?
[23:38] <monkey_d_luffy> that's the problem I'm having now
[23:39] <spiv> Your error says "bound branch" though, which isn't something that "bzr branch" (by itself) could give.
[23:40] <spiv> Did you use "bzr checkout" instead, or perhaps "bzr bind" or "bzr reconfigure" after "bzr branch"?
[23:40] <monkey_d_luffy> I did a branch of my project    bzr branch -r 60   trunk  trunk_new                    then I renamed both directories.   And now when I try to do a commit in my new dir, I get that error
[23:41] <monkey_d_luffy> it could have been a checkout, but I'm pretty sure it was a branch... will try again then
[23:41] <spiv> Hmm.  Well, you should be able to "bzr unbind" (or "bzr reconfigure --tree") to change it.
[23:41] <spiv> And "bzr info" can tell you what it is now.
[23:42] <monkey_d_luffy> I did a bzr info now... it was a checkout after all :|
[23:46] <monkey_d_luffy> so a branch makes it completely independent from the parent branch (which may even be deleted) correct?
[23:50] <spiv> Yes.
[23:51] <monkey_d_luffy> ok thansk