| SpamapS | 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:00 |
|---|---|---|
| mwhudson | jelmer: if you're still here | 00:16 |
| mwhudson | jelmer: how does bzr-git's GitBranchBuilder avoid the | 00:17 |
| jelmer | mwhudson: I am | 00:17 |
| mwhudson | *** Your name cannot be determined from your system services (gecos). | 00:17 |
| mwhudson | problem? | 00:17 |
| mwhudson | i'm saying | 00:17 |
| mwhudson | run_git( | 00:17 |
| mwhudson | 'commit', '-m', 'dsadas', '--author', 'Joe Foo <joe@foo.com>') | 00:17 |
| mwhudson | and the above message is making me sad :( | 00:17 |
| mwhudson | (run on a test server, it works locally) | 00:18 |
| mwhudson | i guess i can just run git config | 00:19 |
| mwhudson | but it seems pretty ick | 00:19 |
| jelmer | ah | 00:20 |
| jelmer | you might need a ~/.git/config file | 00:20 |
| jelmer | mwhudson: please file a bug, we shouldn't require that to be able to run the testsuite | 00:20 |
| mwhudson | jelmer: it's not your tests that are failing :) | 00:20 |
| jelmer | ah | 00:21 |
| jelmer | mwhudson: I'm not so sure we avoid that | 00:23 |
| jelmer | do we? | 00:23 |
| mwhudson | i can probably find out | 00:23 |
| mwhudson | jelmer: bzr selftest git ? | 00:23 |
| jelmer | mwhudson: yep | 00:23 |
| mwhudson | jelmer: yeah, some tests fail | 00:24 |
| === bac_afk is now known as abc | ||
| === abc is now known as bac | ||
| mwhudson | jelmer: i'll file a bug | 00:26 |
| jelmer | mwhudson: thanks | 00:27 |
| mwhudson | jelmer: https://bugs.edge.launchpad.net/bzr-git/+bug/348238 | 00:29 |
| ubottu | Ubuntu bug 348238 in bzr-git "tests fail if "Your name cannot be determined from your system services (gecos)."" [Undecided,New] | 00:29 |
| skeftomai | hi...is Bazaar the VCS created by Ubuntu and/or the one they use? | 00:58 |
| bob2 | the same company that largely funds ubuntu also supports bzr | 00:59 |
| skeftomai | ah. did Ubuntu create a VCS? | 00:59 |
| lifeless | skeftomai: no, Ubuntu uses bzr | 01:00 |
| skeftomai | ok. that answers my question. thanks | 01:00 |
| lifeless | jam: ping | 01:13 |
| Jimerson | Has anyone here run bazaar on aix? | 01:52 |
| lifeless | Some folk have posted on the list from time to time | 01:53 |
| Jimerson | I've read some of those posts. | 01:53 |
| Jimerson | I'm having issues getting it compiled, and I can't tell if it is a issue with python or bazaar | 01:54 |
| lifeless | Jimerson: pastebin the error, or you could file a bug | 02:00 |
| Jimerson | http://pastebin.com/m7d649346 | 02:02 |
| jam | lifeless: pong | 02:07 |
| jam | Jimerson: it looks like you don't have the compiler that python was compiled with | 02:08 |
| jam | "xlc_r" | 02:08 |
| Jimerson | Thanks guys. | 02:11 |
| Jimerson | Now I have to try and find the compiler :) | 02:11 |
| lifeless | jam: I'mmaking record_iter_changes a generator | 02:11 |
| jam | lifeless: to return what? | 02:13 |
| lifeless | fs hashes | 02:13 |
| lifeless | its that or call tree._observed_sha1 directly, this seemed more accessible for testing/flexibility | 02:14 |
| Jimerson | Thank you guys so much. | 02:16 |
| Jimerson | That resolved my issue. | 02:16 |
| lifeless | cool | 02:19 |
| jam | 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 |
| jam | however, it is obviously an 'iter' sort of interface :) | 02:25 |
| lifeless | right | 02:26 |
| lifeless | anyhow, its done already :P | 02:27 |
| lifeless | 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:27 |
| * igc lunch | 02:32 | |
| Jimerson | 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 |
| bob2 | put them in separate branches | 02:34 |
| bob2 | or don't use your vcs for deployment | 02:35 |
| lifeless | Jimerson: I'm not entirely sure I understand the question | 02:35 |
| Jimerson | For example: | 02:35 |
| Jimerson | In bazaar I want it like /project/version/blah | 02:36 |
| Jimerson | But I just want to export out to the server everything under blah. | 02:36 |
| lifeless | so, bzr export can do that | 02:36 |
| Jimerson | That means I would have to do a full overwrite everytime though correct? | 02:37 |
| lifeless | yes, if you used export | 02:37 |
| lifeless | uhm | 02:37 |
| lifeless | for production deployments a number of folk use 'bzr upload' | 02:38 |
| lifeless | I agree with bob2 though, in bzr you wouldn't normally have project/version as part of your versioned paths | 02:38 |
| lifeless | note that 'bzr init-repo', if you've used that, is *not* related to versioned data, its just a storage area | 02:38 |
| Jimerson | How do people seperate things then, just branch them out? | 02:39 |
| lifeless | Jimerson: well typically they start separate | 02:41 |
| bob2 | you want one branch per project | 02:41 |
| bob2 | and they would start that way - you'd bzr init each individual thing indidividually | 02:41 |
| lifeless | Jimerson: I mean, examine 'version' as part of a tree | 02:41 |
| Jimerson | I get what you are saying. | 02:42 |
| lifeless | 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 |
| Jimerson | I am new to scm, so I am learning. | 02:42 |
| lifeless | likewise project | 02:42 |
| VSpike | Just wondering... for a checkout, should bzr push to the "checkout of" branch ever do anything? | 02:43 |
| Jimerson | 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 |
| Jimerson | bob2, Thank you as well. | 02:44 |
| lifeless | jam: around? | 02:45 |
| lifeless | or poolie | 02:45 |
| lifeless | currently we do housekeeping in commit | 02:45 |
| lifeless | when we implicitly unversion something, to make sure we only unversion the root of a collection of things that all got unversioned | 02:45 |
| lifeless | like if we have a/b and both are missing | 02:46 |
| lifeless | if we don't, then wt.unversion() blows up | 02:46 |
| lifeless | I'd like to change wt.unversion([a-id, b-id]) to just deal IFF b-id is a child of a-id | 02:46 |
| jam | lifeless: so it wouldn't blow up if you did it in reverse, right? (unversion b-id before you unversion a-id) | 02:48 |
| lifeless | yes | 02:48 |
| jam | and the issue is that we are passing in a 'set' | 02:49 |
| lifeless | yes | 02:49 |
| jam | so it doesn't know what order to do things | 02:49 |
| jam | the problem is that you may have a/b/c/d/e | 02:49 |
| jam | and get b-id, then e-id, then a-id, etc | 02:49 |
| lifeless | as the unversion set should be generally small, I think tracking this in unversion is ok, and easier to work with | 02:49 |
| jam | lifeless: so I would think that keeping track of "things not yet unversioned" would be fine | 02:50 |
| jam | and unversion should complain if all the children don't get unversioned | 02:50 |
| jam | or something like that | 02:50 |
| lifeless | well unversion should complain if something provided was never versioned at all | 02:50 |
| lifeless | but sure, we seem agreed that pushing this to unversion is fine | 02:50 |
| jam | lifeless: right, I'm actually saying that unversion should complain if you unversion "a" but *don't* unversion "b" | 02:51 |
| lifeless | jam: I don't think so, its meant to recurse for us | 02:51 |
| lifeless | and I like that | 02:51 |
| jam | 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 |
| jam | say "iter_changes" somehow | 02:52 |
| jam | for the case of "a/b" and "a/c" | 02:52 |
| jam | somehow just saw a and a/b being deleted | 02:52 |
| jam | suddenly the commit doesn't think about 'c' | 02:52 |
| jam | but unversion removes it anyway | 02:52 |
| lifeless | if that bug exists we have it already | 02:53 |
| lifeless | if you do bzr commit a/b and a is deleted, we should just delete b | 02:56 |
| lifeless | care will be needed, I agree | 02:56 |
| jam | 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 |
| lifeless | I'm down to 20 failures | 02:56 |
| lifeless | but we won't remove all of a unless we record a delete of a | 02:57 |
| jam | I feel like it is opening up a hole, that you can catch by saying that the delta must verify itself complete | 02:57 |
| lifeless | 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 |
| jam | I agree, a delta being corrupt is serious, and you are missing a chance to catch it | 02:57 |
| lifeless | jam: unversion is on tree, its not the delta committed to the repository | 02:58 |
| lifeless | jam: I don't quite see the correspondence | 02:58 |
| jam | lifeless: the delta you are committing to the repository *should* match the one that tree is applying to itself | 02:58 |
| lifeless | jam: uhhhh | 02:59 |
| lifeless | jam: may be we're talking about completely different thigns | 02:59 |
| jam | so commit auto-detects missing files | 02:59 |
| jam | and then calls tree.unversion on them | 02:59 |
| jam | to match the fact that it commits the delete to the repo | 02:59 |
| jam | I'm saying that the logic in unversion | 03:00 |
| jam | can check that the logic from commit is matched properly | 03:00 |
| jam | If commit sees that 'a' is missing, commit *better* see that a/b and a/c are missing | 03:00 |
| jam | and thus it can pass all of those to unversion | 03:00 |
| jam | and unversion can double check that it agrees that everything under 'a' was marked removed | 03:01 |
| lifeless | well | 03:01 |
| lifeless | these sets do not have an equality constraint | 03:02 |
| lifeless | already unversioned things | 03:02 |
| lifeless | 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 |
| lifeless | or something | 03:04 |
| poolie | lifeless: hi i'm back | 03:22 |
| poolie | lifeless: so iiuc you're saying | 03:23 |
| poolie | deleting the parent will implicitly remove the childern | 03:24 |
| poolie | children* | 03:24 |
| poolie | but explicitly removing some or all of the children as well will not be an error? | 03:24 |
| poolie | that makes sense to me | 03:24 |
| lifeless | right | 03:24 |
| lifeless | specifically today, unversion[b,a] works, unversion[a,b] doesn't | 03:25 |
| lifeless | I think it should work | 03:25 |
| lifeless | down to 16 errors | 03:32 |
| poolie | agree | 03:33 |
| igc | 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 |
| poolie | thanks igc | 03:43 |
| poolie | ah right | 03:43 |
| igc | poolie: from memory, you were involved in the email thread leading up to it | 03:43 |
| igc | poolie: and it's been sitting there for a month now as most of us are buried in brisbane-core | 03:44 |
| poolie | sure | 03:44 |
| poolie | i read the previous version | 03:44 |
| poolie | i asked for tests and they seem to be there so it should be good to go | 03:44 |
| poolie | thanks for the nudge | 03:44 |
| lifeless | bah | 03:58 |
| lifeless | iter_changes skips over subtrees | 03:58 |
| lifeless | 6 to go | 04:16 |
| poolie | igc: that docs fix does actually work for me even in a new checkout | 04:24 |
| poolie | which is odd | 04:24 |
| poolie | igc, i'm inclined to just send it and see if pqm agrees... | 04:31 |
| igc | poolie: worth a try :-) | 04:38 |
| lifeless | 4 tests left | 04:42 |
| poolie | lifeless: hi? | 04:59 |
| poolie | you fell offline? | 05:00 |
| VSpike | Just wondering... for a checkout, should bzr push to the "checkout of" branch ever do anything? | 05:01 |
| lifeless | poolie: nope | 05:01 |
| lifeless | poolie: still here :) deep hack is all | 05:01 |
| poolie | hm how curious, pidgin shows you as offline | 05:01 |
| lifeless | lies, its all lies! | 05:01 |
| lifeless | so, I have inventory free commits | 05:16 |
| lifeless | -woo- | 05:16 |
| chrispitzer | i'm hitting a problem pushing to a remembered location with bzr. | 05:46 |
| chrispitzer | 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 |
| chrispitzer | any idea what's happening? | 05:47 |
| lifeless | chrispitzer: hmm, are you onwindows perhaps? | 05:48 |
| chrispitzer | nope | 05:49 |
| chrispitzer | dev on ubuntu - pushing to shared hosting. | 05:50 |
| chrispitzer | so I guess i don't know what the shared host is using... it's dreamhost | 05:50 |
| lifeless | is it ftp? | 05:50 |
| lifeless | (sorrry, on a phone call will be high latency | 05:51 |
| chrispitzer | The remembered location is over sftp | 05:51 |
| lifeless | chrispitzer: thats odd | 06:01 |
| lifeless | could be permissions, or a still open file | 06:02 |
| Peng_ | DreamHost used to use NFS. They do something different now; probably just local ext3. Shrug. | 06:03 |
| lifeless | chrispitzer: what bzr version are you using? | 06:03 |
| chrispitzer | how do i check that? | 06:05 |
| Peng_ | chrispitzer: "bzr version" | 06:06 |
| Peng_ | Augh! | 06:08 |
| chrispitzer | 1.6.1 | 06:09 |
| chrispitzer | I just nuked the .bzr folder on the remote server and pushed using --use-existing-directory | 06:09 |
| chrispitzer | so that solves it for now. | 06:10 |
| chrispitzer | *shrug* | 06:11 |
| lifeless | chrispitzer: I suspect this is fixed somewhere around 1.10 or so | 06:14 |
| lifeless | I recall a similar bug report which we fixed | 06:14 |
| Peng_ | What's Andrew Bennetts's nick again? andrew? | 06:14 |
| lifeless | oh, or someone deleted a directory | 06:14 |
| lifeless | Peng_: spiv | 06:14 |
| Peng_ | Oh, duh, right! | 06:14 |
| Peng_ | Thanks. | 06:14 |
| Peng_ | spiv: ping | 06:14 |
| chrispitzer | hm | 06:23 |
| chrispitzer | how so i push a working copy to a remote location? | 06:23 |
| Peng_ | chrispitzer: You could use the bzr-upload plugin. | 06:24 |
| Peng_ | 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:25 |
| chrispitzer | i think I'll need bzr-upload, as the server doesn't have bzr and I don't have control to install it | 06:29 |
| Peng_ | chrispitzer: DreamHost? Why not? You can install it in your homedir if you want to. | 06:32 |
| Peng_ | chrispitzer: I don't recommend it, since procwatch will probably murder it in the middle of large operations, but you *can*. | 06:32 |
| chrispitzer | lol | 06:35 |
| chrispitzer | ug... | 06:38 |
| chrispitzer | bzr upload only allows full uploads, not differential? | 06:38 |
| lifeless | it does incrementak | 06:38 |
| lifeless | but each file is full copied | 06:38 |
| chrispitzer | lol | 06:39 |
| chrispitzer | what's the point of that? | 06:39 |
| chrispitzer | it uploads the file, and if the file's already there it ignores the upload? | 06:39 |
| Peng_ | What's the point of what? | 06:40 |
| chrispitzer | uploading everything, when you're going to discard 90% of what you upload | 06:40 |
| Peng_ | Why are you going to discard 90% of what you upload? | 06:41 |
| spiv | Peng_: pong | 06:41 |
| Peng_ | spiv: Hi! | 06:41 |
| chrispitzer | that's what bzr upload is doing (if I'm reading it correctly) | 06:42 |
| Peng_ | 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:42 |
| spiv | Peng_: possibly both | 06:43 |
| spiv | Peng_: start with filing a bug, though | 06:43 |
| spiv | I'm surprised to hear that case broke, though. | 06:43 |
| Peng_ | :D | 06:43 |
| spiv | In what way did it break? | 06:44 |
| Peng_ | spiv: The server's logs get spammed with "BzrError: jail break: 'chroot-139142476:///repo/", the client gets a similar UnknownErrorFromSmartServer. | 06:45 |
| spiv | That's very odd. That suggests a mismatch between the jail setup and the backing transport on the request handler. | 06:46 |
| poolie | igc, i did that review btw | 06:57 |
| poolie | hullo spiv | 06:57 |
| Peng_ | spiv: Filed bug 348308. | 06:58 |
| ubottu | Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [Undecided,New] https://launchpad.net/bugs/348308 | 06:58 |
| lifeless | chrispitzer: you're reading it wrong :P it uploads only the changed files AFAIK | 06:58 |
| chrispitzer | it uploaded everything the first time, but only incremental since then. | 07:01 |
| chrispitzer | so it's good. | 07:01 |
| chrispitzer | I mean, even the first time the working copy should have matched the remote copy time stamps and all... but oh well. :P | 07:02 |
| lifeless | 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:03 |
| igc | poolie: saw that, thanks | 07:08 |
| vila | hi all | 07:09 |
| lifeless | hi vila | 07:09 |
| poolie | hi vila | 07:10 |
| poolie | it might be nice if we really could deal with full remote working copies | 07:11 |
| poolie | it's possibly possible :) | 07:11 |
| vila | 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 |
| lifeless | poolie: I'm still skeptical but won't stop people doing it:) | 07:14 |
| poolie | oh sometime i'd like to talk to you about whether just adding an indirection file to the dirstate is really enough | 07:15 |
| lifeless | poolie: ok | 07:15 |
| lifeless | poolie: over lunch perhaps :P | 07:15 |
| poolie | as i said in the bug i thought there was a bug in that but imbw | 07:15 |
| lifeless | on my plate is to analyse 'st' updates and then I have enough data for a proposal | 07:15 |
| lifeless | I'll check the bug when I next think aboout that problem | 07:17 |
| lifeless | for now, conversion to current chk is in progress, -> dinner | 07:17 |
| poolie | do you mean analyze the value of updating the hash from st? | 07:17 |
| poolie | cool, good night | 07:17 |
| lifeless | I mean to analyse the potential race conditions of status doing that | 07:19 |
| lifeless | with the alternate design | 07:19 |
| === thekorn_ is now known as thekorn | ||
| igc | hi vila | 08:02 |
| igc | vila: a present for you in the mailing list: my 'log DIR' patch ready for you to reconsider :-) | 08:03 |
| vila | igc: hehe, ok, will look at it | 08:03 |
| igc | vila: that would be awesome - thanks | 08:03 |
| vila | 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:08 |
| igc | vila: Sure do. I'll do that either tonight or tomorrow | 08:13 |
| * igc dinner | 08:13 | |
| vila | igc: thanks, enjoy your dinner :) | 08:13 |
| lifeless | 19K test revisions converted | 08:26 |
| poolie | hi lifeless | 08:49 |
| poolie | i'm about to press send... | 08:49 |
| spiv | lifeless, jml: http://pybites.blogspot.com/2009/03/unittest-now-with-test-skipping-finally.html | 09:54 |
| lifeless | spiv: well, thats good. the total lack of discussion is a bit odd | 10:06 |
| lifeless | or perhaps we were looking in the wrong place? | 10:06 |
| lifeless | also the implementation of class skipping is pretty bong | 10:11 |
| lifeless | wtf doesn't def run() handle that | 10:11 |
| AfC | bong. | 10:16 |
| OllieR | is there a command to find out if a checkout if lightweight or heavyweight? | 11:41 |
| Peng_ | OllieR: "bzr info", I suppose | 11:41 |
| OllieR | Peng_: that gives checkout location info and type | 11:42 |
| OllieR | but doesn't tell me whether it was lw or hw | 11:42 |
| OllieR | annoyingly :( | 11:42 |
| Peng_ | Seriously? | 11:42 |
| Peng_ | Huh! | 11:42 |
| OllieR | yah | 11:42 |
| OllieR | unless it does on a later version i am running Bazaar (bzr) 1.3.1 | 11:42 |
| Peng_ | OllieR: I'm on bzr.dev, and the second line will say either "checkout root" or "light checkout root". | 11:43 |
| Peng_ | (err, third line. The first line of the Location section.) | 11:43 |
| OllieR | Peng_: right yes so it does :) | 11:46 |
| OllieR | Peng_: many thanks | 11:46 |
| Peng_ | :) | 11:46 |
| Mez | Hey there, getting a bit of a weird error. | 12:07 |
| Mez | bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x9e117ac>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request. | 12:07 |
| Peng_ | 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 |
| Mez | 1.12 | 12:08 |
| Peng_ | Mez: Oh. That probably won't help, then. Still, 1.13.1 is out; you should upgrade. :) | 12:09 |
| Peng_ | Mez: Sorry I can't help you... | 12:09 |
| Mez | seems an upgrade to 1.13 worked Peng_ (after running break-lock) | 12:16 |
| Peng_ | Mez: Really? Great. :) | 12:18 |
| lifeless | igc: did you see my commit figures? | 12:27 |
| igc | lifeless: I did. well done | 12:30 |
| igc | lifeless: we just need to sort out the nested trees issue & I'm be very happy | 12:31 |
| igc | re commit in brisbane-core | 12:31 |
| Peng_ | This is a dumb comment, but.. is it just me, or is brisbane-core a scarily large amount of new code? | 12:32 |
| igc | Peng_: it's a scary amount of thought ... | 12:36 |
| igc | the code change themselves aren't huge in volume | 12:36 |
| igc | night all | 12:37 |
| Peng_ | igc: G'night. | 12:37 |
| Peng_ | igc: 12,230 new lines according to diffstat, though they aren't all necessarily very interesting. | 12:39 |
| OllieR | can you get bzr to default to a lightweight checkout? | 12:42 |
| lifeless | 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 |
| lifeless | igc: it would be very useful to know if there are surprises | 12:43 |
| lifeless | igc: there is about 12MB of packs | 12:43 |
| Peng_ | OllieR: I guess you could make "checkout" an alias for "checkout --lightweight". | 12:43 |
| Peng_ | OllieR: I'm not sure how you'd make a heavyweight checkout then.. | 12:43 |
| lifeless | igc: I am wondering if we want to just cherry pick from bbc a lot to do the merge | 12:43 |
| lifeless | Peng_: --no-lightweight | 12:43 |
| Peng_ | lifeless: Oh, okay. | 12:44 |
| Peng_ | lifeless: Cherrypicking's no fun. | 12:44 |
| lifeless | 10% of our total history isn't either :P | 12:44 |
| OllieR | Peng_: yeah not bad thinking | 12:44 |
| OllieR | lifeless: how do you mean --no-lightweight? | 12:45 |
| OllieR | can't see that in any man pages | 12:45 |
| Peng_ | Once everybody upgrades to bbc, that'll only be like 20 KiB, right? So what's the big deal? :D | 12:45 |
| Peng_ | 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 |
| Peng_ | It's only significant because it'll come all at once. | 12:47 |
| * Peng_ gets shot by someone on dial-up | 12:47 | |
| jelmer | Peng_: you can also always do a stacked branch | 12:48 |
| Peng_ | I wonder how large it would be even without history? | 12:50 |
| Peng_ | Sending it to BundleBuggy would be funny. :) | 12:51 |
| james_w | does the new progress ever move to a unit larger than KB? | 12:56 |
| james_w | 130000KB is too many digits for me | 12:57 |
| nilg | hi, is there a tool to print what modifications has been done by who for a given file, thx | 13:22 |
| Peng_ | nilg: "bzr annotate"? | 13:23 |
| nilg | yeah exactly what I wanted Peng_, thanks! | 13:25 |
| Peng_ | :D | 13:26 |
| james_w | vila: hi | 13:36 |
| vila | james_w: hi ! | 13:37 |
| james_w | vila: would adding something like transport.get_transport(for_writing=True) make any sense? | 13:37 |
| james_w | then bubbling that up to things like Branch.open()? | 13:37 |
| james_w | 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:38 |
| vila | 1) I think most commands already use {branch,repo,wt}.open[_containing] so I'm not sure it's the right place | 13:40 |
| vila | 2) You can't always decide from the url only if you will be able to write or not | 13:41 |
| vila | and even if the scheme itself allows writing you may be denied later | 13:41 |
| vila | You're back to the not-logged-in-launchpad error message ? | 13:42 |
| james_w | yeah | 13:42 |
| james_w | I put it there, so I feel responsible that it sucks so much | 13:43 |
| vila | responsible does not imply gulty :) | 13:43 |
| james_w | 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:43 |
| james_w | Branch.open_containing(for_writing=True) or similar | 13:44 |
| james_w | there may be a few cases where they don't know, but that would be acceptable I guess | 13:44 |
| james_w | your point 2 makes sense, but I believe we could at least communicate this to the directory service | 13:44 |
| james_w | the lp: service could then give an error when it needs to | 13:45 |
| vila | How about checking that in the commands themselves via the underlying transport ? | 13:45 |
| vila | or catch the exception and rephrase it if needed ? | 13:46 |
| vila | :-/ | 13:46 |
| james_w | checking was my first attempt, but the way that I did it was vetoed | 13:49 |
| james_w | 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 |
| james_w | plus that gives no way for the lp: service to suggest lp-login | 13:49 |
| jam | james_w: I think we would consider a "Branch.open_locked(for_write=True)" or "Branch.open_write_locked()" | 14:03 |
| jam | We've talked about it on the list | 14:03 |
| jam | as a way to get around the current open + lock as a standard function | 14:03 |
| jam | also, some internals tend to lock objects, and then unlock them to return them | 14:03 |
| jam | which then gets locked right away | 14:04 |
| james_w | that sounds sensible | 14:05 |
| james_w | would passing that information down to the transport layer be ok? | 14:05 |
| james_w | most things wouldn't use it I imagine | 14:05 |
| james_w | or perhaps I misunderstood at what layer the directory services operate | 14:06 |
| abentley | james_w: It is a lookup that is performed by get_transport. Transports themselves don't use it. | 14:11 |
| abentley | james_w: So I think pushing it down there would be fine. | 14:11 |
| rocky | jelmer: is svn-push still required to setup a new branch folder with bzr 1.13 and related bzr-svn ? | 14:11 |
| abentley | jam: +1000 on a method for opening locked branches. | 14:12 |
| jelmer | rocky: yeah | 14:13 |
| jelmer | rocky: I have a patch for bzr.dev that allows it to integrate into "bzr push", but it hasn't landed yet | 14:13 |
| jelmer | whoa, when did "bzr branch --stacked" get so freakishly quick? | 14:15 |
| jelmer | checkout out bzr.dev takes just 7 wallseconds | 14:16 |
| Peng_ | jelmer: http://bazaar-vcs.org/bzr/ was upgraded to btrees recently; maybe that's why? | 14:16 |
| jelmer | Peng_: yeah, I guess that'd explain it | 14:17 |
| rocky | jelmer: hrm, my svn-push is hanging :/ | 14:23 |
| Peng_ | rocky: Hanging or doing a lot of work very inefficiently? :D | 14:25 |
| rocky | hehe it's hard to tell the difference when it doesn't end ;) | 14:29 |
| brink_ | 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:32 |
| jelmer | brink_: :-) | 14:55 |
| gnomefreak | can i push a branch using sftp? | 15:01 |
| james_w | yep | 15:02 |
| gnomefreak | james_w: thanks | 15:02 |
| jam | 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 |
| jam | which made a big difference for the python 'branch --stacked' I was testing | 15:08 |
| jam | (rather than requesting the content for each file separately) | 15:08 |
| abentley | 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:19 |
| jam | abentley: it wouldn't be terribly hard to add another "chk_map" or similar to the disk format for brisbane-core | 15:20 |
| jam | and bring it in before we merge it to stable | 15:20 |
| jam | (we have a few more days, at least) | 15:20 |
| jam | otherwise, if you feel it isn't possible to do efficently without a disk format bump | 15:21 |
| jam | 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 | |
| jam | I'm wondering, for example, if "bzr branch meta-1 meta-2" *needs* to create the new branches | 15:21 |
| abentley | jam: I think an additional chk_map would probably work. | 15:22 |
| abentley | jam: I guess we could make it optional. | 15:24 |
| jam | abentley: I would sort of like if the top level "inventory" record could know whether there was actually any entries, and could store a "NULL" reference, separate from a genuine sha1 reference | 15:24 |
| jam | otherwise, I guess you just get the same null-sha1 everywhere | 15:25 |
| jam | which isn't terrible | 15:25 |
| abentley | jam: The idea is that nested behaviour should match non-nested behavior as much as possible. | 15:25 |
| abentley | jam: not sure what you mean. Are you talking about the chk map? | 15:25 |
| jam | abentley: we still have an inventory text, which points out the file-id for the root of the tree, the root node in the id_to_entry map, and the root node in the parent_id_basename_to_file_id map | 15:26 |
| jam | I assume we would add a root key for the "tree_reference" map | 15:26 |
| abentley | jam: That seems like a sane optimization. | 15:26 |
| jam | I'm just offering that it should probably consider having a "tree_reference: NULL" entry | 15:27 |
| jam | when we don't have any actual references | 15:27 |
| jam | it isn't a big deal | 15:27 |
| jam | but it means avoiding paging in an empty page | 15:27 |
| abentley | jam: so about nested matching non-nested behavior: if you branch from foo, you have a new line of development for all files in foo. If you branch from bar, and bar contains baz, it makes sense that you have a new line of development for all files in baz. | 15:29 |
| abentley | Whether baz is a tree reference or a directory. | 15:30 |
| abentley | jam: We're probably also going to want some more sophisticated branch/checkout operation that knows some trees should be checkouts and some should be branches. | 15:31 |
| abentley | jam: based on user configuration. | 15:32 |
| jam | abentley: my argument is that there are a lot of ways it could be done, I would also venture that in the most common case, you *don't* want new branches for *all* of the sub projects | 15:33 |
| jam | I understand your arguments, and it comes down to the "implementor" gets to decide | 15:33 |
| jam | I'm just thinking that if the only use case that *has* to have the index, is "bzr branch" in a shared treeless repository | 15:35 |
| jam | (all other cases being ones where we are already walking the inventory) | 15:36 |
| jam | then maybe we need to re-think that use case | 15:36 |
| abentley | jam: I would venture that you want at least two new branches in the common case: one for the top-level directory holding the project and all its libraries, and one for the project source code itself. | 15:36 |
| gioele | hello | 15:36 |
| gioele | is the bzr package on PPAs based on 1.13 or 1.13.1? | 15:36 |
| abentley | jam: That's the only one we've found so far, but I haven't looked around at the others yet. | 15:37 |
| jam | gioele: I would guess the ppa hasn't been updated yet, as it should be "1.13.1-X" | 15:39 |
| jam | johnf is the one who has been building them, but I haven't seen him around | 15:39 |
| jam | then again, maybe he used -2 rather than going .1-1 | 15:41 |
| jam | which would be incorrect, but possible | 15:41 |
| gioele | jam: I see | 15:43 |
| abentley | jam: At a glance, everything else could be redesigned to not use iter_references, not that this would be especially easy. | 15:43 |
| jam | gioele: if you install it, you can always do "bzr --version" to find out :) | 15:43 |
| jam | abentley: sure, like I mentioned in the post with Robert, the layering gets a bit tricky for stuff like "commit" | 15:45 |
| jam | though I think having iter_changes always return tree references | 15:45 |
| jam | because we don't *know* whether they have changed or not | 15:45 |
| jam | is a reasonable change | 15:45 |
| abentley | jam: it depends on what you mean by changed. We don't know if the subtree is changed, but the tree reference is only changed if its revision doesn't match the last_revision. | 15:46 |
| jam | abentley: but we don't know if its revision would match last_revision unless we've checked that the subtree has/hasn't changed | 15:47 |
| jam | consider what "diff" really cares about when it wants to recurse | 15:47 |
| jam | Arguably iter_changes in revision trees could chop off that entire subtree | 15:47 |
| abentley | jam: The subtree will commonly change without its last_revision changing. | 15:48 |
| jam | but workingtrees seem like they should always recurse | 15:48 |
| jam | abentley: ..... | 15:48 |
| jam | then when you commit | 15:48 |
| jam | it doesn't record a new reference | 15:48 |
| jam | so that checkout | 15:48 |
| jam | gives you the new subtree? | 15:48 |
| jam | I thought the "content" for a tree-reference was the last-committed revision of the subtree | 15:48 |
| jam | not the last-modified revision of the tree root | 15:48 |
| abentley | jam: last-modified revision of the *subtree* root? | 15:49 |
| jam | right | 15:49 |
| jam | sorry | 15:49 |
| jam | It should be the Tree.get_revision_id() not Tree.inventory.root.revision | 15:50 |
| abentley | jam: Correct. | 15:50 |
| jam | abentley: which means that if the subtree content changes | 15:50 |
| jam | then it's Tree.get_revision_id() should change | 15:50 |
| jam | possibly being "None" to indicate it doesn't know what it will be | 15:50 |
| jam | yte | 15:51 |
| jam | yet | 15:51 |
| abentley | jam: only if there's a commit. | 15:51 |
| jam | abentley: I would argue that it should be None if there are changes and no commit | 15:51 |
| jam | such that "bzr commit --no-recurse" would then know to record the last value | 15:51 |
| jam | but "bzr commit" and "bzr diff" would both know that there are changes to be checked | 15:51 |
| abentley | jam: I don't think so. | 15:51 |
| jam | abentley: what do you gain by having a value that is "not quite correct" ? | 15:52 |
| abentley | jam: The value is entirely correct. | 15:52 |
| jam | (the content of the tree that is referenced, does not match exactly the content that the revision_id describes) | 15:52 |
| abentley | It's defined to be whatever the last_revision in the subtree was at the time when the last commit in the parent tree happened. | 15:53 |
| abentley | If there are no commits to the subtree, it's unchanged. | 15:53 |
| jam | abentley: that is the "basis_revision_id" | 15:53 |
| jam | which I think we sort of get confused with "revision_id" | 15:53 |
| jam | because WT.last_revision() and RevisionTree.last_revision() both return something | 15:53 |
| jam | but it doesn't actually have the same meaning | 15:53 |
| abentley | jam: No, it's MutableTree.last_revision | 15:54 |
| jam | abentley: so if you compare the current WT versus its basis, the fact that the tree reference points at the old value is sort-of wrong | 15:54 |
| abentley | jam: I was not aware that RT had a last_revision | 15:54 |
| jam | because it would indicate that there are no changes in the subtree | 15:55 |
| jam | when there are | 15:55 |
| abentley | jam: You are assigning a meaning to the tree reference that I am not assigning to it. | 15:55 |
| jam | abentley: And I'm wondering why have a value there that doesn't have meaning | 15:55 |
| jam | if you can't use it to check for equality | 15:55 |
| jam | then you may as well use None | 15:55 |
| abentley | jam: My mistake, for a WT the value of the tree reference should always be the subtree's WT.last_revision | 15:58 |
| jam | abentley: you still can't use it as an equality check | 15:58 |
| jam | and it still seems like it should be None | 15:58 |
| jam | just like the last-modified-revision for all files/dirs in the WT | 15:58 |
| abentley | jam: You can then compare it to the basis one and decide whether to commit the entry. | 15:58 |
| abentley | jam: I think it's more like get_file_sha1. | 15:59 |
| jam | abentley: but without scanning the subtree, you don't know if there are any modifications | 15:59 |
| jam | I suppose "bzr commit --no-recurse" could use it | 15:59 |
| abentley | jam: and neither do I care if there are uncommitted modifications in the subtree. | 15:59 |
| jam | abentley: commit and diff both care, don't they? | 15:59 |
| jam | as in "bzr diff" in the parent project | 15:59 |
| jam | should tell you there are changes in the child | 15:59 |
| jam | even if you haven't committed | 16:00 |
| jam | Or are "commit" and "diff" not fully recursive? | 16:00 |
| abentley | jam: Sure they do. | 16:00 |
| abentley | jam: They don't use iter changes that way, though. | 16:00 |
| jam | abentley: I'm arguing that they should... | 16:00 |
| jam | as it means you don't need iter_references() | 16:01 |
| abentley | jam: At the cost of damaging the clarity of iter_changes futher. | 16:01 |
| abentley | jam: If you're going to do recursion via iter_changes, you might as well just recurse in iter_changes itself. | 16:02 |
| abentley | That way, you don't have to emit unmodified entries. | 16:02 |
| jam | abentley: except 'commit' needs to start a new commit process in the subtree | 16:03 |
| jam | since it won't share the revision_id, etc of the containing tree | 16:03 |
| abentley | jam: commit can figure out that the containing tree doesn't own the file and start a new commit process. | 16:04 |
| jam | abentley: that seems far more expensive | 16:04 |
| jam | I think there should be room for a WT.iter_changes() that can return objects that may-or-may not have changed | 16:04 |
| jam | so that we don't have to verify that things have definitely changed | 16:04 |
| jam | until commit has finished | 16:05 |
| jam | (to avoid double-sha, etc) | 16:05 |
| abentley | jam: I don't know how expensive it would be, but it doesn't seem like it has to be expensive. | 16:06 |
| jam | abentley: checking that every record is in the containing tree means you have to check every file, and recurse up to its root | 16:06 |
| jam | abentley: at a minimum, it is an extra check on every object | 16:06 |
| jam | rather than having it handed to you | 16:06 |
| jam | since it already knows it | 16:06 |
| jam | when we hit a tree-reference, we *know* we are at the boundary | 16:07 |
| jam | we don't have to check every modified file to see if it "really is" in this tree | 16:07 |
| jam | (the check isn't very expensive, but it is still a check on all files, and even whether you have tree references or not | 16:07 |
| jam | because there *might* be a tree reference) | 16:07 |
| abentley | jam: Don't we already look up the record for each modified file anyway? And wouldn't that automatically fail? | 16:09 |
| jam | abentley: perhaps, though you then need to go figure out which subtree it was really in, etc. | 16:10 |
| jam | it still seems far cleaner to have it done with commit getting a tree-reference | 16:11 |
| jam | not that it isn't possible to do either way, just cleaner | 16:11 |
| jam | again, whoever is willing to write the code gets the final say | 16:12 |
| jam | I'm just describing my viewpoint | 16:12 |
| abentley | Yeah, and I disagree about all of this being cleaner. | 16:13 |
| jam | abentley: consider that the file_id may not be present, because it was an added file | 16:13 |
| abentley | jam: what happens when you implement iter_changes betweeen two CHK trees? | 16:13 |
| jam | abentley: we have one, but it doesn't support subtrees | 16:14 |
| jam | because the behavior is still pretty "undefined" | 16:14 |
| jam | also, note that WT versus basis | 16:14 |
| jam | is *very* different from RevisionTree to RevisionTree | 16:14 |
| jam | and will always be so | 16:14 |
| jam | as you have to probe the content on WT | 16:14 |
| jam | and you *don't* on RevisionTrees | 16:14 |
| jam | and you also don't try to *commit* | 16:15 |
| abentley | It just seems that it's hard to emit the tree reference in that case unless it has changed. | 16:15 |
| jam | the results of RT.iter_changes(RT) | 16:15 |
| jam | abentley: I generally, agree, my main argument is that for WT.iter_changes() we don't *know* without recursing if the subtree has changed | 16:15 |
| jam | separate from RT.iter_changes(RT) | 16:15 |
| jam | abentley: I suppose I would agree that RT.iter_changes(RT) doesn't return tree references that haven't changed | 16:16 |
| abentley | jam: They're supposed to have the same behaviour, given the same options. | 16:16 |
| jam | but WT.iter_changes(WT.basis_tree()) doesn't know | 16:16 |
| jam | and *should* return something | 16:16 |
| jam | either that, or it has to recurse into the subtree, wait for it to return whether it has changed or not | 16:16 |
| jam | and then use that to decide the last-modified of this tree | 16:17 |
| jam | entry | 16:17 |
| jam | and then finish scanning | 16:17 |
| jam | that would be okay | 16:17 |
| jam | as it would then emit records for subtrees that really have changed | 16:17 |
| jam | which is what commit cares about | 16:17 |
| abentley | jam: I don't think last-modified enters into it. | 16:17 |
| abentley | jam: are you thinking of reference_revision? | 16:18 |
| jam | possibly, I'm not 100% sure what values go where | 16:19 |
| jam | the point is that WT.iter_changes(basis) needs to actually scan, and can't rely on a cached value | 16:19 |
| phinze | is it considered "bad form" to commit code to a downstream shared branch that really belongs in the central main branch? i'm working on a feature that belongs in our trunk shared branch, but currently it has only one use case in the shared project branch i'm on... so i've been essentially shelving and unshelving to make sure that the code that belongs in trunk doesn't make it into the project branch | 16:19 |
| phinze | my question is whether or not this is unnecessary and i should just commit it and pull it upstream when i'm ready? | 16:20 |
| abentley | phinze: I'd be inclined to commit it into a separate branch, just to reduce the hassle. | 16:21 |
| vila | phinze: I think you answered yourself, commit in branches with clear definition, create as many as you need and then merge them when you're ready | 16:21 |
| phinze | yeah i suppose i'm only running into this because in this particular case i've neglected to use a task branch | 16:21 |
| vila | phinze: see, you knew :) | 16:21 |
| abentley | phinze: The loom plugin gives a way to automate this more. | 16:21 |
| abentley | jam: Well, iter_changes doesn't emit either, so it's just a question of whether to set the modified boolean. | 16:22 |
| phinze | okay so assuming i have a task branch were all changes belong in project branch "bar" but changes to file "dir/qux" belong in trunk | 16:22 |
| phinze | i would just merge everything into bar and then from trunk merge ../foo/dir/qux? | 16:23 |
| phinze | ooop | 16:23 |
| jam | phinze: I'll often split things out to go into a separate feature of trunk, commit it, get it merged to trunk, and then bring it back into my project branch | 16:23 |
| phinze | that should be ../bar/dir/qux in my example | 16:24 |
| === beuno_ is now known as beuno | ||
| phinze | jam: like this?: bzr branch trunk trunk-feature; cd trunk-feature; bzr merge ../bar-feature/dir/qux; bzr ci -m "Merging trunk feature from bar task branch"; cd ../trunk; bzr merge ../trunk-feature; bzr ci -m "Adding trunk feature"; cd ../bar; bzr merge ../trunk; bzr ci -m "Merging trunk into bar"; bzr merge ../bar-feature; bzr ci -m "Merging bar feature that happens to have trunk feature that I already merged from upstream" | 16:27 |
| phinze | perhaps i should have pastebinned that... :\ | 16:27 |
| phinze | jam: http://pastie.org/426694 | 16:29 |
| rocky | bah i hate it that in emacs shell the status tty stuff doesn't work very well with bzr | 16:29 |
| phinze | bbl | 16:30 |
| jelmer | rocky: did your svn-push finish? | 16:30 |
| rocky | jelmer: it didn't but i cancelled it, i'm trying again right now | 16:31 |
| rocky | outside of emacs ;) | 16:31 |
| rocky | it's doing something but the status message is "discovering revprop revisions 609/" | 16:31 |
| jelmer | jam: hi | 16:33 |
| rocky | so far it says 10285kB @ 30kB/s ... whatever that means | 16:33 |
| jelmer | rocky: well, that's the amount of data it's transferred from the remote server | 16:34 |
| rocky | from or to? | 16:34 |
| jelmer | rocky: both, subversion doesn't distinguish when reporting data transfer | 16:34 |
| rocky | it occurs to me that there is a lot of content to upload so perhaps that's the issue here | 16:35 |
| jelmer | rocky: this all happens before the actual pushing | 16:35 |
| jelmer | rocky: it's just checking which revisions you have in your bzr repo already exist in the svn repo | 16:35 |
| Mez | how do I get rid of | 16:35 |
| Mez | No handlers could be found for logger "bzr" | 16:35 |
| Peng_ | Mez: Context? Where is this happening? | 16:36 |
| beuno | Mez, try removing bzrtools | 16:41 |
| beuno | and see if it still happens | 16:41 |
| beuno | what version of bzr are you using? | 16:41 |
| Mez | Peng_: any action with bzr | 16:42 |
| Mez | using 1.13 | 16:42 |
| Mez | removing bzrtools makes no difference | 16:43 |
| Peng_ | Mez: Oooh. I don't know. Do you have permissions to write to ~/.bzr.log? | 16:43 |
| Peng_ | Mez: Do you have the environment variable BZR_LOG set? | 16:44 |
| Mez | ah...-rw-r--r-- 1 root root 66911 2009-03-25 16:42 /home/mez/.bzr.log | 16:44 |
| Peng_ | Mez: Better, "bzr version" will show where it puts the log file. -- but you've already got it. | 16:44 |
| Mez | that resolved it (chown) | 16:45 |
| Peng_ | :) | 16:45 |
| Peng_ | Maybe bzr should warn if the log setup fails. | 16:45 |
| === Toksyury1l is now known as Toksyuryel | ||
| jam | jelmer, phinze: sorry I didn't get back to you yet, I had a phone call, and I'm going to eat lunch real quick, bb ~30min | 17:06 |
| jam | phinze: my guess is that doing "bzr merge ../bar-feature/dir/qux" is going to actually be a "cherrpick" because you aren't merging all of the changes from that branch. | 17:30 |
| jam | However, it otherwise looks correct. | 17:31 |
| jam | I might do it as... | 17:31 |
| jelmer | jam: I was wondering if a combination of your two suggested solutions for subtree performance handling in bbc would work | 17:31 |
| jam | phinze: nm, I saw that you were merging trunk back into bar, which is what I was about to mention | 17:32 |
| jam | jelmer: there are certainly lots of possibilities. There is also the "we would like to have bbc in core by the end of this week" | 17:33 |
| jam | so it is part of the rc1 next week | 17:33 |
| jelmer | oh | 17:33 |
| jelmer | I wasn't aware that was the plan :-) | 17:33 |
| jam | so what is our immediate goal | 17:33 |
| jam | and what will we get done later | 17:33 |
| jelmer | not that I'm complaining ;-) | 17:33 |
| jam | can we get subtree performance to not be an immediate regression such that it would block bbc | 17:34 |
| jelmer | jam: in that case the "subtrees known broken" one seems most reasonable to me | 17:34 |
| jam | jelmer: though if "known broken" is the case, and we know we need a disk format bump | 17:34 |
| jam | then we may as well continue to leave them broken | 17:34 |
| jam | sorry | 17:34 |
| jam | disabled completely | 17:34 |
| jam | and expect there to be a --dev6 before we make them an official format | 17:34 |
| jam | so the discussion was about seeing if we reall need a --dev6 | 17:35 |
| jam | or whether the current structures are enough | 17:35 |
| jelmer | ahh | 17:35 |
| jam | The current structures are enough for all cases but 1 | 17:35 |
| jam | well 'hypothetically given enough coding" enough | 17:35 |
| jam | and that 1 case could be written to happen differently | 17:35 |
| jam | but if that is seen as a bad route to what we want ultimately | 17:36 |
| jelmer | jam: but leavning them broken would mean people don't need to upgrade to a new inventory file format | 17:38 |
| jelmer | jam: when they start becoming supported | 17:38 |
| jam | jelmer: right, but if we need new data on disk | 17:39 |
| jam | they have to upgrade *anyway* | 17:39 |
| jam | so why allow them to shoot themselves in the foot with the current format | 17:39 |
| jelmer | jam: we'd just have to do a (cheap) upgrade to a format that had that index | 17:39 |
| jam | jelmer: sure, but why wouldn't the rest of it also be cheap? | 17:39 |
| brink_ | Starting to think rename determination should be automatic. Now that I've played around with it enough I realize that it makes integration, refactoring, etc., work much better. | 17:40 |
| jelmer | jam: aren't upgrades that involve inventory rewriting expensive? | 17:41 |
| jam | jelmer: it depends on how much of the inventory you have to rewrite | 17:42 |
| jam | XML inventories have a single text for everything | 17:42 |
| jam | so you have to rewrite MB of data | 17:42 |
| jam | If it is just changing a format value in the top level node | 17:42 |
| jam | that is pretty cheap | 17:43 |
| jam | Anyway, I don't have a problem having a serializer that can include "tree-reference" in the stream | 17:43 |
| jam | and just set the flag "supports_subtree = False" in the RepositoryFormat | 17:43 |
| jam | And possibly add a bit in the serializer to have it check that it really-doesn't-yet have 'tree-reference' written. | 17:43 |
| jelmer | jam: ah, I hadn't considered the fact that bbc's inventory format is faster to write deltas for | 17:46 |
| jelmer | jam: thanks for the explanation of all of this | 17:47 |
| jam | jelmer: out of curiosity, how does subversion handle commits with svn:external? | 17:47 |
| jam | Is it not possible to have an atomic update? | 17:48 |
| Peng_ | So would bbc make going from plain to rich roots cheap as well? | 17:48 |
| jam | Peng_:bbc is rich-root only | 17:48 |
| jam | at least, that is the plan | 17:48 |
| jam | we may back down | 17:48 |
| Peng_ | jam: Sure, but if it wasn't, would it be? | 17:48 |
| jam | Peng_: converting a CHK-plain => CHK-rich-root should be *much* cheaper than it is today, yes | 17:48 |
| jam | as it is writing 2 pages | 17:49 |
| jam | (affected page, and root) | 17:49 |
| jelmer | jam: externals are a bit of a hack | 17:49 |
| Peng_ | How cheap? Like, "bzr pack" cheap or "instant" cheap? | 17:49 |
| jelmer | jam: basically it will run "svn commit" in all underlying trees as far as I know | 17:49 |
| jam | Peng_: well, you'd probably want to do a "pack" afterwards anyway... | 17:49 |
| jam | but that is 10-20min cheap, not 48hours | 17:49 |
| jam | for the MySQL repo | 17:50 |
| Peng_ | 48 hours? Woah. | 17:50 |
| jam | "bzr pack" on bzr.dev takes approx 2 minutes in bbc | 17:50 |
| jam | and recompresses all the texts | 17:50 |
| jelmer | jam: externals are a bit like config-manager, in that they point at a URL that's to be checked out | 17:50 |
| jam | jelmer: I thought it could also refer to an exact revision | 17:50 |
| jam | possibly URL@revnum | 17:50 |
| jelmer | jam: but it's possible to not reference a specific revision, and if you reference a specific revision, you have to write that into the externals property yourself AFAIK | 17:51 |
| jam | jelmer: so you could "guess" at the right revnum | 17:51 |
| jam | but in the end you could be wrong | 17:51 |
| jam | jelmer: I also thought with svn there was a way to say "i'm starting a commit, when I'm ready to finish, if the revnum doesn't match what I thought it would, abort and start over" | 17:52 |
| jelmer | jam: yeah, in the case of a two-phase commit there could be some other person committing in between the first and the second commit | 17:52 |
| jelmer | *first and second phase | 17:52 |
| jelmer | jam: that's only for the base revision | 17:53 |
| jelmer | jam: so if you open /trunk for committing when the last revision is 3 | 17:54 |
| jelmer | then somebody else could be committing revision 4 in /branches/foo and you wouldn't get an error | 17:54 |
| === beuno_ is now known as beuno | ||
| === cprov-afk is now known as cprov | ||
| === beuno_ is now known as beuno | ||
| === beuno_ is now known as beuno | ||
| === mario_ is now known as pygi | ||
| chrish1 | Hello. I've been reading the bazaar workflows documentation, and I've noticed something that puzzles me. In the "Decentralized with human gatekeeper version", Bundle Buggy is given as an example. Then at the end in the notes, it says "The Bazaar developers use Decentralized with automatic gatekeeper to develop Bazaar itself." And from what I understood from reading the mailing list, Bazaar uses Bundle Buggy | 20:11 |
| chrish1 | for its development. So, one of these three statements has got to be wrong, no? Which one is it? | 20:11 |
| chrish1 | Can Bundle Buggy also do "automatic gatekeeper" (run a testsuite before commit, etc.)? | 20:11 |
| Peng_ | chrish1: Bundle Buggy is used for reviews. PQM is used as the gatekeeper. | 20:11 |
| LarstiQ | chrish1: the human gatekeeper needs to track what to merge, the Bazaar developers need to track what to review (with bundlebuggy) | 20:12 |
| LarstiQ | hi davidstrauss | 20:13 |
| chrish1 | Oh. So when the merge request is approved via Bundle Buggy, it forwards that to PQM to be merged into the trunk? | 20:13 |
| davidstrauss | LarstiQ: hi | 20:13 |
| Peng_ | chrish1: No, when it's approved via BB, someone manually sends it to PQM. | 20:14 |
| chrish1 | Oh. So there's no need for any integration between the two. If I want to duplicate that setup, I just install Bundle Buggy and PQM separately, and forward manually between the two. That clarifies it, thanks! | 20:16 |
| LarstiQ | chrish1: I guess you could make bundlebuggy submit requests to PQM, I think we like to keep some human judgement in the loop still. | 20:17 |
| LarstiQ | but maybe it can be smoothened | 20:17 |
| chrish1 | I guess it's just a single command to submit a change to PQM once it's been accepted at review? | 20:19 |
| LarstiQ | chrish1: hmm, you ask PQM to merge a branch, maybe you could point it at BB. That might not actually be mergeable depending on the state of trunk, hmm. | 20:21 |
| LarstiQ | chrish1: try it! :) | 20:21 |
| chrish1 | Will try it when the project has started to get off the ground (when there's a testsuite, etc.). Btw, what's the best place to suggest a clarification to the bazaar-vcs.org web site content? (For what confused me in the Workflows page.) | 20:25 |
| LarstiQ | chrish1: if you're confident about the change, editing the wiki. | 20:26 |
| LarstiQ | chrish1: if not, the list or maybe here if it's something I could apply immediatly | 20:27 |
| chrish1 | I just want to suggest adding something like "(using Bundle Buggy for patch reviews and PQM to manage the trunk.)" after the "The Bazaar developers use Decentralized with automatic gatekeeper to develop Bazaar itself." sentence. Would have clarified things for me. | 20:29 |
| LarstiQ | chrish1: sure, I can do that | 20:36 |
| LarstiQ | chrish1: especially since I realise that documentation is not on the wiki :) | 20:38 |
| chrish1 | Thanks! | 20:39 |
| LarstiQ | chrish1: could you point me at the exact url/section you had in mind? | 20:40 |
| poolie | chrish1: you should also look at launchpad.net/tarmac | 20:40 |
| poolie | which is meant to read review results and then test and merge automatically | 20:41 |
| chrish1 | LarstiQ: http://bazaar-vcs.org/Workflows (go to the end, the "Notes" section, etc.) Basically clarifying what I didn't understand before asking here... | 20:42 |
| LarstiQ | chrish1: thanks | 20:43 |
| LarstiQ | chrish1: so I was mislead by similar sections existing in the user guide, this _is_ the wiki afterall. | 20:44 |
| * LarstiQ edits | 20:44 | |
| chrish1 | poolie: Wow. Looks cool. Thanks for the pointer! Is it already at a stage where it's usable, or should I wait some more before giving it a shot? | 20:46 |
| abentley | jam: Can you clarify: iter_references is slow on a RevisionTree? | 20:47 |
| jam | abentley: yes | 20:47 |
| abentley | jam: Even though it's an all-memory operation? | 20:48 |
| LarstiQ | chrish1: edited. | 20:48 |
| jam | abentley: it is all memory for XML trees, it isn't for CHK, but regardless it is an O(tree) operation | 20:50 |
| jam | so 'slow' is a bit relative | 20:50 |
| chrish1 | LarstiQ: Saw it, cool. Nice to see the quick turnaround time for clarifications to the documentation. :-) | 20:50 |
| jam | it is only slightly fast for XML RevisionTrees because we already paid the cost of deserializing every entry | 20:51 |
| LarstiQ | chrish1: it helps that you had a clear request :) | 20:51 |
| LarstiQ | chrish1: so thank you for the feedback. | 20:51 |
| chrish1 | LarstiQ: Thanks. Will come back and visit (and hopefully have clear requests) if there's something I find unclear again. | 20:52 |
| fullermd | Does tortoise have an interface to 'revert'? | 20:53 |
| LarstiQ | chrish1: cool. I haven't set up PQM myself, but am here to help regardeless. | 20:53 |
| LarstiQ | fullermd: hmm, it should. | 20:53 |
| * fullermd is on a conference call. | 20:54 | |
| * LarstiQ looks at the code | 20:54 | |
| LarstiQ | fullermd: it has a call to qrevert, so I'd wager yes. | 20:58 |
| fullermd | I couldn't guess how to get at it, and he couldn't find it... | 20:59 |
| LarstiQ | I can't actually test fully without windows here. | 21:02 |
| LarstiQ | but: gettext("Re&vert..."), gettext("Revert local changes"), | 21:02 |
| LarstiQ | if that's not showing up in the context menu, I don't know how it works | 21:02 |
| fullermd | Well, we ended up using the obvious and trivial workaround of making a new checkout of the whole tree at a given revision and copying the files. | 21:02 |
| * fullermd is sure that was good PR. | 21:02 | |
| LarstiQ | fullermd: :/ | 21:03 |
| jelmer | lifeless: hi | 22:03 |
| lifeless | hi | 22:06 |
| Peng_ | Who thought of stacked branches? They're a really great idea. :) | 22:10 |
| jelmer | lifeless: You did some research before choosing a db format for bzr-search right? | 22:11 |
| jelmer | lifeless: I'm trying to decide what bzr-svn should use instead of sqlite | 22:11 |
| jelmer | lifeless: the main things I'm looking for are simple search keys (integers or strings), append-only, multiple concurrent writers/readers, preferably widely available (ideal would be included with bzr/python by default) | 22:12 |
| * mwhudson would also be interested in such a thing for loggerhead/revnocache | 22:13 | |
| Peng_ | Doesn't bzr-search just use bzr indexes...? | 22:15 |
| jelmer | Peng_: it uses an additional index | 22:15 |
| Peng_ | jelmer: Yeah. And the format is just a GraphIndex or btree index. | 22:15 |
| jelmer | ah, crap | 22:16 |
| mwhudson | jelmer: what's the problem with sqlite? the writers-block-readers thing? | 22:18 |
| jelmer | mwhudson: yeah | 22:19 |
| lifeless | jelmer: yes, I did | 22:33 |
| lifeless | jelmer: gimme 30 to grab food and stuff, and I'll chat about this with you | 22:34 |
| jelmer | lifeless: thanks! | 22:39 |
| lifeless | jelmer: so | 23:16 |
| lifeless | jelmer: I researched search engines first | 23:16 |
| lifeless | jelmer: with a requirement that they be able to work over ftp etc [ideally by hooking into the python transports of bzr] | 23:17 |
| lifeless | non-starters, or at least 'much work needed' | 23:17 |
| lifeless | for various reasons | 23:17 |
| lifeless | jelmer: I ended up writing my own search engine; and yes I based it on bzr's B+Tree indices which are pretty good and have nice characteristics like write-once | 23:18 |
| lifeless | jelmer: bzr-search builds a similar infrastructure to packs to get multiple writer multiple readers safely | 23:20 |
| spiv | I just had a spam that started with "Jam with your bundle!". No wonder it got past my spam filter... | 23:22 |
| lifeless | spiv: 1:30 is definitely fine | 23:22 |
| spiv | lifeless: cool | 23:22 |
| jelmer | lifeless: hmm | 23:23 |
| lifeless | jelmer: and I have a small project aiming to replace bzr searches storage guts with a general purpose thing it could reuse | 23:24 |
| lifeless | I'm feeling my way around the domain/needed heuristics at the moment | 23:25 |
| lifeless | jelmer: if you need to replace the value of keys its a little more tricky than bzr-search or repositories support | 23:26 |
| lifeless | do you need to do that? | 23:26 |
| jelmer | lifeless: no, it's read-only | 23:27 |
| jelmer | s/read/append/ | 23:27 |
| lifeless | jelmer: k | 23:28 |
| jelmer | basically there are three kinds of information in the cache: | 23:28 |
| jelmer | - a copy of "svn log -v" on the root of the repository (incrementally updated whenever new revisions appear in the svn repo) | 23:28 |
| jelmer | - a table mapping bzr revision ids to svn revno/path tuples | 23:29 |
| jelmer | - a table with basic bzr metadata about each round-tripped revision | 23:30 |
| lifeless | right | 23:35 |
| lifeless | so bzr-search's approach would work fine for you, I think | 23:35 |
| lifeless | as my generic thing isn't fit to show yet :) - its basically: | 23:36 |
| lifeless | have a collection of packs with a names list (crib this from bzr-search) | 23:36 |
| lifeless | with a function to merge at log2 or whatever | 23:36 |
| lifeless | each pack has a directory, which the names list points at (by saying the bytes the index is found at) | 23:36 |
| lifeless | the directory maps table names to byte ranges in the pack | 23:37 |
| lifeless | each of those byte ranges is itself a B+Tree index, with the right tuple keywidth for the table and strings as values | 23:37 |
| jelmer | lifeless: thanks, I'll look into that | 23:42 |
| lifeless | bzrlib.plugins.search.index | 23:42 |
| lifeless | read through that | 23:42 |
| lifeless | you'll be able to discard everything specific to searching | 23:42 |
| lifeless | jelmer: https://code.edge.launchpad.net/~jelmer/pqm/distutils/+merge/569 did you get notified of my review/ | 23:56 |
| lifeless | ? | 23:56 |
| mrooney | Is there an easy way to see the unpushed commits of a branch to the push branch? | 23:58 |
| jelmer | lifeless: yeah, I just haven't gotten round to fixing it yet | 23:58 |
| lifeless | mrooney: bzr missing | 23:58 |
| lifeless | mrooney: e.g. bzr missing :push | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!