[00:00] when we had 15 users... we were like "well we need it" .. now we have 25 users... every user is I think $500 .. plus $100/year. [00:16] jelmer: if you're still here [00:17] jelmer: how does bzr-git's GitBranchBuilder avoid the [00:17] mwhudson: I am [00:17] *** Your name cannot be determined from your system services (gecos). [00:17] problem? [00:17] i'm saying [00:17] run_git( [00:17] 'commit', '-m', 'dsadas', '--author', 'Joe Foo ') [00:17] and the above message is making me sad :( [00:18] (run on a test server, it works locally) [00:19] i guess i can just run git config [00:19] but it seems pretty ick [00:20] ah [00:20] you might need a ~/.git/config file [00:20] mwhudson: please file a bug, we shouldn't require that to be able to run the testsuite [00:20] jelmer: it's not your tests that are failing :) [00:21] ah [00:23] mwhudson: I'm not so sure we avoid that [00:23] do we? [00:23] i can probably find out [00:23] jelmer: bzr selftest git ? [00:23] mwhudson: yep [00:24] jelmer: yeah, some tests fail === bac_afk is now known as abc === abc is now known as bac [00:26] jelmer: i'll file a bug [00:27] mwhudson: thanks [00:29] jelmer: https://bugs.edge.launchpad.net/bzr-git/+bug/348238 [00:29] Ubuntu bug 348238 in bzr-git "tests fail if "Your name cannot be determined from your system services (gecos)."" [Undecided,New] [00:58] hi...is Bazaar the VCS created by Ubuntu and/or the one they use? [00:59] the same company that largely funds ubuntu also supports bzr [00:59] ah. did Ubuntu create a VCS? [01:00] skeftomai: no, Ubuntu uses bzr [01:00] ok. that answers my question. thanks [01:13] jam: ping [01:52] Has anyone here run bazaar on aix? [01:53] Some folk have posted on the list from time to time [01:53] I've read some of those posts. [01:54] I'm having issues getting it compiled, and I can't tell if it is a issue with python or bazaar [02:00] Jimerson: pastebin the error, or you could file a bug [02:02] http://pastebin.com/m7d649346 [02:07] lifeless: pong [02:08] Jimerson: it looks like you don't have the compiler that python was compiled with [02:08] "xlc_r" [02:11] Thanks guys. [02:11] Now I have to try and find the compiler :) [02:11] jam: I'mmaking record_iter_changes a generator [02:13] lifeless: to return what? [02:13] fs hashes [02:14] its that or call tree._observed_sha1 directly, this seemed more accessible for testing/flexibility [02:16] Thank you guys so much. [02:16] That resolved my issue. [02:19] cool [02:25] lifeless: I don't have a huge opinion either way. It seems a bit odd to iterate over record_iter_changes, just because if you stop mid-way it seems to be in a strange state. [02:25] however, it is obviously an 'iter' sort of interface :) [02:26] right [02:27] anyhow, its done already :P [02:27] there are two issues, it could yield more than is put in (merge commits) or less (no stat cache calculations to update), which is why generator is better [02:32] * igc lunch [02:34] One last question and I will leave you all alone, As bazaar does not handle partial checkouts. How do you handle a situation, where you want to arrange the structure, with folders that are only their for organanization, but you want to be able to export it to a production server? [02:34] put them in separate branches [02:35] or don't use your vcs for deployment [02:35] Jimerson: I'm not entirely sure I understand the question [02:35] For example: [02:36] In bazaar I want it like /project/version/blah [02:36] But I just want to export out to the server everything under blah. [02:36] so, bzr export can do that [02:37] That means I would have to do a full overwrite everytime though correct? [02:37] yes, if you used export [02:37] uhm [02:38] for production deployments a number of folk use 'bzr upload' [02:38] I agree with bob2 though, in bzr you wouldn't normally have project/version as part of your versioned paths [02:38] note that 'bzr init-repo', if you've used that, is *not* related to versioned data, its just a storage area [02:39] How do people seperate things then, just branch them out? [02:41] Jimerson: well typically they start separate [02:41] you want one branch per project [02:41] and they would start that way - you'd bzr init each individual thing indidividually [02:41] Jimerson: I mean, examine 'version' as part of a tree [02:42] I get what you are saying. [02:42] if you made a tarball of your project, each version would be a separate tarball right? and thus in bzr each version is a separate branch, or even just separate commits in a single branch, but they aren't both versioned in the same tree [02:42] I am new to scm, so I am learning. [02:42] likewise project [02:43] Just wondering... for a checkout, should bzr push to the "checkout of" branch ever do anything? [02:44] lifeless, Thanks for all your help. I think I have enough to get rolling down the path. I'll be back. you have a nice evening. [02:44] bob2, Thank you as well. [02:45] jam: around? [02:45] or poolie [02:45] currently we do housekeeping in commit [02:45] when we implicitly unversion something, to make sure we only unversion the root of a collection of things that all got unversioned [02:46] like if we have a/b and both are missing [02:46] if we don't, then wt.unversion() blows up [02:46] I'd like to change wt.unversion([a-id, b-id]) to just deal IFF b-id is a child of a-id [02:48] lifeless: so it wouldn't blow up if you did it in reverse, right? (unversion b-id before you unversion a-id) [02:48] yes [02:49] and the issue is that we are passing in a 'set' [02:49] yes [02:49] so it doesn't know what order to do things [02:49] the problem is that you may have a/b/c/d/e [02:49] and get b-id, then e-id, then a-id, etc [02:49] as the unversion set should be generally small, I think tracking this in unversion is ok, and easier to work with [02:50] lifeless: so I would think that keeping track of "things not yet unversioned" would be fine [02:50] and unversion should complain if all the children don't get unversioned [02:50] or something like that [02:50] well unversion should complain if something provided was never versioned at all [02:50] but sure, we seem agreed that pushing this to unversion is fine [02:51] lifeless: right, I'm actually saying that unversion should complain if you unversion "a" but *don't* unversion "b" [02:51] jam: I don't think so, its meant to recurse for us [02:51] and I like that [02:52] lifeless: I think it can lead to deleting things that didn't get properly recorded as being deleted as part of the commit [02:52] say "iter_changes" somehow [02:52] for the case of "a/b" and "a/c" [02:52] somehow just saw a and a/b being deleted [02:52] suddenly the commit doesn't think about 'c' [02:52] but unversion removes it anyway [02:53] if that bug exists we have it already [02:56] if you do bzr commit a/b and a is deleted, we should just delete b [02:56] care will be needed, I agree [02:56] lifeless: I agree, but I'm saying that "record_iter_changes" is only going to have a delta for 'a/b' and not 'a/c' even though we are removing it in a follow up pass [02:56] I'm down to 20 failures [02:57] but we won't remove all of a unless we record a delete of a [02:57] I feel like it is opening up a hole, that you can catch by saying that the delta must verify itself complete [02:57] and thus a/c won't be deleted, and if we did record a delete of a, a/c will be deleted [or the inventory delta is corrupt, which is even more serious] [02:57] I agree, a delta being corrupt is serious, and you are missing a chance to catch it [02:58] jam: unversion is on tree, its not the delta committed to the repository [02:58] jam: I don't quite see the correspondence [02:58] lifeless: the delta you are committing to the repository *should* match the one that tree is applying to itself [02:59] jam: uhhhh [02:59] jam: may be we're talking about completely different thigns [02:59] so commit auto-detects missing files [02:59] and then calls tree.unversion on them [02:59] to match the fact that it commits the delete to the repo [03:00] I'm saying that the logic in unversion [03:00] can check that the logic from commit is matched properly [03:00] If commit sees that 'a' is missing, commit *better* see that a/b and a/c are missing [03:00] and thus it can pass all of those to unversion [03:01] and unversion can double check that it agrees that everything under 'a' was marked removed [03:01] well [03:02] these sets do not have an equality constraint [03:02] already unversioned things [03:04] I think that it might be good if repo.add_inventory_by_delta checked deletes remove all children correctly (by checking the basename map) [03:04] or something [03:22] lifeless: hi i'm back [03:23] lifeless: so iiuc you're saying [03:24] deleting the parent will implicitly remove the childern [03:24] children* [03:24] but explicitly removing some or all of the children as well will not be an error? [03:24] that makes sense to me [03:24] right [03:25] specifically today, unversion[b,a] works, unversion[a,b] doesn't [03:25] I think it should work [03:32] down to 16 errors [03:33] agree [03:43] poolie: one patch you may wish to review before you go on leave is http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cb87b89280902251019u212be32bv5e1b33fbe3dea83c%40mail.gmail.com%3E [03:43] thanks igc [03:43] ah right [03:43] poolie: from memory, you were involved in the email thread leading up to it [03:44] poolie: and it's been sitting there for a month now as most of us are buried in brisbane-core [03:44] sure [03:44] i read the previous version [03:44] i asked for tests and they seem to be there so it should be good to go [03:44] thanks for the nudge [03:58] bah [03:58] iter_changes skips over subtrees [04:16] 6 to go [04:24] igc: that docs fix does actually work for me even in a new checkout [04:24] which is odd [04:31] igc, i'm inclined to just send it and see if pqm agrees... [04:38] poolie: worth a try :-) [04:42] 4 tests left [04:59] lifeless: hi? [05:00] you fell offline? [05:01] Just wondering... for a checkout, should bzr push to the "checkout of" branch ever do anything? [05:01] poolie: nope [05:01] poolie: still here :) deep hack is all [05:01] hm how curious, pidgin shows you as offline [05:01] lies, its all lies! [05:16] so, I have inventory free commits [05:16] -woo- [05:46] i'm hitting a problem pushing to a remembered location with bzr. [05:47] I'm getting this when I try to push... bzr: ERROR: Generic path error: '85zdaceo7r26xzgd8t3m.fetch': Failure: unable to rename to '../packs/e1918987d0a82b7fad850f3c976fe036.pack') [05:47] any idea what's happening? [05:48] chrispitzer: hmm, are you onwindows perhaps? [05:49] nope [05:50] dev on ubuntu - pushing to shared hosting. [05:50] so I guess i don't know what the shared host is using... it's dreamhost [05:50] is it ftp? [05:51] (sorrry, on a phone call will be high latency [05:51] The remembered location is over sftp [06:01] chrispitzer: thats odd [06:02] could be permissions, or a still open file [06:03] DreamHost used to use NFS. They do something different now; probably just local ext3. Shrug. [06:03] chrispitzer: what bzr version are you using? [06:05] how do i check that? [06:06] chrispitzer: "bzr version" [06:08] Augh! [06:09] 1.6.1 [06:09] I just nuked the .bzr folder on the remote server and pushed using --use-existing-directory [06:10] so that solves it for now. [06:11] *shrug* [06:14] chrispitzer: I suspect this is fixed somewhere around 1.10 or so [06:14] I recall a similar bug report which we fixed [06:14] What's Andrew Bennetts's nick again? andrew? [06:14] oh, or someone deleted a directory [06:14] Peng_: spiv [06:14] Oh, duh, right! [06:14] Thanks. [06:14] spiv: ping [06:23] hm [06:23] how so i push a working copy to a remote location? [06:24] chrispitzer: You could use the bzr-upload plugin. [06:25] chrispitzer: Or, if you have bzr installed on the server, you could push the branch, create a working copy on the remote side ("bzr co" in the branch), and install the bzr-push-and-update plugin locally. [06:29] i think I'll need bzr-upload, as the server doesn't have bzr and I don't have control to install it [06:32] chrispitzer: DreamHost? Why not? You can install it in your homedir if you want to. [06:32] chrispitzer: I don't recommend it, since procwatch will probably murder it in the middle of large operations, but you *can*. [06:35] lol [06:38] ug... [06:38] bzr upload only allows full uploads, not differential? [06:38] it does incrementak [06:38] but each file is full copied [06:39] lol [06:39] what's the point of that? [06:39] it uploads the file, and if the file's already there it ignores the upload? [06:40] What's the point of what? [06:40] uploading everything, when you're going to discard 90% of what you upload [06:41] Why are you going to discard 90% of what you upload? [06:41] Peng_: pong [06:41] spiv: Hi! [06:42] that's what bzr upload is doing (if I'm reading it correctly) [06:42] spiv: The smart server jail stuff completely broke bzr+http with shared repos. What's the solution? File a bug? Edit my smart server script? [06:43] Peng_: possibly both [06:43] Peng_: start with filing a bug, though [06:43] I'm surprised to hear that case broke, though. [06:43] :D [06:44] In what way did it break? [06:45] spiv: The server's logs get spammed with "BzrError: jail break: 'chroot-139142476:///repo/", the client gets a similar UnknownErrorFromSmartServer. [06:46] That's very odd. That suggests a mismatch between the jail setup and the backing transport on the request handler. [06:57] igc, i did that review btw [06:57] hullo spiv [06:58] spiv: Filed bug 348308. [06:58] Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [Undecided,New] https://launchpad.net/bugs/348308 [06:58] chrispitzer: you're reading it wrong :P it uploads only the changed files AFAIK [07:01] it uploaded everything the first time, but only incremental since then. [07:01] so it's good. [07:02] I mean, even the first time the working copy should have matched the remote copy time stamps and all... but oh well. :P [07:03] chrispitzer: it doens't work with working copies though, because we don't have the ability to efficiently and in a user-friendly deal with concurrent changes, conflicts etc [07:08] poolie: saw that, thanks [07:09] hi all [07:09] hi vila [07:10] hi vila [07:11] it might be nice if we really could deal with full remote working copies [07:11] it's possibly possible :) [07:14] hmm, it would be nice if people stop proposing bzr-upload to upload a working tree since there is an explicit check there to ensure it will refuse to do so :) [07:14] poolie: I'm still skeptical but won't stop people doing it:) [07:15] oh sometime i'd like to talk to you about whether just adding an indirection file to the dirstate is really enough [07:15] poolie: ok [07:15] poolie: over lunch perhaps :P [07:15] as i said in the bug i thought there was a bug in that but imbw [07:15] on my plate is to analyse 'st' updates and then I have enough data for a proposal [07:17] I'll check the bug when I next think aboout that problem [07:17] for now, conversion to current chk is in progress, -> dinner [07:17] do you mean analyze the value of updating the hash from st? [07:17] cool, good night [07:19] I mean to analyse the potential race conditions of status doing that [07:19] with the alternate design === thekorn_ is now known as thekorn [08:02] hi vila [08:03] vila: a present for you in the mailing list: my 'log DIR' patch ready for you to reconsider :-) [08:03] igc: hehe, ok, will look at it [08:03] vila: that would be awesome - thanks [08:08] igc: on the other hand if you could have a look at the bbc test failures related to 'CHKInventory' object has no attribute 'filter' ... :) [08:13] vila: Sure do. I'll do that either tonight or tomorrow [08:13] * igc dinner [08:13] igc: thanks, enjoy your dinner :) [08:26] 19K test revisions converted [08:49] hi lifeless [08:49] i'm about to press send... [09:54] lifeless, jml: http://pybites.blogspot.com/2009/03/unittest-now-with-test-skipping-finally.html [10:06] spiv: well, thats good. the total lack of discussion is a bit odd [10:06] or perhaps we were looking in the wrong place? [10:11] also the implementation of class skipping is pretty bong [10:11] wtf doesn't def run() handle that [10:16] bong. [11:41] is there a command to find out if a checkout if lightweight or heavyweight? [11:41] OllieR: "bzr info", I suppose [11:42] Peng_: that gives checkout location info and type [11:42] but doesn't tell me whether it was lw or hw [11:42] annoyingly :( [11:42] Seriously? [11:42] Huh! [11:42] yah [11:42] unless it does on a later version i am running Bazaar (bzr) 1.3.1 [11:43] OllieR: I'm on bzr.dev, and the second line will say either "checkout root" or "light checkout root". [11:43] (err, third line. The first line of the Location section.) [11:46] Peng_: right yes so it does :) [11:46] Peng_: many thanks [11:46] :) [12:07] Hey there, getting a bit of a weird error. [12:07] bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium '' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request. [12:08] Mez: That probably means some unknown error happened, but it got masked by that. What version of bzr? It might've been fixed. [12:08] 1.12 [12:09] Mez: Oh. That probably won't help, then. Still, 1.13.1 is out; you should upgrade. :) [12:09] Mez: Sorry I can't help you... [12:16] seems an upgrade to 1.13 worked Peng_ (after running break-lock) [12:18] Mez: Really? Great. :) [12:27] igc: did you see my commit figures? [12:30] lifeless: I did. well done [12:31] lifeless: we just need to sort out the nested trees issue & I'm be very happy [12:31] re commit in brisbane-core [12:32] This is a dumb comment, but.. is it just me, or is brisbane-core a scarily large amount of new code? [12:36] Peng_: it's a scary amount of thought ... [12:36] the code change themselves aren't huge in volume [12:37] night all [12:37] igc: G'night. [12:39] igc: 12,230 new lines according to diffstat, though they aren't all necessarily very interesting. [12:42] can you get bzr to default to a lightweight checkout? [12:43] igc: would like it if you could arrange to run usertest with bbc + my patch from bundlebuggy merged + the lineI highlighted commented out [12:43] igc: it would be very useful to know if there are surprises [12:43] igc: there is about 12MB of packs [12:43] OllieR: I guess you could make "checkout" an alias for "checkout --lightweight". [12:43] OllieR: I'm not sure how you'd make a heavyweight checkout then.. [12:43] igc: I am wondering if we want to just cherry pick from bbc a lot to do the merge [12:43] Peng_: --no-lightweight [12:44] lifeless: Oh, okay. [12:44] lifeless: Cherrypicking's no fun. [12:44] 10% of our total history isn't either :P [12:44] Peng_: yeah not bad thinking [12:45] lifeless: how do you mean --no-lightweight? [12:45] can't see that in any man pages [12:45] Once everybody upgrades to bbc, that'll only be like 20 KiB, right? So what's the big deal? :D [12:47] lifeless: 10% of history ish't *that* terrible. It'll be a pain to "bzr pull" when it lands, but it's not significant to "bzr branch" or anything. [12:47] It's only significant because it'll come all at once. [12:47] * Peng_ gets shot by someone on dial-up [12:48] Peng_: you can also always do a stacked branch [12:50] I wonder how large it would be even without history? [12:51] Sending it to BundleBuggy would be funny. :) [12:56] does the new progress ever move to a unit larger than KB? [12:57] 130000KB is too many digits for me [13:22] hi, is there a tool to print what modifications has been done by who for a given file, thx [13:23] nilg: "bzr annotate"? [13:25] yeah exactly what I wanted Peng_, thanks! [13:26] :D [13:36] vila: hi [13:37] james_w: hi ! [13:37] vila: would adding something like transport.get_transport(for_writing=True) make any sense? [13:37] then bubbling that up to things like Branch.open()? [13:38] having the intent there would allow better error messages when there is a mismatch between what you want to do and what is possible on the transport I feel [13:40] 1) I think most commands already use {branch,repo,wt}.open[_containing] so I'm not sure it's the right place [13:41] 2) You can't always decide from the url only if you will be able to write or not [13:41] and even if the scheme itself allows writing you may be denied later [13:42] You're back to the not-logged-in-launchpad error message ? [13:42] yeah [13:43] I put it there, so I feel responsible that it sucks so much [13:43] responsible does not imply gulty :) [13:43] I don't see what commands using open_containing et al have to do with it, they would indicate whether they will try and lock the branch for write or not [13:44] Branch.open_containing(for_writing=True) or similar [13:44] there may be a few cases where they don't know, but that would be acceptable I guess [13:44] your point 2 makes sense, but I believe we could at least communicate this to the directory service [13:45] the lp: service could then give an error when it needs to [13:45] How about checking that in the commands themselves via the underlying transport ? [13:46] or catch the exception and rephrase it if needed ? [13:46] :-/ [13:49] checking was my first attempt, but the way that I did it was vetoed [13:49] I think we do attempt to catch the errors in a few places, but it's hard to get them all, and it keeps shifting [13:49] plus that gives no way for the lp: service to suggest lp-login [14:03] james_w: I think we would consider a "Branch.open_locked(for_write=True)" or "Branch.open_write_locked()" [14:03] We've talked about it on the list [14:03] as a way to get around the current open + lock as a standard function [14:03] also, some internals tend to lock objects, and then unlock them to return them [14:04] which then gets locked right away [14:05] that sounds sensible [14:05] would passing that information down to the transport layer be ok? [14:05] most things wouldn't use it I imagine [14:06] or perhaps I misunderstood at what layer the directory services operate [14:11] james_w: It is a lookup that is performed by get_transport. Transports themselves don't use it. [14:11] james_w: So I think pushing it down there would be fine. [14:11] jelmer: is svn-push still required to setup a new branch folder with bzr 1.13 and related bzr-svn ? [14:12] jam: +1000 on a method for opening locked branches. [14:13] rocky: yeah [14:13] rocky: I have a patch for bzr.dev that allows it to integrate into "bzr push", but it hasn't landed yet [14:15] whoa, when did "bzr branch --stacked" get so freakishly quick? [14:16] checkout out bzr.dev takes just 7 wallseconds [14:16] jelmer: http://bazaar-vcs.org/bzr/ was upgraded to btrees recently; maybe that's why? [14:17] Peng_: yeah, I guess that'd explain it [14:23] jelmer: hrm, my svn-push is hanging :/ [14:25] rocky: Hanging or doing a lot of work very inefficiently? :D [14:29] hehe it's hard to tell the difference when it doesn't end ;) [14:32] jelmer: bzr git took me by surprise. I had some bzr commands I forgot about in some scripts. Accidentally ran them in a git repo and it just worked. Nice. [14:55] brink_: :-) [15:01] can i push a branch using sftp? [15:02] yep [15:02] james_w: thanks [15:08] jelmer: Along with the btree changes, I also recently changed the "grab the working tree" code to batch up requests into 5MB chunks [15:08] which made a big difference for the python 'branch --stacked' I was testing [15:08] (rather than requesting the content for each file separately) [15:19] jam: The need for a fast iter_references seems legitimate to me, but since the current bbc format doesn't have it, should we consider having a new format for nested trees? [15:20] abentley: it wouldn't be terribly hard to add another "chk_map" or similar to the disk format for brisbane-core [15:20] and bring it in before we merge it to stable [15:20] (we have a few more days, at least) [15:21] otherwise, if you feel it isn't possible to do efficently without a disk format bump [15:21] then we can just disable it, and plan for one [15:21] * Kinnison finally works out what brisbane-core is. "oooh" is my reaction [15:21] I'm wondering, for example, if "bzr branch meta-1 meta-2" *needs* to create the new branches [15:22] jam: I think an additional chk_map would probably work. [15:24] jam: I guess we could make it optional. [15:24]