[02:29] <bignose> I've accidentally done ‘bzr pull . -r revid:blah’ on the wrong branch
[02:29] <bignose> and now I want this branch to be back to where it was
[02:29] <bob2> do you know where it was
[02:30] <bignose> I know the revid I need to get back to, but when I pull to that it just says “No revisions or tags to pull.”
[02:30] <bignose> but the history is still for the wrong branch.
[02:31] <bob2> can you just reclone
[02:31] <bignose> I don't know, will that not destroy things like shelves?
[02:31] <bignose> I'd prefer to do it with ‘pull’ since that seems the right operation for fixing this non-destructively
[02:33] <bignose> so, ‘pull’ both pulled in the revision, and switched the history of this branch.
[02:33] <lifeless> bignose: bzr pull -r xxx --overwrite
[02:33] <bignose> now attempting to ‘pull’ it already has the revision it needs, but refuses to change the history this time.
[02:33] <lifeless> pull won't do anything if you are pulling a successor
[02:34] <lifeless> sorry, a predecessor
[02:34] <lifeless> unless you tell it you mean it
[02:35] <bignose> bizarre. now I'm getting “Unable to obtain lock filtered-46882576:///~benf/Projects/bnv/cam/trac-380_setup-supertues-2012-09/.bzr/branch/lock”
[02:35] <bignose> and every time I break the lock, then ‘bzr pull …’ again, it complains about the lock again.
[02:36] <lifeless> is the branch bound ?
[02:36] <bignose> yes
[02:36] <lifeless> so pull is locking both the master and the slave
[02:37] <bob2> bound:|
[02:37] <bignose> and ‘break-lock’ is different?
[02:37] <lifeless> there are two possible things here, IIRC break-lock only checks the specific branch
[02:37] <lifeless> so you may need to break-lock both branches
[02:38] <bignose> the thing is, it appears to be a new lock each time
[02:38] <bignose> “locked 2 seconds ago” every time
[02:38] <bignose> i.e. the lock is occurring within the execution of ‘bzr pull …’, but then it's complaining about it before it completes.
[02:39] <lifeless> can you pastebin, bzr info -v, the exact command you're running to do the pull, and the contents of .bzr/branch/branch.conf somewhere?
[02:39] <bignose> shall do, thanks
[02:41] <bignose> lifeless: <URL:http://dpaste.org/ZNWIt/>
[02:42] <lifeless> ok, its possible that you have found a bug (well, clearly its a bug that this doesn't work, but you know what I mean)
[02:42] <lifeless> I suggest:
[02:42] <lifeless> bzr unbind
[02:42] <lifeless> do the pull
[02:43] <lifeless> do a bzr push --overwrite <full url here>/trac-380_setup-supertues-2012-09
[02:43] <lifeless> then bzr bind
[02:43] <lifeless> which should get you past the situation
[02:43] <lifeless> and then file a bug describing it, the version of bzr, and include the contents from that pastebin
[02:45] <bignose> lifeless: thank you.
[02:45] <bignose> (using ‘bzr bind’ before ‘bzr push --overwrite’ worked, and meant I didn't need to specify the remote location.)
[02:48] <lifeless> np
[02:51] <bignose> :-( still won't let me file a bug without making a new Launchpad identity
[02:51] <lifeless> in your case I believe that that is 'a' Launchpad identity
[02:51] <bignose> so I'll have to leave that to someone with an account there.
[02:53] <bignose> $ bzr version
[02:53] <bignose> Bazaar (bzr) 2.6.0dev2
[02:53] <bignose> on Debian Wheezy.
[02:54] <lifeless> thanks
[03:09] <bignose> thank you all!
[07:40] <vila> jelmer: ping, can you look at bzr.dev revno 6207.3.2 (merged in revno 6214) and explain me why you changed bzrlib/tests/__init__.py there ?
[07:41] <vila> jelmer: I found that while investigating an almost unrelated issue and couldn't understand the comment about  http://pad.lv/825027
[08:06] <mgz> morning!
[08:10] <vila> morning mgz
[08:11] <mgz> how are you vila?
[08:11] <vila> fine :)
[08:11] <vila> found another weird merge circa revno 6214, see my last mp
[19:18] <mgrandi> why would libsvn.dylib not be loaded? or missing?
[19:18] <mgrandi> do i need to reinstall svn or something?
[23:37] <jimis> hi all, I work on light checkout of a tree-less repo. To rename a branch on that repo can I just rename the directory?
[23:38] <jimis> What about the checkout dir, will it understand the change?
[23:49] <fullermd_> mv'ing the branch by itself is fine.  You'll have to update things that point to it to the new location.
[23:49] <fullermd_> Checkouts would be one such thing.  Saved locations (push, pull, etc) in other branches referring to it would be another.
[23:57] <jimis> thanks fullermd, I'll try it
[23:57] <jimis> how do I update a checkout?
[23:58] <mnn> mgz: if you're here, have you looked into InterTree.iter_changes(), why it does kind = (None, None) in some cases?