=== bigjools-afk is now known as bigjools [01:49] AHA [01:49] Got it [01:50] The reason all those UDD imports are failing with LockContention is because branch.bzrdir.open_workingtree() gives you a tree whose tree.branch isn't the same branch as the original [01:50] Which isn't unreasonable given the indirection via bzrdir [06:36] maxb: do you need the actual tree in that location? If so, can't you start with it? [06:43] maxb: thats actually deliberate [06:44] maxb: keeps the core simple, lets folk do clever things if they need to. [07:17] morning all! [07:20] hei mgz [07:22] LarstiQ: The code flow is such that we already have the branch open when it becomes relevant to want the tree too - at least, without restructuring it a bit [07:25] lifeless: Yes, "... isn't unreasonable ..." = me being happy with bzr core's behaviour [07:28] maxb: and branch.basis_tree() is not sufficient? [07:29] maxb: cool cool [07:31] ...I missed the context while on bus, this is about relocking issues with new branch objecT? [07:31] Needs to be a WorkingTree [07:31] mgz: yeah, 01:50:14 < maxb> The reason all those UDD imports are failing with LockContention is because branch.bzrdir.open_workingtree() gives you a tree whose tree.branch isn't the same branch as the original [07:31] Yes, a LockContention happens because udd has accidentally aliased the branch object [07:34] jam: if you have some spare cycles, mind having a look at bug 541626 and whether lp:~larstiq/bzr/bug541626 heads in the right direction? [07:34] Launchpad bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] https://launchpad.net/bugs/541626 [07:35] can you preserve the token from the original lock operation and pass it in when locking the new branch? [07:35] not ideal, really don't want multiple branch objects for the same location [07:36] preserving the token isn't an option - too many layers of code in the way [07:37] hm. [07:37] It's a bit annoying that there isn't a way to open one kind of object from its siblings [07:38] I suppose I'll just rearrange the code in UDD so it can open the WT first and get the Branch from the WT object [07:39] that's what I've done in the past, does feel like there should be a better method [07:39] sometimes you always want the branch but may or may not want the tree [07:39] hi all [07:39] moin vila [07:40] maxb: tree's can't do their thing w.o the branch though [07:40] maxb: which is why opening the tree implies opening the branch [07:41] it might be interesting to try having a tree with no operations that need a branch, and branch w none that need a repo [07:41] I wonder what that would look like [07:41] e.g. what would 'do a commit' look like. [07:43] lifeless: The issue is, I have a Branch already open, and I really want to just open a WorkingTree using my already open Branch [07:43] Instead, I'm going to have to close my Branch, and open a WorkingTree, which will re-open the branch [07:43] you could keep your branch, and open a working tree [07:44] the issue AIUI is that you have the branch write locked. [07:44] which is rather separate. [07:45] multiple objects are still an issue for other reasons. is branch.repository shared at least? [07:45] if not, you also have two sets of caches. [07:46] there is a facility to pass in existing transports to various opens() [07:46] you could extend that for live objects too; though it would depend on url equivalence [07:47] I am keeping my branch and opening a working tree - this results in the branch (and repository) being re-opened [07:48] right, just checked, the repo isn't shared either, that's bad. [07:49] and I don't like the idea of adding an extra param that can get forgotten as the new right way [07:49] Really what I need is for the WorkingTree API to acknowledge that the associated Branch may already be open, and let it be passed in [07:50] It turns out my WT has already been opened once, then discarded, too :-) [07:50] So, I think my answer here is to stop using BzrDir.create_branch_convenience, and do the creation myself so that I can get hold of the return value of create_workingtree [07:58] LarstiQ: looks fine to me. You'll probably want to look at the tests in test_btree.py that currently only go against index implementations, (or maybe it is per_index?) [07:58] to see if you can get a builder object passing the same _find_ancestors tests. [08:00] jam: aye [08:02] Hm. Actually, if you're doing work on lots of branches in a shared repository, it must be really easy to accidentally reopen the repository every time you open a new branch [08:02] maxb: it is. [08:05] riight, so the udd importer is probably opening repositories N * number-of-existing-ubuntu-series times :-/ [08:06] * maxb kicks off a test import with the modified code [08:08] gah, thinko, called create_workingtree on the branch not the bzrdir [08:11] It is a bit inconsistent that we have a branch.bzrdir.create_workingtree(from_branch=branch) but no equivalent for open_workingtree [08:24] maxb: point me at the mp when you're ready [08:26] https://code.launchpad.net/~maxb/udd/lockcontention/+merge/104500 [08:46] maxb: reviewed. I can deploy to jubany later, or you can do that. [08:57] maxb: from my questions, only real addition that I'd like would be a docstring on create_branch that says what the aim is exactly [08:58] it's kinda just a thin wrapper with some preconfigured bits, maybe the functions that use it need more [09:04] Well, it's only used in two places, and those have little in common [09:05] It might even be appropriate to rename it to an underscore-prefixed name, it's so much an implementation detail [09:05] right, what I'm not clear on is if create_updates_branch needs the tree [09:05] right, underscore or rename would be good. === idnaria is now known as idnar === kgoetz is now known as Kamping_Kaiser [10:15] Hi all! [10:17] hi PaoloRotolo [10:19] I have a problem with Bazaar. I get this error: "paolo@voyager:~/Sviluppo$ bzr branch lp:ubuntu/precise/gnome-control-center [10:19] bzr: ERROR: Revision {package-import@ubuntu.com-20120316192311-zi5yuz8wrcq6tbhg} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))"... [10:25] PaoloRotolo: see bug 888615 [10:25] Launchpad bug 888615 in Bazaar "UDD branch freshness checker breaks on incomplete history" [High,Confirmed] https://launchpad.net/bugs/888615 [10:27] jelmer, thanks! === bob2_ is now known as bob2 === yofel_ is now known as yofel [13:53] halp [13:53] jml! [13:53] I just ran 'bzr rmbranch foo' in my colo and now it doesn't work [13:54] was in 'trunk', ran 'bzr rm working-public-ip', and now I can't switch branches [13:54] jml: what version of bzr? [13:54] 2.5.9 [13:54] 9? 0. [13:55] Bazaar (bzr) 2.5.0 [13:55] * mgz guesses, need to back port the rmbranch fix still [13:55] jml: that doesn't have the rmbranch fix [13:55] so if you specify a branch name, it will try to open the branch containing that path [13:55] s/branch/control directory/ [13:55] that control directory would be 'trunk' [13:55] and then it removes the active branch [14:01] jelmer: yuck. [14:01] jelmer: how do I dig myself out of this? [14:03] jml: you can create the branch again by running "bzr heads --dead-only" to find the relevant revision [14:04] and then using "bzr pull -rrevid:REVID --overwrite ." to create the branch again [14:05] jelmer: ok. I'll try that. [14:06] bzr: ERROR: Not a branch: "/home/jml/src/lp-dev-utils/.bzr/branch/": location is a repository. [14:06] :( [14:06] jml: try a "bzr init ." first [14:08] jelmer: interesting. now when I try that I get: $ bzr switch trunk [14:08] bzr: ERROR: Cannot switch a branch, only a checkout. [14:09] jml: you want "bzr switch -b trunk" [14:09] bzr: ERROR: Cannot lock LockDir(file:///home/jml/src/lp-dev-utils/.bzr/branches/trunk/lock): File exists: u'/home/jml/src/lp-dev-utils/.bzr/branches/trunk/lock': [Errno 17] File exists: '/home/jml/src/lp-dev-utils/.bzr/branches/trunk/lock' [14:09] break the loc? [14:10] jml: ah, it already exists [14:10] sorry, I didn't realize your current branch was just a reference [14:10] ah [14:10] jml: try "bzr rmbranch; bzr co --lightweight file:,branch=trunk ." [14:11] jelmer: that succeeds without error, but then: bzr switch trunk [14:11] bzr: ERROR: Not a branch: "/home/jml/src/lp-dev-utils/.bzr/branch/": location is a repository. [14:12] jml: what does "bzr branches" say? [14:12] jml: generally speaking though, I would recommend using something 2.6-ish with colocated branches [14:12] jelmer: it lists four branches, including trunk, but none are selected. [14:12] jelmer: I'm guessing 2.6 is not in 12.04? === jcsackett_ is now known as jcsackett [14:13] jml: no, unfortunately not [14:13] jml: you can try "bzr switch --force" [14:13] jelmer: ok. [14:14] jelmer: I think I'll just refetch, and then use heads to pull the branches from the old one into a new colo [14:15] ok [14:15] jelmer: thanks though. [14:15] jml: I don't think colocated branches are ready for production use, tbh. They're not polished enough. [14:16] jelmer: well, I started using them because I prefer the layout, and because I wanted to help polish them as an alpha user [14:16] doesn't look like that's going to happen though. [14:20] * jml goes temporarily Eeyore === deryck is now known as deryck[lunch] [17:43] i'd like to have a diff of all files between two commits [17:43] how can I do this? :-) [17:44] lduros: bzr diff -r4..5 [17:44] bzr diff -rXXX..XX [17:44] ah ok [17:44] :-) [17:44] to get the diff between revision 4 and 5 [17:44] lduros: :) [17:44] i thought the dots had to be replaced [17:44] with something [17:44] They're actually upside-down apostrophes. With amputated tails. [17:46] fullermd: that sounds like punctuation-abuse to me [17:46] ah [17:47] but does it commits in between [17:47] You call it punctuation abuse, I call it thursday. [17:47] does it compare all the commits in between [17:47] I meant [17:47] There's no "in between" really. There are just two states. [17:48] ok [17:48] how can you tell what revision number you are on currently [17:48] sorry... just learning bzr [17:49] lduros: 'bzr revno' [17:49] cool [17:49] that shows the latest one though [17:49] if you are using revert -r xxx [17:49] it wouldn't show xxx [17:49] but the latest [17:49] revision [17:49] number === deryck[lunch] is now known as deryck [17:51] lduros: revert doesn't change the revion number [17:51] hmm ok [17:51] lduros: it justs sets the contents of the working tree to match that of the specified revision [17:51] but it puts the file to a given revision number no? [17:51] ok [17:51] lduros: to the contents of the file in that revision [17:51] rightok [17:51] no big deal then :-P [17:51] hehe [17:54] at least revision numbers are easier to remember than git sha1 hashes [17:54] :-P === lifeless_ is now known as lifeless [22:44] I've been using bazaar for two weeks, and I really love it [22:44] thanks for making bazaar! [22:45] :-P [22:45] if anybody here is involved with it [22:46] going back in revisions is much simpler than git [22:50] lduros: excellent [22:50] lifeless: I had to find a subtle bug, which I introduced I didn't know where, hundred commits ago [22:50] I went back, revert commit 10 by 10 [22:51] until I narrowed down to the revision that had an issue [22:51] this in git was a headache for me [22:51] with the hashes [22:51] maybe there's a better way to do it in git [22:51] than I would [22:52] I believe many folk would use git bisect [22:53] there is a bisect tool for bzr as well [22:53] it just automates (and optimises) the process of narrowing down a change [22:54] lifeless: hmm [22:54] but you need to automate the test no? [22:54] which is not that easy to do in my case [22:55] since it requires starting firefox, navigating to a certain page and performing a certain task :-P [22:56] in any case, the fact is that with bzr I didn't need to learn about something like bisect [22:57] i could do it using the revision numbers [22:57] makes more sense to humans :-P [22:57] nah [22:57] you can [22:57] but you can also just use it to go one step [22:57] check yourself [22:58] ok [22:58] then say 'problem still exists' vs 'problem is gone' [22:58] and it decides to go further back or forwards [22:58] ok [22:58] so you're convincing me to use git :-P [22:58] hehe [22:59] not at all [22:59] just kidding [22:59] I'm saying that there is a tool, that both systems have, that can help with the problem you had [22:59] i know, got it :-) [22:59] I think its great - its a design goal - that with bzr you didn't need the tool ;) [22:59] yeh [23:11] lduros: in git you can also use HEAD~10 to refer to the 10th revision before the tip of the current branch [23:12] dOxxx: maybe, but then HEAD~10 changes if the tip of the current branch changes [23:12] you can't turn off your computer, or even write the revision number on a piece of paper [23:12] :-) [23:12] was just saying I love revision numbers [23:13] because I like to use my brain [23:13] :-P [23:13] maybe people despise that because it's not really being a power user [23:13] but it's being a power user with your brain, ... sort of [23:25] heh [23:26] you don't need to use the whole git hash. you can usually just use the first 6-8 digits and it should be unique enough [23:26] yeh but even that many it makes no sense [23:26] but yeah it's not easy as -r500 -r490 etc [23:26] there's no succession [23:26] yeh [23:28] btw, as a solution to the tip changing problem, you can use a hash with the ~10 syntax as well, so like abc123~10 would be the 10th commit before the revision whose hash starts with abc123 [23:28] with bzr? [23:28] yeh [23:29] git [23:29] yeh, realized afterwards [23:29] i don't like it as much [23:29] :-P [23:29] heh [23:33] so is that bzr bisect: http://doc.bazaar.canonical.com/plugins/en/bisect-plugin.html [23:34] yes [23:34] cool [23:44] just wrote a little post :-P incorporated some of what you lifeless and dOxxx said. Hope that's ok with you. I bet many people will despise me for what i'm saying in there, anyway... http://lduros.net/posts/why-i-think-bazaar-better-git/ [23:46] "A simple bzr -r 610..611 allowed me" -> "A simple bzr diff -r 610..611 allowed me" ;) [23:47] but good post :) [23:47] explaining *why* you prefer one to the other may help somebody else decide which they should try first because the same thing would bug them