[03:58] <mwhudson> how do you resurrect files in bzr?
[03:58] <lifeless> mwhudson: holy water
[03:59] <lifeless> mwhudson: or, revert -r X Y
[03:59] <mwhudson> ah right
[04:00] <mwhudson> hm
[04:00] <mwhudson> that gives "paths not versioned"
[04:01] <lifeless> was Y in rev X ?
[04:01] <mwhudson> yes
[04:01] <mwhudson> ah
[04:01] <mwhudson> no
[04:02] <mwhudson> confusing myself with intermixed renames
[04:02] <lifeless> this is a single valued answer
[04:02] <mwhudson> lifeless: thanks
[04:02] <lifeless> :)
[04:02] <mwhudson> it was there, but not with the name "Y" :)
[04:03] <lifeless> :)
[04:08] <mwhudson> so it was revert a directory out of oblivion, delete some files, move some files out of the directory over previous files, remove directory again and commit
[04:09] <mwhudson> i'm sure this sort of thing used to corrupt your dirstate occasionally :)
[04:09] <lifeless> yeah
[04:09] <lifeless> we should be beyond that
[04:10] <mwhudson> seems like it
[04:11] <lifeless> jams new stuff has the risk of reintroducing it, but like it was worth it for commit, it will be worth it for revert etc
[07:18] <bignose> How do I spell “the latest revision on branch foo” as a revspec?
[07:19] <AfC> bignose: -r branch:../path/to/branch ?
[07:19] <bignose> AfC: okay. but how do I use the “last:N” on that branch?
[07:20] <AfC> bignose: no idea. Anytime I tried to use branch: it crashed. :/
[07:20] <AfC> I'm Sure They've Fixed That Nowtm
[07:20] <spiv> bignose: revno:-N:/path/to/branch
[07:21] <AfC> ':' ?
[07:21] <AfC> really?
[07:21] <spiv> Which colon are you questioning?
[07:41] <AfC> spiv: 2nd
[07:41] <AfC> (not questioning. Is that shorthand for "the branch at path"?
[08:10] <spiv> AfC: I'm not sure what you mean by shorthand; it's part of the syntax supported by the "revno:" revspec.
[08:17] <lifeless> AfC: its short for 'the tip rev of the branch at path'
[08:20] <AfC> lifeless: good to know! Thanks
[08:35] <leo2007> In my branch, I have 2 extra revision(s) and are missing 10 revision(s).
[08:36] <leo2007> What's the best way to sync the missing 10 revisions.
[08:38] <spiv> Usually with "bzr merge"
[08:38] <spiv> (followed by resolving any conflicts and committing)
[08:39] <leo2007> Is it difficult to resolve conflicts?
[08:39] <leo2007> I am mostly a git user.
[08:39] <spiv> Depends on the conflicts :)
[08:39]  * gour is moving (back) to bzr from fossil
[08:39] <spiv> The conflicts are unlikely to be much different to the sort you'd get with git.
[08:39] <leo2007> but after bzr merge, the extra 2 revisions will not be on top of the history, right?
[08:40] <spiv> merge by itself doesn't do anything to history
[08:41] <spiv> It's when you commit that a new revision is, well, committed to the history.
[08:41] <leo2007> OK, I am doing 'b merge' now.
[08:41] <spiv> If you commit a merge, the revision will have two parents (or more if you did multiple merges before committing).
[08:42] <leo2007> 2 conflicts encountered.
[08:43] <spiv> So both your 2 extra revisions and the other 10 previously missing revisions will be immediately connected off the new revision that is now the tip of your history.  "bzr qlog" (from qbzr) and "bzr log -n0" give you some ways to see that.
[08:44] <leo2007> Now I edited the two conflicts and they seem to contain the intended changes.
[08:44] <leo2007> What to do next?
[08:45] <spiv> Use "bzr resolve" to inform bzr that the conflicts have been resolved, and commit.
[08:50] <leo2007> I am screwed.
[08:50] <spiv> What's up?
[08:50] <leo2007> How can I go back to a previous status: 104334
[08:51] <spiv> Do you mean undo the commit?  "bzr uncommit"
[08:51] <kiranmurari> I'm trying push code to a branch created for my project... but bzr push always fails
[08:52] <kiranmurari> bzr push --use-existing lp:~kiranmurari/proj_name/branch
[08:52] <spiv> (And then possibly "bzr revert" as well, depending on what you want)
[08:52] <spiv> kiranmurari: what's the error?
[08:52] <kiranmurari> gives me..
[08:52] <kiranmurari> ssh_exchange_identification: read: Connection reset by peer
[08:52] <kiranmurari> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist
[08:52] <spiv> kiranmurari: any other lines before that?
[08:52] <kiranmurari> nothing
[08:52] <awilkins> kiranmurari, Can you open just a normal SSH shell on that server (if you have the rights?)
[08:52] <spiv> Then it's a firewall most likely.
[08:53] <leo2007> spiv: after the merge, the first commit seems to contain all the changes from the missing 10 revisions: http://paste.pocoo.org/show/394134
[08:53] <spiv> what happens if you try "telnet bazaar.launchpad.net 22"?
[08:53] <spiv> kiranmurari: (regarding your pm), no, I really mean telnet
[08:53] <kiranmurari> ohh ok
[08:54] <spiv> I want to know if you get connection closed by peer even then
[08:54] <kiranmurari> it doesn't succeed.. says connection closed by foreign host
[08:54] <spiv> Or if you successfully get the SSH banner from that host.
[08:54] <kiranmurari> i don't see the banner
[08:54] <awilkins> You should see "SSH-2.0-Twisted"
[08:54] <kiranmurari> is it my corporate FW blocking me....
[08:55] <spiv> Ok, so it's a firewall blocking your access to bazaar.launchpad.net's SSH service
[08:55] <leo2007> spiv: after uncommit, there are lots of changes in the work dir, is there a way to discard those changes too?
[08:55] <awilkins> leo2007, `bzr revert`
[08:55] <spiv> leo2007: "bzr revert", but why do you think that "bzr log -r -1" output is wrong?
[08:55] <awilkins> leo2007, Those changes are the ones from the revisions you uncommitted
[08:55] <kiranmurari> ohh.. need to talk to my sysadmin guys to give that access...
[08:55] <kiranmurari> thx.. spiv
[08:58] <leo2007> spiv: I am new to this so I am going to do it the stupidest way. Backout my commits and then sync and then reapply them.
[08:59] <spiv> leo2007: Isn't what you want a branch that includes the changes from your 2 revisions combined with the changes from other 10 revisions?  With the original history of all those revisions intact?
[08:59] <spiv> leo2007: if so, then the merge you did and committed should be exactly what you want.
[09:01] <kiranmurari> spiv, thanks...
[09:02] <spiv> Perhaps you're more used to rebasing rather than merging, and the bzr-rewrite plugin provides a rebase command, but if you just want to a) record the history of your changes and b) share your changes with others, then there's no need to rebase when a simple merge will do.
[09:02] <spiv> kiranmurari: you're welcome
[09:03] <spiv> leo2007: but I'm just guessing, because you haven't explained what your problem actually is :(
[09:07] <spiv> Hi Riddell
[09:08] <Riddell> morning
[09:08] <spiv> I guess you're going to be my cue to be done for the day ;)
[09:09] <spiv> Especially when the toddler's new trick is pulling his shirt over his face and then, entirely predictably, walking into things!
[09:09] <spiv> Well, predictable if you're not a toddler at least.
[09:09] <leo2007> spiv: I need to read up on bzr but I am only using it occasionally so I am not confident.
[09:15] <gour> leo2007: what's your 'other' dvcs which you (mostly) use?
[09:18] <leo2007> gour: mostly git.
[09:19] <leo2007> gour: and mostly from emacs via magit.el.
[09:25] <gour> leo2007: ineresting...i'm just switching from emacs to vim...and simply cannot grok git...used darcs for a long time, then monotone & fossil, but now i'm back to bzr which i find the most intuitive (after darcs) where i do not need to think about the tool, but just using it...fossil is nice idea due to integrated tracker, wiki, but let's hope there will be wiki at LP at some time
[09:27] <leo2007> gour: Somehow git grows on me. I am most productive with it.
[09:27] <gour> leo2007: good luck. ;) i believe my feet would be destroyed very soon :-)
[09:31] <leo2007> I eventually get my 2 commits upstream.
[09:35] <leo2007> spiv: many thanks for your help. Really appreciated.
[09:40] <spiv> leo2007: you're welcome
[09:41] <spiv> leo2007: FWIW, usually if upstream wants to incorporate your changes they just "bzr merge" from your branch.
[09:41] <leo2007> spiv: usually they just ask me to commit directly.
[09:42] <spiv> leo2007: ah, in that case you're upstream, so you can do the merge of your branch into the upstream branch yourself :)
[09:43] <leo2007> spiv: yeah, but my repo setup might have some problems so I need to find time to fix it first. Hopefully tonight.
[09:45] <leo2007> Have to go, run out of battery soon. Talk later.
[09:45] <spiv> leo2007: good luck.  Feel free to ask in here for help if you get stuck; I'm done for the night but there should be plenty of other folk here that can help.
[09:45] <leo2007> spiv: thanks a lot.
[09:45] <leo2007> I will do so.
[10:18] <Pegasus_RPG> hey spiv. Thought I'd come in here rather than clutter up the bug report with troubleshooting info. (referring to https://bugs.launchpad.net/bzr/+bug/772935 0
[10:50] <spiv> Pegasus_RPG: I'm mostly not here atm, but try prefixing the URL with nosmart+
[10:50] <Pegasus_RPG> k
[10:55] <Pegasus_RPG> that seems to have helped. It's working for much longer now, thanks.
[12:33] <cheater_> hi!
[12:34] <cheater_> how can i remove a file from disk, without it getting removed from bzr?
[12:34] <cheater_> is this possible?
[12:40] <maxb> You want a file not not exist on disk, but that deletion to never be committed? Why?
[12:41] <cheater_> i need to give access to this machine to someone else. i don't want them to be able to see the file - the guy is too stupid to know what bzr is, though
[12:41] <soren> cheater_: Just delete it and "bzr revert" when you get the box back?
[12:42] <cheater_> yeah but the thing is, it's just one of the checkouts i'm on. i want to be able to do "bzr ci" without having to cherry-pick the file
[12:42] <cheater_> the files
[12:42] <cheater_> and they get access to the pc all the time
[12:43] <soren> Maybe you could "bzr ignore" it.
[12:43] <soren> Not sure if that would work.
[12:43] <cheater_> hmhmhm.
[12:43] <maxb> It seems very wrong to me that you are trying to rely on the absence of this file from disk in the working tree as a form of security, yet are happy for the data to remain on disk inside the bazaar repository
[12:44] <soren> Nope, doesn't work :(
[12:44] <cheater_> maxb: exactly.
[12:44] <maxb> So, don't do that.
[12:44] <cheater_> maxb: thanks, i can also think for myself :-)
[12:45] <cheater_> maxb: but i'll let you know when it's time to go potty
[12:45] <cheater_> :p
[13:16] <kiranmurari> i don't know what went wrong.... i'm unable to push code to launchpad
[13:16] <kiranmurari> neither "bzr branch" nor "bzr checkout" succeed...
[13:17] <kiranmurari> i doubted it to be a firewall issue... but from a different machine in the same network, i'm able to branch and checkout the code
[13:17] <kiranmurari> does it have to do something with the SSH keys
[13:17] <kiranmurari> i keep getting this error message... for both "bzr push" and "bzr branch"
[13:18] <kiranmurari> ssh_exchange_identification: read: Connection reset by peer
[13:18] <kiranmurari> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[13:18] <kiranmurari> any help is appreciated...
[13:25] <LeoNerd> Sounds like SSH is upset
[13:26] <maxb> You should attempt to run "ssh your-launchpad-id@bazaar.launchpad.net" to test SSH connectivity outside of bazaar
[13:26] <maxb> If working correctly it prints "No shells on server"
[13:27] <kiranmurari> maxb: it says ssh_exchange_identification: read: Connection reset by peer
[13:28] <maxb> I'm inclined to blame connectivity or firewalling within your network
[13:29] <kiranmurari> but from a different machine in same network, i'm able "bzr branch"
[13:30] <kiranmurari> on this machine even "bzr branch" doesn't work.. resulting in the same error
[14:11] <ironcamel> anyone got bzr bisect installed?
[14:11] <ironcamel> https://launchpad.net/bzr-bisect
[14:16] <cr3> is there a way to be verbose about the ssh connection being attempted by bzr pull?
[14:27] <soren> cr3: For bzr+ssh or for sftp?
[14:29] <cr3> soren: bzr+ssh, I just ran ssh -vvv on the same host used by bzr which does the trick, I was wondering though if there might be a debug environment variable that might come in handy in the future
[14:49] <spyzer> hello everyone, is there any method to resume an interrupted bzr checkout
[14:49] <spyzer> please help
[14:50] <spyzer> please i can't afford more downloading it costs me too much money :(
[14:50] <spyzer> please help
[14:56] <gour> spyzer: lightweight checkout?
[14:56] <spyzer> gour is that a command
[14:56] <gour> spyzer: bzr checkout --lightweight url...check help
[14:57] <spyzer> ohhkk thanks a lot :)
[15:13] <mgz> ...that could be exactly the wrong thing, unless he's running a very recent version
[15:17] <mgz> bug 737234
[15:17] <mgz> let's hope he had at least 2.3.2 :)
[15:18] <gour> ahh, that was too much for me to know
[15:19] <mgz> indeed, it was a reasonable answer otherwise.
[15:19] <mgz> bug 116148 is also relevent.
[15:20] <gour> i wonder why after i decided to become serious with bzr (again), fossil shows some unexplainable problems like inability to launch ui for every repo i have
[15:22] <mgz> it doesn't like your infidelity?
[15:23] <gour> he he...or it's simply time to say goodbye, although not like zed shaw did :-)
[16:47] <etenil> Hi there
[16:50] <etenil> I'm programming a forge in python for bzr (with bzrlib), I've managed to retrieve the commits log for a project, but I get some Revision objects. Unfortunately, they don't seem to contain all information I want, like their revision ID or the date they were commited. I looked at the API reference, but it's quite overwhelming and I can't find what I need. Could someone point me in the right direction please?
[17:53] <cody-somerville> How do I specify the revision before a revision?
[18:01] <james_w> cody-somerville, before:
[18:01]  * cody-somerville nods.
[18:01] <cody-somerville> james_w, thanks.
[18:36] <vila> mgz: ping, still around ? I lost track of your no-pseudo-cycles work but the test on windows won't be able to pass again until you land some parts of your patch no /
[18:36] <vila> grrr
[18:36] <vila> ?
[18:37] <mgz> hey vila
[18:37] <vila> mgz: hey !
[18:37] <mgz> I'm a bit stuck at the moment as the trunk state seems unmergable with my branch
[18:38] <vila> huh ? Nothing a good pitchfork can't fix no ?
[18:38] <mgz> rev 5901 and rev 5902 seem to invert each other rather than being two bits of the branch split out
[18:40] <mgz> if you know how to get bzr.dev back into a state I can merge into, that would be great
[18:40] <vila> meh, better to prepare a branch that solve the issue and merge that
[18:41] <vila> but bzr qlog is quite... clear about what happened no ?
[18:42] <mgz> ...not to me?
[18:43] <vila> it looks like jam merged your work twice with two variants the later merging an older version of your work...
[18:44] <vila> so the result is that all of your work up to 'Clear extra lists with test instances in fork_for_tests' has already been merged with some amendments
[18:44] <mgz> this is not in fact the case.
[18:44] <mgz> the merges did not result in any code changing on trunk.
[18:45] <vila> urgh, really ?
[18:46] <mgz> and I don't know how to fix it.
[18:46] <vila> wow,  bzr diff -r5900..5902
[18:46] <vila> now that's censoring :)
[18:47] <mgz> right.
[18:48] <vila> weirdo, jam landed a revid:john@arbash-meinel.com-20110519185007-yzrct57glwjip8co *after* revid:john@arbash-meinel.com-20110519185931-9xcxj2ow2v1y4xvv
[18:48] <vila> but the former was created *before* the later
[18:49] <vila> mgz: did you discuss the issue with him ?
[18:50] <mgz> I did, but I'm not sure he gathered that I was stuck unless something gets fixed.
[18:53] <mgz> I need to update a few things, so I think I take the superceding revision off my branch, continue working, then worry about what's needed to get this landed later.
[18:56] <vila> mgz: I think showing him that `bzr diff -r5900.5902` outputs *nothing* should give him a hint that something went wrong
[20:08] <jam> mgz: can you link the branches that are an issue?
[20:08] <jam> mgz: I can probably just give you a branch tip
[20:08] <jam> vila: I landed the one after the former, because the first landed had a test fix, that the other one needed because it removed _get_log
[20:09] <jam> but it is possible that ones diff confused things
[20:09] <mgz> jam: lp:bzr doesn't contain any of the changesets from lp:~gz/bzr/cleanup_testcases_by_collection_613247
[20:09] <mgz> and if I now try to merge lp:~gz/bzr/cleanup_testcases_by_collection_613247 into lp:bzr no changes from bzrlib/tests/__init__.py are included
[20:22] <vila> jam: but have a look at `bzr diff -r5900.5902', it outputs nothing
[20:22] <vila> jam: and if the later needed the former shouldn't it be based on it ?
[20:23] <jam> vila: I determined it ad-hoc after the branches had been created.
[20:23] <vila> jam: but how do you explain the empty diff ?
[20:23] <jam> vila: that confuses me. I could see how one would supersede the other, and revert some content, but not how it would revert itself
[20:24] <jam> perhaps the criss-cross got things really confused, and both sides saw the other side revert its change..
[20:24] <vila> jam: indeed, I'm sure you wanted to land *something*
[20:24] <jam> I can see how it could have happened
[21:01] <whitley> I'm about to use bzr rebase to burn out some bad (as in massive, binary "nuke 'em from orbit") commits from old history on a purely private repo.
[21:04] <whitley> With the current rebase UI, it looks like I'll have to run rebase roughly once for each contiguous span of bad commits... is there a more straightforward way than re-running rebase (ala git rebase --interactive, for example)?
[21:04] <AuroraBorealis> i have no idea how rebase works, sowwy :<
[22:40] <lamont> oh hai.
[22:41] <lamont> http://paste.ubuntu.com/612467/  <--  wtf?
[22:41] <lamont> hardy with bzr 2.3.1-0.0.ISPATCHED.8.04
[22:41] <lamont> the patch, specifically, is to do a bzr whoami --branch if /etc/ doesn't already know who it is.
[22:42] <lamont> in postinst
[22:42] <lamont> this machine alone in my experience of hating bzr with this much passion
[22:43] <lamont> purging and reinstalling bzr and python-bzrlib has no effect
[22:48] <lamont> lifeless: ^^ when you see that
[23:10] <KombuchaKip> How do I commit just locally for now, and not to my launchpad account?
[23:12] <KombuchaKip> nm, --local is what I need, but what is a "bound branch"
[23:17] <lifeless> lamont: fun
[23:17] <lifeless> KombuchaKip: if you have a local branch, just commit and don't push
[23:17] <lifeless> KombuchaKip: if you started with 'bzr checkout' then you have a bound branch
[23:17] <lamont> lifeless: I'll happily delve into wtf happend on that box with you
[23:18] <KombuchaKip> lifeless: Right, so how do I make it so when I commit, it just goes local for now?
[23:18] <lamont> all I know history-wise is "it ain't happy now"
[23:19] <lifeless> lamont: File "/usr/lib/python2.5/site-packages/bzrlib/osutils.py", line 972, in failed_to_load_extension
[23:19] <lifeless> lamont: I think you've found a regression
[23:19] <lifeless> lamont: could you file a bug ?
[23:20] <lifeless> KombuchaKip: did you start with 'bzr checkout' ?
[23:20] <KombuchaKip> lifeless: How do I know what a branch is "plugged into".
[23:20] <lifeless> KombuchaKip: or 'bzr branch' ?
[23:20] <lifeless> KombuchaKip: 'bzr info
[23:20] <KombuchaKip> lifeless: Yes, I started with a checkout.
[23:20] <lifeless> '
[23:21] <KombuchaKip> lifeless: Ok, so now I just want to commit local for now. When I commit, what happens to the server's revision numbers when I finally plug back into the server's branch on LP?
[23:21] <lifeless> KombuchaKip: http://doc.bazaar.canonical.com/bzr.2.3/en/user-guide/using_checkouts.html may be helpful
[23:21] <KombuchaKip> lifeless: Thank you.
[23:21] <lifeless> KombuchaKip: if noone use has committed to the server, then your local ones will be used
[23:21] <KombuchaKip> lifeless: I'm reading the guide now, but still curious what happens to revision numbers.
[23:22] <lifeless> KombuchaKip: if someone else has committed, you'll need to do a bzr update; bzr commit - and their revision numbers will be used.
[23:22] <KombuchaKip> lifeless: Right. So if I make 5 local commits and server is at r6, after I rebind, server will be at r11?
[23:22] <lifeless> once you push yes
[23:23] <KombuchaKip> lifeless: Can you explain the difference between push and commit?
[23:23] <KombuchaKip> lifeless: I still don't get it.
[23:25] <lifeless> so commit creates a new commit object
[23:26] <lifeless> push shoves commit objects between branches
[23:26] <lifeless> a 'checkout' creates a bound branch which is a regular branch that has an automatic push to the other branch when a commit is done
[23:26] <AuroraBorealis> checkout also requires an internet connection.
[23:26] <AuroraBorealis> which sux.
[23:26] <KombuchaKip> lifeless: Right. So when you checkout, a commit and push are the same thing. A commit implies a push.
[23:27] <AuroraBorealis> or connection to the branch you checked out from :o
[23:28] <KombuchaKip> lifeless: Ok, I think I totally understand this bind / unbind / commit / push stuff now. Thanks
[23:39]  * KombuchaKip jumps and clicks his heels at the epiphany
[23:39] <AuroraBorealis> so if you have a branch
[23:40] <AuroraBorealis> and you kinda make a 'fork' of that branch and do stuff so you don't fuck up the original one, what happens if the original one updates
[23:40] <KombuchaKip> You really don't understand bzr until you've had to do something random like actually take your work on the road without a connection and where you have more than one machine you need to do something in private on.
[23:40] <AuroraBorealis> does the 'fork' have to update too?
[23:40] <KombuchaKip> AuroraBorealis: I think you don't have to deal with that until you push back into the main branch.
[23:41] <KombuchaKip> AuroraBorealis: And even then, you should be prompted to merge, I believe.
[23:41] <AuroraBorealis> yeah.
[23:41] <AuroraBorealis> ive never done multiple branches / merges before
[23:41] <KombuchaKip> AuroraBorealis: Me neither, just learning now.
[23:41] <AuroraBorealis> woo and yay!