[00:10] Peng_: bzr annotate http://bzr.mattnordhoff.com/bzr/loggerhead/cheezum/serve-branches explodes in an entertaining way :( [00:10] mwhudson_: Huh! [00:11] also nosmart+ [00:11] $ bzr annotate nosmart+http://bzr.mattnordhoff.com/bzr/loggerhead/cheezum/serve-branches [00:11] bzr: ERROR: Transport operation not possible: http does not support mkdir() [00:11] whut? [00:11] mwhudson_, it's trying to get a lock [00:11] Oh, one of you has IPv6! Awesome! :D [00:11] oh [00:11] Peng_, that must be me [00:12] it's certainly very unlikely to be me [00:12] jelmer: why would it do that? [00:12] jelmer: If there was a prize for "First IPv6 HTTP request that isn't localhost", you'd win it. :D [00:12] mwhudson_, not idea [00:12] Unfortunately there's not. [00:12] *no idea [00:12] bzr annotate http://bazaar.launchpad.net/~mnordhoff/loggerhead/cheezum/serve-branches also fails [00:12] in a rather different way though [00:12] I can annotate the file in my local branch. [00:13] oh [00:13] * mwhudson_ stabs historycache [00:13] * jelmer is waiting for bzr to support gopher [00:13] I can do it over HTTP too. [00:13] That file has ugly history, FWIW. [00:14] so at some point launchpad's mirroring produced a broken branch [00:14] though actually, given that it's bzr+http, that's not so amazingly surprising [00:14] :> [00:22] thumper, moin [00:22] jelmer: hi [00:23] thumper, you pasted a URL here earlier, what repository was that for? [00:23] jelmer: I'm trying to remember... [00:23] jelmer: I think it was another bzr-git failure [00:23] a different one [00:24] thumper: Yeah, it was [00:24] thumper, it didn't include a URL though, so it was a bit hard to reproduce [00:24] heh, oops [00:24] * thumper thinks [00:25] thumper, mwhudson_: btw, what's the eta on a new bzr-git on lp? there's a couple of issues now that should be fixed [00:25] jelmer: no specific eta, i guess it's not too much work though [00:25] mwhudson_: we could land it and roll it out [00:25] mwhudson_: it is very contained [00:25] right [00:25] even i have privs to roll it out :) [00:25] jfdi :) [00:25] really? [00:26] how? [00:26] yeah [00:26] this is a bad thing though [00:26] thumper: i can sudo importd on the relevant boxes [00:26] ok, I don't want to know then [00:27] morning [00:28] moin Ian [00:32] hi jelmer [00:45] jelmer: pong [00:45] jml: yes [00:46] lifeless: were there any interesting outcomes? [00:51] lifeless, does subunit-stats work for you? [00:51] lifeless, it only recognizes a single test for me in a large stream [00:55] jelmer: checking [00:55] jml: 'even code you don't think will be reused will be reused' is probably the strongest message I took away [00:55] I have an unusual perspective though [00:56] :D [00:56] it was broadly: [00:56] - bzr's structure is nice and landscape had a bunch of tools that would benefit being in that structure [00:56] - it was too hard to reuse bzr's structure in situ [00:57] - a 90% version [primarily bzr's ExternalCommand] was fast to TDD up [00:57] - jkakar now wants the rest and is looking at actually reusing bzr's stuff :) [00:57] lifeless: thanks, that's a helpful summary. [00:58] lifeless: I guess bzr isn't going to start depending on commandant any time soon [00:58] happily, for various reasons I'd been cleaning this up, and there is a patch I've done which allows nuking all the builtin bzr commands [00:58] so you can have the infrastructure alone [00:58] \o/ [00:58] jml: the other way is quite likely [00:58] jelmer: new bzr-svn assertion just started happening [00:58] https://bugs.launchpad.net/bzr-svn/+bug/383414 [00:58] Ubuntu bug 383414 in bzr-svn "Assertion in iter_changes on path" [Undecided,New] [00:59] after I pushed a revision up [00:59] jml: seen my facebook feed for a link to the patch; I promised jkakar I'd link it to him after the talk [00:59] bzr.dev$ ./bzr selftest --no-plugins --subunit selftest | subunit-stats [00:59] Total tests: 183 [00:59] Passed tests: 182 [00:59] Failed tests: 0 [00:59] Skipped tests: 1 [00:59] Tags: [00:59] jelmer: ^ [00:59] using facebook for *patches* [00:59] I can no longer pull, push or branch that svn remote branch [00:59] what the hell :) [00:59] jml: for links to merge requests actually, but yeh. [00:59] jml: hey, you guys bullied me into it. [01:00] :D [01:00] lifeless, also, does it really have to repeat all input to me? [01:00] lifeless, or is that perhaps related? [01:00] jelmer: you have a test that is managing to corrupt the output stream [01:01] jelmer: I've been thinking of changing the control emitters to start their output with \n [01:01] jelmer: which would insulate against this [01:01] lifeless: anyway, it sounds like commandant and bzr are both proceeding in a direction that will make my script-writing life much better. :) [01:01] lifeless: How can a test do that? [01:01] Urg, and I just ran into https://bugs.launchpad.net/bzr-svn/+bug/383415 [01:01] Ubuntu bug 383415 in bzr-svn "AttributeError: 'SubversionTags' object has no attribute '_resolve_reverse_tags_fallback'" [Undecided,New] [01:02] jml: commandant's strengths are external commands and minimalism [01:02] jml: Personally, I'd hammer on bzrlib until its perfect for your needs :) [01:02] jelmer: say your stream is on stdout [01:02] jfroy, that one should be fixed now [01:03] jelmer: actually, just capture the first three tests or so [01:03] and pastebin [01:04] lifeless, http://pastebin.ubuntu.com/187766/ [01:06] jelmer: ok [01:07] But yeah, that logwalker bug has just killed me dead [01:07] can't operate on the remote branches at all [01:07] I can try reverting bzr-svn revision by revision to try to find the one that introduced the problem [01:07] unless it's a new one... [01:08] jfroy: I doubt this is a regression [01:08] jfroy: I think it's a new problem, just looking at it now [01:08] I think it started happening after I pushed some changes to svn [01:08] and looking at the svn log [01:09] it also pushed a merged branch up [01:09] (I've since disabled that option, it seems to not be quite as well tested as it should be) [01:09] and it was doing "strange" operations, like copying a directory unto itself on svn [01:09] jelmer: cat /tmp/t | subunit-stats [01:09] ... 1 fail [01:10] jelmer: debugging tip - if you see that, run through subunit2pyunit [01:10] e.g. copied foo/bar to foo/bar [01:10] ====================================================================== [01:10] ERROR: samba4.rpc.samba3.sharesec on ncalrpc with seal,padcheck (dc:local) [01:10] ---------------------------------------------------------------------- [01:10] RemoteException: lost connection during test 'samba4.rpc.samba3.sharesec on ncalrpc with seal,padcheck (dc:local)' [01:11] jfroy, I think I see where the problem is [01:11] lifeless, any idea what could cause that? [01:12] lifeless, ah, perhaps explanations of the result arent' allowed for skip? [01:13] should be === Kissaki is now known as Kissaki^0ff [01:14] lifeless, yeah, looks like it refuses those: [01:14] test: foo [01:14] skip: foo [ foo ] [01:14] fails [01:14] test: [01:14] skip: foo [01:14] works [01:15] jelmer: well, subunit itself outputs explanations for skips [01:15] so its something more than 'not supported' [01:16] I don't think subunit knows how to deal with one-line explanations [01:16] jelmer: http://home.devklog.net/~bahamut/12191.xml, http://home.devklog.net/~bahamut/12189.xml [01:16] if that's of any help [01:17] jfroy, revno 3033 should fix it [01:17] jfroy, but thanks for providing such valuable bug reports [01:18] jelmer: its dyin on the fail [01:18] jelmer: the very first one, not the skip [01:18] jelmer: no, thanks for being so awesome :) [01:18] lifeless, Which fail ? :-) [01:19] oh, I was testing something :) [01:19] anyway [01:19] you're quoting in a way that subunit doesn't expect [01:19] jelmer: mmm, no joy [01:20] lifeless, what does it expect? [01:20] status:? NAME($| [) [01:20] lifeless, fail [\nfoo\n]\n ? [01:20] explanation* [01:20] ]\n [01:20] yes [01:20] so I have to have a newline after the [ ? [01:20] same backtrace [01:21] though it seems I can pull existing branches now [01:21] and then a final newline before the ] [01:21] can't branch though [01:21] but I'll accept a patch to handle your layout too [01:21] simplest to get you going will be to use the multiple line layout subunit does [01:21] jfroy: Can you paste an updated backtrace ? [01:22] lifeless, ok, I'll see if I can provide a patch for that [01:22] lifeless: We have lots of tests and usually only short explanations, this makes it a bit easier to read "raw" subunit streams [01:23] done [01:24] jelmer: I usually read the pyunit2unit output when debugging, as it has the lot [01:24] jelmer: but sure, room for variation [01:29] jelmer: so in PDB, prefixes is equal to the path that gets printed by the assertion [01:30] which means it did path = prefixes[0].strip("/") [01:30] probably not relevant :/ [01:30] ascending is True [01:31] the from_revnum / to_revnum tuple is swapped somewhere, I'm trying to find out where [01:31] it usually doesn't matter, only if prefixes is not empty [01:31] it's not [01:31] from_revnum should be higher than to_revnum [01:32] from_revnum=12189 to_revnum=12191 in repository.py(1114)find_branchpaths [01:33] ditto for repository.py(1182)find_fileprop_paths [01:33] I think I've found the place where this is going wrong, just running the testsuite now to check that I didn't break anything else [01:34] same for find_branch_tips [01:35] might be in revids.py(243)get_branch_revnum [01:35] yeah, that's where I've swapped the two atm [01:36] (Pdb) p last_revnum [01:36] 12191 [01:36] (Pdb) p last_checked [01:36] 12189 [01:36] in there [01:37] layout is TrunkLayout(2) [01:37] project is the prefix [01:38] (same value as prefixes[0] in find_branchpaths) [01:44] jelmer: actually, I reverted my quoting hack in my server. [01:44] I had a broken link, apparently related to lack of escaping of "/" for a subdir branch. [02:12] jam: ping [02:16] jfroy, I've got a fix that should also improve performance in some situations [02:16] jfroy, but still one test failing [02:16] will push when I've fixed that [02:16] jelmer: all good [02:37] lifeless, oh btw, I've asked for a rename of bzr-rebase to bzr-rewrite on Launchpad [02:37] heh [02:37] so I've been thinking of doing a ground up recode [02:37] but not necessarily for good reasons [02:38] recode of rebase you mean? [02:39] yeah [02:39] huh [02:39] people will get confused even more [02:39] they're look for "rebase for bazaar" [02:39] *they'll look [02:40] lifeless: There's certainly a couple of improvements that can be made, I don't think there's much to gain in a rewrite from the grounds up rather than just fixing things gradually [02:41] jelmer: I've found it hard to get code that fixes peoples issues into trunk [02:41] jelmer: and there seemed to be a definitional tension [02:41] lifeless, I don't think it's unreasonable for me to refuse patches that break the testsuite. [02:42] jelmer: thats fine :), it was other ones [02:42] by definitional I mean 'rebase vs replay vs ...' [02:43] lifeless: So you're considering doing a rewrite based on a single discussion over an command parameter? [02:43] I have a dream of having a single command that supports all the history rewrite operations we need [02:43] jelmer: did I say 'not necessarily for good reasons' [02:44] lifeless: I don't object to having such a command, and I think bzr-rewrite would be a good place. [02:44] lifeless, I think it should be a different command from "bzr rebase" though, which is one of the reasons I asked for the rename of the plugin [02:47] jfroy, the rebase plugin already includes more than just the rebase command, so I don't think it's unreasonable to have a different name for it [02:48] That's true [03:13] jelmer: https://code.edge.launchpad.net/~jelmer/bzr-search/merge is still empty [03:14] lifeless, it was created using bzr send, I'll see if I can push to it manually [03:15] also file a bug [03:15] lifeless, pushed now [03:32] jfroy, pushed [03:32] jelmer: checking [03:33] success [03:33] you can close [03:36] jelmer: you, sir, are awesome [03:36] jfroy, :-) [03:59] * igc lunch [04:11] jelmer: so what does lp:~jelmer/subunit/subunitrunner [04:11] do? [04:42] spiv: ping [04:42] spiv: [network deltas, hopefully you're awake now] === timchen119 is now known as nasloc__ [04:59] lifeless: yes, I'm awake :) [05:00] so for 2.0 we wanted to get network deltas gong [05:00] (I don't think my problem is jet lag so much as getting over ubuflu... I'm not having any trouble getting sleep at appropriate times, I just seem to need a lot more sleep than usual.) [05:00] Yeah, I'm sleeping 9-10 hours, which is about 40% more than usual [05:00] "ubuflu"? [05:01] Peng_: the UDS plague. [05:01] Peng_: the result of uds, where lots of viruses get together and have a party [05:01] And you people wanted to invite me! :P [05:01] its like an uberflu [05:01] but with a kiwi accent [05:02] there are compensations [05:02] interesting people [05:02] mwhudson_: true, I don't know how else I'd be able to fill a large bucket of snot... [05:03] Factoring in everybody sleeping 40% more than normal, was UDS really good for productivity? :D [05:07] Well, that explains why I'm getting _less_ sleep than normal... obviously the cosmic balance is being maintained. [05:09] Wait, I am too. Scary. [05:38] * spiv -> food [06:01] spiv: so, are you still blocked onthe question you asked me monday week ago, or jam helped, or EILL === abentley1 is now known as abentley [06:53] lifeless: I haven't looked at it at all, actually, so not sure if I'm blocked :) [06:53] lifeless: the UDS sprint was mostly on gc-stacking and nested-trees. [06:54] This week has been pretty slow (EILL), but I have caught up on a few things and fixed a regression for jml. [07:00] yah [07:00] I'm struggling [07:22] hi all [07:23] lifeless, spiv: me too EILL, at least I need far more sleep than usual, so not really ill but... [07:24] abentley: FYI, hg is overhauling forests, 'subrepos' is what they are calling it [07:24] is it going to be less silly? [07:24] who knows [07:25] lifeless: I heard "nested repositories": http://bazaar-vcs.org/NestedTreesDesign#mercurial-nested-repositories [07:26] abentley: mpm is talking subrepos in IRC on and off at the moment [07:26] it may be a reference to cleaning up http://www.nabble.com/sub-repository-extension-td20345412.html [07:27] or may be new code; I don't know === abentley1 is now known as abentley [07:44] blink [07:45] ? [07:46] just realised the time [07:46] Ah. [07:47] Oh, 06:47, when my logs rotate (but not on this day of the week). [08:03] What's the difference between checkout & branch? [08:05] when you commit in a checkout, the commit goes both locally in the checkout, and also in some other branch that the checkout was made of [08:05] its useful for maintainers of a project to all have a checkout of trunk === abentley1 is now known as abentley [08:23] halt() [09:17] i want to start a new repo (tree?) and then import into it single files from multiple other repos while preserving the history for just those files. is that possible? [09:17] i'm basically combining a document from three diff repos, but first i want to import the existing ones while preserving the log === abentley1 is now known as abentley [09:43] hi folks - what's the status of initial commit and explicit-file commit with 2.0? === abentley1 is now known as abentley === abentley1 is now known as abentley [11:13] lifeless: Ping? [11:14] Pah, Australians. Always 12 hours ago. [11:15] pah. [11:32] Hi, I want to share my code using bzr and sftp. Now I have setup a repo, but on the server there is no code, just the history. How do I set it up in a way, that there is code on my server as well? [11:33] balachmar: Pushing via remote protocols does not update the tree [11:34] balachmar: There is a plugin that executes a tree update via ssh [11:34] ooh, I thought since, I didn't setup the remote tree with no-trees it would actually do it... [11:35] Pushing a tree over SFTP would be more costly than the remote machine writing the tree [11:36] is there a way to automate that? So that when I commit changes, the tree gets regenerated? [11:38] push-and-update plugin http://bazaar-vcs.org/BzrPlugins [11:38] Although there are thoughts about implementing it in the smart server rattling around on the mailing list [11:47] ok, will just do it manually for now then. Thanks for the info [11:48] Even now, you could probably use a hook in the hpss? === mrevell is now known as mrevell-lunch [13:07] hi :) [13:08] I tried to use uncommit. It work on local copy, but I could not reflect it on launchpad. Is it possible ? [13:09] it works* === Kissaki^0ff is now known as Kissaki [13:30] you can "push --overwrite" probably [13:30] but be careful with that === mrevell-lunch is now known as mrevell [13:58] hi, I've set my authentication.conf to this: http://pastie.org/500323 but when I try to access my home computer with bzr+ssh://, it times out waiting on port 22? is there something wrong with the .conf? [13:59] I can't help you with authentication.conf, but I'd use ~/.ssh/config for this [14:00] cdecarlo: as luks said, .ssh/config is more appropriate, especially if you want port 2662 to be used [14:00] luks: It never occured to me to try that, thanks, I'm always interested in other ways to skin cats ;) [14:01] out of curiosity then, why then does bzr support those options in it's authentication.conf? [14:01] cdecarlo: authentication.conf purpose is different, it said: *if* you use port 2662 then user is 'colin', whereas .ssh/config allows you to say *if* connection goes to example.com then *use* port 2662 [14:01] vila: ah [14:02] thanks [14:03] cdecarlo: the main purspose of authentication.conf is to provide some facilities to protocols *other* than ssh, .ssh/config and ssh agents are not available for all protocols :) But auth.conf doesn't even try to replace them [14:03] for ssh [14:04] that would make a great note in the user docs, does bzr use trac or something similar? [14:09] cdecarlo: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#authentication-settings says "SFTP can use either a password or a host key to authenticate. However, ssh agents are a better, more secure solution. So we have chosen to not provide our own less secure method." [14:10] cdecarlo: but if you can think of a better way to say that or other places where it should be pointed at, feel free to send a patch. The sources are under the 'doc' directory in bzr [14:10] hi folks === nevans1 is now known as nevans [14:16] vila: thanks, I'll try to think of something [14:17] pygi: hi [14:34] Hi [14:35] I can't seem to find out how I should setup a repo on a ftp server. [14:35] Can YOU help me? [15:00] nickoe: 'bzr init ftp://example.com/path/to/branch' should create a empty branch [15:21] vila, how should I then use t correctly? [15:22] bzr push ftp://example.com/path/to/branch from your local branch [15:22] 'bzr push ftp://example.com/path/to/branch' from your local branch [15:23] that is if I already got a branch on locally, right? [15:23] nickoe: yes === abentley1 is now known as abentley [15:24] vila, then tha same data is locally and on the ftp, right? [15:25] except for the working tree, yes [15:25] uncommitted changes are not pushed either [15:26] Okay. But the fact that the working tree is not on ftp, means that you actually can't download a revision from the server? [15:27] nickoe: no, it means the ftp branch has no working tree, but it can be used to branch or pull from other clients [15:28] nickoe: if you never login with a shell on the ftp server, you don't care about the working tree [15:31] okay, so antoher user can use bzr checkout ftp://bla.com/path to get the latest revision, or? [15:37] Seems to be working now. vila thank you [15:37] nickoe: always happy to help (TM) [15:38] But why do I have to type the ftp password all the time? vila [15:39] nickoe: because your server requires a password ? :-) === thunderstruck is now known as gnomefreak [15:40] nickoe: what os/version are you using ? [15:40] linux [15:40] ubuntu 9.04 [15:41] nickoe: so authentication.conf is the way to go [15:41] nickoe: is sftp an option on the server side ? Or is the server not under your control ? [15:41] sftp not an option atm [15:42] nickoe: too bad, keys and ssh agents are more secure, anyway, have a look at http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#authentication-settings [15:42] yes I know, but not an option atm... [15:42] :-/ [15:44] nickoe: is that server public or on a private LAN ? [15:44] well it is public, but the information on it is just temporary [15:45] nickoe: np, I was just trying to better understand your use case [15:45] k [15:47] But I will thank you once again [15:59] morning vila [15:59] jam: hi ! === mvo_ is now known as mvo [16:11] my unshelve command failed miserably [16:11] bzr: ERROR: exceptions.NotImplementedError: [16:11] I'm not entirely sure what's in my shelf - where can I find what the contents are? [16:12] cat .bzr/checkout/shelf/shelf1 [16:12] nice === mario__ is now known as pygi [19:09] Morning. [19:10] I was wondering if there was a way to have bzr stomp all over my working tree when switching branch. [19:24] jfroy: ? you mean touch everything? [19:30] * garyvdm is trying to catch up on email. I've had no internet since I got back from the sprint. [19:36] garyvdm: :p [19:36] I've told you not to cut the wires! [19:36] haha [19:42] jam: sorry, I got dragged away [19:42] so my problem is that I have some branches which have file foo/bar versioned, and some later branches that do not (they generate foo/bar) [19:43] and when switching from a branch that generates foo/bar to a branch that versions the file, I get a content conflict [19:43] I'd rather just have bzr blow away files it needs to check out from the branch [19:43] I understand it cannot be default behavior, but a flag would be useful [19:44] jfroy: well, there is always "bzr switch; bzr reverT" [19:45] true [19:45] that's what I do right now, and it works well, but I'm lazy :p [19:47] bzr switch --hard ? [19:47] bzr switch --and-reset [19:47] bzr switch --and-revert [19:48] --nuclear-option [19:58] jam, ping [19:58] jelmer: pong [19:59] I'm looking at bug 246880 and wondering how it relates to the bug we worked on during UDS [19:59] Launchpad bug 246880 in bzr "ghost fetch issue: fail when fetching a text referenced by a live revision introduced by a ghost revision" [High,Triaged] https://launchpad.net/bugs/246880 [19:59] the original error is different (line delta missing) but the reconcile problem should be fixed now [20:15] nevermind, enough other ghost bugs open :-/ [20:22] evening [20:23] evening LarstiQ [20:23] garyvdm: reviewed my patch yet? :p [20:23] heya gary [20:23] * pygi hides [20:24] pygi: No :-( - Had no internet. Will do it Now! [20:24] garyvdm: xD [21:38] Peng, is there anything that's enabled by --allow-writes atm or is it there in preparation of the smart server support? === GaryvdM_Windows_ is now known as GaryvdM_Windows [21:49] GaryvdM_Windows: ! === mwhudson_ is now known as mwhudson [22:31] If I deleted a file in revision 5, and am now at revision 10, what is the best way to get that file again? [22:33] Snova: bzr revert -r 5 filename [22:34] Thank you. :) [22:34] jam: thanks [22:44] hi. i'm trying to create a branch on launchpad but am getting the following error: [22:44] bzr: ERROR: Target directory "lp:darwindotnet/0.1" already exists. [22:46] the branch clearly hasn't been pushed to yet. [22:46] any ideas? [22:51] luks: What are your thoughts who copyright is assigned to in the license headers in qbzr? [22:51] If someone adds a new file, they should assign the copyright to them selves? [22:53] Noldorin: try passing --use-existing-dir to push [22:53] mwhudson: i'm attempting to branch directly to a separate launchpad branch. is that the wrong way to be doing it? [22:54] oh [22:54] (bzr branch doesn't have the --use-existing-dir option) [22:54]