| garyvdm | How do we write a test for say qdiff? | 00:00 |
|---|---|---|
| garyvdm | side - by - side qdiff | 00:01 |
| garyvdm | and check that the systax highlighting is working? | 00:01 |
| bialix | puzzling | 00:01 |
| fullermd | Obviously, you write two tests and run them side by side! | 00:01 |
| bialix | if our internal data is correct then colors should be correct | 00:01 |
| bialix | fullermd :-P | 00:02 |
| garyvdm | Ok - thats a very extreame case. | 00:02 |
| garyvdm | qlog should not be too hard - just lots of work. | 00:02 |
| bialix | garyvdm: I've installed winmerge today. it's more powerful than qdiff s-b-s, albeit lacks syntax highlighting | 00:03 |
| bialix | there is too much 3rd party diff gui tools | 00:03 |
| bialix | may be we just need ad them | 00:04 |
| garyvdm | On windows - I prefer Araxis Merge - unfortunately it is proprietary. | 00:04 |
| garyvdm | But I'm doing most of my dev on ubuntu these days - so I use meld | 00:04 |
| bialix | some people can buy proprietary soft | 00:04 |
| garyvdm | or crack pro^H^H^H^H^H^H^H^H^H^H^H^H^H^ | 00:05 |
| bialix | I dunno, luks rewrote qdiff s-b-s several times and we still is not perfect | 00:06 |
| bialix | garyvdm, I understand | 00:06 |
| bialix | there is one area we can do better: qann | 00:07 |
| garyvdm | Yes - we need to be able to select the revision you are annotating. | 00:07 |
| garyvdm | Go back | 00:07 |
| bialix | yes, something like this | 00:08 |
| garyvdm | I personally don't gannotate's ui for that though. | 00:08 |
| bialix | don't? don't like? | 00:08 |
| garyvdm | err - yes - don't like | 00:08 |
| garyvdm | I would rather have this: you right click on a revision in the revision list - and click "Annotate this revision" | 00:09 |
| bialix | I don't ran bzr-gtk for ages, I don;t remember how it | 00:09 |
| bialix | this is fine way | 00:10 |
| garyvdm | The revision that is annotated is highlighted in the list. | 00:10 |
| * fullermd just wishes viz would stop polluting his clipboard... | 00:10 | |
| bialix | one thing that turn me mad in qt is clipboard | 00:10 |
| bialix | I'm selecting some text in qdiff, close it -- and then find that clipboad is empty | 00:11 |
| garyvdm | You need to go back to an older qt | 00:11 |
| bialix | err, I mean I'm copy text to clipboard but qt clear it on exit | 00:12 |
| bialix | older? | 00:12 |
| bialix | I'm using 4.3.1 | 00:12 |
| bialix | fullermd: switch to qbzr and your clipboard will be empty all the time | 00:13 |
| garyvdm | Are you sure - We had a discussion on the ml about it - you told me that it worked in 4.3.1 | 00:13 |
| garyvdm | Subject: Copy, Close Window, Paste does not work | 00:14 |
| fullermd | qbzr requires qp 4 though, don't it? | 00:14 |
| garyvdm | Yes | 00:14 |
| bialix | yes, I'm observing this issue only in qdiff, but not in qlog | 00:14 |
| fullermd | I don't have 4 around. And QT is freakin' HUGE. | 00:14 |
| fullermd | (only reason I have bzr-gtk around is that I already have GTK anyway) | 00:14 |
| bialix | fullermd: windows installer is about 12MB | 00:14 |
| bialix | it's not very huge for me :-P | 00:15 |
| * fullermd doesn't own a machine that runs Windows :p | 00:15 | |
| igc | morning | 00:15 |
| bialix | good day igc | 00:15 |
| fullermd | Heck, even QT 3 takes longer to build than Firefox, IIRC. Nutbar. | 00:15 |
| garyvdm | fullermd: so you have never tried qbzr? | 00:16 |
| bialix | that's why I prefer python tools: I don;t need to compile tem (usually) | 00:16 |
| fullermd | No. I wouldn't have tried bzr-gtk if I didn't already have all the pieces but the python gtk bindings either. | 00:16 |
| fullermd | I don't have any real use for it. | 00:16 |
| fullermd | I don't think I've ever even fired up anything but viz, and I've only used viz recreationally. | 00:17 |
| bialix | garyvdm: I've re-read that discussion about clipboard | 00:17 |
| bialix | I have no problem with most of the q-windows, only with qdiff | 00:18 |
| bialix | only with s-b-s qdiff, because it's default | 00:18 |
| garyvdm | bialix: ok | 00:18 |
| === mark1 is now known as markh | ||
| bialix | I suspect it's because there is different widget used | 00:18 |
| bialix | maybe something related to painting | 00:19 |
| * bialix checks | 00:19 | |
| garyvdm | bialix: linux desktops generally have clipboard managers. I wounder if you can find one for windows. | 00:19 |
| fullermd | (I note that viz resets its clipboard damage when it exits too, which makes it either better or worse; I'm not actually sure which) | 00:20 |
| bialix | wow | 00:20 |
| bialix | it looks interesting | 00:20 |
| igc | hi bialix | 00:20 |
| bialix | it works now on win xp for black text | 00:20 |
| bialix | ian, I have question about fast-import | 00:20 |
| lifeless | garyvdm: http://msdn.microsoft.com/en-us/library/ms649014(VS.85).aspx | 00:20 |
| igc | bialix: sure, and I have a Q for you! | 00:21 |
| lifeless | garyvdm: which is, its built in. You can supply the content or you can be called back. | 00:21 |
| igc | bialix: bug 328007 - any thoughts? | 00:21 |
| ubottu | Launchpad bug 328007 in bzr "UnicodeDecodeError on 'log -p'" [Undecided,Confirmed] https://launchpad.net/bugs/328007 | 00:21 |
| bialix | garyvdm: but it does not work as expected with win2k I'm using at work | 00:21 |
| * bialix looks | 00:22 | |
| igc | bialix: my simply fix breaks a fair few tests that I think you wrote so I wanted to hear how you thought we should proceed there | 00:22 |
| * bialix cough | 00:23 | |
| bialix | it's tricky | 00:23 |
| bialix | honestly, I think we should have versioned properties to store encoding of files | 00:23 |
| bialix | or at least rules | 00:24 |
| garyvdm | lifeless: thanks | 00:24 |
| bialix | it's ideal situation I know | 00:24 |
| bialix | igc: you can't use exact on log | 00:25 |
| bialix | otherwise you have to manually encode log messages | 00:26 |
| igc | bialix: I'm not sure I understand how encoding files/rules will help here? | 00:27 |
| bialix | igc: because then you can decode them to unicode | 00:28 |
| jelmer | lifeless, do you remember the subject of your email with instructions on running bzr serve from homedir on a remote side? | 00:28 |
| jelmer | *site | 00:28 |
| bialix | igc: I think to fix this issue one have to provide exact stream for log formatter but create another wrapped stream internally to log everything but diff | 00:29 |
| lifeless | streaming-push alpha testing | 00:29 |
| bialix | igc: is it correct? | 00:29 |
| igc | bialix: something like that but I have next to no idea on how to do that :-( | 00:30 |
| bialix | ok, I can try to figure it out, but I have a question about fast-import first | 00:31 |
| igc | bialix: my knowledge in the whole encode/decode space is "just the basics" | 00:31 |
| igc | bialix: fire away | 00:31 |
| poolie | hey igc | 00:32 |
| igc | hi poolie | 00:32 |
| bialix | igc: I'm pleased to hear you think I'm expert in unicode, of course, I hope I can help | 00:32 |
| igc | lifeless, jam, poolie: got a bzr-1.12 branch converted to gcchk255 yesterday | 00:33 |
| poolie | oh ok | 00:33 |
| igc | it took 4.5 hours | 00:33 |
| poolie | igc, i'd like to set them up on orcadas | 00:33 |
| bialix | igc: I have a real need to replay some my branches and filter them in very smart way. But I need to preserve file-ids | 00:33 |
| igc | but it's 1/2 the size!!! | 00:33 |
| igc | jam: I've been trying to benchmark it this morning but I've been running into gremlins here and there - mostly in my setup | 00:34 |
| poolie | i had many gremlins on orcadas | 00:34 |
| igc | jam: however, "./bzr log -r-1 NEWS" doesn't work for me on brisbane-core | 00:35 |
| poolie | the patch i sent you was really pathetically small for how long it took me to work out :-} | 00:35 |
| bialix | igc: where the code for generating diff in log lives? | 00:35 |
| bialix | poolie: what is orcadas | 00:35 |
| poolie | bialix: the machine that's http://benchmark.bazaar-vcs.org/ | 00:35 |
| igc | bialix: the diff gets generated by calling into diff.py - the result is stored in a StringIO | 00:36 |
| poolie | you can really see in that first graph how the noise makes it hard to say straight away whether there was a meaningful change or not | 00:36 |
| bialix | poolie: your genius to choose right names for things is imressive | 00:36 |
| igc | bialix: later on, the LOgFormatter calls a method called show_diff that tries to dump it to self.outf | 00:36 |
| poolie | bialix: is that sarcasm or not? :) | 00:36 |
| bialix | poolie: but Kergelen is a bit offensive :-P | 00:37 |
| bialix | a bit | 00:37 |
| poolie | ah ok | 00:37 |
| bialix | the naming of cat is a difficult matter | 00:37 |
| poolie | well, that one i did not choose | 00:37 |
| bialix | :-) | 00:37 |
| poolie | Orcadas Base <http://en.wikipedia.org/wiki/Orcadas_Base> | 00:37 |
| poolie | the worst canonical machine name (for me) is in russian actually | 00:38 |
| poolie | um | 00:38 |
| bialix | soyuz | 00:38 |
| igc | poolie: sorry that the usertest code is pretty rough - it gets minimal love because it doesn't necessarily deserve/need more | 00:38 |
| bialix | yes? | 00:38 |
| poolie | Novolazarevskaya | 00:38 |
| igc | poolie: well until some other por sucker tries to tweak it :-( | 00:38 |
| bialix | LOL LOL LOL LOL | 00:38 |
| igc | s/por/poor/ | 00:38 |
| poolie | igc, i know, it's ok | 00:39 |
| bialix | ROTFL!!!!!!!!!!!!!!!!!!!! | 00:39 |
| bialix | poolie: you know the English is hard language too | 00:39 |
| poolie | i'm not sure if this is true but i've heard it means something like "New Miami Beach" | 00:40 |
| poolie | which is a joke because it's a place in Antarctica | 00:40 |
| bialix | they have a bath there | 00:41 |
| bialix | bath == warm | 00:41 |
| bialix | warm == beach | 00:41 |
| bialix | Novolazarevskaya is just a name | 00:42 |
| bialix | Novo == new | 00:42 |
| poolie | maybe it's the nickname for the place or something | 00:43 |
| poolie | soyuz is about the last part of landscape to have an obscure code name | 00:43 |
| bialix | lazarevskaya it's the beach near the Sochi | 00:43 |
| bialix | Black Sea | 00:43 |
| bialix | so yes, it's ~= New Maiami Beach | 00:44 |
| bialix | igc: so what about fast import and file ids? | 00:45 |
| igc | bialix: its a good question! | 00:46 |
| igc | bialix: fast-import has some support for incremental changes ... | 00:46 |
| igc | but I feel it needs some deeper thought | 00:47 |
| igc | at a minimuym, some better ui polish and doc on how to do it and the limitations would be nice | 00:47 |
| bialix | igc: until I saw fast-import in action I'm thinking about writing my tool for this | 00:47 |
| bialix | also, I have many failures with renames | 00:48 |
| igc | bialix: I really need to bug Jelmer about this topic when we both have some time | 00:48 |
| bialix | some of my branches even have cyclic renames??? | 00:48 |
| igc | bialix: please raise bugs for the rename issues | 00:48 |
| igc | bialix: I've recently added a heap of tests for fast import, though fast-export doesn't have any yet | 00:49 |
| bialix | igc: it's occured on private branches | 00:49 |
| igc | bialix: I know I'm still missing fast-import tests for renaming and copying directories though | 00:49 |
| bialix | I dunno how to properly write bug report | 00:50 |
| lifeless | igc: 1/2 size, thats a bit disappointing | 00:50 |
| igc | bialix: all I need is a minimal fast-import stream showing the scenario and expected outcome | 00:50 |
| bialix | igc: ok I see LogFormatter.show_diff, but who call it? | 00:50 |
| igc | lifeless: you were expecting more? | 00:51 |
| bialix | rats | 00:51 |
| bialix | I'm back | 00:51 |
| lifeless | igc: yes, various sample data goes to 1/7th | 00:51 |
| lifeless | jam: probably need the byte-length encoding for gc 'i' instructions | 00:51 |
| igc | lifeless: the other curious thing about running brisbane-core/bzr upgrade --gcchk255 was that the dirstate size went up | 00:51 |
| igc | not by much but a bit (328 blocks to 36) - something like that) | 00:52 |
| lifeless | igc: ? *blink* | 00:52 |
| igc | s/36)/360/ | 00:52 |
| bialix | igc: how about this fix for log -p | 00:52 |
| bialix | igc: store original exact stream as self.exact_stream and use it for show_diff | 00:53 |
| igc | bialix: show_diff is called by the ShortLOgFormatter and LOngLF | 00:53 |
| lifeless | igc: did you do a full branch of the result? | 00:53 |
| bialix | igc: and wrap it as in command.py Commad._setup_outf and store as self.to_file | 00:53 |
| lifeless | igc: that will get rid of some redundancy (outside a shared repo, obviously) | 00:54 |
| igc | bialix: line 1311 of log.py is one called to show_diff() | 00:54 |
| bialix | igc: I'll write it for you. Here is just 02:56 and I'm don;t sleep anyway | 00:55 |
| igc | bialix: legend | 00:55 |
| igc | lifeless: I was upgrading from a pack branch - no shared repo before or after | 00:55 |
| bialix | legend? | 00:55 |
| * bialix hates chatzilla but have no better irc client | 00:56 | |
| igc | bialix: I was trying to say thnk-you very, very much | 00:56 |
| igc | s/thnk/thank/ | 00:56 |
| igc | lifeless: I'll upload the branch (as an archive) to orcadas - I just wanted to make sure it mostly worked first | 00:57 |
| bialix | lifeless: I've used to pb. don't see it with bzr 1.12 is hurt | 00:58 |
| bialix | igc: one downside with using exact encoding for log: output will be LF-only on Windows | 01:00 |
| lifeless | bialix: yeah, I'm not sure whats going on; if it was 1.13 I'd know (because spiv and I broke it temporarily) | 01:02 |
| bialix | but I think for Windows qlog is rocks | 01:02 |
| bialix | lifeless: and I don;t see pb in qbzr too, it seems it's just disappear | 01:03 |
| igc | bialix: does diff have the same issue? | 01:04 |
| bialix | igc: what issue? | 01:04 |
| bialix | igc: for plain diff exact is right thing | 01:05 |
| bialix | igc: but for plain log -- i'm not sure | 01:05 |
| bialix | but I can live with this | 01:05 |
| bialix | I just want to inform you abut this side effect | 01:06 |
| bialix | igc: ping | 01:12 |
| shtylman | is there a way to delete a bazaar branch remotely? without logging into launchpad per se? | 01:12 |
| poolie | shtylman: there probably is an API for it in launchpadlib but i don't think there is a UI at present | 01:13 |
| shtylman | poolie: thanks | 01:13 |
| bialix | igc: I have the patch for you | 01:13 |
| igc | bialix: thanks! I'll test it later today | 01:14 |
| bialix | send it to list or to you personally? | 01:14 |
| poolie | shtylman: you could add one to bzr's launchpad plugin if you're keen | 01:15 |
| bialix | I've tested it manually only, have no desire to write unittest | 01:15 |
| shtylman | poolie: well, I don't just want to be able to do it in launchpad, but for other projects as well | 01:16 |
| bialix | igc: sent to ML | 01:18 |
| bialix | perhaps I need to manage me to sleep. bye | 01:19 |
| Stanlin | whos bazaar for windows developer? | 01:34 |
| khemicals | how does one duplicate a bzr repository to another bzr repository -- do you have to do it one branch at a time? | 01:46 |
| Peng_ | khemicals: I'd probably use rsync. | 01:46 |
| khemicals | rsync doesn't talk http | 01:46 |
| Peng_ | There might be a plugin that helps, but if so, I don't remember it. | 01:47 |
| khemicals | so -- there's no command I am m issing | 01:47 |
| khemicals | but bzr doesn't natively support it | 01:47 |
| Peng_ | If it's plain HTTP, there's no way to walk the file system, so unless bzr kept a list of branches somewhere, which it doesn't, it isn't possible... | 01:48 |
| Peng_ | Mmm, commas. | 01:48 |
| khemicals | k | 01:48 |
| mlh | it doesn't keep a list of branches? | 01:48 |
| Peng_ | mlh: Correct. | 01:49 |
| mlh | nowhere? | 01:49 |
| Peng_ | mlh: Correct. | 01:49 |
| mlh | so you can't discover branches remotely, you have to know what you want. | 01:49 |
| khemicals | So, I pulled a branch from an existing public repo (just playing with bzr here to see how it goes) and tossed it into a local repo (was created using repo-init) using something akin to bzr push bzr+ssh://host/PATH_TO_REPO but now I cannot check it out since I don't know what the branch name is | 01:49 |
| Peng_ | There are find_bzrdirs and find_branches methods, but they just go recursing through the file system. | 01:50 |
| khemicals | is there a default branch name | 01:50 |
| Peng_ | khemicals: ...What? | 01:50 |
| Peng_ | khemicals: Branch names shouldn't matter, just the specific location. | 01:50 |
| khemicals | it errors | 01:50 |
| khemicals | let me get the error for you | 01:50 |
| * Peng_ avoids knowing much about checkouts | 01:50 | |
| khemicals | bzr: ERROR: Not a branch: | 01:51 |
| khemicals | and then the path thereafter | 01:51 |
| khemicals | with git, for instance, I can clone the ENTIRE repository | 01:52 |
| khemicals | just trying to figure out how to do the same without filesystem access to the repo I am trying to duplicate | 01:53 |
| khemicals | Peng_: Why do you avoid knowing much about checkouts? | 01:53 |
| khemicals | trying to figure out where I am going wrong here | 01:53 |
| Peng_ | khemicals: Checkouts are something extra to learn. Regular branches are usually enough for me. | 01:56 |
| khemicals | what's the difference between pull/checkout/branch commands? | 01:57 |
| * khemicals reads the man I guess | 01:57 | |
| Peng_ | Ehh, I'm not good at explaining things. | 01:57 |
| Peng_ | khemicals: Were you trying to "bzr branch" from a repository or checkout instead of a branch? | 01:58 |
| khemicals | it was a branch since none of it worked against the repo root I don't think | 02:00 |
| lifeless | khemicals: pull maintains a mirror; checkout creates a checkout - a place to edit an existing branch, branch creates a new branch (and if the target is local it can be edited in-place) | 02:00 |
| khemicals | so, pull still only works against a branch though, right? | 02:00 |
| Peng_ | khemicals: Right. Use "update" against a checkout. | 02:01 |
| khemicals | so, can I pull a branch from one repository and use push to push it to another? | 02:02 |
| lifeless | khemicals: yes | 02:02 |
| khemicals | do I need to create a destination branch in the repo I am pushing to first? -- or is that was export is for? | 02:02 |
| lifeless | khemicals: no, push will make a branch if one doesn't exist alrady | 02:03 |
| khemicals | what's the name of the branch -- the same as what I pulled? | 02:03 |
| lifeless | khemicals: branches have urls, not names | 02:03 |
| lifeless | khemicals: in git branches are 'refs in a repo', in bzr 'branches are directories at a url' | 02:04 |
| lifeless | s/refs in a repo/'named refs in a repo' | 02:04 |
| khemicals | well, the name is essentially just a subdir of the repo | 02:04 |
| khemicals | so, how is that name determined | 02:04 |
| lifeless | khemicals: you don't need a repo | 02:04 |
| lifeless | khemicals: try it - bzr branch [some branch] /tmp/demo | 02:05 |
| khemicals | bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr | 02:10 |
| khemicals | so, how do I populate a new repo, that I want to share, with that content (including full history)? | 02:10 |
| AfC | khemicals: bzr branch | 02:12 |
| khemicals | bzr branch bzr SOME_NEW_URL ? | 02:12 |
| Peng_ | khemicals: Sure. | 02:12 |
| lifeless | khemicals: if you have a lot of branches, or a lot of history, you can run 'bzr init-repo URL' to create a history-sharing repository with no content, then whenever you bzr branch URL/suffix, or bzr push URL/suffix, bzr will use that repository to share branch content | 02:13 |
| lifeless | khemicals: but generally most folk don't need this | 02:14 |
| lifeless | the folk that do tend to be server admins and developers on projects with hundreds of MB's of history | 02:14 |
| khemicals | I found my issue | 02:22 |
| khemicals | in checking out the various protocols server side, I set the --directory option on the bzr daemon | 02:22 |
| khemicals | it stripped too much of the path out | 02:22 |
| khemicals | so it didn't match the path used by the other mechanism | 02:23 |
| khemicals | thus confusing the heck out of me | 02:23 |
| khemicals | but I do understand it enough to limp along now -- will keep reading, thx for the assist | 02:24 |
| lifeless | khemicals: no problem | 02:24 |
| lifeless | khemicals: most folk just use 'bzr+ssh://' as the protocol, which sets --directory automatically | 02:24 |
| khemicals | I am just toying with all its server side functions | 02:25 |
| khemicals | bzr+ssh is fine | 02:25 |
| lifeless | cool | 02:25 |
| khemicals | but wanted to try native bzr | 02:25 |
| khemicals | protocol | 02:25 |
| khemicals | as well | 02:25 |
| lifeless | feel free to shout if you want any more input | 02:25 |
| khemicals | you can checkout from loggerhead to? or no? | 02:25 |
| lifeless | I think you can branch from loggerhead in the very latest versions | 02:25 |
| lifeless | mwhudson: ^ please confirm or deny | 02:25 |
| mwhudson | yes you can | 02:26 |
| khemicals | s/checkout/branch | 02:26 |
| khemicals | wrapping head around new nomenclature that overlaps others | 02:26 |
| mwhudson | but it doesn't support Range:s so don't use it on anything big... | 02:26 |
| lifeless | yeah, I can appreciate that | 02:26 |
| lifeless | strictly speaking you could checkout from loggerhead, but it doesn't support writing back to it, so you wouldn't be able to commit -> checkout isn't that useful in that case :) | 02:27 |
| mwhudson | loggerhead will do bzr+http sooner or later i guess | 02:32 |
| igc | lifeless: can you help me with a CHKInventory issue please? | 03:06 |
| igc | lifeless: what's the way forward wrt referencing "children" of an InventoryDirectory? | 03:07 |
| igc | it looks like iter_entries() on a chk-inventory can break because the attribute is now _children, not children, and there's a children() method on the ... | 03:08 |
| igc | ChkInventryDirectory class but not one I can see on InventoryDirectory? | 03:08 |
| igc | jam: ^^^ | 03:09 |
| jam | igc: I would say we need to add one to InventoryDirectory() | 03:10 |
| jam | we really want to be able to lazily bring stuff in | 03:10 |
| igc | jam: ok, I'll do that and change the references to .children to .children() | 03:11 |
| igc | jam: sound right? | 03:11 |
| jam | sounds right to me | 03:11 |
| igc | jam: thanks | 03:11 |
| igc | jam: fyi, to see the bug in action, try bzr ls -r-1 on a chk branch and you'll see nothing listed | 03:12 |
| jam | interesting | 03:13 |
| jam | igc: btw, I just finished another improvement to chk+gc | 03:13 |
| jam | which improves inventory compression by 50-100% | 03:13 |
| igc | jam: sweet | 03:13 |
| jam | I'm pushing it up now | 03:13 |
| === montywi is now known as montywi|zzz | ||
| igc | jam: is gcchk255 still the preferred format for me to be benchmarking? | 03:14 |
| jam | igc: I need to do another round of testing myself | 03:14 |
| igc | jam: it souded like you were leaning towards a 127? | 03:14 |
| jam | I might also be cheating more than I realized | 03:14 |
| jam | igc: I have to test *after* compression | 03:14 |
| jam | it can make smaller things become bigger | 03:14 |
| * fullermd blinks. | 03:16 | |
| fullermd | Something went screwy with pushing multi-initial-rev branches? | 03:17 |
| * fullermd really needs to watch bugs more closely... | 03:17 | |
| spiv | fullermd: apparently! | 03:18 |
| spiv | fullermd: I was surprised too. | 03:18 |
| * fullermd is extremely surprised. | 03:19 | |
| fullermd | A very large number (quite possibly a majority) of my branches have >1 initial rev. | 03:19 |
| fullermd | I've never seen issues pushing with say a up to 1.5 version spread between my bzr.dev client and the latest-release-mod-upgrade-slack-time server. | 03:20 |
| fullermd | It's only a blowup, right? Not a "gee, it worked fine, but it's gonna screw you later"? | 03:20 |
| spiv | Right. | 03:20 |
| spiv | And it's purely a client-side issue. | 03:21 |
| jam | spiv, lifeless: question on the new stream tests | 03:21 |
| jam | if an entry is in "Chunked" encoding | 03:21 |
| fullermd | Oh, good. That leaves me with only 38,849 entries on my worry stack for today. | 03:21 |
| jam | the "capture_stream()" fails | 03:21 |
| jam | because "self.assertIsInstance(factory.get_bytes_as(factory_kind), str)" | 03:21 |
| jam | groupcompress hits this | 03:21 |
| jam | because it only talks in fulltexts/chunked (so far) | 03:21 |
| lifeless | igc: so as jam says, it needs to stay lazy | 03:21 |
| lifeless | igc: there is a property for children; if the property isn't working correctly there is a bug | 03:22 |
| jam | I would guess that ultimately we want to have gc go the same route as your "knit-delta-closure" patch | 03:22 |
| lifeless | igc: it sounds like something changed in bzr.dev | 03:22 |
| lifeless | jam: yes, knit-delta-closure is roughly the same problem case as gc for streaming network | 03:22 |
| lifeless | jam: I just haven't gotten around to it | 03:23 |
| lifeless | jam: that might be a bug in the test; but generally we don't want any stream returning direct Chunked or Fulltext objects, because they don't have a small network representation | 03:24 |
| jam | igc: for example, I expect 255-way to compress better, because you have a big top level page, and fewer intermediate pages | 03:28 |
| jam | so even though its raw size is slightly larger | 03:28 |
| jam | it may end up smaller post compression | 03:28 |
| * igc lunch | 03:32 | |
| jam | igc: So if you pull the latest groupcompress, you should be able to 'bzr pack' | 03:34 |
| jam | and have it spend far too long with no progress bars | 03:34 |
| jam | but end up with a smaller inventories | 03:35 |
| igc | jam: so just running pack is enough? I don't need to upgrade to another format then upgrade back for example? | 03:40 |
| jam | igc: for this, that should be enough | 03:40 |
| jam | so in my quick test | 03:40 |
| igc | lifeless,jam: so I missed the @property bit - make me wonder whether the bug is in the inventory building rather than the inventory lookup? | 03:41 |
| igc | lifeless,jam: but lots of stuff *is* working | 03:41 |
| igc | so it's not obvious to me yet where the bug is | 03:42 |
| jam | pre-compression, gc+chk16 is 20MB versus gc+chk255 is 31MB, after compression it is 9.5MB versus 7MB | 03:42 |
| jam | so 20MB raw => 9.5MB comp, 31MB raw => 7MB comp | 03:42 |
| jam | which makes gc255 better | 03:42 |
| jam | There are other factors to test, though, so I'll get there | 03:42 |
| igc | jam: any do you expect lookup speed to be much the same? or 255 faster? | 03:43 |
| igc | s/any/and/ | 03:43 |
| fullermd | How relevant are those compression numbers, though? Aren't you still to-do delta compression or other schemata on them? | 03:44 |
| jam | igc: smaller == less bytes to read, larger fan-out means you filter more keys per pass. So overall, I expect 255 to be better on both counts | 03:45 |
| jam | but expect != measured | 03:45 |
| jam | fullermd: this is one form of delta compressino | 03:45 |
| jam | still one of the factors to be evaluated | 03:45 |
| fullermd | Well. But does it have the same properties as $FINAL, though. | 03:46 |
| jam | it should at least have *similar* properties | 03:48 |
| igc | jam: pulled groupcompress rev 50 and kicked off that pack now | 03:48 |
| lifeless | igc: So yeah, there is a property; it should work; there are tests - perhaps the input is flawed in some way. Cross checking by using iter_entries_by_dir or something might be enlightening | 03:52 |
| jam | igc: wait | 03:52 |
| jam | I just found a quick bug when there are signatures | 03:53 |
| jam | I'll have a fix in just a sec | 03:53 |
| igc | jam: ok, I'll stop it | 03:54 |
| jam | I'll also get a quick progress on the texts done | 03:54 |
| igc | lifeless: sure. I tried a quikc corss check using entries but it's not defined on CommonInventory, just Inventory, so I might move that up a level too | 03:55 |
| lifeless | igc: when moving up just take the time to check it uses public interfaces not private attributes | 03:56 |
| igc | lifeless: sure | 03:58 |
| jam | igc: revno 52 is available | 04:00 |
| jam | should give you some idea of progress now | 04:00 |
| jam | I also noted that converting is slower than 'bzr pack', which is good | 04:00 |
| jam | well, good that 'pack' is faster :) | 04:00 |
| igc | jam, lifeless: so I'm closer t finding that children() bug - the "slow path" in CHKInventoryDirectory.children() gives a good result while the code after that if statement finds no children | 04:10 |
| jam | lifeless: so here are some hard numbers for including/removing 'label' and 'sha1' sum fields. | 04:13 |
| jam | for gc+chk255, the inventories go from 8.3MB compressed down to 7.0MB compressed | 04:14 |
| jam | the texts go from 11.0MB => 9.6MB | 04:14 |
| jam | or approx 107 bytes per object for inventories | 04:15 |
| jam | and 202 bytes/object for texts | 04:16 |
| jam | [compressed] | 04:16 |
| jam | though interestingly enough, after a 'bzr pack', the final inventories shrunk dramatilaly | 04:20 |
| jam | as it is now 6.5MB rather than 8.3 (so w/ labels is smaller than w/o labels) | 04:21 |
| jam | though after 'bzr pack' the *text* size went up, 11.0MB => 11.3MB. | 04:22 |
| mwhudson | hm | 04:42 |
| mwhudson | in a test, i want to create a (local) branch, then open it over the smart protocol | 04:43 |
| mwhudson | what's the easiest way to do this? | 04:43 |
| mwhudson | nm, got something working | 04:46 |
| jml | lifeless: I deleted your subunit/filter merge proposal and created it again so that I could blog about something more easily | 05:04 |
| jml | lifeless: please ignore the mail :) | 05:04 |
| jam | igc: a quick update. revno 53 drops it by another 2MB, so now 4.4MB down from 6.5 | 05:10 |
| Stanlin | how to undo last changes in my directory | 05:11 |
| jam | Stanlin: "bzr revert" | 05:12 |
| jam | lifeless: woot!. Surprisingly, changing the grouping had a much bigger impact than I expected. | 05:19 |
| Stanlin | thanks | 05:19 |
| jam | By creating more groups, I'm down to 1.5MB, which is actually finally *smaller* than the knit source | 05:19 |
| jam | (1.8MB) | 05:19 |
| jam | I'm going to do a conversion from scratch to confirm, but it looks good so far | 05:19 |
| jam | (raw size is identical, etc) | 05:19 |
| jam | igc: You may want to stop it and use revno 55 | 05:20 |
| jml | jelmer: so, it's still running | 05:20 |
| jml | jelmer: "copying revision 1405/6696" (I killed it and restarted it at one point, in a bout of nervous fear) | 05:20 |
| eferraiuolo | I was wondering if there was an appropriate way to delete a branch that's in a shared repo? | 05:37 |
| eferraiuolo | if I have /repo and /repo/b1 and b1 branch is using the shared repo for storage, I've just been deleting the b1 directory... Does that leave un-wanted cruft around in my shared repo? | 05:38 |
| eferraiuolo | Is this where the pack command comes in? I guess I'm just unsure since there isn't a remove-branch from repo command... | 05:39 |
| poolie | eferraiuolo: there's a bzr gc plugin that will remove it | 05:40 |
| poolie | normally people just leave it there unless it's unreasonably big | 05:40 |
| eferraiuolo | poolie: so there is some cruft left around in my repo if I just delete the branch dir? | 05:41 |
| poolie | yes | 05:41 |
| eferraiuolo | poolie: thanks. I'll look into the gc (garbage collection??) plugin | 05:42 |
| poolie | yes | 05:42 |
| poolie | igc, are if you're still here, is http://pastebin.ubuntu.com/123652/ correct/reasonable? | 05:43 |
| poolie | igc, also, i was wondering about encoding eg the project name, scenario name, script name into the csv file | 05:43 |
| igc | poolie: back from reviewing some chk code | 06:13 |
| igc | poolie: that pastebin looks fine bar lines 54/55 which is a partial sentence | 06:13 |
| igc | poolie: I'm open to any encoding suggestions, though the current output of 'just a table' has value in it's simplicity | 06:15 |
| === mark1 is now known as markh | ||
| poolie | i was basically thinking about putting just a couple of other heading rows | 06:23 |
| poolie | like tool, version, project, scenario | 06:23 |
| poolie | suite | 06:23 |
| igc | poolie: sure | 06:34 |
| poolie | it shouldn't break anyone using them in eg a spreadsheet | 06:52 |
| poolie | as long as they can cope with there being nonnumeric data | 06:53 |
| poolie | and it'll make it more selfcontained | 06:53 |
| vila | hi all | 07:07 |
| igc | hi vila | 07:18 |
| vila | hi Ian :) | 07:19 |
| berto- | abentley: hi. | 07:35 |
| thrope | help - tried to upgrade bzr and now get: bzr: ERROR: The API for "<module 'bzrlib' from '/usr/lib/python2.4/site-packages/bzrlib/__init__.pyc'>" is not compatible with "(1, 9, 0)". It supports versions "(1, 11, 0)" to "(1, 12, 0)". | 08:00 |
| thrope | but bazaar is 1.12 - I don't know where 1.9 is coming from | 08:00 |
| luks | from a plugin, probably | 08:03 |
| thrope | deleting bzr-lib seemed to work | 08:03 |
| thrope | now when I try to update bzr-svn directory I get bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~jelmer/bzr-svn/trunk/"./ 0kB | 08:04 |
| igc | night all | 08:16 |
| vila | thrope: what do you mean by 'deleting bzr-lib' ? bzrlib ? Where did you delete that ? | 08:19 |
| thrope | vila: site-packages | 08:20 |
| thrope | anyway thats ok now - but it seems bzr-svn and bzr-rebase that I had a branch of have moved or something so I just gave up and downloaded a tar ball | 08:21 |
| vila | thrope: So you deleted the bzrlib fron you site-installed packages (but you may still have the bzr script somewhere). What OS are you using ? | 08:22 |
| thrope | vila: centos - its really fine now - I had installed a new version without manually deleting the old one | 08:22 |
| thrope | so i deleted the old one (script and site-packages) and reinstalled the new one | 08:22 |
| vila | thrope: ok | 08:23 |
| === montywi|zzz is now known as montywi | ||
| === serg is now known as serg|phone | ||
| Spaz | is it possible to allow checkins to bzr via http? | 10:45 |
| finiteset | I want to delete Bazaar from one of my projects completely. How do I do that? | 10:45 |
| ollie_ | hey what is the parameter for adding a dir but not recursively | 10:46 |
| === ollie_ is now known as Ollie_R | ||
| luks | bzr help add is hard to read? | 10:47 |
| Ollie_R | luks: nope :) | 10:48 |
| Ollie_R | luks: thanks | 10:48 |
| Spaz | finiteset, what do you mean? | 10:48 |
| === serg|phone is now known as serg | ||
| finiteset | Spaz: I have this folder for one of my projects which is a Bazaar branch. It has all the .bzr stuff in it. Now I want to get rid of Bazaar from the folder. I was wondering if I can use a Bazaar command to remove Bazaar from the folder. | 10:51 |
| Spaz | just rm -rf .bzr | 10:51 |
| Spaz | no special commands needed | 10:51 |
| finiteset | So all Bazaar files are in .bzr folder? | 10:52 |
| finiteset | its done thanks | 10:54 |
| vila | Spaz: commit needs write access, you need to either install a smart server or configure DAV and use the webdav plugin | 10:55 |
| Spaz | hm ok | 10:55 |
| vila | The former is preferred for performance reasons, the later exists for people who just can't administer their http server | 10:55 |
| vila | Spaz: what is your server ? | 10:56 |
| Spaz | it's internal | 10:56 |
| Spaz | :p | 10:56 |
| Spaz | (not publically accessible) | 10:56 |
| vila | Spaz: or more to the point, what is available on this server ? bzr+ssh it easy to setup, or even bzr: if it's really internal on you don't need to implement access rules | 10:57 |
| vila | s/internal on/internal and/ | 10:57 |
| Spaz | well access rules will still be necessary | 10:57 |
| Spaz | bzr+ssh is a possibility | 10:57 |
| Peng_ | If you don't mind configuring ssh, bzr+ssh is probably best. | 10:59 |
| vila | Spaz: Just as Peng_ said :-) | 10:59 |
| wysek | Hi, I have a user-question. Is this the proper place to ask? | 11:49 |
| luks | I'd say it's *a* proper place | 11:52 |
| LarstiQ | assuming it's about bzr :) | 11:53 |
| wysek | Ok. I have a bzr repo with some revs. I need to commit these into svn repo. | 11:53 |
| wysek | It started as a normal bzr repo; there is no module/branch in the svn repo yet, I have to create it | 11:54 |
| wysek | how should I do it? | 11:54 |
| LarstiQ | wysek: I'd use the bzr-svn plugin | 11:55 |
| wysek | (well, I want to test it before I commit to svn, so I did: svnadmin create ~/repo) | 11:55 |
| LarstiQ | wysek: how did you install bzr? | 11:55 |
| wysek | LarstiQ: I had bzr from ubuntu, but 10min ago I upgraded to latest stable | 11:55 |
| LarstiQ | wysek: via the ppa? | 11:57 |
| wysek | yes | 11:57 |
| wysek | assuming a clean svn repo is at ~/svn and my bzr repo is at ~/bzr/$dir. | 11:57 |
| wysek | I need to commit $dir to ~/svn/$dir | 11:58 |
| LarstiQ | wysek: (with bzr-svn installed), afaics that should be `cd ~/bzr/$dir; bzr push ~/svn/$dir` | 11:58 |
| * LarstiQ goes to work, later | 11:58 | |
| wysek | great, I've just encountered an "internal error" | 12:00 |
| awilkins | wysek: You want the dpush command | 12:04 |
| awilkins | Pushing new branches just off "push" doesn't work yeyt | 12:05 |
| awilkins | *yet | 12:05 |
| wysek | ok, I'll try | 12:07 |
| wysek | hmm | 12:08 |
| rcmorano | btw, does anybody knows if it is technically possible to push a complete branch to a svn repo served via http and preserve the commiters in the log?? | 12:08 |
| wysek | wysek@scout:~/bzr/radardaemon$ bzr dpush /home/wysek/svn/radardaemon | 12:08 |
| wysek | bzr: ERROR: Not a branch: "/home/wysek/svn/radardaemon". | 12:08 |
| rcmorano | i have been trying hard with bzr-svn | 12:08 |
| rcmorano | even hacking it a bit | 12:08 |
| rcmorano | but i always got something like i wasnt allowed to change the revprop on that scenario | 12:09 |
| rcmorano | scenario = context = using post-revprop-change hook in server side | 12:11 |
| wysek | wysek@scout:~/bzr/radardaemon$ bzr dpush /home/wysek/svn/radardaemon | 12:15 |
| wysek | bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. | 12:15 |
| wysek | wysek@scout:~/bzr/radardaemon$ bzr merge /home/wysek/svn/radardaemon | 12:15 |
| wysek | bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. | 12:15 |
| wysek | awilkins: what now? :) | 12:16 |
| wysek | (I did svn mkdir file:///home/wysek/svn/radardaemon before that) | 12:16 |
| awilkins | Are you pushing the trunk branch? | 12:25 |
| awilkins | Or a branch branch? | 12:25 |
| awilkins | wysek: You are creating a new folder, so push to the URI that makes sense for that new folder ; i'd go for | 12:26 |
| awilkins | bzr dpush /home/wysek/svn/radardaemon/trunk | 12:26 |
| wysek | (I don't know much about svn, trunk...) | 12:26 |
| awilkins | The usual convention is /project/trunk|tags|branches | 12:27 |
| wysek | bzr: ERROR: Not a branch: "/home/wysek/svn/radardaemon/trunk". | 12:27 |
| wysek | awilkins: and trunk|tags|branches are just dirs? | 12:27 |
| awilkins | Oops, make that into a file:/// URI | 12:27 |
| wysek | ok | 12:27 |
| awilkins | wysek: Yes, everything in SVN is a "cheap copy" | 12:27 |
| wysek | the same | 12:28 |
| awilkins | wysek: There's no technical distinction between tags and branches, it's just convention | 12:28 |
| * awilkins looks at the scripts he has doing thing | 12:28 | |
| awilkins | Try svn-push | 12:29 |
| wysek | actually I need to commit to some svn repo: svn://repo/trunk/<project>/radardaemon/ | 12:29 |
| wysek | and I'm just testing it locally | 12:29 |
| awilkins | Yuck, they have the _other_ convention | 12:29 |
| awilkins | I thikn it's svn-push, not dpush | 12:29 |
| awilkins | At least, that's what I've got here - I've been converting old archives into bzr repos and then SVN repos | 12:30 |
| wysek | so first I need to svn_mkdir $SVN/trunk/ | 12:31 |
| wysek | and svn_mkdir $SVN/trunk/radardaemon/ ? or just the trunk? | 12:31 |
| awilkins | I'm not so sure about that layout | 12:31 |
| awilkins | But hey, it's a test | 12:31 |
| wysek | wysek@scout:~/bzr/radardaemon$ bzr svn-push file:///home/wysek/svn/trunk/ | 12:31 |
| wysek | Initialising Subversion metadata cache in /home/wysek/.bazaar/svn-cache/921462df-d7b4-450a-9d4b-2ef3c14a844f | 12:31 |
| wysek | bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. | 12:32 |
| wysek | *diverged* :D | 12:32 |
| awilkins | Are you pushing to a folder that exists? | 12:32 |
| awilkins | rm -rf /home/wysek/snv | 12:32 |
| awilkins | svnadmin create ~/svn | 12:32 |
| awilkins | mkdir ~/svn_template | 12:33 |
| awilkins | mkdir ~/svn_template/trunk | 12:33 |
| awilkins | mkdir ~/svn_template/trunk/project | 12:33 |
| awilkins | svn import svn_template file:///home/wysek/svn -m "Initial folder structure" | 12:34 |
| awilkins | bzr svn-push -d ${bzr_branch} file:///home/wysek/svn/trunk/project/radardaemon | 12:34 |
| * awilkins crosses fingers | 12:35 | |
| wysek | Initialising Subversion metadata cache in /home/wysek/.bazaar/svn-cache/52c0211b-6b7a-4d98-8a1d-2bbbabca63ca | 12:35 |
| wysek | bzr: ERROR: Prefix missing for trunk/project/radardaemon; please create it before pushing. | 12:35 |
| wysek | svn import does not need commit? | 12:36 |
| jelmer | wysek, what version of bzr-svn are you using? | 12:36 |
| awilkins | Not afaik | 12:36 |
| * awilkins cheers jelmer | 12:36 | |
| jelmer | wysek, iirc older versions of dpush don't support creating new branches | 12:36 |
| wysek | 0.5.0-1 | 12:36 |
| wysek | ok | 12:37 |
| wysek | it almost worked | 12:38 |
| wysek | *** Bazaar has encountered an internal error. | 12:38 |
| wysek | it pushed 24/33 revisions | 12:38 |
| wysek | the error was: | 12:38 |
| wysek | bzr: ERROR: subvertpy.SubversionException: ('Attempted to get textual contents of a *non*-file node', 160017) | 12:38 |
| wysek | hmm, there is a link in my repo, maybe that's the problem | 12:39 |
| jelmer | wysek, does the problem occur if you push repeatedly? | 12:40 |
| wysek | jelmer: yes | 12:40 |
| wysek | it seems it "sees" that it has pushed some revs and goes just to the error | 12:40 |
| jelmer | wysek: Can you pastebin the traceback? | 12:40 |
| wysek | (no progress bar) | 12:41 |
| wysek | sure | 12:41 |
| jelmer | back in 10m | 12:42 |
| wysek | http://pastebin.com/m72316e4c | 12:43 |
| wysek | ok it has nothing to do with the link as it stopped 6 revisions before the link appeared | 12:44 |
| wysek | in the revision it stopped I have added a binary file | 12:46 |
| wysek | and the error is: SubversionException: ('Attempted to get textual contents of a *non*-file node', 160017) | 12:46 |
| wysek | note _textual_ | 12:46 |
| wysek | seems like a bug:) | 12:47 |
| jelmer | wysek, please run with BZR_PDB=1 set | 12:49 |
| jelmer | that should land you in a debugger | 12:49 |
| wysek | yep | 12:50 |
| jelmer | wysek, after that, please run "up" followed by "print new_inv.id2path(child_ie.file_id)" | 12:50 |
| wysek | (Pdb) up | 12:51 |
| wysek | > /usr/lib/python2.5/site-packages/bzrlib/plugins/svn/commit.py(319)dir_editor_send_changes() | 12:51 |
| wysek | -> modified_files[child_ie.file_id](child_ie), child_editor) | 12:51 |
| wysek | (Pdb) print new_inv.id2path(child_ie.file_id) | 12:51 |
| wysek | tests/src/radardaemonTest/radardaemonTest.csproj | 12:51 |
| wysek | (hmm, this is not thah binary file I was talking about) | 12:51 |
| jelmer | what about "print new_inv.revision_id" ? | 12:52 |
| wysek | None | 12:52 |
| jelmer | wysek, what about "print base_revnum" ? | 12:53 |
| wysek | 24 | 12:53 |
| === barry-away is now known as barry | ||
| jelmer | wysek, does that file exist in svn, and is it actually a file ? | 12:53 |
| wysek | jelmer: it does not exist as the push process threw an exception | 12:55 |
| wysek | btw, in bzr_last_rev it does not exist too, as I removed it from the bzr repo | 12:56 |
| jelmer | wysek, so "print child_ie.file.id in base_inv" returns False? | 12:57 |
| wysek | after up? | 12:57 |
| wysek | *** AttributeError: 'InventoryFile' object has no attribute 'file' | 12:58 |
| wysek | ok | 12:58 |
| jelmer | sorry | 12:58 |
| wysek | should be file_id | 12:58 |
| wysek | returns True | 12:58 |
| jelmer | yeah | 12:58 |
| jelmer | wysek, that suggests the file should already be there in the svn repository | 12:59 |
| wysek | well, the repo was empty before the svn-push | 13:00 |
| jelmer | wysek: but it should exist now, since the push has partially succeeded | 13:00 |
| wysek | which file? radardaemonTest.csproj? | 13:01 |
| jelmer | wysek, yep | 13:01 |
| wysek | well, it sort of exists. but it's in a different dir and it's name is different too. | 13:01 |
| wysek | that is, radardaemonTest.csproj is the name in the last_bzr_rev (and the desired name) | 13:02 |
| wysek | but in rev24 it is named differently and is in a differrent dir | 13:02 |
| jelmer | wysek, 24 would be the name of the revision in svn | 13:03 |
| wysek | (I've heard svn does not support filename changes or mv in a "normal" way) | 13:03 |
| jelmer | wysek, not the bzr revno | 13:03 |
| wysek | yeah, they differ by 1 | 13:03 |
| wysek | I mean the revno the svn-push process stopped | 13:03 |
| wysek | so what now? | 13:04 |
| wysek | any ideas?:) | 13:04 |
| jelmer | wysek, is this bzr repo public? | 13:07 |
| wysek | jelmer: no | 13:08 |
| jelmer | wysek, so the "svn log -v" output doesn't match the "bzr log -v" output for the revisions already pushed? | 13:08 |
| wysek | for the revs pushed it matcheds | 13:11 |
| wysek | *matches | 13:12 |
| jelmer | wysek, do the contents of that particular file match? | 13:13 |
| wysek | the rev it stopps is full of binary_files add and files moves | 13:13 |
| wysek | jelmer: yes | 13:14 |
| wysek | ok I've found sth | 13:15 |
| wysek | in bzr_rev 24 there is : | 13:15 |
| wysek | renamed: radardTest => tests/src/radardaemonTest/radardaemonTest.csproj | 13:16 |
| wysek | removed: radardTest/radardTest.csproj | 13:16 |
| wysek | as I remember I did some renames automatically and I did a mistake | 13:17 |
| jelmer | wysek, ah, that may be it | 13:17 |
| wysek | I renamed a dir into a filename | 13:17 |
| wysek | somehow I got the file back | 13:17 |
| jelmer | wysek, so | 13:18 |
| jelmer | wysek, radardTest is a directory | 13:18 |
| jelmer | wysek, and tests/src/radardaemonTest/radardaemonTest.csproj is a file ? | 13:18 |
| wysek | right | 13:19 |
| jelmer | wysek, please file a bug about this | 13:19 |
| jelmer | wysek, I'll see if I can commit a test + fix for this this afternoon | 13:19 |
| wysek | is it a bug with bzr or bzr-svn?? | 13:19 |
| wysek | I think its bzr bug as it shouldn't allow me such a change, I think | 13:20 |
| wysek | (or at least, without a warning) | 13:20 |
| jelmer | wysek, it's a bzr-svn bug | 13:25 |
| jelmer | I think such a change is allowed | 13:26 |
| jelmer | it's not a really common kind of change though.. | 13:26 |
| wysek | I don't know what bzr actually did as the order of file/dir name changes is important in this case | 13:27 |
| wysek | if bzr did well then it's a bzr-svn bug :) | 13:27 |
| wysek | I'll try to recreate the bug first, and then file it | 13:27 |
| wysek | ok I recreated the bug | 13:37 |
| wysek | but | 13:37 |
| wysek | I still think it's a bzr bug | 13:37 |
| wysek | what I did is: | 13:37 |
| wysek | I had: dir1/ dir2/ dir2/file1 | 13:38 |
| wysek | then I did: bzr rm dir2/file1 ; bzr mv dir1 dir2/file ; rm -r dir2/file ; echo "new file contents" > dir2/file | 13:38 |
| wysek | then bzr commit | 13:39 |
| wysek | log says: | 13:39 |
| wysek | removed: dir2/file1 | 13:39 |
| wysek | renamed: dir1 => dir2/file1 | 13:39 |
| wysek | modified: dir2/file1 | 13:39 |
| wysek | it does not say that a dir changed into a file :) | 13:39 |
| abentley | wysek: When you did "bzr rm", you told bzr that you deleted the file. If you wanted to change the file type, you should have just used "rm". | 13:43 |
| wysek | abentley: I did that by a mistake. I didn't want to revert the changes as there were too many changes. | 13:44 |
| vila | mthaddon, spm, herb: PQM stucked again, should be the moon... | 13:47 |
| vila | herb: I don't know if you changed the way you kill whatever process but the yesterday occurrence was slightly different than usual | 13:47 |
| herb | vila: how so? | 13:47 |
| vila | the merge succeeded, yet the public branch didn't contain it... is pqm using some sort of local branch and push regularly ? (The next sumbision went well and made the first merge apparent) | 13:48 |
| wysek | jelmer: I've just submitted a bugreport | 13:50 |
| herb | vila: that's strange. I don't know what would have caused that. pqm should build a fresh tree every time from the public branch. | 13:50 |
| jelmer | wysek, thanks | 13:50 |
| vila | Also, I think poolie has a fix for it in the bzr-email plugin but 1) I'm not sure, 2) I don't really know what should be done to get that fix taken into account on pqm (but don't spend time investigatin until we at least try that fix) | 13:50 |
| jelmer | abentley, a kind change while keeping the file id is allowed inside bzr though, right? | 13:51 |
| jelmer | abentley, even if not recommended | 13:51 |
| abentley | jelmer: Sure thing. | 13:51 |
| wysek | ok thanks a lot, cu guys | 13:54 |
| herb | vila: should be fixed now. | 13:56 |
| vila | herb: sounds like some thing happened, http://bazaar-vcs.org/bzr/bzr.dev/ doesn't mention revno 4064 (revision-id:v.ladeuil+lp@free.fr-20090227084553-ritia8ukxh8i25po) | 13:59 |
| vila | s/some/same/ | 13:59 |
| vila | grrr | 13:59 |
| vila | herb: yet, I'm pretty sure the merge succeeded, is there some mirroring between pqm and bazaar-vcs.org ? | 14:00 |
| jimmy_dean | anyone know if it's possible to push a local bzr branch up to a central repository with tortoisebzr? | 14:06 |
| barry | jelmer: hi! it's morning here in dc, so i want to try to find some time today to get bzr-svn 0.5.2 up on code.py.org | 14:06 |
| herb | vila: no. pqm commits to the public branch at the end of the run if the test suite completes successfully. It *may* do that after the email is sent though. I don't know pqm internals well enough to comment on that. | 14:07 |
| vila | herb: ok, thanks for the help anyway. I'll have to resubmit with crossed fingers :-/ | 14:08 |
| jimmy_dean | it doesn't seem like the functionality is in there yet and I just want to make sure I didn't miss it somewhere | 14:08 |
| RaceCondition | is it possible to have bzr generate patches to reverse existing patches? | 14:17 |
| RaceCondition | I wan't to revert the effect of a certain patch | 14:18 |
| luks | bzr merge (X-1)..X | 14:19 |
| luks | er | 14:19 |
| luks | bzr merge -r (X-1)..X | 14:19 |
| luks | actually, still wrong | 14:19 |
| luks | bzr merge -r X..(X-1) | 14:19 |
| RaceCondition | and I can also do bzr merge -r (X-n)...(X-m)? | 14:20 |
| luks | you can use any revision range | 14:20 |
| RaceCondition | and the range is inclusive on both ends, right? | 14:20 |
| RaceCondition | so when I do -r 19..9, all revisions from 9 to 19 including 9 and 19 are reverted? | 14:21 |
| luks | if you are talking about revisions, then yes | 14:21 |
| RaceCondition | yeah | 14:21 |
| luks | it will take revision 19 and revision 9 | 14:21 |
| luks | and compare them | 14:21 |
| RaceCondition | $ bzr merge -r 19..9 | 14:21 |
| RaceCondition | bzr: ERROR: No location specified or remembered | 14:21 |
| luks | use . as the location | 14:21 |
| RaceCondition | ok | 14:22 |
| RaceCondition | and is it also possible to delete existing patches? | 14:25 |
| luks | bzr doesn't have patches, you mean revisions? | 14:25 |
| RaceCondition | looks like the 19..9 range was a bit wrong because some changes were not reverted | 14:25 |
| RaceCondition | revisions, yeah, same thing.. | 14:25 |
| luks | no, it's all immutable | 14:25 |
| luks | the point is that revisions are states, not changes | 14:26 |
| luks | maybe the range was incorrect | 14:26 |
| RaceCondition | it's all immutable? like SVN? | 14:26 |
| RaceCondition | that's bad | 14:26 |
| luks | "more" immutable than SVN :) | 14:26 |
| RaceCondition | is there just some way I can simply return to a specific revision? | 14:27 |
| vila | herb: right, this is getting more obscure by the minute :-) pqm now refuses to merge saying there is nothing to merge, yet the branch it is asking to merge contain my revisions :-) Oh well, I think we need to escalate that :) lifeless ? | 14:27 |
| luks | do you want a new branch completely ignoring the old revisions or the existing branch changed to have files like in the old revisions? | 14:27 |
| RaceCondition | luks: looks like the range is non-inclusive | 14:28 |
| RaceCondition | 19..9 means 19-10 really | 14:28 |
| luks | RaceCondition: because you are thinking in changesets, not revisions | 14:28 |
| luks | the -r option specificies revisions | 14:28 |
| RaceCondition | whatever | 14:28 |
| RaceCondition | I mean, even revision wise, this could still have been inclusive | 14:29 |
| luks | they are | 14:29 |
| luks | 19..9 does exaclty this: take revision 19, take revision 9, compare them and apply the reversed patch | 14:29 |
| herb | vila: what was your change? | 14:31 |
| vila | revno 4064 (revision-id:v.ladeuil+lp@free.fr-20090227084553-ritia8ukxh8i25po) | 14:31 |
| herb | vila: was that a change to the NEWS file? | 14:33 |
| vila | herb: revno 4063 v.ladeuil+lp@free.fr-20090227082909-6i864fof6qyksm87 includes a change to NEWS, 4064 fixed a 2.4 compatibility bug in bzrlib/transport/ftp/__init__.py | 14:35 |
| vila | the submission includes both | 14:36 |
| herb | vila: ok. I'm going to get the tree in a state where you can submit 4063 and 4064 again. give me a couple of minutes. | 14:37 |
| vila | herb: ok, so the tree is refreshed instead of created from scratch then ? | 14:38 |
| herb | vila: it seems that way. | 14:38 |
| jam | morning all | 14:45 |
| beuno | hiya jam | 14:45 |
| barry | jam: morning! | 14:46 |
| barry | jelmer: any possibility of getting bzr-svn 0.5.2 into the ppa? i'd really love to update code.py.org today | 14:47 |
| jam | hi beuno, barry | 14:47 |
| herb | vila: try to submit now. it should work. | 14:48 |
| vila | herb: thanks, done | 14:49 |
| jelmer | barry, I've just uploaded to the PPA (hardy only) | 14:50 |
| barry | jelmer: perfect! let me see if i can grab it. thanks | 14:50 |
| jelmer | barry, it'll take some time to build | 14:50 |
| barry | jelmer: right! okay, i'll wait a bit, thanks | 14:50 |
| jelmer | Is there any chance brisbane-core is going to make it into 1.13? | 14:52 |
| jam | jelmer: I think we are targetting late March, after the next get-together | 14:53 |
| jelmer | ah, hmm | 14:53 |
| jam | I *just* got it to the point where inventory compression is reasonable | 14:53 |
| jelmer | so the OOo folks won't be able to take that into account | 14:53 |
| jam | we've had excuses to push things earlier based on real-world needs | 14:53 |
| jam | but I think we'd like to make this one a bit more polished | 14:54 |
| jam | We might have it as a '--development' in 1.13, but I don't think OOo would count that, right? | 14:54 |
| jelmer | I have no idea | 14:54 |
| jelmer | they said "released versions", so I guess not | 14:55 |
| jelmer | converting to 1.9-rich-root is a real PITA, took me a whole night to do 30k revisions | 14:56 |
| === ja1 is now known as jam | ||
| barry | jelmer: ROCK! time bzr pull on the 2.5 branch: 1m8s :) | 15:38 |
| jelmer | barry: :-) | 15:39 |
| barry | jelmer: thanks so much. i'm wondering if i should try svn-import again? | 15:39 |
| barry | jelmer: i have branches = ... in my subversion.conf file, which should limit to just the branches i care about, right? | 15:40 |
| barry | jelmer: that does not include the 2.0 branch which we were having problems with | 15:40 |
| jelmer | barry, yep | 15:40 |
| jelmer | barry, in that case, I think it should work | 15:40 |
| barry | jelmer: let's give it a shot! | 15:41 |
| jam | jelmer: do you know if the caching changes I gave you had a perf impact for importing something like OOo? | 15:57 |
| jelmer | jam, I haven't tried yet | 15:57 |
| vila | herb: submitted and... stucked again, not my day :-) | 16:00 |
| herb | vila: boo | 16:01 |
| herb | vila: ok. I'll see if I can clear it up. | 16:01 |
| * LarstiQ gets confused trying to preserve merged revisions with bzr-svn pushing back to svn | 16:02 | |
| rbriggsatuiowa | is there a quick way I could find what revision I deleted a file in? | 16:02 |
| LarstiQ | rbriggsatuiowa: other than looking at `bzr log -v`? | 16:04 |
| vila | herb: I submitted once again but with a different public branch, let's see if it works better | 16:04 |
| herb | vila: I was going to suggest breaking it up into two commits to see if one part or the other is causing a problem. | 16:05 |
| herb | vila: but we'll go ahead with this. | 16:05 |
| rbriggsatuiowa | yeah - my bzr log -v is dragging down my machine | 16:06 |
| vila | herb: I usually submit a single revision and still encounter the problem, so I'm pretty sure this isn't related | 16:06 |
| herb | ok | 16:07 |
| === Leonidas is now known as Leonidas1880 | ||
| === Leonidas1880 is now known as Leonidas1980 | ||
| === Leonidas1980 is now known as Leonidas | ||
| barry | jelmer: ping | 17:48 |
| jelmer | barry, pong | 17:49 |
| barry | jelmer: hi. bzr svn-import pulled in too much it seems | 17:49 |
| jelmer | too much? | 17:50 |
| barry | jelmer: well, i wanted to limit it to updating only the 5 or so branches that we're publishing through bzr, but it pulled in everything under http://svn.python.org/projects | 17:51 |
| barry | jelmer: i guess what i'm trying to mimic is say 'bzr pull in each of the 5 branches i care about' and ignore everything else in that svn repo | 17:52 |
| jelmer | barry, what was the output from svn-import exactly? | 17:53 |
| barry | jelmer: it didn't really output much except for the progress bar, which i didn't watch too closely | 17:54 |
| jelmer | barry, there should be a line saying what repository layout it was going to use | 17:54 |
| barry | jelmer: if it did, it didn't survive my control-C :/ | 17:56 |
| barry | jelmer: but the subversion.conf now has branching-scheme = trunk1 branching-scheme-guess = trunk1 | 17:56 |
| jam | barry: sounds like it didn't see your specific listing request | 17:57 |
| jam | or I had you format it wrong, etc | 17:57 |
| barry | jam, jelmer let me pastebin what i've got | 17:57 |
| jelmer | ah, of course.. | 17:58 |
| barry | jam, jelmer http://pastebin.ca/1348884 | 17:58 |
| jelmer | barry: branches = * won't work with v3 mappings | 17:59 |
| barry | ah | 17:59 |
| barry | sounds like i really want to update to v4 ;) | 17:59 |
| barry | well, for now i think i'll just cron a 'bzr pull' in each directory separately | 17:59 |
| barry | and when/if the experiment ends, i'll do things the right way at that time | 18:00 |
| barry | with bzr-svn 0.5.2, those are very quick now! :) | 18:00 |
| barry | jam: we talked about doing the bzr pack. should i do that in the shared repo directory or in the individual branch directories? | 18:01 |
| barry | <barry> ah | 18:02 |
| barry | <barry> sounds like i really want to update to v4 ;) | 18:02 |
| barry | <barry> well, for now i think i'll just cron a 'bzr pull' in each directory separately | 18:02 |
| barry | <barry> and when/if the experiment ends, i'll do things the right way at that time | 18:02 |
| barry | <barry> with bzr-svn 0.5.2, those are very quick now! :) | 18:02 |
| barry | * thekorn_ (n=markus@a89-183-70-151.net-htp.de) has joined #bzr | 18:02 |
| barry | <barry> jam: we talked about doing the bzr pack. should i do that in the shared repo directory or in the individual branch directories? | 18:02 |
| jam | barry: so first off, I see your repo got quite a bit bigger, is this because of the extra branches? or is there just a lot of stuff going on? | 18:03 |
| jam | and you run 'bzr pack' at the root of the repo | 18:03 |
| barry | jam: i think it's because of all the extra branches i got with svn-import | 18:03 |
| barry | jam: i guess there's no way to clear that out? | 18:03 |
| jam | barry: well, branch out to another repo, and then bring it back, but not easily | 18:04 |
| jam | for now, we'll just live with it | 18:04 |
| barry | jam: dang. yeah | 18:04 |
| jam | it shouldn't impact things *too* much | 18:04 |
| jam | barry: though I seem to see about 200MB *more* data that was just brought in | 18:05 |
| jam | perhaps there is a mapping issue causing the data to be copied 2x ? | 18:05 |
| jam | ugh | 18:09 |
| jam | barry, jelmer: I see a mix of "svn-v3-trunk1" and "svn-v3-single1" in the index files | 18:10 |
| jam | which certainly sounds like a mismatched conversion | 18:10 |
| barry | jam: it's certainly possible that i f'd up somewhere ;) | 18:10 |
| barry | jam, jelmer the pack is finished | 18:11 |
| jam | barry: well, it just sounds like you effectively have 2 different conversions | 18:11 |
| jam | stored in the same repo | 18:11 |
| jam | which is a bit less than ideal | 18:11 |
| barry | jam: that doesn't sound good ;) | 18:11 |
| jam | since instead of being a 200MB repo, it is a 400MB now | 18:11 |
| barry | jam: that could affect branch times for clients, right? | 18:11 |
| jam | barry: so we should only be copying half the data, but it means seeking through the other data as we do it | 18:12 |
| jam | jelmer: do you know how you would get "svn-v3-single1" mapping? | 18:13 |
| jam | Is that what you get when you do "bzr branch" instead of "bzr svn-import" ? | 18:13 |
| jelmer | jam: Yes, that's what bzr-svn will use if the branching scheme it's determined doesn't match | 18:13 |
| jam | barry: so looking closer, it seems the only extras might be: | 18:14 |
| jam | sandbox%2Ftrunk%2F2to3 | 18:14 |
| jelmer | jam: (also specific to v3, v4 will always create the same svn-v4 mappings) | 18:15 |
| jam | is that one of the important branches? | 18:15 |
| barry | jam: no, that's one of the ones i don't care about and deleted after killing the svn-import | 18:15 |
| jam | barry: so what are the *specific* branches you are interested in? | 18:16 |
| jam | (I'm a bit confused between '2.6/' and 'experimental/2.6' and some other such differences) | 18:16 |
| barry | jam: 2.5, 2.6, 3.0, py3k, trunk | 18:17 |
| jam | barry: and probably the 'users/'? | 18:17 |
| barry | jam: the experimental stuff is not the svn mirrors | 18:17 |
| jam | (though I assume those are native bzr branches) | 18:17 |
| barry | jam: right, users too | 18:17 |
| barry | i guess we care about experimental but i don't think anyone's using it afaik | 18:17 |
| barry | i don't even know what shared is for | 18:17 |
| === thekorn_ is now known as thekorn | ||
| barry | jam: perhaps we should get rid of experimental and shared | 18:18 |
| vila | herb: sorry for the delay, my last submission (using an http: public branch instead of a lp: one) went through | 18:30 |
| === beuno_ is now known as beuno | ||
| herb | vila: good news | 18:46 |
| vila | herb: I'll stick to that until I'm in a better position to diagnose the problem, I'm not sure using http is the right solution (I seem to remember having problems with that too, but my memory is blurry (it's hard to keep straight facts which such transient bugs)) | 18:48 |
| luke-jr | How can I clear the related branches (pull, push, submit) info? | 19:16 |
| james_w | luke-jr: there's currently no way through the UI | 19:19 |
| james_w | luke-jr: you can delete the entries from the config files | 19:19 |
| james_w | .bzr/branch/branch.conf or ~/.bazaar/locations.conf | 19:19 |
| Spaz | hm | 20:11 |
| tyhicks | I'm trying to figure out how to get a unified diff with commit message out of bzr. Google suggests that it it isn't possible, is that still the case? | 20:21 |
| LarstiQ | tyhicks: you'll have to be a bit more specific. diff and log produce that output, so what about that isn't good enough? | 20:22 |
| LarstiQ | tyhicks: or do you mean log -p? | 20:23 |
| tyhicks | LarstiQ: Well those are 2 different commands - maybe I'm being selfish in wanting it done in a single command? | 20:23 |
| LarstiQ | tyhicks: you're not being selfish | 20:23 |
| tyhicks | LarstiQ: I need to post a patch to a bugzilla ticket | 20:23 |
| LarstiQ | tyhicks: oh, in that case, use `bzr send` | 20:24 |
| LarstiQ | tyhicks: assuming the project uses bzr, maybe I shouldn't have assumed so? | 20:25 |
| tyhicks | LarstiQ: Yes, my project uses bzr | 20:25 |
| LarstiQ | tyhicks: this would be easier if I had enough context information :) | 20:25 |
| LarstiQ | tyhicks: ok, then `bzr send` sounds like the way to go | 20:26 |
| Spaz | i'm having issues with bzr svn-import | 20:26 |
| Spaz | [root@ind-prod003 /home/awos-bzr/repo]# bzr svn-import https://awos.svn.sourceforge.net/svnroot/awos . | 20:26 |
| Spaz | bzr: ERROR: Not a branch: "https://awos.svn.sourceforge.net/svnroot/awos/". | 20:26 |
| * tyhicks runs off to play with bzr send | 20:26 | |
| LarstiQ | Spaz: is bzr-svn listed in `bzr plugins` ? | 20:26 |
| Spaz | just svn | 20:27 |
| LarstiQ | right | 20:27 |
| LarstiQ | Spaz: bzr: ERROR: [Errno 0] Path 'https://awos.svn.sourceforge.net/svnroot/awos/' is not canonicalized; there is a problem with the client. | 20:34 |
| LarstiQ | Spaz: is what I get | 20:34 |
| Spaz | hm | 20:35 |
| tyhicks | LarstiQ: I'm still missing something with bzr send. I've already written up a nice commit message - but bzr send doesn't seem to include it in the unified diff. | 20:37 |
| LarstiQ | tyhicks: the produced bundle actually includes all metadata | 20:41 |
| LarstiQ | tyhicks: so you can bzr pull/merge that file | 20:41 |
| tyhicks | LarstiQ: But that bundle means nothing to the package maintainer who is viewing the bugzilla ticket | 20:42 |
| tyhicks | LarstiQ: No worries, I piped bzr diff to a file and copied the commit message from bzr log to the top of the diff. That doesn't take too long to do by hand | 20:43 |
| LarstiQ | tyhicks: I thought you said the project was in bzr? | 20:43 |
| tyhicks | LarstiQ: It is in bzr, but this is an external bug tracker and people viewing the bug need to see the commit message, not the bzr bundle | 20:44 |
| LarstiQ | maybe I'm too tird to make sense of this | 20:44 |
| LarstiQ | tyhicks: so what I think the maintainer would do, is bzr pull url/to/bug/tracker/attachement | 20:45 |
| LarstiQ | tyhicks: and get your changes | 20:45 |
| LarstiQ | tyhicks: no monkeying with diff and patch | 20:45 |
| Spaz | grr | 20:45 |
| LarstiQ | tyhicks: but if you want to do things manually, look at `bzr log -p` from 1.12+ | 20:45 |
| Spaz | what's the best (most reliable) way to migrate a bzr repository to svn | 20:46 |
| Spaz | i can't make a dump unfortunately | 20:46 |
| Spaz | as the repo is hosted on sourceforge | 20:46 |
| LarstiQ | Spaz: svn->bzr or bzr->svn? | 20:46 |
| Spaz | LarstiQ, svn->bzr | 20:46 |
| LarstiQ | Spaz: I would use bzr-svn | 20:46 |
| tyhicks | LarstiQ: They could do a pull, but it would be nice if they could simply view the patch and commit message in a vcs agnostic way in the bug ticket | 20:46 |
| Spaz | that requires a dump | 20:46 |
| Spaz | i can't get a dump as aforementioned | 20:47 |
| tyhicks | LarstiQ: Thanks for the help, I will take a look at bzr log -p as well | 20:47 |
| LarstiQ | Spaz: it doesn't, are you thinking of svn2bzr? | 20:47 |
| LarstiQ | tyhicks: hmkay, I don't understand your use case then | 20:47 |
| LarstiQ | Spaz: it does seem like the svn repo is acting up | 20:48 |
| Spaz | ooh, apparently i can get an svn dump via rsync | 20:49 |
| Spaz | hm | 20:49 |
| radix | yeah, bzr-svn doesn't need an SVN dump | 20:49 |
| Spaz | LarstiQ, i tried bzr-svn but it gave me errors | 20:49 |
| Spaz | and an inconsistent repo which made bzr reconcile crash | 20:50 |
| LarstiQ | jelmer: ^^ | 20:50 |
| tyhicks | LarstiQ: The use case is that not everyone uses bzr and lp. Sometimes individual patches have to be carried by maintainers, patches need to be shared through email, etc. | 20:51 |
| tyhicks | LarstiQ: I was just looking for a vcs agnostic way to share a diff and the commit message I already wrote for it | 20:52 |
| LarstiQ | tyhicks: That I get, but doesn't match my understanding of what you described. | 20:52 |
| LarstiQ | tyhicks: well, log -p for the simple case then | 20:52 |
| tyhicks | LarstiQ: cool, thanks again! | 20:52 |
| LarstiQ | tyhicks: little bit more involved if you need to roll up more than one revision | 20:52 |
| jelmer | Spaz: If you can make bzr-svn 0.5.x do that, I'd be very interested in a bug report.. | 20:56 |
| LarstiQ | jelmer: I can make 0.5.x do that | 20:57 |
| LarstiQ | jelmer: oh, depends on what you mean with 'that' | 20:57 |
| LarstiQ | jelmer: bzr ls 'https://awos.svn.sourceforge.net/svnroot/awos/' | 20:57 |
| LarstiQ | jelmer: for the canonicalized path | 20:58 |
| LarstiQ | and now I'm going to bed, ciao | 20:58 |
| jelmer | LarstiQ, the making reconcile crash | 20:58 |
| LarstiQ | jelmer: that, I don't know how to do | 20:58 |
| Spaz | jelmer, i'm using 0.5.2 | 20:59 |
| Spaz | jelmer, atm it doesn't work on my fbsd box, it works fine on my linux box but it results in a corrupted repo | 20:59 |
| jelmer | Spaz, public repo ? | 20:59 |
| Spaz | the repo isn't public | 20:59 |
| Spaz | but i can give you a tarball | 20:59 |
| Spaz | (well, not public yet, getting it ready) | 21:00 |
| jelmer | I'd be interested in a copy of the svn repo | 21:00 |
| jelmer | Not aware there are any corruption bugs left | 21:00 |
| Spaz | jelmer, https://awos.svn.sourceforge.net/svnroot/awos/, or get the raw repo by rsync -az awos.svn.sourceforge.net::svn/awos/ /foo/bar/ | 21:02 |
| jelmer | LarstiQ, fixed that one | 21:04 |
| jelmer | Spaz, imports fine here, at least trunk | 21:06 |
| jelmer | Spaz, what exactly goes wrong on your end? | 21:07 |
| === thumper_laptop is now known as thumper | ||
| Spaz | hm | 21:08 |
| Spaz | jelmer, http://pastebin.ca/1349026 | 21:09 |
| Spaz | on checkout | 21:09 |
| jimmy_dean | ok, so my co-worker had bzr delete a file (unintentionally) today when trying to do a commit to a bound branch | 21:10 |
| jimmy_dean | is there any kind of condition where this would happen because it's obviously not desirable | 21:10 |
| Spaz | jelmer, as for reconcile | 21:11 |
| Spaz | jelmer, http://pastebin.ca/1349028 | 21:11 |
| jimmy_dean | he did: bzr add myfile.doc | 21:11 |
| jimmy_dean | bzr commit | 21:11 |
| jimmy_dean | said his bound branch was out of date so he did "bzr commit --local" | 21:11 |
| jimmy_dean | bzr update (at this point his file was gone) | 21:11 |
| Spaz | jelmer, that's the result of doing bzr svn-import https://awos.svn.sourceforge.net/svnroot/awos/ . | 21:11 |
| Spaz | on the box it actually works | 21:11 |
| Spaz | on | 21:12 |
| Spaz | jelmer, should i just try doing trunk/branches separate? | 21:12 |
| jelmer | Spaz, ah, I think I can reproduce it as well now | 21:12 |
| jimmy_dean | anybody have any ideas? I can't seem to reproduce this myself | 21:13 |
| jelmer | jimmy_dean: Did he perhaps do a bzr revert after the update? | 21:13 |
| jimmy_dean | yes he did | 21:14 |
| jelmer | jimmy_dean, that would explain it | 21:14 |
| jelmer | jimmy_dean, "bzr up" will turn local commits into pending merges | 21:14 |
| jelmer | and "bzr revert" removes pending changes, including pending merges | 21:14 |
| jimmy_dean | jelmer, but the bzr revert was done after he had already lost the file | 21:15 |
| jelmer | Spaz, looks like a bzr-svn bug | 21:16 |
| Spaz | whee. | 21:16 |
| jelmer | Spaz, it's not picking up the fact there are old bzr-svn revisions in that svn repo for some reason | 21:16 |
| Spaz | jelmer, any workaround? | 21:16 |
| jelmer | Spaz, no idea what's causing it yet | 21:16 |
| Spaz | ah ok | 21:17 |
| jimmy_dean | jelmer, I have the .bzrlog file from his Windows machine, mind taking a look at it on pastebin? | 21:17 |
| jelmer | jimmy_dean, sorry, already kindof busy looking into this bug spaz is running into | 21:17 |
| jimmy_dean | oh ok, thanks anyway! | 21:18 |
| jam | jimmy_dean: I'll take a peek | 21:18 |
| jimmy_dean | jam: thanks, one sec | 21:19 |
| jelmer | Spaz, found it | 21:22 |
| Spaz | hm? | 21:23 |
| Spaz | jelmer, where is it? :o | 21:23 |
| jimmy_dean | jam: ok | 21:24 |
| radix | aw dang, bzr-svn isn't built for dapper? | 21:24 |
| jimmy_dean | jam: the file to look for in the log is: Battery Controller CoProcessor Specifications.doc | 21:24 |
| jimmy_dean | jam: http://pastebin.ca/1349047 | 21:24 |
| Spaz | jelmer, the reconcile problem was discovered a while ago: https://bugs.launchpad.net/bzr/+bug/297024 | 21:25 |
| ubottu | Ubuntu bug 297024 in bzr "bzr reconcile crashes" [Undecided,New] | 21:25 |
| jam | jimmy_dean: there is no 'update' or 'commit' in this log | 21:25 |
| jam | perhaps in ".bzr.log.old" ? | 21:26 |
| jam | (we keep 1 level of backlog) | 21:26 |
| jelmer | Spaz, that's just a similar traceback, it's a different bug | 21:26 |
| jimmy_dean | jam: I truncated it, perhaps I was too aggressive, let me paste the whole thing | 21:26 |
| jimmy_dean | jam: http://pastebin.ca/1349052 | 21:27 |
| jelmer | Spaz, I've pushed a fix | 21:28 |
| jelmer | Spaz, You'll have to remove ~/.bazaar/svn-cache and your existing repo | 21:28 |
| Spaz | ok | 21:28 |
| jam | jimmy_dean: so.. it looks like it was an 'update' triggers a merge, which failed half-way through because of an open file, and then the following update finished, but the file was gone | 21:33 |
| jam | the good news, is that you should be able to do "bzr heads --dead" | 21:34 |
| jam | and find the revision that the branch used to be at | 21:34 |
| jam | so you can do "bzr merge . -r revid:XXX" | 21:34 |
| jimmy_dean | excellent, thanks...we'll give that a shot | 21:34 |
| jml | jelmer: hi | 21:34 |
| jam | I would have thought that a merger failing half-way through would have rolled-back the action, but I guess not | 21:34 |
| jml | jelmer: so, I'm importing Twisted with bzr-svn using "bzr svn-import --incremental svn+ssh://svn.twistedmatrix.com/svn/Twisted Twisted" | 21:35 |
| jelmer | jml: Hey! | 21:35 |
| jml | jelmer: it's copied 20000+ revisions, but it's going really, really, really slowly on the last few thousand. | 21:35 |
| * jelmer gives it a try as well | 21:36 | |
| jelmer | jml: how large is the tree? | 21:37 |
| jml | jelmer: an svn checkout is 42M | 21:37 |
| jml | < 2000 files and directories. | 21:38 |
| Spaz | jelmer, http://pastebin.ca/1349063 | 21:39 |
| Spaz | :S | 21:39 |
| jimmy_dean | jam: success! my co-worker said I'm his hero, how you're my hero | 21:40 |
| jelmer | Spaz, you need bzr.dev for bzr-svn trunk | 21:40 |
| Spaz | ah ok | 21:40 |
| jelmer | Spaz, sorry about that | 21:40 |
| Spaz | eh it's fine. | 21:41 |
| jam | jimmy_dean: always happy to help | 21:42 |
| jimmy_dean | jam: so do you think that's a bug for bzr on Windows? | 21:42 |
| jimmy_dean | because Windows is super aggressive in its file locking | 21:42 |
| eix | jimmy_dean did you ever tried linux ? | 21:43 |
| jam | jimmy_dean: sort of, yeah. we certainly should have an alternate way of resolving a locked file than aborting in the middle of an update | 21:43 |
| jam | we'd still have to do some sort of conflict resolution | 21:43 |
| jimmy_dean | eix: yes, I use Linux but this machine has to be Windows | 21:44 |
| jimmy_dean | and he uses Linux for certain things | 21:44 |
| eix | jimmy_dean no machine has to be Windows :-) | 21:44 |
| jimmy_dean | eix: it does if only certain software runs on it | 21:45 |
| eix | jimmy_dean use alternatives | 21:45 |
| jimmy_dean | there aren't any | 21:45 |
| menesis | same wiht my girlfriends computer - she has to use a certain licensed application for her job. but I admit I have not tried to run it under WINE... | 21:46 |
| jelmer | jml: And you're using bzr-svn trunk? | 21:47 |
| jelmer | jml: whoa, that's a lot of branches | 21:47 |
| jml | jelmer: yes and YES | 21:50 |
| jml | jelmer: Twisted's been using the same dev process as bzr and Launchpad except in Subversion :) | 21:50 |
| jelmer | jml: nice :-) I think that's the first project I see that actually uses cheap branching in subversion | 21:51 |
| radix | we could probably clean up a lot of the dead branches. I'm not sure when we did that last. | 21:51 |
| jelmer | jam: What's this mutter message for: | 21:51 |
| jelmer | 324.402 Collapsed 1 keys into 1 requests w/ 1 file_ids w/ sizes: [336] | 21:51 |
| radix | we're into swap on that svn server. | 21:51 |
| radix | although I don't think it's actively swap*ping* | 21:52 |
| radix | (how can I tell that?) | 21:52 |
| jimmy_dean | eix: like SolidWorks for 3D modeling | 21:52 |
| eix | jimmy_dean try blender ;) | 21:52 |
| jimmy_dean | eix: I love Linux don't get me wrong, I'm sold out on it...but I also like to use the best tool per each job | 21:52 |
| eix | jimmy_dean I'm really thirsty I want linux to be adopted in business world... | 21:53 |
| menesis | is there a way to exclude branches by pattern using `bzr svn-import`? | 21:53 |
| jimmy_dean | eix: Blender is not optimized for 3D modeling for creating industrial product that you'll send and have a factory make | 21:53 |
| eix | not only for their damn servers | 21:53 |
| eix | ah | 21:53 |
| jam | jelmer: just tracking how we split up a request for XX files into YY bytes | 21:54 |
| jimmy_dean | jam: I think I'll add my co-worker's experience as a bug and let the developers decide if it actually is one or not | 21:54 |
| jelmer | jam: so that's mainly useful for remote transports, I guess? | 21:54 |
| jimmy_dean | jam: thanks again for the help...you saved a month's worth of work redo | 21:54 |
| jam | jelmer: generally, though it isn't really necessary overall | 21:54 |
| jam | hence mutter() | 21:54 |
| jam | we can remove it if it is causing you problems | 21:55 |
| jelmer | it's ok, but a little bit verbose compared to everything else | 21:55 |
| jml | jelmer: have you fixed anything performance related in bzr-svn over the last day or so? | 21:55 |
| jelmer | jml: not really | 21:55 |
| jml | jelmer: hmm. ok. | 21:55 |
| jml | so, I'm wondering if this is a memory thing. | 21:56 |
| jelmer | jml: If memory is a problem for you, do you have the latest subvertpy? | 21:56 |
| jml | jelmer: yes. | 21:56 |
| jelmer | I'm about to reach r1000 | 21:56 |
| jml | jelmer: of ~27k? | 21:57 |
| jelmer | 1084/34680 | 21:57 |
| jml | jelmer: ok. | 21:58 |
| vila | while _tasks and now >= _tasks[0].timeout: | 21:58 |
| vila | IndexError: list index out of range | 21:58 |
| jelmer | jml: Is that similar to what you were seeing? | 21:58 |
| jml | jelmer: I've hit Ctrl-C and restarted the process a couple of times now. | 21:58 |
| vila | doh | 21:58 |
| jml | so it's "copying revision 779/5703" | 21:58 |
| jelmer | ah | 21:58 |
| jml | "2439.492 Collapsed 1 keys into 1 requests w/ 1 file_ids w/ sizes: [1390946] | 21:59 |
| jml | " is the last thing in the log. | 21:59 |
| jelmer | jml: Strange, there shouldn't be a particular reason for it to get slower over time | 21:59 |
| radix | could be the server? | 21:59 |
| radix | but it doesn't seem to be under particular load. dunno | 21:59 |
| jelmer | jml: That last bit is pretty large | 21:59 |
| jml | jelmer: yeah. actually I'll pastebin a chunk of the log. | 22:00 |
| jelmer | hmm, I need "bzr svn-import -j" | 22:00 |
| radix | heh | 22:01 |
| jml | actually I won't pastebin the log. | 22:05 |
| jml | since it just interrupted itself, I think | 22:05 |
| lifeless | moin | 22:06 |
| jml | lifeless: good morning. | 22:06 |
| lifeless | jml: nose uses 'inspect the exception in addError', and have a deprecated addSkip | 22:07 |
| radix | interrupted? as in, blew up? | 22:07 |
| lifeless | bzr uses inspect the exception in addError | 22:07 |
| jml | lifeless: sweet. | 22:07 |
| jml | lifeless: I like that way of doing it as well. | 22:07 |
| lifeless | why | 22:07 |
| jml | lifeless: because it makes the interface narrower and easier to use with other pyunit things | 22:08 |
| jml | lifeless: what do you think? | 22:08 |
| lifeless | jml: bzr does it that way to meet the pyunit protocol; I don't think narrow is particularly strong as a reason | 22:08 |
| jml | lifeless: neither do I. | 22:08 |
| lifeless | I want to change the protocol | 22:09 |
| jml | lifeless: you want addSkip? | 22:09 |
| lifeless | I think a stronger question is 'does the source of the skip event matter | 22:09 |
| jml | lifeless: by "source", do you mean the test? | 22:09 |
| lifeless | line of code | 22:10 |
| jml | 85% mem usage :( | 22:10 |
| lifeless | addError and similar interfaces give you a stack trace | 22:10 |
| lifeless | so they pinpoint where it happened | 22:10 |
| lifeless | addSuccess and similar don't | 22:10 |
| jml | lifeless: so, I can't think of a use-case where I'd want that information beyond having the name of the test. But I can't think of a good reason to *not* have that information either. | 22:12 |
| jml | lifeless: so I'm wondering why you think it's an important question? | 22:12 |
| lifeless | if we start with the premise of designing for python inclusion; then the base classes for both test and result will be in sync, so 'pyunit compatibility' isn't hard any which way; so I then started thinking about how the different approaches vary | 22:13 |
| jml | jelmer: is it possible that there's a particularly troublesome revision? | 22:13 |
| jelmer | jml, could be; a particularly big file, for example | 22:14 |
| jelmer | jml: Did you re-build subvertpy ? | 22:15 |
| jml | jelmer: I got the trunk for it and ran python setup.py install | 22:15 |
| Ollie_R | is there anyway to get a readout of transfer speeds when doing a bzr co over sftp. There is a progress bar but it is very vague, and seems to jump in large chunks which is not especially useful. The verbose argument also doesn't give any more info | 22:15 |
| jml | jelmer: but that was 1-2 days ago. haven't done anything to it since. | 22:15 |
| jml | Ollie_R: what version of bzr are you using? | 22:16 |
| jelmer | jml: That should do it | 22:16 |
| Ollie_R | jml: i believe 1.5 let me check | 22:16 |
| jelmer | jml: another copy of subvertpy installed by PPA perhaps? | 22:16 |
| jelmer | I'm at 3500 now | 22:17 |
| Ollie_R | Bazaar (bzr) 1.3.1 on both client and server/repo | 22:17 |
| jml | Ollie_R: upgrade. the progress bar is substantially improved. | 22:17 |
| jml | (as indeed is the rate of progress :)) | 22:17 |
| Ollie_R | ah ok great | 22:18 |
| Ollie_R | do both client and server need to be running the same versions? | 22:18 |
| lifeless | jml: what i have so far is 'addSkip is clearer for implementors of Results; it can have a exc_info if desired; its not innately compatible with existing TestResult objects that didn't subclass TestResult' | 22:18 |
| jml | jelmer: I can't find a python-subvertpy or a python2.5-subvertpy package | 22:19 |
| lifeless | jml: 'addError is unclear for implementors as they don't have a full list of exceptions-that-are-skips, that-are-expected-fail, etc; using addError will mean that tests that skip show up as errors rather than as test-framework issues, and using addError defines that there will be a stacktrace' | 22:20 |
| fullermd | Ollie_R: Not in theory at least. I run with a 1-2 version skew pretty regularly without problems. | 22:20 |
| fullermd | I've never tried a ~9 version skew, but I would guess it works OK (though it may not show much improvement on some things, since both sides wouldn't support $SOMETHING_NEW) | 22:21 |
| * jml afk | 22:21 | |
| Ollie_R | the version labelling is kind of strange bzr 1.1rc1 2008-01-05 bzr 1.9 2008-11-07 bzr 1.10rc1 2008-11-28 bzr 1.11rc1 "Eyes up!" 2009-01-09. Expected it to go to 2.0 - kind of strange | 22:23 |
| fullermd | It can't go to 2.0 until it can read email. Law of nature. | 22:23 |
| Ollie_R | fullermd: being serious? | 22:24 |
| fullermd | I'm always serious. | 22:24 |
| fullermd | Or is it never? One of the two. | 22:24 |
| Ollie_R | hah | 22:25 |
| Ollie_R | so which version is considered stable atm | 22:25 |
| radix | Ollie_R: that's not really strange at all | 22:25 |
| Ollie_R | just noticed i am running 1.5 on my macbook | 22:25 |
| lifeless | Ollie_R: 1.12 | 22:25 |
| fullermd | The latest release, generally. | 22:25 |
| radix | Ollie_R: versions are not decimal | 22:25 |
| radix | this is pretty common in lots of software | 22:26 |
| Ollie_R | radix: hmm some apps go from 1.9 to 2.0 though. So if something is 1.9 you have no reference if it is going to go to 2.0 or 1.10,,, | 22:26 |
| fullermd | Well, lots of apps go from 1.4 to 2.0 too.. | 22:27 |
| fullermd | Heck, bzr went from 0.18 to 0.90, which is still WAY weirder in my book. | 22:27 |
| jml | lifeless: let me think out loud for a bit | 22:28 |
| Ollie_R | well my box here is 1.3.1 which at a glance looks like a newer version than 1.12 so that seems odd to me | 22:28 |
| Ollie_R | neways all a little irrelevent | 22:28 |
| radix | once you internalize the fact that versions aren't decimal, you'll get over it :) | 22:28 |
| Ollie_R | radix: yep | 22:28 |
| jml | lifeless: the way I see it, there are two ways to add more types of events to unittest: add more methods to the listener interface or enrich the object that represents the event | 22:29 |
| fullermd | It would probably confuse more people if we called it "1.C" :p | 22:29 |
| jml | lifeless: I guess if I wrote unittest in the first place, I would probably have defined a TestResultEvent class and sent those to TestResult, rather than the multiple-method approach they have now | 22:30 |
| jml | lifeless: incidentally, you used to consider "using addError will mean that tests that skip show up as errors rather than as test-framework issues" to be a good thing | 22:32 |
| jml | lifeless: have you changed your mind? | 22:32 |
| lifeless | jml: that was designed around pyunit | 22:33 |
| lifeless | jml: I'm designing for pyunit now | 22:34 |
| jml | lifeless: :D | 22:34 |
| jml | lifeless: part of our "ply mwhudson with whisky until he commits testtools to trunk" plan? | 22:34 |
| * mwhudson blinks | 22:35 | |
| jml | mwhudson: sssh. it's a secret plan. | 22:35 |
| * mwhudson goes away again | 22:35 | |
| mwhudson | oh, cpython trunk? | 22:36 |
| jml | yeah. | 22:36 |
| jml | lifeless: what do you want addSkip's parameters to be? | 22:39 |
| jml | lifeless: and how do you see this interacting with Feature support. | 22:39 |
| lifeless | jml: I thought it was offer mwhudson whiskey but withhold until he commits it | 22:40 |
| jml | lifeless: it's a delicate balance. | 22:40 |
| mwhudson | alka seltzer would be a better inducement this morning, i think | 22:41 |
| jml | mwhudson: :) | 22:41 |
| lifeless | jml: so that was why the question about exc_info relevance | 22:43 |
| lifeless | jml: I think TestResultEvents are messages, and xUnit has a smalltalk heritage where messages are messages | 22:43 |
| lifeless | jml: which is to say TestResultEvent isn't any better than explicit method calls for this, IMO | 22:44 |
| === barry is now known as barry-away | ||
| Ollie_R | am i right in thinking that if i do a light checkout from a to b then i can't do a checkout from b to c ? | 22:45 |
| lifeless | Ollie_R: if you do a checkout from b to c, it will be a checkout from a to c | 22:45 |
| lifeless | Ollie_R: if you want multiple branches, the branch command makes new branches | 22:46 |
| Ollie_R | i want to start using bzr to deploy websites. so i have a repo and my develoeprs checkout locally. Then my website is a checkout of the repo which I update as and when i need to | 22:46 |
| lifeless | I suggest you use the bzr-upload plugin | 22:47 |
| lifeless | developed by a guy at a website hosting company :) | 22:47 |
| Ollie_R | but obviously as the dir is going to be web enabled I don't want people to be able to checkout from my actual website | 22:47 |
| Ollie_R | lifeless: yeah i know of it | 22:47 |
| jml | lifeless: that's why I'm interested in addSkip's parameters :) | 22:47 |
| brutimus | the authentication ring (authentication.conf) stuff made it into mainline, right? (this stuff http://bazaar-vcs.org/DraftSpecs/AuthenticationRing) | 22:48 |
| lifeless | brutimus: yup | 22:48 |
| brutimus | ok thank you lifeless.. i must be doing it wrong then :-) | 22:48 |
| billiejoex | I'm sorry, I'm trying to get a copy of bazaar source branch but I get this error: http://rafb.net/p/b4T8mc45.html | 22:49 |
| lifeless | jml: I think that addSkip(test, str()_able_reason) is minimal and meets the needs of all tests I've seen | 22:49 |
| lifeless | billiejoex: you have an older version of bzr | 22:49 |
| jml | lifeless: are you planning on using skip for features? | 22:49 |
| jml | lifeless: and how do tests signal a skip | 22:49 |
| Ollie_R | yeah bzr-upload plugin isn't quite right as oddly I want to be able to commit from the live checkout to send back the users files added to the live site via a cms. | 22:49 |
| Ollie_R | basicially normal bzr will work i just need to prevent people checking out from http://www.example.com/ when the site is live | 22:50 |
| jelmer | lifeless: it's a bit unfortunate that lenny has 1.5, making it impossible to checkout bzr.dev :-/ | 22:51 |
| Ollie_R | bzr-upload basicially just looks like bzr revision history linked in with a rsync | 22:51 |
| lifeless | Ollie_R: checkout --lightweight will have that property; but just blocking the .bzr dir in apache will have it too | 22:52 |
| Ollie_R | lifeless: ok brilliant thanks for that bit of info, cleared things up nicely. Hadn't considered doing this via apache actually | 22:52 |
| billiejoex | lifeless: 'm using the latest 1.12 version | 22:53 |
| lifeless | billiejoex: 1.12 can read 1.9 | 22:53 |
| lifeless | billiejoex: what does 'bzr --version' show ? | 22:53 |
| billiejoex | lifeless: 1.6.1 | 22:54 |
| lifeless | billiejoex: then thats the version you're actually using | 22:54 |
| billiejoex | I thought I did get the 1.12 version :\ | 22:54 |
| lifeless | :> | 22:54 |
| lifeless | jml: not sure re: features | 23:04 |
| lifeless | jml: TestCase.skip(), like TestCase.fail() | 23:05 |
| lifeless | jml: I'd kind of like TestCase.succeed() too :: | 23:05 |
| jml | lifeless: so it would raise an exception? | 23:05 |
| lifeless | yes, to allow dropping out of an arbitrary call depth | 23:05 |
| lifeless | which lets people write helpers to decide when to skip | 23:05 |
| jml | lifeless: what use cases are there for skip besides missing features? | 23:07 |
| lifeless | jml: expensive test, and expensive test mode not on | 23:09 |
| lifeless | jml: test enumeration [in a sick sort of way :P] | 23:09 |
| lifeless | jml: users may find others; probably will in fact :) | 23:09 |
| === montywi is now known as montywi|zzz | ||
| rasker | hi, how does one use the --stacked option in bzr branch? | 23:09 |
| jml | lifeless: those are good use cases. | 23:10 |
| jml | lifeless: so, I am thinking that missing features is a special kind of skip | 23:10 |
| jml | lifeless: is that the way it's done in bzr right now? | 23:10 |
| rasker | anyone? | 23:13 |
| jml | rasker: what are you trying to do? | 23:14 |
| lifeless | jml: self.requireFeature raises UnavailableFeature, which is not a subclass of SkippedTest, and there is an addNotSupported on bzr's TestResult | 23:15 |
| lifeless | jml: I'd be comfortable mapping that to skipped, at least for now | 23:16 |
| jml | lifeless: ok. | 23:16 |
| jml | lifeless: so I'm happy enough with adding addSkip. | 23:17 |
| jml | and not imposing any extra burden on addError. | 23:17 |
| rasker | jml I'm looking at a project that contains one feature/bugfix per branch. I'm writing a script that automatically merges a few branches against the release branch to see if anything breaks (sort of like 'continuous integration'). I'm thinking I can use the --stacked option to pull in the branches, stacked against the release branch | 23:18 |
| rasker | jml does that make sense? | 23:19 |
| jml | rasker: sure. | 23:19 |
| jml | rasker: probably easier than using stacked is to use shared repos | 23:19 |
| lifeless | jml: revno12 is tip ? | 23:20 |
| jml | rasker: so, bzr init-repo <project>; cd <project>; bzr branch <trunk url> trunk; bzr branch <branch url> <branch name> | 23:20 |
| jml | rasker: that second "branch" command will only fetch revisions that are in the branch but not in the trunk branch. | 23:20 |
| jml | lifeless: yes | 23:21 |
| jml | lifeless: man, it runs the full test suite in 0.006s -- why can't all my projects be like that. | 23:21 |
| rasker | jml right, I see. so the amount of data downloaded from launchpad for a trunk plus a bunch of it's development branches for example would be less? | 23:22 |
| rasker | for each branch | 23:22 |
| jml | rasker: yes. (if I understand you correctly) | 23:23 |
| jml | rasker: the trick is running init-repo in a directory above the branches. | 23:23 |
| rasker | jml great! Just what I was looking for. Just for interests sack then, how does stacked work (the docs are a bit hazy)? | 23:24 |
| lifeless | jml: because most of your projects do a bunch of things | 23:24 |
| jml | rasker: so, roughly speaking, a repository is a bucket for revisions | 23:25 |
| jml | rasker: a stacked branch is a branch whose bucket is missing most of its revisions, but has a pointer to another branch where those revisions can be found. | 23:26 |
| rockstar | jml, I branched difftodo. I have a patch that I'll want you to look at on Sunday. | 23:26 |
| jml | rockstar: awesome | 23:27 |
| jml | rockstar: why don't you submit a merge proposal? | 23:27 |
| rockstar | rockstar, I will when I'm not on a semi-hostile network. | 23:27 |
| * jml wants to use the sexy new diff generation stuff on Launchpad | 23:27 | |
| jml | rockstar: ahh ok. | 23:27 |
| jml | rockstar: where are you right now? | 23:27 |
| rockstar | jml, you've seen thumper's MAD, right? | 23:27 |
| rockstar | jml, in the Denver airport. They're boarding now. | 23:28 |
| jml | rockstar: I've seen its effects, not the actual code. | 23:28 |
| rasker | jml, ok, that makes sense. the repository then contains 'full' or complete branches? or is it something like, a repository uses stacked branches internally? | 23:28 |
| rockstar | jml, can you submit merge proposals for junk branches? | 23:29 |
| jml | rockstar: no you can't | 23:29 |
| rockstar | I didn't think so. | 23:29 |
| jml | rockstar: I guess I should register a project. | 23:29 |
| rockstar | Make a project please. | 23:29 |
| rockstar | :) | 23:29 |
| jml | rasker: not quite | 23:29 |
| jml | rasker: repositories don't contain branches | 23:29 |
| jml | rasker: they just contain revisions. | 23:30 |
| jml | rasker: quite often a branch contains its own repository | 23:30 |
| jml | rasker: this is what happens in the default case when you do 'bzr branch <foo>' | 23:30 |
| lifeless | difftodo is your python pending thing? | 23:31 |
| jml | lifeless: yeah. | 23:31 |
| lifeless | cool | 23:31 |
| lifeless | well, I'm -> lunch event | 23:31 |
| lifeless | I have testtools | 23:31 |
| lifeless | will make a skipped thing I think is beautiful | 23:31 |
| jml | lifeless: sweet. | 23:33 |
| jml | rasker: so, when you run init-repo in dir1/ and then branch to dir1/dir2/, Bazaar finds the repository in dir1/ and sticks all the revisions in there. | 23:33 |
| jml | rockstar: https://edge.launchpad.net/difftodo | 23:33 |
| jml | oh wait. the branch. | 23:34 |
| rasker | jml ok so repositories are more flexible and --stacked is basically used to save space? | 23:34 |
| jml | rasker: again, not quite :) | 23:35 |
| rasker | :) | 23:35 |
| jml | rasker: all branches have repositories whether you like it or not -- most of the time you don't have to care about this fact though | 23:35 |
| jml | rasker: both stacking and *shared* repositories are used to save space and prevent unnecessary network transfer. | 23:35 |
| rasker | jml perhaps if you could give me an example of where --stacked would be used I could differentiate them better? | 23:35 |
| jml | rockstar: https://code.edge.launchpad.net/difftodo | 23:36 |
| jml | rasker: perhaps, but no example is leaping to mind and it's past time for my morning shower :) | 23:36 |
| lifeless | rasker: --stacked is used to get a branch which *can only be used while online* but downloads less data [it skips all the history] | 23:36 |
| jml | rockstar: have a good flight | 23:37 |
| lifeless | rasker: a shared repository is used to allow many branches with common history to share the storage of their history | 23:37 |
| lifeless | rasker: imagine you have 1GB of history, and a working tree of 50MB | 23:37 |
| lifeless | rasker: a shared repository will need to download that GB. | 23:37 |
| lifeless | rasker: a stacked branch will download ~50MB | 23:37 |
| lifeless | rasker: but you can't use the stacked branch without being connected to the server that has the rest of that 1GB | 23:38 |
| lifeless | rasker: for many small but related branches a shared repo will work better - more setup time but you get offline support | 23:39 |
| rasker | jml lifeless !!!! Ok I finally understand !!!! Thank you both for taking the time to explain. | 23:40 |
| jelmer | jml: at 13k | 23:42 |
| jelmer | jml: When did it slow down for you exactly? | 23:42 |
| jml | jelmer: ~5000 before the end. | 23:43 |
| rasker | jml lifeless so basically --stacked effectively gets you the working tree and would do something like refer back to the original branch for the history if needed | 23:43 |
| lifeless | rasker: exactly | 23:44 |
| lifeless | I'm heading out now | 23:44 |
| lifeless | ciao | 23:44 |
| rasker | thanks | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!