[00:11] hi [00:11] what should I do if bzr instructs me to run 'bzr upgrade' but then it tells me that it is already at the latest format version? [00:11] see http://pbot.rmdir.de/c09c1e95ebc98ddbc7148e2c3a228cc8 [00:13] Raim: It's telling you to upgrade http://code.bitlbee.org/bitlbee/ [00:13] Damn LF. [00:13] Raim: , not your local repo. [00:13] Peng_: ah! [00:13] Actually, it's telling you to upgrade http://code.bitlbee.org/. [00:13] yeah, I understand [00:14] and by reading the message again it even said exactly that [00:15] Unless you actually run code.bitlbee.org, you can't fix it, but it does encourage you to send them an email, and it helps explain why you'll have awful performance pulling from that repo. :"D [00:16] s/"// [00:22] hi there, i'm new to bazaar and DVCS in general, was wondering if someone could help explain to me what the difference between 'pull' and 'merge' is? === Kissaki is now known as Kissaki^0ff [00:36] that had better be in the manual, it's kinda important [00:36] * mzz checks [00:39] itistoday: "pull" either turns the branch you're running it in into a copy of the branch you're pulling from (while keeping any uncomitted changes) or complains if it can't do so because you have committed changes that aren't in the branch you're pulling [00:39] it isn't explained well in the user guide, but the man page has a good concise summary (i.e. man bzr) [00:40] itistoday: "merge" should only be done on a branch with no uncommitted changes and combines anything you've committed with anything in the branch you merge that you don't have yet, after which you get to review the result and commit it if it makes sense [00:40] weird that this isn't explained properly in the manual, imho it's kinda important to understand the difference [00:42] thanks, although sorry, i'm still a little confused... so first, for both 'pull' and 'merge' you need to have an existing branch to run the command from? [00:42] itistoday: it is important to realise that merge is normally done in a clean working dir, and you need to commit the result if it makes sense. "merge" always creates a brand new revision nobody else has yet, even if the resulting text is identical to some revision that already exists. pull fast-forwards, you don't add any revisions other than what you're pulling in. [00:42] yes, both pull and merge need two branches [00:43] so... I'm assuming the answer to this is 'no', but is then 'pulling' simply merging and then committing? if no, then what's the difference? [00:43] itistoday: if in doubt pulling if you can and merging if pull complains will often work, but in some workflows you may want to explicitly commit a merge even though a pull would be possible. [00:44] itistoday: pull does not create any new revisions that aren't already in the branch you're pulling. after merge you always have to commit the result (even if there are no conflicts) [00:45] itistoday: (this also means that you can merge and then revert if you did not like the result. With pull you'd have to remember the previous revision yourself to be able to do that) [00:46] mzz: thanks, kinda getting it, still have more questions tough, so then is 'pull' as if you were to remove your entire local branch and use the 'branch' command? [00:46] itistoday: yep [00:46] ok... that makes a whole lot more sense [00:46] itistoday: but only if you don't have any revisions locally that aren't in what you pull. If you do it'll complain that the branches have diverged. [00:47] itistoday: so other than that you can't easily undo it if you don't quite remember what the previous revision was, and assuming no *uncommitted* local changes, "pull" is quite safe [00:47] mzz: does that mean: local branch must have a revision number less than the one from where you're pulling? [00:47] itistoday: revision numbers in bzr confuse me. You'll have to read the manual for that one. [00:48] i guess that was a bad question, but essentially does that mean that you cannot have made any changes to the branch you have that are not in the one you're pulling from? [00:48] itistoday: (what if you committed one extra revision and you're pulling from a branch that has two (unrelated) new revisions?) [00:49] itistoday: no *committed* changes, yes. [00:49] itistoday: "pull" will attempt to keep uncommitted changes (just like "up" does in things like svn and cvs) [00:50] ok, cool :-) i think i get pull now [00:50] thanks! [00:50] itistoday: actually so will merge, but using that is usually a bad idea, since it means it's hard to tell which changes are part of the merge and which are yours! [00:50] that was going to be my next question [00:50] so you can merge when you have uncommitted changes? [00:50] By default, merge yells at you if you have uncommitted changes. You have to pass --force to do it. [00:51] ah, I didn't know that. [00:51] Peng_: thanks! What does the --uncommitted option mean? [00:51] (because I'm pretty good at making sure I have no uncommitted changes before merging myself) [00:51] --uncommitted: "Apply uncommitted changes from a working copy, instead of branch changes." [00:52] does that mean only grab the uncommitted files from the place you're merging from? [00:52] itistoday: Yeah. [00:52] itistoday: That merges the uncommitted changes in the source branch's working tree into yours, instead of merging the new revisions and ignoring the working tree. [00:52] that's really weird [00:53] It's really useful. [00:53] I don't think I've used that, but that's my fault. [00:53] i'm sure, i'm just new to this entire thing, it's all fascinating to me [00:53] Say you're making some changes in a branch, but then decide they should be in a new branch. Do "bzr branch", "bzr merge --uncommitted", and then "bzr revert" in the source branch. Bang! [00:53] I think I'd usually end up just committing those uncommitted changes to the other branch, then merging regularly. [00:53] ah, that's actually useful. [00:54] Peng_: great example! thanks [00:54] although unsurprisingly there are other ways to do that :) [00:54] so, one other thing regarding pull.. in the user's guide part 6.2.3: [00:55] 6.2.3 Refreshing a mirror branch [00:55] "Use the pull command to do this:" [00:55] cd trunk; bzr pull [00:55] that seems to be similar to 'update' [00:55] what's the difference? [00:55] itistoday: Pull is about branches, while update is about working trees. [00:56] ok, the terminology still hasn't stuck quite yet, is this right: pull is more granular than update? i.e. update does it for all the branches..? [00:56] "up" becomes important if you have working trees and their corresponding branch in different locations. [00:57] itistoday: Pull is "copy new revisions from branch X to Y". The pull command also implicitly runs "bzr update". Update is "update my working tree with new changes in branch X". [00:58] Peng_: does 'new revisions' there mean the 'history' from branch X to Y? [00:58] sounds right to me [00:58] and then 'update' takes the latest history and makes it visible to the file system for you to work? [00:58] itistoday: Yeah. [00:58] yep [00:59] awesome! thank you both very much for helping explain this :-) [00:59] itistoday: if this is just the result of "bzr branch" (aka "get") you'll end up with working tree and branch in the same spot, and won't have much use for "update" [00:59] itistoday: but there are ways to get the branch revision updated that don't automatically update the working tree afterwards, in which case you'll need "update". It'll probably be obvious once it happens. [01:00] err, branch history, not revision [01:00] "bzr help working-trees" mentions a few, I think [01:01] mzz: thanks, i'll keep that in mind [01:01] i looked over a quick git tutorial, it seems to take a different approach with where branches are stored, i.e. it seems like the entire folder contains the repository [01:01] does someone know if there's a plugin I overlooked that automates creating a new branch for a lightweight checkout and switching to it? [01:02] itistoday: I haven't used git much, but see 10.2.5 in the manual [01:03] I use a variation of that setup: my lightweight checkout isn't below the repository. [01:03] mzz: k, reading... [01:03] I'm looking for a more convenient way to do the "bzr branch ...", "bzr switch ..." mentioned there. [01:03] perhaps I should just write a plugin. [01:05] * mzz throws together a "relswitch" plugin [01:06] is there a generalized way to create server aliases, a la "lp"? [01:06] flvr8: I just came across the "bookmark" plugin, which may do what you want [01:06] thanks, will take a look [01:08] flvr8: Better than writing Python code, you mean? [01:09] Peng_: heh, i take it "lp" is hardcoded somewhere? are there other "presets"? [01:10] oh, huh. ":this" partially fixes what was annoying me. [01:11] flvr8: "lp:" is a bit fancier than it looks (deals with logins and some transformations of the path too iirc, it's not just a fixed prefix) [01:11] mzz: that seems a bit different from how git does it, i think. i think git sortof hides the branches from you, whereas with bzr you have to have the directory structure already laid out (repo/branches), i think git does (folder <- invisible branches) [01:11] mzz: ah, of course [01:11] itistoday: git does have a directory structure, but it's below .git, iirc. [01:12] itistoday: I suck at git, but afaict it's considered acceptable to peek inside .git. That's *much* less common with .bzr. [01:12] mzz: ah ok, then it should be possible to do something similar with 'bzr'? [01:12] itistoday: well, I do think the two are pretty similar, but I haven't compared them in any amount of depth :) [01:14] itistoday: I just found out about the magical ":this" location which points at the current branch. I think that can make them more similar [01:14] let's see [01:15] the idea would be to have a branch with a .bzr folder in it, and to be able to change the working directory of that to another branch, without changing the folder's location [01:15] I don't think you can have a .bzr folder, but you can have a .hidden-repo folder. Give me a minute, experimenting. [01:15] k [01:17] the .hidden-repo folder would have to reside within the branch itself... i'm not sure if that's possible with bazaar, which i think expects the repo to be the parent folder [01:18] yay lightweight checkouts [01:19] itistoday: haven't thought this through, but http://paste.pocoo.org/show/125465/ [01:20] itistoday: note that putting the checkout inside the repo works just fine (that's how that example in the manual I mentioned does it) [01:20] itistoday: I'm interested in doing it this way because I have my repo on a network mount while I want my checkout to be local. [01:21] mzz: so initially in that example :this points to .hidden-repo/trunk ? [01:22] itistoday: yeah, because that's what we checked out [01:22] with the checkout, do you still have access to all the revisions? [01:22] itistoday: as long as the repository is reachable [01:22] err, as long as the branch is reachable is better [01:23] it's a lightweight checkout, which means it has just a working tree. For anything involving history it needs the branch and its repository [01:23] which it transparently accesses? [01:24] itistoday: might actually want to peek at what ends up in .bzr to understand what's going on here, imho. [01:24] itistoday: the checkout remembers the location of its branch [01:24] mzz: so the lightweight checkout acts as an alias to the branch? [01:25] see "bzr help checkouts" [01:26] thanks, yeah, it seems like an alias [01:26] oh, I forgot --no-trees on the init-repo [01:26] what does that do? [01:26] er... i'll have a look at the manual [01:26] stop it from putting working directories in .hidden-repo, which is kinda silly here [01:27] cool, that makes sense, thanks for the example :-) [01:28] notice there's very little to a branch without a working tree: just a revision id, tags, and branch.conf [01:29] neat [01:30] but yeah, i think the main difference here between git is that with bzr the repo must be in a different directory than the working tree [01:30] and bzr gives you quite a bit of flexibility in where you put the repo, the branch, and the working tree (in the same place is simplest, but you can spread them out a bit too) [01:30] you might even be able to put the repo inside the checkout and .bzrignore it [01:31] now that would be cool [01:31] well, I think it'd be confusing. [01:31] if you mess up the .bzrignore you could end up committing the repo to itself, or something equally daft. [01:31] let's see though. [01:32] flvr8: lp: is provided by the built-in Launchpad plugin (bzrlib.plugins.launchpad), using bzrlib's directory service API. You could totally write a plugin to provide something similar, but you can't just add "foo: = http://bzr.foo.org/" to some config file. [01:32] the bookmark plugin mostly does just that, iiuc [01:34] itistoday: http://paste.pocoo.org/show/125470/ does seem to work, although I still think it's confusing. [01:35] Peng_: thanks [01:37] itistoday: to improve this setup further you'd want a :repo alias so you don't have to specify those paths relative to the branch [01:37] mzz: thanks! is there any easy way to set that alias? [01:37] does anybody have experience with the bzr-emailer-notifier script? it's sending emails ok for two of the repositories, but not the third. (and there are a bunch of 'No handlers could be found for logger "bzr" errors' in the log, which makes me wonder if it's hung up on a lock per #141172 or #172392 -- any way to tell?) [01:37] itistoday: and adding that to bzr is pretty trivial, although it is arguably a misfeature because branches are normally just an optimization, you're not supposed to care about their location [01:38] itistoday: I'm tempted to just write it anyway though. [01:38] lemme grab a snack and do that. [01:38] mzz: :-) [01:41] wow this is neat [01:41] so, i did something very similar to what you did, mzz [01:42] except i had a branch to start with already [01:42] so after creating the repo in the branch (.bzr-repo) [01:42] i branched to it like this: bzr branch . .bzr-repo/trunk [01:42] then I deleted everything inside the folder *except* for the .bzr-repo folder [01:43] and did a lightweight checkout from the .bzr-repo/trunk [01:43] and now it appears i have the same setup [01:43] yep (remember to make that a --no-trees repo, bit faster that way) [01:44] yeah i did :-) [01:44] is there a bzr command though to do what i did via rm -rf and bzr checkout --lightweight? [01:44] i.e. turning the current branch into a checkout from someplace else? [01:44] it seems like a dangerous thing to do though so there might not be [01:45] just want to know if what i did would be the standard way of doing that [01:45] lemme see [01:48] itistoday: bzr reconfigure --lightweight-checkout --bind-to .bzr-repo/trunk . [01:49] wowww [01:49] let me see if that works... [01:52] incredible [01:52] bazaar is awesome :-) [01:52] i might write a blog post on this if that's OK? i'll of course be sure to credit you and your examples [01:52] mmm, drat. "lookups" is not an instance variable, so I can't just hack up the existing AliasDirectory so you get the same style of alias. Oh well. [01:53] i think people would be interesting for the git people to know that this can be done in bazaar [01:53] *think people = think it [01:58] how does the autocompletion work in bzr shell? [01:58] i type 'br[tab]' and it just puts a tab [02:10] itistoday: meh. Try http://paste.pocoo.org/show/125474/ (put in ~/.bazaar/plugins, then turn the ":this/.." in earlier examples into "repo:") [02:11] * mzz found various fun locations differing from the one he wanted [02:12] itistoday: tab-completion works for me [02:12] i'm on OS X [02:12] oh well, not a big deal [02:12] re plugin: neat! [02:12] ill try it right now :-D [02:13] (I was ending up with locations at various spots below .bzr, which wasn't what I wanted) [02:13] (took me a while to realise I had to go through .bzrdir) [02:13] it might be useful for me to learn python at this point, if only to be able to customize bzr to my liking :-) [02:14] not sure what what you mean ..? [02:14] can be quite useful to do ad hoc scripts or plugins [02:14] just that I was getting the code wrong initially [02:15] how do i setup the plugin folder properly with this paste? [02:15] i've always seen plugins as directories, and they usually have some sort of specific setup with an __init__.py file in it [02:18] mzz: ping [02:19] itistoday: http://paste.pocoo.org/show/125477/ is slightly cleaner [02:20] mzz: how do I setup the plugin though? [02:20] itistoday: just store as ~/.bazaar/plugins/repoalias.py, or ~/.bazaar/plugins/repoalias/__init__.py if you prefer [02:21] doesn't seem to work via the second method... [02:22] Unable to load plugin 'repoalias' from '/Users/gslepak/.bazaar/plugins' [02:22] Unable to load plugin 'repoalias' from '/Users/gslepak/.bazaar/plugins' [02:22] err, sorry for the dup [02:23] no? urgh, now what did I do wrong [02:23] mzz: have you tried it? [02:23] there should be a message above the failure [02:23] yes, I have [02:23] well, I've tried way one, and I can't think of a reason for way 2 to fail [02:23] (don't do both at the same time though) [02:23] i tried method 1 too [02:23] same message [02:24] wonder if there's any way to get what the reason is? [02:24] no further output? Also check ~/.bzr.log [02:25] yeah, there is [02:25] 1 sec [02:25] http://paste.pocoo.org/show/125478/ [02:26] doesn't seem to like RepositoryDirectory [02:27] that traceback makes no sense to me [02:27] oh wait [02:28] itistoday: how did you paste this code over? Did you accidentally end up with the call to directory_service.directories.register indented? [02:28] let me check [02:28] yes [02:28] sorry, i don't know python [02:28] itistoday: indentation is syntax in python. Using the "download" button of the pastebin is strongly recommended. [02:29] (under "paste details") [02:29] or I guess I could just stuff this thing on launchpad [02:29] k, will remember that from now on for python code [02:30] ok that seemed to work :-) [02:30] although i'm probalby using it incorrectly: bzr branch . :repo/expirmental [02:30] bzr: ERROR: ":repo/expirmental" is not a valid location alias. [02:31] itistoday: repo:, not :repo. Sorry about that. [02:31] :-D [02:31] mzz: thanks! sorry about that [02:31] i like that syntax a lot actually [02:31] I actually think I like repo: better, so I think I'll keep it [02:31] yeah [02:31] definitely [02:32] hmm, what to call the plugin [02:32] mzz: you might want to consider making this a real plugin? [02:32] i think lots of people would find this useful [02:32] hardest part: think of a name [02:32] repoalias is pretty good i think... [02:32] repoalias it is [02:32] :-) [02:34] yup, seems like it [02:36] itistoday: just give me a minute, pushing etc [02:36] mzz: sure :-) [02:38] * mzz is figuring out whether lp can host branches without having a whole project for them [02:38] mzz: Use +junk in place of the project name. [02:39] "bzr push lp:+junk/repoalias" fails [02:39] mzz: You need your username in there too. [02:39] bzr push lp:~username/+junk/branch [02:39] yeah, got it. Thanks! [02:40] itistoday: bzr get lp:~marienz/+junk/repoalias [02:41] mzz: awesome, thanks! [02:42] if I get time i'll write a blog entry on this plugin and using bazaar like git here: http://taoeffect.com/blog [02:44] notice this is just a hack so far, I don't know if there are any gotchas if you actually use this [02:45] mzz: k, will be sure to mention that if i post it [02:48] added it to the list on the wiki too [02:48] I guess I'll turn it into a proper lp project if people use it [02:48] just used it with merge, seems to be working fine :-) [02:49] mzz: if i find any bugs in it, what would be the best way to report them to you? [02:51] * mzz wonders if launchpad has a way to file bugs on a person instead of a project [02:52] itistoday: I'm actually more reachable through irc than through email, I'm weird like that. Just poke me in here. [02:52] mzz: k, sure thing, yeah, and it would be neat if launchpad could do that, although if you decide to turn it into a project that would solve it [02:59] already, i'm heading out, thanks again mzz for all your help, and the awesome plugin! === davidstrauss_ is now known as davidstrauss [07:36] If I see this: [07:36] working tree: Working tree format 4 [07:36] branch: Branch format 6 [07:36] repository: Development repository format - rich roots, group compression and chk inventories [07:36] ... from 'bzr info -v', does that mean I'm using brisbane core? [07:37] 'chk inventories' == brisbane core [07:37] Not sure if that's 2a, though. [07:37] 2a has branch7 too [07:38] kfogel: run bzr upgrade --2a in the *branch* directory [07:38] Right, my 2a has that repository type but branch7 [07:38] (it will be very quick) [07:38] although [07:38] you should probably recreate the working tree too [07:39] mwhudson: this is the mysql-server branch that I created, using the script you've seen by email. I ran 'bzr upgrade --2a mysql-server' to get this! [07:40] kfogel: it's a standalone branch? [07:40] mwhudson: yes [07:40] I though branch7 was only needed for stacking. Does 2a force it just because it's a good opportunity? [07:41] mwhudson: it is not in a repo other than itself [07:41] kfogel: strange! [07:41] wgrant: yes, i think so [07:42] wgrant: any client that can understand a chk repo can certainly understand branch7 [07:42] mwhudson: That is true. [07:42] mwhudson: this appears to be bzr 1.16, not 1.16.1, fwiw (it's on devpad). [07:43] kfogel: i don't think any of the fixes will have made a difference here [07:43] kfogel: you did run reconcile before updgrade, right? [07:44] mwhudson: yup. I just ran that script, as per my email. [07:44] good [07:44] What benefit does the reconcile bring? [07:44] well, you could try running bzr upgrade --2a again... [07:44] (apart from making a nice heater) [07:45] wgrant: inconsistent revision information in the revision graphs can mess the conversion up [07:45] (i don't really know the details tbh) [07:45] * mwhudson goes to cook dinner [07:46] mwhudson: Ah, right. [07:46] mwhudson: bzr upgrade --2a will take another four days? [07:46] kfogel: it really shouldn't [07:46] changing the branch format is easier [07:46] maybe tar it up first though... [07:47] time bzr upgrade --2a [07:47] starting upgrade of file:///home/kfogel/lp-testing/mysql-server/ [07:47] making backup of file:///home/kfogel/lp-testing/mysql-server/.bzr [07:47] to file:///home/kfogel/lp-testing/mysql-server/backup.bzr [07:47] bzr: ERROR: File exists: u'/home/kfogel/lp-testing/mysql-server/backup.bzr/': [\ [07:47] Errno 17] File exists: '/home/kfogel/lp-testing/mysql-server/backup.bzr/' [07:47] rm -rf backup.bzr [07:48] mwhudson: done (well, moved it elsewhere). now re-running [07:48] mwhudson: thanks for taking time out from cooking dinner [07:49] mwhudson: upgrade completed :-) [07:49] 22 milliseconds [07:50] bzr info -v now says branch format 7 [08:31] kfogel: yay === lamont` is now known as lamont [16:18] G'day all… [16:20] I'm reading http://bazaar-vcs.org/Roadmap/BrisbaneCore/PlusOne and the last feature listed there appeals to me for a client. [16:20] Any hint whether we're talking months or years here? === Kissaki^0ff is now known as Kissaki [16:53] is there a mirror for bzr downloads somewhere? lp seems to be down [17:31] Glenjamin: should be back up [17:36] mm, got it now [17:36] altho i'm having a problem installing bzrtools on linx [17:37] i;ve installed bzr and bzrtools via easy_install, but they both seem to be eggs, instead of bzrtools going into the plugins folder [18:54] Glenjamin: but does "bzr plugins" list bzrtools? === asabil_ is now known as asabil === Noya_ is now known as Noya [23:11] SamB: cheers for replying, i figured our that easy_install did an egg, which didnt work - but setup.py install did it properly === Kissaki is now known as Kissaki^0ff === RAOF__ is now known as RAOF [23:58] abentley: not around are you?