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