[08:23] <mthaddon> can anyone explain what's going on here? http://paste.ubuntu.com/5720952/ - seems like bzr di --old --new isn't giving the right info
[08:28] <fullermd> From a glance at the diff, it's suggesting that trunk has stuff memcached doesn't.  And trying to merge memcached into trunk shows nothing to do.  Which sounds sensible.  What are you expecting and not getting?
[08:28] <fullermd> (you may want to check 'missing')
[08:29] <mthaddon> I thought the two branches would have no diff
[08:29] <mthaddon> but you're right, that does seem to be the case - checking
[08:31] <mthaddon> sorry for the noise, my bad
[08:31]  * fullermd takes the credit for fixing it.
[08:32] <fullermd> (only 6 more, and I get a free lollipop!)
[08:33] <mthaddon> heh
[11:00] <Andy80> hi
[11:02] <Andy80> I've a very newbie question. Suppose you have the "master" branch and "new-feature" branch (based on master). When I use git I can easily switch between the two branches doing "git checkout master / git checkout new-feature". How can I do it with Bazaar? Checkout seems to have a different meaning in bzr. Thanks!
[11:03] <LeoNerd> Generally we don't bother switching between branches in a single working directory. Usually I keep different branches in different dirs
[11:03] <LeoNerd> You can  bzr switch  if you want, though
[11:04] <LeoNerd> But usually I find  cd  nicer :)
[11:05] <maxb> Of course, that needlessly wastes diskspace if you have several branches, some fairly inactive
[11:05] <LeoNerd> Wellyeah, depends on the use case. Usually I'm never working on things with multiple-gigabyte source trees :)
[11:05] <Andy80> maxb: which approach? the switch one or having all in different folders?
[11:05] <LeoNerd> Also my disk is far cheaper than my time is
[11:06] <maxb> I tend to init-repo --no-trees a shared repository , have a bunch of branches in it, and a single checkout, which I switch
[11:07] <Andy80> ~800Mb in my case :)
[11:09] <Andy80> I think it's also useful (switch approach) when you want to temporary switch to an old revision, test some code and switch forward to the latest available, don't you think?
[11:18] <Andy80> I got an internal error from bazr using switch :(
[11:19] <Andy80> I get this http://pastebin.com/uSGyTzAa
[11:19] <Andy80> I jut did: bzr switch -r 2797
[11:24] <LarstiQ> Andy80: huu
[11:25] <LarstiQ> Andy80: you didn't give it a branch to switch to?
[11:25] <LarstiQ> ah hmm, that does seem to work here
[11:26] <LarstiQ> Andy80: that traceback is incomplete, could you pastebin the full one from ~/.bzr.log?
[11:26] <fullermd> I suspect you really want update rather than switch there anyway.
[11:27] <Andy80> fullermd: update what?
[11:27] <fullermd> bzr update -r2797
[11:27] <Andy80> LarstiQ: gime me some minutes, I'm doing a different thing right now and cannot abandon it
[11:28] <Andy80> fullermd: no... I just wanted to switch, execute some code with no modification and switch back...
[11:28] <LarstiQ> Andy80: no worries
[11:28] <Andy80> just like the git "checkout" command
[11:28] <fullermd> As is usual for such things, there isn't a 1:1 mapping of command intentions and names among systems   :)
[11:29] <fullermd> 'switch' is really geared toward "change this WT to be with another branch".  'update' is asking for "change this WT to a different rev in this branch".
[11:30] <LarstiQ> and 'revert' would only change the WT contents
[11:30] <fullermd> There's some overlap and ambiguity between the two, to be sure, but weird behavior is likely when you get into the offsides of clearer cases.
[11:30] <LarstiQ> which for running some code imo is what you care about
[11:31] <fullermd> No, you really only want revert when you're wanting to do things like "change individual file to state as of rev X".
[11:31] <fullermd> When you want to do things more like "temporarily change the whole tree to state X, and I'll be going 'back' to 'now' later", update is a much better choice, since it knows what it's done.
[11:32] <fullermd> That is, a sequence like "revert -rX, try some stuff, revert -rY, try stuff, revert -rZ, try stuff, OK, I'm doing, revert -rLATEST" is just thumbing your nose at Murphy.
[11:32] <fullermd> update is much better suited for that, doubly so since it can do merges.
[11:32] <LarstiQ> right
[11:33] <fullermd> (e.g., "update -rX, make some changes, update -r-1, those changes are now merged forward as much as possible")
[11:33]  * LarstiQ usually only does revert -rX; stuff; revert;
[11:33] <LarstiQ> where stuff does not include making changes
[11:33] <LarstiQ> fullermd: I'll see if I can get used to using update :)
[11:34] <fullermd> As my rule, the overriding use case for revert is "discard {some,all} changes I've made since last commit", with the secondary use case being "change this file back to a previous state, I think I wanna dump some committed changes to it".
[11:35] <fullermd> I figure "Let me try something on the whole tree at a previous rev" is solidly in 'update's baliwick.
[11:42] <Andy80> so basically I need to do: bzr update -r 2797, I do my stuff, tests etc.... then I: bzr revert, right?
[11:42] <fullermd> (actually, for the case of "let me try a quick experiment on a pristine old tree, then discard it all", I'm probably most likely to just make a throwaway branch for it.  Depending on size and environment, of course...)
[11:42] <fullermd> You'd want update -r-1 (or maybe just 'update'; I don't recall offhand) to get back to the head of the branch.
[11:42] <Andy80> ah cool
[11:43] <fullermd> That revert would just wipe whatever changes you'd made relative to pristine r2797.
[11:43] <fullermd> (revert fiddles with the working tree _files_, but not the working tree _state_.  update twiddles the state, then merges changes to the files relative to the previous state)
[11:44] <fullermd> So if you start out with a clean tree at the head (call it r3000), running 'bzr diff' will show nothing (Since you have no changes)
[11:44] <fullermd> After running a "update -r2797", doing a 'diff' will also show nothing (since you now have a tree just like r2797)
[11:45] <fullermd> But if you'd done "revert -r2797", the diff would give you the output of "bzr diff -r3000..2797", since your files look like r2797, but your WT considers itself to be based at r3000.
[11:46] <fullermd> So if you "update -r2797", then later do a "revert", you'll get a pristine r2797.  If you "revert -r-1", you'll get a tree with 3000's contents that considers itself based on '2797', so diff would show "bzr diff -r2797..3000"ish output.
[11:48] <fullermd> Or, to make some attempt at handwavy comparisons (don't expect perfect correspondence, but it's closeish)
[11:48] <fullermd> "git checkout $BRANCH" is like "bzr switch $BRANCH"
[11:49] <fullermd> "git checkout $COMMIT" is more like "bzr update -r$COMMIT" (except that you're not really setup to commit based on it at that point)
[11:49] <fullermd> "git checkout $PATH" is in "bzr revert $PATH" territory.
[11:51] <Andy80> fullermd: and what happens if, for example, once I'm on r2797 I do some changes? Firtst question: how do I simply discharge them (if I want) and how do I keep them and merge/push to another new branch?
[11:52] <fullermd> Well, if you did a "bzr update -r2797 ; <make changes> ; bzr revert", the result would be that you're back sitting at an unchanged r2797.
[11:52] <Andy80> ok
[11:52] <fullermd> If you decide you want to commit them, you'd have to make a branch to do them on.  If you expect that from the get-go, you might as well make the branch in the first place and work from there.
[11:53] <fullermd> (e.g., "bzr branch -r2797 source newbranch ; cd newbranch ; <make changes>" etc.  Or something similar but different, if you're doing a shared-WT setup.
[11:53] <Andy80> and what if I know only later that I want to have a new branch with my changes?
[11:53] <fullermd> If it's only after the fact that you decide you want to make a new branch with those changes, you can make that newbranch at that point and use "merge --uncommitted" to pull over the changes from the WT.
[11:54] <fullermd> (or, if you're using a common WT...   mmm....   I think you can do a "shelve ; switch ; unshelve" sequence?)
[11:55] <LeoNerd> shelve/unshelve is useful for this sort of thing. Though sometimes I've wanted to be able to "unshelve-from" a different working tree
[11:55] <LeoNerd> bzr unshelve-from ../foo.OTHERBRANCH  could be nice
[11:55] <fullermd> e.g., "whoops, I want to make a branch with these" ; cd .. ; bzr branch -r2797 source newbranch ; cd newbranch ; bzr merge --uncommitted ../source ; bzr ci (those new changes on this new branch) ; cd ../source ; bzr revert (to clean up in source) ; bzr update (to get source back up to the head of the branch)
[11:56] <LeoNerd> Oohyes... merge --uncommitted  is useful too
[11:57] <LeoNerd> Is that quite a new thing? I often forget about that one
[11:57] <fullermd> Not very...
[11:57] <fullermd> A quick grep in release notes says it came in with 0.10.
[11:58] <Andy80> fullermd: cool, nice example, thanks :)
[13:31] <Andy80> are the bazaar location all hardcoded under .bzr/branch/location ? I've moved some branches I had under a different location and now I get this error: andrea@ultrabook ~/Documents/Glow/src/2798/andrea $ bzr status
[13:31] <Andy80> bzr: ERROR: Not a branch: "/home/andrea/Documents/Glow/2798/andrea/".
[13:39] <Andy80> I've tried to change the path inside that file but it's not working, I cannot fix it :(