/srv/irclogs.ubuntu.com/2013/04/19/#bzr.txt

=== thumper is now known as thumper-afk
=== milleja46_ is now known as milleja46
=== thumper-afk is now known as thumper
mthaddoncan anyone explain what's going on here? http://paste.ubuntu.com/5720952/ - seems like bzr di --old --new isn't giving the right info08:23
fullermdFrom 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:28
mthaddonI thought the two branches would have no diff08:29
mthaddonbut you're right, that does seem to be the case - checking08:29
mthaddonsorry for the noise, my bad08:31
* fullermd takes the credit for fixing it.08:31
fullermd(only 6 more, and I get a free lollipop!)08:32
mthaddonheh08:33
Andy80hi11:00
Andy80I'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:02
LeoNerdGenerally we don't bother switching between branches in a single working directory. Usually I keep different branches in different dirs11:03
LeoNerdYou can  bzr switch  if you want, though11:03
LeoNerdBut usually I find  cd  nicer :)11:04
maxbOf course, that needlessly wastes diskspace if you have several branches, some fairly inactive11:05
LeoNerdWellyeah, depends on the use case. Usually I'm never working on things with multiple-gigabyte source trees :)11:05
Andy80maxb: which approach? the switch one or having all in different folders?11:05
LeoNerdAlso my disk is far cheaper than my time is11:05
maxbI tend to init-repo --no-trees a shared repository , have a bunch of branches in it, and a single checkout, which I switch11:06
Andy80~800Mb in my case :)11:07
Andy80I 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:09
Andy80I got an internal error from bazr using switch :(11:18
Andy80I get this http://pastebin.com/uSGyTzAa11:19
Andy80I jut did: bzr switch -r 279711:19
LarstiQAndy80: huu11:24
LarstiQAndy80: you didn't give it a branch to switch to?11:25
LarstiQah hmm, that does seem to work here11:25
LarstiQAndy80: that traceback is incomplete, could you pastebin the full one from ~/.bzr.log?11:26
fullermdI suspect you really want update rather than switch there anyway.11:26
Andy80fullermd: update what?11:27
fullermdbzr update -r279711:27
Andy80LarstiQ: gime me some minutes, I'm doing a different thing right now and cannot abandon it11:27
Andy80fullermd: no... I just wanted to switch, execute some code with no modification and switch back...11:28
LarstiQAndy80: no worries11:28
Andy80just like the git "checkout" command11:28
fullermdAs is usual for such things, there isn't a 1:1 mapping of command intentions and names among systems   :)11:28
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:29
LarstiQand 'revert' would only change the WT contents11:30
fullermdThere'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
LarstiQwhich for running some code imo is what you care about11:30
fullermdNo, you really only want revert when you're wanting to do things like "change individual file to state as of rev X".11:31
fullermdWhen 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:31
fullermdThat 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
fullermdupdate is much better suited for that, doubly so since it can do merges.11:32
LarstiQright11:32
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
LarstiQwhere stuff does not include making changes11:33
LarstiQfullermd: I'll see if I can get used to using update :)11:33
fullermdAs 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:34
fullermdI figure "Let me try something on the whole tree at a previous rev" is solidly in 'update's baliwick.11:35
Andy80so 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
fullermdYou'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
Andy80ah cool11:42
fullermdThat 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:43
fullermdSo 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
fullermdAfter running a "update -r2797", doing a 'diff' will also show nothing (since you now have a tree just like r2797)11:44
fullermdBut 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:45
fullermdSo 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:46
fullermdOr, 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:48
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:49
Andy80fullermd: 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:51
fullermdWell, 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
Andy80ok11:52
fullermdIf 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:52
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
Andy80and what if I know only later that I want to have a new branch with my changes?11:53
fullermdIf 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:53
fullermd(or, if you're using a common WT...   mmm....   I think you can do a "shelve ; switch ; unshelve" sequence?)11:54
LeoNerdshelve/unshelve is useful for this sort of thing. Though sometimes I've wanted to be able to "unshelve-from" a different working tree11:55
LeoNerdbzr unshelve-from ../foo.OTHERBRANCH  could be nice11:55
fullermde.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:55
LeoNerdOohyes... merge --uncommitted  is useful too11:56
LeoNerdIs that quite a new thing? I often forget about that one11:57
fullermdNot very...11:57
fullermdA quick grep in release notes says it came in with 0.10.11:57
Andy80fullermd: cool, nice example, thanks :)11:58
=== Saviq is now known as Saviq|mtg
=== wedgwood_away is now known as wedgwood
=== Saviq|mtg is now known as Saviq
Andy80are 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 status13:31
Andy80bzr: ERROR: Not a branch: "/home/andrea/Documents/Glow/2798/andrea/".13:31
Andy80I've tried to change the path inside that file but it's not working, I cannot fix it :(13:39
=== frankoid_ is now known as frankoid
=== SamB_ is now known as SamB
=== yofel_ is now known as yofel
=== wedgwood is now known as wedgwood_away
=== wedgwood_away is now known as wedgwood
=== wedgwood is now known as wedgwood_away

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!