[00:09] <jimis> hmmm, unshelve --preview was useful to save some diffs, but they are full of conflicts :-s
[00:11] <fullermd> Unshelving would do a better job, since it can merge.  The diffs would just be relative to the basis.
[00:11] <fullermd> Of course, if you've diverged far from the basis, you'd still be paddling.
[00:12] <jimis> fullermd: ideally I'd want to keep a diff versus the source branch/revision
[00:12] <jimis> so that it is most readable in case I ever need it
[00:13] <jimis> I can guess that internally that's the kind of diff stored :-p
[00:14] <jimis> I'll file a feature request
[00:15] <jimis> anyway thanks again :-)
[01:31] <jimis> "bzr info" shows as parent branch an http://bazaar.launchpad.net url
[01:31] <jimis> that means I'm not using the fastest protocol, right?
[01:32] <jimis> I remember I had to use http because of the firewall
[01:32] <jimis> So how can I reset the parent branch to the lp:project url?
[07:02] <LarstiQ> jimis: either `bzr pull --remember lp:branch` or `bzr config parent_location=lp:branch`
[07:03] <LarstiQ> jimis: isn't it an option to copy/rsync your working setup to the different pc?
[17:51] <gwal> hey guys, I recently did a bzr merge because the remote root branch and my local branch were both at revision 4 and bzr rspush complained about it
[17:52] <gwal> now, after successful merge, when doing bzr rspush I get this: You have 2 extra revision and two local revisions: 5 [merge] and 4
[17:52] <gwal> does anyone know how to resolve this?
[17:53] <LarstiQ> gwal: have you committed the merge?
[17:53] <gwal> LastiQ: yes I have
[17:54] <LarstiQ> (also, wow, rspush is a really old plugin, it's still alive?)
[17:55] <LarstiQ> gwal: what does `bzr missing remote/branch` sa?
[17:55] <LarstiQ> say
[17:55] <gwal> oh is it really old? what else would you use to push both the database and files onto a remote box? (sorry if this sounds like I have no idea what I'm talking about ... which is true)
[17:56] <gwal> bzr missing says:
[17:56] <gwal> You have 2 extra revision(s):
[17:56] <gwal> revno: 5 [merge]
[17:56] <gwal> (details about revision)
[17:56] <gwal> revno: 4
[17:57] <gwal> (followed by details about rev 4)
[17:57] <LarstiQ> gwal: so that seems either like it didn't push, or it is comparing with a different location
[17:57] <LarstiQ> afk for a minute
[17:59] <gwal> when I try to do bzr rspush I get: bzr: ERROR: Local branch is not a newer version of remote branch.
[17:59] <gwal> and I am positive that bzr is attempting to push to the same location as always
[18:00] <gwal> and that bzr missing is comparing with the same location
[18:04] <gwal> I also need to go but it would be fantastic if anyone had an idea ... will check later
[18:05]  * LarstiQ has a look at the rspush code
[18:13] <LarstiQ> gwal: what version of bzrtools/bzr are you using?
[18:15] <LarstiQ> gwal: as for the usecase of pushing a branch and then updating the files, there is https://launchpad.net/bzr-push-and-update for example
[19:31] <jimis> LarstiQ: copy/rsync which parts of my setup? I copied the no-trees repo, but the light-checkout can't be copied, a new one must be made from the new location.
[19:31] <LarstiQ> jimis: must it? hmm
[19:32] <jimis> LarstiQ: That happens because checkout refers to absolute path, which is different now.
[19:32] <jimis> I couldn't figure a way to reconfigure this one
[19:32] <LarstiQ> jimis: you _could_ try just the .bzr/checkout/shelf dir
[19:33] <jimis> and the path is absolute, even when I give relative path: "bzr co ../no-trees-repo/trunk"
[19:33] <LarstiQ> jimis: I admit it's a bit hacky, but to get you out of the ditch
[19:34] <jimis> nice, was afraid to just move this one since .bzr is incomprehensible thus I don't mess with it :-)
[19:36] <LarstiQ> jimis: that is good approach usually :)
[22:36] <gwal> LarstiQ: bzr --version spits out this:
[22:36] <gwal> Bazaar (bzr) 2.2.4
[22:36] <gwal>   Python interpreter: /usr/bin/python 2.7.0
[22:36] <gwal>   Python standard library: /usr/lib64/python2.7
[22:36] <gwal>   Platform: Linux-2.6.35.6-48.fc14.x86_64-x86_64-with-fedora-14-Laughlin
[22:36] <gwal>   bzrlib: /usr/lib64/python2.7/site-packages/bzrlib
[23:15] <dOxxx> gwal: bzr 2.2 is quite old by now, 2.5 is the current stable version.
[23:17] <gwal> dOxxx: do you think that the age of my bzr version causes this error though?
[23:18] <dOxxx> no idea, but I always try the latest version in case it fixes the problem :)
[23:19] <gwal> good call bud ;)
[23:20] <dOxxx> I jsut read up on rspush
[23:20] <dOxxx> are you sure you are pointing it at the same remote branch?
[23:20] <dOxxx> check what `bzr info` says for the push or parent branch
[23:20] <gwal> ok hang on
[23:23] <gwal> yea no I'm positive it's the correct location
[23:24] <gwal> to my mind, this problem came up after I had merged the remote branch (revision 4 at remote location) with my local branch (also revision 4)
[23:25] <gwal> for some reason bazaar now thinks I got two different revisions in my local branch and lists them as revno 5 [merge] and revno 4
[23:25] <gwal> maybe it is still trying to push revno 4 to the remote location when it really should be pushing revno 5
[23:25] <dOxxx> did your local and remote branch diverge at rev 4? i.e. is your local rev 4 commit different from the remote rev 4 commit?
[23:25] <gwal> yes they're different
[23:26] <gwal> but I merged them into revno 5
[23:26] <gwal> which I am now trying to push to the remote location
[23:26] <dOxxx> what if you try using the standard push command?
[23:27] <gwal> hang on
[23:28] <gwal> hmm ... it claims I'm holding a lock at this computer and therefore can't push
[23:28] <dOxxx> the rspush docs say " It will also error out if the upstream directory is non-empty and not an earlier version of the branch."
[23:29] <dOxxx> this makes me suspect that it can't handle divergent branches even if you merged them
[23:30] <dOxxx> do you have any other bzr tools open that are using your local branch?
[23:30] <dOxxx> like qlog or something like that?
[23:30] <gwal> no it's really just the one terminal I'm working in
[23:31] <gwal> I don't even know what qlog is ... I'll Google it
[23:31] <dOxxx> qlog is part of thq qbzr plugin, it's Qt-based GUI commands for bzr
[23:31] <dOxxx> quite nice to use
[23:32] <dOxxx> anyway if you're sure that you don't have another bzr command in progress on your local branch, you can try using `bzr break-lock` to force the lock to be released
[23:32] <gwal> so QBzr?
[23:32] <dOxxx> yeah that's the plugin
[23:33] <dOxxx> it's not really related to your problem though...
[23:33] <gwal> yea thanks though, I'll check it out
[23:33] <gwal> oh wait ... my bad I think
[23:34] <gwal> I had used bzr in the terminal on my local machine, then ssh'ed into the remote computer that I am trying to push from in the same window
[23:35] <gwal> "bzr break-lock ." on the remote machine should do the trick no?
[23:35] <gwal> I also closed the terminal (local computer) and opened a new one .. doesn't seem to work
[23:35] <dOxxx> only if you're sure you don't have another bzr process oeprating on that branch
[23:35] <gwal> i.e. doesn't seem to release the lock
[23:36] <gwal> ps aux | grep bzr doesn't give any process
[23:36] <dOxxx> try the push again
[23:36] <gwal> still complains about the lock
[23:37] <dOxxx> and break-lock does nothing?
[23:37] <gwal> doesn't seem to ... at least it doesn't acquire the lock for me
[23:38] <gwal> wait, do I need to say break-lock for the local branch or do I need to operate it on the remote location?
[23:39] <dOxxx> local
[23:39] <gwal> yea no, tried that
[23:39] <dOxxx> could you copy & paste the output of the push command?
[23:40] <gwal> bzr push
[23:40] <gwal> Using saved push location:
[23:40] <gwal> (... location ...)
[23:41] <gwal> Unable to obtain lock  held by (my name) at (my local computer's name), acquired 25 minutes ... ago
[23:41] <gwal> bzr: ERROR: Could not acquire lock "(local)":
[23:42] <dOxxx> and yet break-lock in that local branch directory does nothing?
[23:44] <gwal> no, I type in "bzr break-lock" in the local branche's directory, the terminal accepts it (no errors etc.) and I will get the same error message for my next attempt at bzr push
[23:44] <dOxxx> what URL transport are you using? bzr+ssh?
[23:45] <gwal> I indicate the remote location with sftp://
[23:45] <gwal> I'm not sure if that involves ssh?
[23:46] <dOxxx> similar but not quite the same
[23:46] <gwal> yea probably does eh?
[23:46] <gwal> ok
[23:47] <dOxxx> strange... okay, shot in the dark... try break-lock on the remote branch
[23:48] <gwal> ssh to the remote location and do break lock there or inside local branch do a bzr break-lock sftp://remote-loc
[23:48] <gwal> ?
[23:49] <dOxxx> ssh
[23:50] <gwal> it was 50/50 ... I tried the latter and that worked
[23:51] <dOxxx> so it actually found a lock?
[23:51] <gwal> yes it asked whether I wanted to break the lock of (my name) at my local computer
[23:51] <dOxxx> weird
[23:52] <dOxxx> ah I see
[23:52] <gwal> knowing nothing about bzr I can't gauge that really
[23:52] <gwal> so doing bzr push worked but it gave me all this info:
[23:53] <gwal> This transport does not update the working tree of: sftp://(remote loc) ... See 'bzr help working-trees' for more information. Pushed up to revision 5.
[23:53] <gwal> then doing bzr rspush also worked surprisingly
[23:53] <dOxxx> right...
[23:53] <gwal> what's this working trees business?
[23:54] <dOxxx> okay, so push will update the working tree of the remote branch to the revision you pushed up, but only if the protocol you use supports doing so
[23:54] <dOxxx> sftp doesn't
[23:54] <dOxxx> but bzr+ssh should
[23:54] <gwal> but why does it still say "pushing up rev 5"?
[23:55] <dOxxx> it's pushed new revisions into the repository in the remote branch
[23:55] <dOxxx> if you want the working tree in the remote branch to be updated as well, you will have to ssh and run bzr update
[23:57] <gwal> does that mean that if I were to ssh to the remote location and work on the local branch there then I would be modifying the old revision number 4? whereas if I go somewhere else and pull from the same remote location I would receive the updated revision number 5?
[23:58] <gwal> the latter seems to hold
[23:59] <dOxxx> the working tree would be at rev 4, so I'm not quite sure what would happen if you were to commit changes at that point.
[23:59] <dOxxx> it may give you an error
[23:59] <dOxxx> it may create a new rev 5 and the old rev 5 would be lost in the ether
[23:59] <dOxxx> otherwise known as a detached head, I think
[23:59] <dOxxx> it helps to think of these revisions as a directed acyclic graph