[01:49] <maxb> AHA
[01:49] <maxb> Got it
[01:50] <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
[06:36] <LarstiQ> maxb: do you need the actual tree in that location? If so, can't you start with it?
[06:43] <lifeless> maxb: thats actually deliberate
[06:44] <lifeless> maxb: keeps the core simple, lets folk do clever things if they need to.
[07:17] <mgz> morning all!
[07:20] <LarstiQ> hei mgz
[07:22] <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:25] <maxb> lifeless: Yes, "... isn't unreasonable ..." = me being happy with bzr core's behaviour
[07:28] <LarstiQ> maxb: and branch.basis_tree() is not sufficient?
[07:29] <lifeless> maxb: cool cool
[07:31] <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:34] <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:35] <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:36] <maxb> preserving the token isn't an option - too many layers of code in the way
[07:37] <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:38] <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:39] <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:40] <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:41] <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:43] <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:44] <lifeless> the issue AIUI is that you have the branch write locked.
[07:44] <lifeless> which is rather separate.
[07:45] <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:46] <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:47] <maxb> I am keeping my branch and opening a working tree - this results in the branch (and repository) being re-opened
[07:48] <mgz> right, just checked, the repo isn't shared either, that's bad.
[07:49] <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:50] <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:58] <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.
[08:00] <LarstiQ> jam: aye
[08:02] <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:05] <maxb> 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] <maxb> gah, thinko, called create_workingtree on the branch not the bzrdir
[08:11] <maxb> It is a bit inconsistent that we have a branch.bzrdir.create_workingtree(from_branch=branch) but no equivalent for open_workingtree
[08:24] <mgz> maxb: point me at the mp when you're ready
[08:26] <maxb> https://code.launchpad.net/~maxb/udd/lockcontention/+merge/104500
[08:46] <mgz> maxb: reviewed. I can deploy to jubany later, or you can do that.
[08:57] <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:58] <mgz> it's kinda just a thin wrapper with some preconfigured bits, maybe the functions that use it need more
[09:04] <maxb> Well, it's only used in two places, and those have little in common
[09:05] <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.
[10:15] <PaoloRotolo> Hi all!
[10:17] <jelmer> hi PaoloRotolo
[10:19] <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:25] <jelmer> PaoloRotolo: see bug 888615
[10:27] <PaoloRotolo> jelmer, thanks!
[13:53] <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:54] <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:55] <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
[14:01] <jml> jelmer: yuck.
[14:01] <jml> jelmer: how do I dig myself out of this?
[14:03] <jelmer> jml: you can create the branch again by running "bzr heads --dead-only" to find the relevant revision
[14:04] <jelmer> and then using "bzr pull -rrevid:REVID --overwrite ." to create the branch again
[14:05] <jml> jelmer: ok. I'll try that.
[14:06] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <jelmer> jml: no, unfortunately not
[14:13] <jelmer> jml: you can try "bzr switch --force"
[14:13] <jml> jelmer: ok.
[14:14] <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:15] <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:16] <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:20]  * jml goes temporarily Eeyore
[17:43] <lduros> i'd like to have a diff of all files between two commits
[17:43] <lduros> how can I do this? :-)
[17:44] <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:46] <jelmer> fullermd: that sounds like punctuation-abuse to me
[17:46] <lduros> ah
[17:47] <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:48] <lduros> ok
[17:48] <lduros> how can you tell what revision number you are on currently
[17:48] <lduros> sorry... just learning bzr
[17:49] <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:51] <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:54] <lduros> at least revision numbers are easier to remember than git sha1 hashes
[17:54] <lduros> :-P
[22:44] <lduros> I've been using bazaar for two weeks, and I really love it
[22:44] <lduros> thanks for making bazaar!
[22:45] <lduros> :-P
[22:45] <lduros> if anybody here is involved with it
[22:46] <lduros> going back in revisions is much simpler than git
[22:50] <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:51] <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:52] <lifeless> I believe many folk would use git bisect
[22:53] <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:54] <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:55] <lduros> since it requires starting firefox, navigating to a certain page and performing a certain task :-P
[22:56] <lduros> in any case, the fact is that with bzr I didn't need to learn about something like bisect
[22:57] <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:58] <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:59] <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
[23:11] <dOxxx> lduros: in git you can also use HEAD~10 to refer to the 10th revision before the tip of the current branch
[23:12] <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:13] <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:25] <dOxxx> heh
[23:26] <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:28] <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:29] <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:33] <lduros> so is that bzr bisect: http://doc.bazaar.canonical.com/plugins/en/bisect-plugin.html
[23:34] <lifeless> yes
[23:34] <lduros> cool
[23:44] <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:46] <dOxxx> "A simple bzr -r 610..611 allowed me" -> "A simple bzr diff -r 610..611 allowed me" ;)
[23:47] <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