| GaryvdM | mbt: I'm busy for a fix for that bug (https://code.launchpad.net/~garyvdm/bzr/bug492116-ls-file/+merge/45679) | 00:00 |
|---|---|---|
| mbt | Oh! | 00:01 |
| mbt | I'll mark my bug a dup | 00:01 |
| mbt | *dupe | 00:01 |
| vila | GaryvdM: hawk eyes you have :) | 00:02 |
| mbt | GaryvdM, thanks! | 00:02 |
| jml | spiv: has it landed yet? | 00:03 |
| vila | GaryvdM: the issue is that there is some weird interaction with hudson, so for the time being I keep them blacklisted | 00:03 |
| vila | GaryvdM: I know "some" people are still running them so I'm not worried about regression there :) | 00:03 |
| vila | GaryvdM: especially since they cover a developer feature :D | 00:03 |
| mbt | zyga, am breaking for dinner; will be back in a bit. if you need to get a hold of me my email and jabber info is on my LP profile | 00:03 |
| vila | GaryvdM: oh, and by the way, these tests are disabled for *all* platforms, not only windows | 00:04 |
| GaryvdM | vila: oh! | 00:04 |
| GaryvdM | vila: I also had problems with them in the past. So I'm also running with ""-x TestBreakin" | 00:05 |
| vila | GaryvdM: you shouldn't ! | 00:05 |
| vila | :-D | 00:05 |
| vila | I rely on *you* :) | 00:06 |
| GaryvdM | ok | 00:06 |
| * GaryvdM restarts tests. | 00:06 | |
| GaryvdM | vila: btw - this is on windows, with the standalone install. | 00:08 |
| GaryvdM | vila: I | 00:11 |
| GaryvdM | vila: It hangs on "blackbox.test_breakin.TestBreakin.test_breakin_harderbreakin_harder" | 00:11 |
| vila | GaryvdM: hmm :-/ | 00:12 |
| vila | GaryvdM: file a bug or is there one already for that ? | 00:12 |
| vila | GaryvdM: and ping jam :) | 00:12 |
| GaryvdM | vila: ok | 00:14 |
| GaryvdM | I'll do that tomorrow. Good night. | 00:14 |
| === GaryvdM is now known as GaryvdM_away | ||
| zyga | mbt: okay | 00:18 |
| zyga | mbt: I got first _very_ rough version that talks with remote daemon | 00:18 |
| zyga | mbt: I only route the info() request this way | 00:19 |
| zyga | but it works | 00:19 |
| mbt | zyga, I am back. | 01:22 |
| exarkun | What is the "submit branch" (in particular in comparison to the "parent" branch)? | 01:25 |
| zyga | mbt: great | 01:25 |
| zyga | mbt: I'll commit and push my stuf | 01:25 |
| zyga | mbt: it's not much | 01:25 |
| mbt | exarkun, It is the branch used for the "bzr send" command | 01:25 |
| exarkun | weuoook | 01:26 |
| mbt | exarkun, you can specify the parent branch as :parent | 01:26 |
| mbt | exarkun, e.g., bzr send :parent | 01:26 |
| zyga | mbt: pushed | 01:27 |
| zyga | mbt: check it out | 01:27 |
| zyga | mbt: it's nice, I'm working on more | 01:27 |
| exarkun | mbt: okay thanks | 01:28 |
| mbt | zyga, sure thing, one second | 01:28 |
| mbt | zyga, what's the link to the branch? | 01:28 |
| mbt | oh nvm, I can pull can't I. | 01:29 |
| zyga | lp:~zkrynicki/+junk/redmine-bzr | 01:29 |
| zyga | :-) | 01:29 |
| zyga | right | 01:29 |
| fullermd | I think submit is also used as a default for merge. | 01:29 |
| zyga | mbt: the adapter hardcodes the location of the rpc server | 01:31 |
| mbt | zyga, looking now, | 01:31 |
| zyga | mbt: eventually you will be able to talk to the server entirely so the url/root url will no longer be meaningful and the branch server can be all that you specify | 01:32 |
| zyga | mbt: with my branch you can also see all the merges | 01:32 |
| zyga | mbt: but there are some bugs so if you find something broken leave me a note | 01:32 |
| zyga | mbt: if you compare my adapter to yours you'll see I removed some if's | 01:32 |
| === dOxxx is now known as dOxxx_away | ||
| mbt | zyga, what's the change to config/environment.rb for? | 01:34 |
| zyga | uh | 01:34 |
| zyga | random junk, sorry | 01:34 |
| zyga | it's 2AM | 01:34 |
| mbt | lol okiedokey just making sure 'cuz I was all like "interrobang" | 01:35 |
| zyga | uncomited and pushed again | 01:35 |
| zyga | with --overwrite | 01:36 |
| mbt | Ah, I see how this works | 01:38 |
| zyga | it's just a start, but we can manage everything this way | 01:38 |
| zyga | the server has to be moved to initialize | 01:38 |
| zyga | but I'm already dying here, I'll hit the bed soon | 01:39 |
| mbt | What's going to manage the lifecycle for the bridge process? Or can Redmine be setup to start it up when it's persistent Rails process is started? | 01:39 |
| zyga | mbt: it's a separate topic, IMHO it can be done in several ways that will make it not a problem in practice | 01:39 |
| zyga | mbt: such as xml-rpc hosted inside apache | 01:39 |
| zyga | mbt: or just plain deployed as a separate service alongside | 01:39 |
| zyga | mbt: redmine does not need to care about this, all you give it is xmlrpc url | 01:40 |
| mbt | zyga, well, it should be able to, lest people have to do extra work when setting up for Bazaar repositories anyway | 01:40 |
| mbt | But yes, later | 01:41 |
| zyga | mbt: you don't have to setup lp.net to use lp.net url with redmine | 01:41 |
| zyga | it think it's out of scope | 01:41 |
| mbt | I'm just thinking in terms of expectations. All other SCMs work out of the box with no additional effort, so this should, too. | 01:41 |
| zyga | well that's true | 01:42 |
| zyga | mbt: we might setup something that will work like that | 01:42 |
| zyga | mbt: one thing I would look at is performance | 01:42 |
| zyga | mbt: if it's faster than everyone else | 01:42 |
| zyga | that's a plus :-) | 01:42 |
| mbt | zyga, True. It does look like, though, the way this XML-RPC thing works, it'd be entirely possible to choose a front-end (e.g., also support command line invocation) | 01:43 |
| mbt | right | 01:43 |
| mbt | ? | 01:43 |
| zyga | mbt: I only worry that setting up stuff like that is flaky | 01:43 |
| zyga | mbt: stuff like the helper dying | 01:44 |
| mbt | No more flakey than shelling out 10 times per page view to determine if the current revision is the latest one | 01:44 |
| zyga | etc | 01:44 |
| mbt | lol | 01:44 |
| zyga | it's part of the system services to oversee this | 01:44 |
| zyga | putting it inside redmine will only be more broken | 01:44 |
| zyga | right but this is about fixing things | 01:44 |
| zyga | personally | 01:44 |
| zyga | apache + xmlrpc server is probably most resiliant method | 01:44 |
| zyga | but we'll need to check how all those read locks behave | 01:45 |
| zyga | I'm really curious how lp.net does this | 01:45 |
| mbt | Hrm. | 01:45 |
| zyga | running loggerhead _AND_ allowing you to push all the time | 01:45 |
| mbt | I'm sure that "buy-in" will be better if it can be done as an either/or | 01:45 |
| zyga | unless they mirror the branch you push to scratch space to run loggerhead from | 01:45 |
| mbt | zyga, probably doesn't hold the locks any longer than necessary | 01:45 |
| mbt | or that. | 01:45 |
| zyga | mbt: I never saw it hold any locks and loggerhead can take a while to run | 01:46 |
| zyga | mbt: setting up redmine is ~10 minutes if you follow the docs | 01:46 |
| zyga | mbt: I'd add +2 minutes to setup the service for bzr | 01:46 |
| zyga | but in a way that will recover, not just running it like that from the comand line | 01:46 |
| zyga | that can be done after it works | 01:46 |
| mbt | Well, one could use dæmontools or Upstart | 01:46 |
| zyga | mbt: yeah there are lots of options | 01:47 |
| mbt | But not every server is going to have the ability to do that either | 01:47 |
| zyga | apache is the logical choice if you already run it | 01:47 |
| zyga | to run what? | 01:47 |
| zyga | why not? managed crippled hosting with rails? | 01:47 |
| mbt | A server where you can deploy rails apps, might not permit ssh access or the ability to run any (other) persistent processes | 01:47 |
| zyga | mbt: perhaps, but personally I dont find this that important, if you already host your code somewhere else you might as well host it using public services, setting up a django app on google app engine that will do this is trivial and will not require anything fancy | 01:49 |
| zyga | (perhaps apart making sure that the app can actually talk to the repository) | 01:49 |
| zyga | mbt: so for the moment, let's fix the adapter, figure out how to make people deoploy it later | 01:49 |
| mbt | Indeed. | 01:49 |
| mbt | :) | 01:49 |
| zyga | mbt: another thing, it can run on _separate_ sever | 01:50 |
| mbt | Well, go ahead and head to bed, and I'll work on this for a while, maybe see if I can get feature-parity tonight | 01:50 |
| mbt | zyga, Indeed | 01:50 |
| zyga | mbt: usually you do have bzr+ssh to get the code in the first place | 01:50 |
| zyga | mbt: thanks, I'll talk to you tomorrow | 01:50 |
| zyga | mbt: btw, I'm +1GMT, you? | 01:50 |
| mbt | zyga, sure thing. Thanks! | 01:50 |
| mbt | zyga, -0500 | 01:50 |
| zyga | okay, see you tomorrow | 01:51 |
| mbt | So noon there is several hours before I wake up here :) | 01:51 |
| mbt | zyga, yep, night | 01:51 |
| === frakturfreak1 is now known as frakturfreak | ||
| === dOxxx1 is now known as dOxxx | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === zyga is now known as zyga-efika | ||
| sender | I am on revision 10. I bzr rm'd a file on revision 4. How do I get that file back? | 10:45 |
| sender | Thanks :) | 10:45 |
| bob2 | bzr cat -r3 xxx > xxxx | 10:45 |
| sender | bob2: thanks, will try now | 10:45 |
| sender | bob2: great, never knew about bzr cat. brilliant. | 10:47 |
| mgz | you'll not get any blame like that, no? | 10:47 |
| bob2 | note: bzr will have no idea what you did | 10:47 |
| bob2 | mgz: right | 10:47 |
| sender | true | 10:47 |
| soren | You can revert the file back to r3. | 10:47 |
| mgz | `bzr merge -r4..3 xxx` any better? | 10:47 |
| soren | That way, bzr will know it's the same file. | 10:47 |
| bob2 | mgz: oh, didn't think of that | 10:48 |
| sender | i've tried that too, bzr revert -r3 robots.txt - didnt do anything | 10:48 |
| mgz | I'm not certain it's any better, but might be. | 10:48 |
| soren | Works for me. | 10:49 |
| soren | Just tested it. | 10:49 |
| awilkins | jelmer, Do you know the evolution codebase well, or do you just keep a PPA of it? | 10:49 |
| === oubiwann is now known as oubiwann_ | ||
| === oubiwann_ is now known as oubiwann | ||
| mgedmin | bzr branch lp:ubuntu/$suite/$package rules! | 13:21 |
| === oubiwann is now known as oubiwann_ | ||
| Odd_Bloke | I want the contents a particular revision of a bzr branch (I'm packaging, I don't care about history whatsoever). Currently I'm doing 'bzr co -r ... <branch>'. This is slow. Is there a better way? | 13:57 |
| Odd_Bloke | In fact, can I use 'bzr export' on the remote branch? | 13:57 |
| Lo-lan-do | You probably can, yes. | 14:03 |
| Odd_Bloke | Hmm, that causes problems. | 14:06 |
| Odd_Bloke | In that previously I had a local copy that I could use for looking up revnos (for example). | 14:06 |
| Odd_Bloke | Whereas now I'm using the remote one, which could change between my export and my revno lookup. | 14:06 |
| Odd_Bloke | Is there any way I can get a lightweight checkout of a particular revision? | 14:07 |
| Lo-lan-do | You could use a revid, which isn't going to change. | 14:09 |
| awilkins | Odd_Bloke, What about export | 14:09 |
| awilkins | bzr export -r URL | 14:09 |
| awilkins | oops | 14:09 |
| awilkins | bzr export -r revid URL | 14:09 |
| awilkins | No checkout, no baggage, just the files | 14:10 |
| awilkins | Oops, didn't read all the scrollback | 14:10 |
| Odd_Bloke | awilkins: :) | 14:10 |
| Odd_Bloke | Added complication: I'm exporting by tag but need to look up the revision. | 14:11 |
| Odd_Bloke | Ah, and 'bzr revno' won't let me specify a revision. | 14:13 |
| awilkins | Odd_Bloke, You can use revno or revision-info with the --tree argument on a lightweight checkout to get the revision of the current tree | 14:13 |
| awilkins | (knew it was supported because qlog does it) | 14:14 |
| Odd_Bloke | awilkins: But I don't think I can create a lightweight checkout of anything but the head of a branch. | 14:14 |
| awilkins | Odd_Bloke, So you can do a checkout --lightweight -r tag:WIBBLE | 14:15 |
| awilkins | Odd_Bloke, Just performed a lw checkout of a 2 revision branch at r1 | 14:15 |
| awilkins | bzr revno --tree # returns 1 as expected | 14:15 |
| Odd_Bloke | awilkins: Victory! Thanks. :) | 14:18 |
| === gthorslund_ is now known as gthorslund | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === oubiwann_ is now known as oubiwann | ||
| maxb | Yikes. This morning, I thought, "I'll just see if bug 705279 is reproducible" | 15:57 |
| ubot5 | Launchpad bug 705279 in bzr (Ubuntu) "bzr crashed, when pulling from a bzr mirror of an svn repo, with BzrCheckError in _commit_write_group()" [Undecided,New] https://launchpad.net/bugs/705279 | 15:57 |
| maxb | It's been running for hours, is half way through, and has transferred 3.3GB | 15:58 |
| === beuno is now known as beuno-lunch | ||
| awilkins | maxb, Is the vcs import of the chromium sources an old-style or new style one, I wonder | 16:19 |
| awilkins | maxb, The newer ones use bzr-svn, the older ones use some other thing that isn't interoperable with it | 16:19 |
| maxb | It's the new kind | 16:20 |
| maxb | cscvs is hellspawn | 16:20 |
| awilkins | I suppose I might have guessed that 'coz Jelmer created it... | 16:21 |
| === beuno-lunch is now known as beuno | ||
| jelmer | awilkins: hi | 17:47 |
| jelmer | awilkins: I know the evolution-mapi source code a bit, not familiar with the core | 17:47 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| SpamapS | if I do 'bzr commit -x debian' .. the debian dir should be totally ignored right? | 17:49 |
| james_w` | SpamapS, yes | 17:50 |
| SpamapS | hrm.. not happening. :( | 17:50 |
| SpamapS | actually... | 17:50 |
| james_w` | SpamapS, you are seeing it in the diff if you "bzr diff -c -1" after the commit? | 17:50 |
| SpamapS | it shows in the modified list if I specify no message.. | 17:50 |
| SpamapS | but it is not actually committed | 17:50 |
| james_w` | yeah | 17:50 |
| SpamapS | DOH | 17:50 |
| * SpamapS looks for the surely already open bug report to +1 | 17:51 | |
| awilkins | jelmer, Ah, it's more the evolution-exchange stuff I was interested in ; our Exchange server is trapped behind one of these cookie redirectors so I was wondering how hard it would be to implement the same sort of solution described here ; http://blogs.interknowlogy.com/timmccarthy/archive/2006/08/05/3659.aspx | 17:51 |
| james_w` | bug 552805 | 17:51 |
| ubot5 | Launchpad bug 552805 in Bazaar "Commit message template does not exclude files" [Medium,Confirmed] https://launchpad.net/bugs/552805 | 17:51 |
| SpamapS | james_w`: I'm not sure what to make of the fact that you know the bug # by heart ;) | 17:51 |
| james_w` | SpamapS, only google knows that | 17:52 |
| glyph | possibly this should not be an internal error: http://buildbot.twistedmatrix.com/builders/debian64-py2.4-select/builds/894/steps/bzr/logs/stdio | 18:20 |
| spiv | glyph: I agree. jelmer? | 18:22 |
| spiv | glyph: jelmer says that may already be fixed in current bzr-svn | 18:23 |
| spiv | glyph: inspection of the code suggests yes | 18:23 |
| spiv | glyph: interactive testing however suggests no! | 18:25 |
| spiv | glyph: investigations continue | 18:25 |
| spiv | (Apparently this is not ERR_UNKNOWN_HOSTNAME?) | 18:26 |
| glyph | spiv: I don't know man, I don't even work here | 18:39 |
| mbt | Dumb question, I can't find this in the docs it seems: given a branch and a file_id, how do I get the last revision that modified the file_id? | 18:43 |
| GaryvdM | jelmer: please can I ask you do advise me on bug 704840 | 19:04 |
| ubot5 | Launchpad bug 704840 in QBzr "qlog crashes on svn working copy" [High,Confirmed] https://launchpad.net/bugs/704840 | 19:04 |
| GaryvdM | I posted a question in the bug. | 19:04 |
| vila | GaryvdM: thanks for the installers ! | 19:08 |
| GaryvdM | vila: It's a pleasure :-) | 19:09 |
| GaryvdM | vila: I got the test suit to finish for the first time (with the standalone installer.) I had to exclude a bunch of https that were causing the test suit to fail. | 19:12 |
| GaryvdM | s/fail/hang/ | 19:12 |
| vila | GaryvdM: fail | 19:12 |
| vila | GaryvdM: grr, file a bug with as much relevant -s xxx you can think of and I'll try to give you more instrucitions | 19:13 |
| vila | to better localize the problem | 19:13 |
| GaryvdM | Ok will do. I'm going to slowly work at. | 19:14 |
| === Ursinha is now known as Ursinha-afk | ||
| vila | GaryvdM: by the way, 2.2.3 in the pipe... :) | 19:43 |
| GaryvdM | vila: Ok | 19:44 |
| jelmer | GaryvdM: hmm | 19:45 |
| jelmer | GaryvdM: I think we should fix the bzr-svn config | 19:45 |
| jelmer | GaryvdM: but I'm also a bit surprised by the actual implementation in bzr.dev | 19:46 |
| GaryvdM | jelmer: ok | 19:46 |
| GaryvdM | I battling to grok the "increasing the python requirement " thread in ml. Where any decisions made? | 19:49 |
| jelmer | I'm not sure, I had the same problem :-) | 19:50 |
| spiv | GaryvdM: "stick with 2.4 for now" is the short answer | 19:50 |
| GaryvdM | spiv: Thanks | 19:51 |
| spiv | GaryvdM: with some interest in playing with 2to3 etc sometime soon to see how hard it would be to run on 3.x | 19:51 |
| mythril | how do I eliminate a specific revision? | 19:55 |
| * mbt 's ears perk up | 19:58 | |
| mbt | Python 3.x? Yes? Yes? :) | 19:59 |
| spiv | mbt: I wouldn't hold your breath... | 20:00 |
| mbt | lol, yeah, that seems to be the general consensus in most major python systems | 20:01 |
| mbt | spiv, You wouldn't know how to answer my ? from earlier, would ya? I'm still stuck; I seem to be barking up all the wrong trees | 20:03 |
| mbt | ha, ha, that was an awful pun | 20:04 |
| GaryvdM | mythril: if there are no revisions after the revision you want to eliminate, then you can do a bzr uncommit | 20:05 |
| === Ursinha-afk is now known as Ursinha | ||
| mbt | mythril, Do you need to eliminate it from the history, or would reverting it be sufficient? | 20:06 |
| GaryvdM | mythril: if there are revisions after, you could do a reverse cherry pick to revert the changes made by that revision, but the revision would still be in the history.. | 20:06 |
| mbt | Should be possible also, in theory, to make a new branch, then on the old one, uncommit repeatedly to back way up, and then merge from the new branch as a cherry pick. Then only the dead revision has to be pruned, right? | 20:08 |
| jam | mbt: this is also something that bzr-rewrite was developed to help with | 20:16 |
| jam | I don't know the specific invocations, though | 20:16 |
| jam | (something like "bzr rebase") | 20:16 |
| jam | but there have been complaints that rebase doesn't work very well with a single branch, etc. | 20:16 |
| GaryvdM | mbt: re you question about getting the revision that last modified a file | 20:24 |
| GaryvdM | If you get the inventory item for the file, you can call item.revision to get the revid. | 20:24 |
| GaryvdM | You will then need to get a revno for the revid. | 20:25 |
| mbt | I _think_ I found a way, using iter_entries_by_dir from RevisionTree | 20:27 |
| GaryvdM | I'm not sure how you are iterating the files, and hence what is the easiest for you to get the inventory item | 20:27 |
| GaryvdM | That will do. | 20:27 |
| GaryvdM | mbt: shout if you need help to go from a revid to a revno | 20:28 |
| mbt | GaryvdM, That I think I have; but whether or not the way I am doing things is going to be efficient is yet to be determined. | 20:29 |
| GaryvdM | mbt: is this for a web server? | 20:29 |
| mbt | Yeah, I'm workign on getting Redmine (a Ruby on Rails application) to try to support shared bzr repositories. | 20:30 |
| mbt | But the way that the bzr command line tool works, and the way that Redmine works, well, they don't have the same conceptual model of things. | 20:31 |
| mbt | Unless I am missing something in bzr or bzrlib, without a branch context a lot of operations are impossible. But Redmine does not give you the branch context if you tell it that the revision system supports branches; instead it treats branches as a reference to a revision number (as if it were a tag in reality), and path information won't include the branch in that instance. | 20:32 |
| mbt | So instead, I'm trying to use the approach that it uses for subversion, which is to pass the repository as the URL; the URL may or may not be a branch, and if it is not a standalone branch, then the branch will have to be found from the relative path information | 20:33 |
| mbt | That seems to be working, but then I am left with breaking apart the branch information to find the relative path for the directory being browsed | 20:33 |
| mbt | And the odd thing is that since that comes from the RevisionTree, which comes from the repository, I can get a whole tree, but then I have to get into the branch context again to map the revision IDs to branch-local revision numbers. | 20:34 |
| mbt | What I am trying to figure out now is the most direct way of finding a path in the revision tree | 20:34 |
| GaryvdM | mbt: Ah - the api is like that, because the calculation of revision numbers is dependent on knowing branch tip | 20:36 |
| mbt | I get the why, but I don't understand why Redmine doesn't pass (branch, rel_path) to the VCS | 20:36 |
| mbt | That would make live a lot easier, and would make the bridge between bzr and Redmine a lot less ugy | 20:37 |
| mbt | *ugly | 20:37 |
| GaryvdM | I see | 20:37 |
| GaryvdM | if you can guess the branch tip, and are willing to go down a api level, you could calculate the revnumbers with out a branch ref | 20:37 |
| mbt | Only other thing is: can I get a path without kicking off the generator? Something like revisiontree.get_file_inventory(file_id) some how or another? | 20:37 |
| mbt | Oh? | 20:38 |
| mbt | (Or for that matter, just get the inventory for the root directory of a working tree, since the inventory apparently has references to all of its children) | 20:39 |
| GaryvdM | Yes | 20:39 |
| mbt | I see get_root_id in revisiontree, but I don't see a way to get its inventory without a generator somewhere. For that matter, I'm not even sure that I'm hunting in the right place in the API | 20:42 |
| GaryvdM | revision_tree.inventory[file_id] | 20:43 |
| mbt | Oh? | 20:46 |
| mbt | Oh, well, sheesh. | 20:47 |
| mbt | Why didn't I see that like three hours ago lol | 20:48 |
| GaryvdM | I'm not sure if that is abusing the api a bit. Maybe one of the core devs can comment on that. | 20:48 |
| mbt | I don't know but it eliminates a function or two from my own code | 20:48 |
| mbt | so that isn't bad | 20:48 |
| zyga-efika | mbt: hi | 20:57 |
| zyga-efika | mbt: I'm still busy today but I looked at your changes | 20:57 |
| zyga-efika | mbt: I'll try to rewrite the single-branch model first | 20:57 |
| zyga-efika | mbt: and see how that works | 20:57 |
| zyga-efika | mbt: but it seems this will work | 20:57 |
| mbt | zyga-efika, I am looking at single branch ATM but I think it will transparently work for both. | 20:58 |
| mbt | I can commit my WIP in a sec | 20:59 |
| mbt | I have a very unhappy Entries list lol | 20:59 |
| zyga-efika | unhappy? | 20:59 |
| mbt | It loads without crashing, but with empty fields | 20:59 |
| mbt | it's what I'm working on right this sec | 21:00 |
| mbt | it's up | 21:00 |
| mbt | I think it's unhappy because I have not yet taught it fetch_changesets | 21:01 |
| mbt | which is I think what I need to do next | 21:01 |
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | 2.2.3 is frozen, time to build the installers ! (rm vila) | ||
| zyga-efika | mbt: I'm still occupied with my daily job, I need to finish some of the stuff in my backlog | 21:13 |
| mbt | zyga-efika, no biggie | 21:13 |
| mbt | am going to bind my branch so i don't forget to push | 21:14 |
| zyga-efika | mbt: thanks | 21:15 |
| mbt | zyga-efika, np... thank you | 21:16 |
| GaryvdM | abentley: I can't see 1.1 in lp:bzr-pipeline. Maybe you forgot to push? | 21:28 |
| poolie | thanks for the windows builds gary | 21:29 |
| GaryvdM | Hi poolie. np :-) | 21:30 |
| GaryvdM | poolie: it feels good to be able to get back in to the swing of things :-) | 21:31 |
| poolie | it's great to have you back | 21:31 |
| abentley | GaryvdM, the 1.1 release is on the stable branch, not the trunk. | 21:32 |
| GaryvdM | abentley: oh - ok | 21:33 |
| lifeless | mkanat: hi | 22:04 |
| mkanat | Hey lifeless. | 22:04 |
| lifeless | I was talking to poolie | 22:05 |
| lifeless | about loggerhead & branches and launchpad | 22:05 |
| lifeless | uhm | 22:05 |
| lifeless | so you know that we've reorged the Launchpad team, right ? | 22:05 |
| mkanat | lifeless: Don't know anything about it, no. | 22:05 |
| lifeless | ah | 22:05 |
| lifeless | so http://blog.launchpad.net/general/changing-how-we-track-launchpads-bugs-questions-and-blueprints references a mail from me | 22:06 |
| mkanat | lifeless: Okay. But that wouldn't apply to loggerhead, since it's a separate product that's used elsewhere in addition to being used by LP. | 22:06 |
| mkanat | (Much like bzr itself wouldn't become part of launchpad.) | 22:07 |
| lifeless | thats true | 22:07 |
| lifeless | what is concretely means is that we're less siloed | 22:07 |
| lifeless | so we are more likely to fix things that are important rather than things that are important in one area | 22:08 |
| mkanat | lifeless: Although I'd think that it will also mean that your design will become more haphazard in the individual pieces, if the same people aren't always working on them. But that's more of a side note. | 22:08 |
| mkanat | Perhaps though the overall design will become more cohesive. Hard to say. | 22:08 |
| lifeless | one way to find out :) | 22:09 |
| lifeless | also its kindof my job, and jml's job to keep the technical and user stories cohesive | 22:09 |
| mkanat | lifeless: Sure, I just would be concerned that this will shift *all* design work onto you. | 22:09 |
| mkanat | Instead of allowing you to have sub-designers for the individual pieces. | 22:10 |
| lifeless | mkanat: nah, I chase after rather than being a bottleneck | 22:10 |
| lifeless | I like being able to sleep | 22:10 |
| mkanat | lifeless: Haha. :-) | 22:10 |
| lifeless | anyhow | 22:10 |
| lifeless | so - I'm worried that with the separate trunk + for-lp branch that we'll end up diverging, if trunk stays unsuitable for lp for extended periods | 22:11 |
| mkanat | lifeless: Oh, that is a temporary situation. | 22:11 |
| lifeless | and AIUI you may be spending less (no?) time on loggerhead | 22:11 |
| lifeless | what are your medium term plans vis-a-vis loggerhead? | 22:12 |
| mkanat | lifeless: Whether or not I'll still be working on loggerhead depends on administrative details at Canonical, so it's hard to say. | 22:12 |
| mkanat | lifeless: The only thing I'll be able to complete in the time that Canonical has currently allotted is bug 567729. | 22:12 |
| ubot5 | Launchpad bug 567729 in loggerhead "loggerhead could mark all pages cacheable" [Medium,Confirmed] https://launchpad.net/bugs/567729 | 22:12 |
| lifeless | mkanat: will this leave trunk unsuitable for lp ? | 22:13 |
| lifeless | or is it currently suitable? | 22:13 |
| mkanat | lifeless: It will leave trunk unsuitable. I had a plan to make trunk suitable for LP, but it was not approved. | 22:13 |
| mkanat | lifeless: The disapproval was not technical, it had to do with contracting. | 22:14 |
| lifeless | ok, I'll talk with poolie and flacoste about that | 22:14 |
| GaryvdM | Hi jam. | 22:14 |
| lifeless | how much work has landed since the point it became unsuitable? | 22:14 |
| mkanat | lifeless: Well, I can't be sure that history_db itself is unsuitable. | 22:15 |
| mkanat | lifeless: But /raw/ is definitely not suitable. | 22:15 |
| mkanat | lifeless: Although we could just hack out /raw/ easily, for LP. | 22:15 |
| mkanat | s/unsuitable/suitable/ | 22:15 |
| GaryvdM | jam: I'm running into a bzr bug when building the win installer. The bzr on the ec2 instance is quite old. | 22:15 |
| lifeless | poolie: btw, that all pages cachable thing isn't useful for lp | 22:15 |
| poolie | oh, because? | 22:16 |
| lifeless | poolie: we can just tell squid to do that in ~2 minutes | 22:16 |
| poolie | ah, true | 22:16 |
| GaryvdM | jam: Admin is needed to install a new version. Please could you do that for me. | 22:16 |
| mkanat | lifeless: BTW, the CSS for loggerhead on LP seems to be wrong. | 22:16 |
| mkanat | lifeless: This page, for example, does not have the right CSS: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/annotate/head:/.bzrignore | 22:17 |
| lifeless | the raw controller has a knob overriding it though? | 22:17 |
| mkanat | lifeless: It doesn't, but it would just involve commenting out a few lines. | 22:18 |
| lifeless | ok | 22:18 |
| mkanat | lifeless: The only think LP needs for it to work properly is the token thing, because of the private branches. | 22:18 |
| mkanat | lifeless: I'd be totally thrilled to do the work to make trunk stable and on LP though. | 22:19 |
| lifeless | :) | 22:20 |
| poolie | jam, GaryvdM, i'd like to sometime migrate the windows vm to use an ebs-based root partition | 22:20 |
| poolie | then it'll be easier to save the state | 22:20 |
| poolie | lifeless, will you comment on that squid bug or shall i? | 22:21 |
| lifeless | I will | 22:23 |
| GaryvdM | poolie: I'm only using the ec2 instance for 2.2 builds. For 2.3, I'm hoping I'll be able to get a 64 bit build done, so I'm using a local 64bit vm. | 22:23 |
| poolie | ah, ok | 22:24 |
| GaryvdM | poolie: having my own local vm allows me freedom to changes things, but I guess it's not good if I need to hand over to someone else. | 22:27 |
| mkanat | lifeless, jam: Is there some plan for how storing and updating history_db would work for LP? | 22:28 |
| jam | mkanat: hand-wavingly every project would get its own sqlite db file | 22:29 |
| jam | which gets updated on demand | 22:29 |
| jam | and we would pre-seed projects like emacs | 22:29 |
| mkanat | jam: Okay. Does history_db do incremental updates now? | 22:29 |
| jam | always has | 22:29 |
| mkanat | jam: Okay, cool. I thought so, just wanted to check. | 22:30 |
| jam | just that the *first* update is faster if you do it manually | 22:30 |
| * mkanat nods. | 22:30 | |
| jam | plus, it means that someone hitting the website isn't the one waiting for it to complete | 22:30 |
| mkanat | Yeah, for sure. | 22:30 |
| mkanat | In an ideal world we'd update it asynchronously every time somebody changed the tip. | 22:31 |
| jam | mkanat: it actually wouldn't be a lot of overhead from that, at least my timings showed it to be quite feasible to run it as a post-commit hook in bzr | 22:31 |
| mkanat | jam: That'd be great if we could do that. Would require instrumentation and changes on codehosting, of course. | 22:31 |
| jam | at least once it has the first 100k revisions completed :) | 22:32 |
| mkanat | Right. :-) | 22:32 |
| jam | mkanat: yeah, some sort of job-task that triggers when a branch is updated | 22:32 |
| * mkanat nods. | 22:32 | |
| jam | we already have the branch scanner which does similar work | 22:32 |
| jam | and we've been talking a bit about changing some of the postgres tables to use the history-db-like layout | 22:33 |
| jam | since BranchRevision currently is something like 0.5Billion rows | 22:33 |
| mkanat | Wow. | 22:33 |
| jam | anyway, when we poke at that, loggerhead could just use the production tables (possibly via an intermediate db, rather than the actual live one, etc) | 22:34 |
| jam | abentley: didn't you write up a LEP on this? | 22:34 |
| mkanat | Right. That'd be even simpler if we had history_db use an ORM. | 22:35 |
| abentley | jam, not quite a LEP, but: https://dev.launchpad.net/Code/BranchRevisions | 22:36 |
| jam | abentley: thanks. I wanted to point mkanat at the idea that we were looking at that sort of thing. | 22:36 |
| jam | mkanat: well, it is pretty generic sql, using python dbapi2 | 22:36 |
| jam | so you could do it to pretty much any SQL backend | 22:36 |
| mkanat | jam: True. | 22:36 |
| jam | some of the create syntax is sqlite specific | 22:37 |
| mkanat | abentley: I wonder about the "use loggerhead" proposal, there. It's possible we could make it fast enough. | 22:37 |
| jam | (PRIMARY KEY AUTOINCREMENT vs using SERIAL in postgres) | 22:37 |
| abentley | mkanat, it's not a complete solution. | 22:38 |
| mkanat | abentley: Okay. Because you need to JOIN that table against other things in SQL? | 22:38 |
| mkanat | jam: Yeah, this would seem like a good reason to abstract history-db out into a plugin, again, reading this BranchRevisions proposal. | 22:40 |
| GaryvdM | jam: Thanks - the upgrade fixed the bug. | 22:40 |
| jam | mkanat: it is a plugin | 22:40 |
| abentley | mkanat, it would not address "Finding the most relevant branch for any given revision" "Allocating revision karma" or "Merge detection in the scanner " | 22:40 |
| jam | we pulled it into loggerhead to avoid having a weird plugin dependency | 22:40 |
| mkanat | jam: Ahhh. | 22:41 |
| jam | for people that want an easy way to set up loggerhead | 22:41 |
| jam | the history is synced up, though, so loggerhead can merge updates from the plugin, and you can cherrypick loggerhead changes back to the plugin | 22:43 |
| mkanat | jam: Oh, okay. Are there changes that I should pull in, now? | 22:43 |
| jam | mkanat: nothing I know of | 22:45 |
| mkanat | jam: Okay. | 22:45 |
| lifeless | mkanat: ok, I has spoken with poolie and flacoste | 22:48 |
| lifeless | mkanat: what we propose to do is: | 22:48 |
| Erimos_Wolf | Hi at all, i have a question considering the behavior of the bazaar plugin for eclipse. Iam not sure if this is the right channel | 22:48 |
| lifeless | - push the history-db & raw stuff to a experimental/future branch and push stable to trunk | 22:48 |
| lifeless | - have the launchpad team adopt the loggerhead project, so we'll do bug triage & code review | 22:49 |
| GaryvdM | Erimos_Wolf: ask away | 22:49 |
| lifeless | mkanat: does that sound sensible to you? | 22:49 |
| mkanat | lifeless: Ah, that doesn't quite make sense. | 22:50 |
| mkanat | lifeless: history_db is already on trunk. | 22:50 |
| mkanat | lifeless: As is raw. | 22:50 |
| mkanat | lifeless: stable is well behind trunk. | 22:50 |
| mkanat | lifeless: Pushing stable to trunk wouldn't make any sense. | 22:51 |
| Erimos_Wolf | I followed the instructions and installed bazaar on my local machine. In eclipse i have under Project->Team all bazaar instructions. But when i try to commit it says every time "nothing to commit". A look at the bazaar explorer says different. There i can commit. Is this normal? | 22:51 |
| mkanat | lifeless: trunk is the experimental and future branch. | 22:52 |
| mkanat | lifeless: The launchpad branch of loggerhead has many important things from trunk that aren't on stable. | 22:52 |
| lifeless | mkanat: yes, thats my understanding; we want to get trunk stabilised and this seems the most robust way to do it | 22:52 |
| jam | mkanat: he wants to turn that around | 22:52 |
| jam | make trunk stable | 22:52 |
| jam | and start and experimental branch | 22:52 |
| jam | by "resetting" trunk | 22:52 |
| mkanat | lifeless: Right, I want to make trunk stable as well. | 22:52 |
| mkanat | jam: I'm not sure that makes sense at this point. | 22:53 |
| mkanat | Why not just do the work to stabilize what's on trunk now? | 22:53 |
| mkanat | It would be a few weeks of work at the most, I think. | 22:53 |
| mkanat | lifeless: Also, I'm not sure that having only the launchpad team work on loggerhead will be the best for the non-launchpad users of loggerhead. | 22:54 |
| GaryvdM | Erimos_Wolf: I guess that's not normal. verterok? | 22:55 |
| mkanat | lifeless, jam: Also, it's not possible to extract the unstable parts of trunk, for the most part--they involved a lot of refactoring and then what comes after is built on that refactoring. | 22:55 |
| mkanat | It would probably be almost as much work to "reset" trunk as it would to actually make trunk stable. | 22:56 |
| lifeless | sorry, local interrupt | 22:58 |
| Erimos_Wolf | is there a log file to digg through? | 22:58 |
| lifeless | mkanat: so the bzr team is focusing on udd | 22:58 |
| GaryvdM | Erimos_Wolf: ~/.bzr.log | 22:58 |
| GaryvdM | My Document\.bzr.log on windows | 22:59 |
| lifeless | mkanat: which means that AFAIK there isn't anyone really worrying about loggerhead atm except you | 23:02 |
| mkanat | lifeless: Yeah, although that's been true for about a year now. | 23:03 |
| lifeless | right | 23:03 |
| lifeless | launchpad has a vested interest in loggerhead being a solid component, and we're decent folk - we like reusable modules and components | 23:03 |
| mkanat | lifeless: Yeah, I agree. I just want to be sure that the user experience or configuration experience doesn't degrade for people who aren't LP. | 23:04 |
| lifeless | I am pretty sure it won't | 23:04 |
| jam | mkanat: I think Peng is a good test subject | 23:04 |
| jam | :) | 23:04 |
| mkanat | jam: Okay. :-) | 23:04 |
| lifeless | I doubt it will improve without someone interesting it making that *better* stepping up | 23:04 |
| Erimos_Wolf | I think the plugin doesnt call bazaar in any way. It just reacts with this message. The log shows only the last actions take from the explorer. | 23:04 |
| lifeless | Peng: yo, around? | 23:04 |
| lifeless | mkanat: now, for the question of code stabilisation | 23:04 |
| lifeless | mkanat: you're saying there are three branches? | 23:04 |
| lifeless | trunk, stable and lp ? | 23:04 |
| mkanat | lifeless: More or less, yeah. | 23:05 |
| lifeless | ok | 23:05 |
| lifeless | so, I think that I'm proposing | 23:05 |
| lifeless | future, trunk and lp | 23:05 |
| mkanat | lifeless: That was something we were forced to do because of my limited time. | 23:05 |
| mkanat | lifeless: Honestly, I think that's just a non-standard terminology change. | 23:05 |
| mkanat | lifeless: "trunk" should mean "future". | 23:05 |
| mkanat | lifeless: I don't see the advantage we'd get from renaming it. | 23:05 |
| mkanat | lifeless: The solution I'd prefer to see is that trunk become stable, then branches for 1.19, and then 1.19 and trunk are both maintained. | 23:06 |
| mkanat | lifeless: And from that point forward, trunk releases frequently in new stable releases. | 23:06 |
| lifeless | so, because of limited resources | 23:06 |
| lifeless | I'd rather not maintain multiple branches | 23:07 |
| mkanat | lifeless: There are just as many branches as in your solution. In fact, there is one less. | 23:07 |
| lifeless | in particular, having patches build on history db when its not production ready (whatever that means) is a bit counter productive - we'll end up being essentially forked, which is undesirable | 23:07 |
| lifeless | mkanat: going forward, after future is integrated, it could be deleted. | 23:08 |
| lifeless | mkanat: in my proposal | 23:08 |
| mkanat | lifeless: Oh, that's what I'm talking about doing in any case. | 23:08 |
| lifeless | I don't have an answer for how future would get integrated | 23:08 |
| lifeless | so we'd just have trunk and lp | 23:08 |
| lifeless | with trunk always stable | 23:08 |
| mkanat | lifeless: Well.... | 23:08 |
| mkanat | lifeless: I think it would be better to have trunk and stable, and lp just runs stable. | 23:08 |
| mkanat | Or trunk and "current stable branch". | 23:09 |
| lifeless | what advantage does an unstable trunk offer? | 23:09 |
| mkanat | lifeless: This is stuff I've already planned out in detail with poolie, quite a bit. | 23:09 |
| mkanat | lifeless: The advantage is in a stable branch, not in the trunk. | 23:09 |
| mkanat | lifeless: And I'm sure you already know the advantages of a stable branch, and me explaining them to you would be redundant. | 23:10 |
| Erimos_Wolf | no ideas? | 23:10 |
| mkanat | Erimos_Wolf: You might want to ask whoever maintains the Eclipse Bzr integration. | 23:11 |
| mkanat | Erimos_Wolf: bzr does keep a ~/.bzr.log | 23:11 |
| Erimos_Wolf | ok, thank you | 23:11 |
| GaryvdM | Erimos_Wolf: bzr-eclipse is maintained by verterok. | 23:12 |
| GaryvdM | Erimos_Wolf: bzr-eclipse is probably looking in the wrong directory. | 23:13 |
| GaryvdM | That might show up in the log if you look at the paths | 23:14 |
| Erimos_Wolf | the directory for the bzr exe is setup | 23:14 |
| Erimos_Wolf | I "shared" the project like the tutorial says. | 23:15 |
| GaryvdM | Erimos_Wolf: maybe you have to add files before you can commit them in bzr-eclipse? | 23:16 |
| Erimos_Wolf | There was already a "hello world" code | 23:16 |
| Erimos_Wolf | if i do any changes, the plugin doesnt recognize them. Although the "history" is written correctly | 23:18 |
| mkanat | lifeless: FWIW, stabilization of trunk would probably just involve some refactoring, writing some tests, and doing some tests to show that everything will work at LP scale. | 23:18 |
| mkanat | lifeless: "writing some tests" is the longest part of that, probably. | 23:18 |
| Erimos_Wolf | looks like verterok is not availible, idle for almost 3 hours | 23:20 |
| GaryvdM | vila: 2.2.3 windows installers are done. | 23:36 |
| vila | GaryvdM: hmpf ! This time you beat the osx packagers :D | 23:37 |
| vila | GaryvdM: nice work ! | 23:37 |
| GaryvdM | :) | 23:37 |
| dOxxx | there was a 2.2.3 release? doh | 23:37 |
| vila | dOxxx: :D | 23:37 |
| dOxxx | bah, you cheated. you posted while I was at work. :P | 23:37 |
| vila | dOxxx: by the way, I'll be on the move tomorrow so I may not be able to build the 10.5 one before.... some days :) | 23:38 |
| dOxxx | vila: just fixing up the release notes and what's new for my mergetools mp | 23:38 |
| vila | dOxxx: ok | 23:38 |
| dOxxx | vila: hmm ok | 23:38 |
| dOxxx | vila: I think the 10.5 audience is smaller so it's probably not such a bad thing if it's delayed a few days | 23:38 |
| vila | dOxxx: hmm, but you pushed that already no ? | 23:39 |
| vila | dOxxx: and as long as it's available when we *announce* (instead of freeze), that's good enough | 23:39 |
| dOxxx | vila: pushed release notes and then noticed in the diff that I forgot to move what's new | 23:39 |
| vila | dOxxx: ha, ok | 23:39 |
| dOxxx | vila: also rewording it a bit | 23:39 |
| dOxxx | pipeline is cool :) | 23:40 |
| GaryvdM | dOxxx: Do you think you patch will land in bzr before 2.3 final. If so, I'll push to get the qbzr side in to. | 23:40 |
| dOxxx | although the handling of conflicts could be a little better. It would be nice if it could pre-populate the commit message, so I would just have to fix the conflicts and commit. | 23:40 |
| dOxxx | GaryvdM: I doubt it. I'm moving my release notes to 2.4. | 23:40 |
| GaryvdM | dOxxx: ok | 23:41 |
| dOxxx | GaryvdM: unless vila has a sudden change of heart ;) | 23:41 |
| GaryvdM | I've fallen a bit behind on email, so I'm not sure what the status is. | 23:42 |
| vila | GaryvdM, dOxxx : hehe, let's make it rock in 2.4 instead of trying to shoehorn it in 2.3 :) | 23:42 |
| dOxxx | yeah | 23:42 |
| vila | dOxxx: my heart is behind the efforts there, I can assure you | 23:43 |
| dOxxx | vila: oh for sure, otherwise you wouldn't have stuck with it for so long :) | 23:43 |
| dOxxx | vila has been slowly weeding the Java OOP out of my mp ;) | 23:43 |
| dOxxx | vila: okay, all set for review :) | 23:48 |
| GaryvdM | jam: Do we have any documentation on how to do a bundle of desolation? | 23:48 |
| vila | dOxxx: ok, I'll try to review it now (~20 left), if I fail to do that... that will be tomorrow only :-/ | 23:49 |
| jam | GaryvdM: I don't think it is explicitly documented. It is go to the AWS console, and tell it to create a bundle, when that finishes, tell it to create an AMI | 23:49 |
| dOxxx | vila: sure, no problem. thanks :) | 23:49 |
| jam | GaryvdM: there *is* doc/developers/ec2.txt | 23:49 |
| GaryvdM | I tried but I'm getting: NoSuchBucket(404)- The specified bucket does not exist | 23:49 |
| jam | GaryvdM: what S3 bucket are you trying to bundle into? | 23:49 |
| jam | do you want me to do it? | 23:50 |
| GaryvdM | jam: I entered desolation-20110121 for the bucket name. Do I have to create it first? | 23:50 |
| GaryvdM | jam: I would like to learn. | 23:51 |
| jam | GaryvdM: no, but you need to set the bucket to ec2.bazaar-vcs.org | 23:51 |
| GaryvdM | ok let me try that. | 23:51 |
| vila | dOxxx: approved, well done, I'll pqm it | 23:51 |
| dOxxx | vila: yay! | 23:51 |
| jam | GaryvdM: from the web console | 23:51 |
| jam | right click on the instance | 23:51 |
| jam | say "bundle" | 23:52 |
| jam | then S3 bucket name is ec2.bazaar-vcs.org | 23:52 |
| jam | the S3 Key Name is desolation-20110121 | 23:52 |
| GaryvdM | Ok - and then shut down from rdc | 23:52 |
| jam | GaryvdM: the bundle request should handle the shutdown | 23:52 |
| jam | so you don't have to do it manually | 23:52 |
| jam | (It didn't always work for me from ElasticFox, but it has always worked from the web console for me) | 23:53 |
| jam | by having "bundle" do it, it will also bring it back up when the bundling is finished, I think | 23:53 |
| GaryvdM | Ok - so I have to remember to come back and shut it down. | 23:54 |
| GaryvdM | jam: thanks - it's working now. | 23:55 |
| jam | GaryvdM: right 3% is the "it isn't shut down yet" but it should progress from there | 23:55 |
| GaryvdM | Ok - I better go. They lock the gates for the office park at 2am . I might come on line at home. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!