| lifeless | igc: whats the testing guide and why isn't it part of the dev guide? | 00:10 |
|---|---|---|
| lifeless | sorry if that came across picky, I'm just a little surprised / concerned about fragmentation | 00:11 |
| igc | lifeless: someone moved it out (vila maybe) | 00:11 |
| igc | lifeless: http://doc.bazaar-vcs.org/developers/ | 00:12 |
| lifeless | oh | 00:12 |
| lifeless | so this is a terminology thing | 00:13 |
| lifeless | thats all dev guide to me | 00:13 |
| lifeless | and I suspect to poolie as well | 00:13 |
| lifeless | just chapters in the dev documentation | 00:13 |
| Peng_ | Is http://bazaar-vcs.org/bzr/.bzr/repository/packs/ really badly compressed, or did I accidentally misplace most of my repo while upgrading to 2a? | 00:20 |
| Peng_ | Oooh. Never mind. That is a 1.9-format repo. Hm. | 00:21 |
| Peng_ | Ohh! http://bazaar-vcs.org/bzr/bzr.dev/ is a branch reference now. Clever! | 00:22 |
| Peng_ | Confusing, too. | 00:22 |
| Peng_ | So lp:bzr is now the official location for bzr.dev? | 00:23 |
| lifeless | yup | 00:23 |
| Peng_ | What should I set bzr to use as the public/submit branch? | 00:24 |
| lifeless | check the docs ;) | 00:25 |
| Peng_ | :< | 00:25 |
| Peng_ | .....Which docs? :D (kidding) | 00:25 |
| lifeless | [I've paged it out] | 00:25 |
| Peng_ | The doc directory in the source tree doesn't help. | 00:26 |
| Peng_ | I'll keep the public and submit branches set to bazaar-vcs.org for now, then. | 00:28 |
| lifeless | Peng_: HACKING.txt | 00:31 |
| lifeless | look for locations.conf | 00:31 |
| Peng_ | Ah, thanks. That didn't help very much, though. I'm not a PQM user. | 00:36 |
| Peng_ | And LP is open source now. I have missed a lot! | 00:37 |
| lifeless | Peng_: well, lp:bzr then ;) | 00:39 |
| Peng_ | Literally "lp:bzr", or the http or bzr+ssh location that points to? | 00:40 |
| lifeless | literally | 00:43 |
| lifeless | if you just want 'bzr send' to work | 00:43 |
| Peng_ | OK. | 00:49 |
| poolie | hi all | 00:55 |
| poolie | welcome back igc | 00:55 |
| igc | thanks poolie | 00:55 |
| spiv | Good morning. | 00:55 |
| Peng_ | Good morning. Or whatever. :) | 00:55 |
| igc | hi spiv | 00:55 |
| Peng_ | Is it morning? | 00:55 |
| igc | hi Peng_ | 00:55 |
| igc | Peng_: it is here :-) | 00:56 |
| thumper | hi ho | 01:40 |
| thumper | what is the simplest way to allow people to push to a machine with bzr+ssh but not to have shell access? | 01:40 |
| Peng_ | There's a script, contrib/bzr_access or somesuch. | 01:41 |
| lifeless | authorized_keys policy | 01:41 |
| Peng_ | Yeah. | 01:41 |
| lifeless | and or that script | 01:41 |
| thumper | oh kay... | 01:41 |
| thumper | which is easier / more configurable? | 01:42 |
| lifeless | launchpad :P | 01:42 |
| Peng_ | Heh. | 01:42 |
| thumper | lifeless: haha | 01:42 |
| Peng_ | He's right... | 01:42 |
| thumper | where does the package install the contrib dir? | 01:42 |
| lifeless | I don't think it does | 01:42 |
| thumper | Peng_: it is for some friends polytech work | 01:42 |
| thumper | no project | 01:42 |
| thumper | and they don't want it public | 01:42 |
| thumper | and I don't want them poking around my machine | 01:43 |
| Peng_ | Umm. Install Launchpad on your machine? :D | 01:43 |
| thumper | heh | 01:43 |
| thumper | no | 01:43 |
| Peng_ | You could just give them SFTP access. | 01:43 |
| SamB_XP_ | Peng_: that isn't great | 01:44 |
| thumper | this should be an easy thing to set up for bzr | 01:44 |
| thumper | I've been frustrated that it wasn't easier | 01:44 |
| thumper | like sticky group bits | 01:44 |
| SamB_XP_ | Peng_: you'd want to give 'em smart server access too ... | 01:44 |
| thumper | and umasks | 01:44 |
| thumper | et al | 01:44 |
| thumper | I think we should be able to set something in the locations.conf (or something) | 01:44 |
| thumper | and have the smart server set the right groups | 01:44 |
| thumper | IMHO | 01:44 |
| Peng_ | SamB_XP_: I know | 01:45 |
| poolie | spiv, hello | 01:58 |
| spiv | poolie: hi | 01:59 |
| spiv | poolie: I've done a couple of rounds of "do something to a bug" "gar, file a bug on launchpad" this morning. | 02:00 |
| spiv | poolie: I have a fix for the 2 hpss vfs calls on incremental push; I've played a bit with trying to anticipate future requirements with the new verb I'm adding, but decided against it so I'll just submit the simple fix. | 02:01 |
| poolie | igc, to answer the only other question on our agenda | 02:03 |
| poolie | see my mail to emma on friday, i'm aiming to get the site up this week | 02:03 |
| poolie | from a shared branch deployed to escudero | 02:03 |
| poolie | spiv, cool | 02:03 |
| igc | poolie: thanks | 02:03 |
| poolie | or you can if you get to it first | 02:03 |
| poolie | spiv, we still seem to get a lot of 'medium(?) in use' errors | 02:03 |
| poolie | maybe this should be handled under -Dcleanup but perhaps there's something else we should do that would avoid them obscuring the real error? | 02:04 |
| spiv | poolie: hmm | 02:05 |
| poolie | my thoughts exactly :) | 02:10 |
| spiv | :) | 02:10 |
| poolie | maybe we'll try -Dcleanup first and then see what happens | 02:10 |
| poolie | or more importantly, putting a choke point for all cleanups | 02:10 |
| lifeless | spiv: whats trigering vfs on incremental push ? | 02:13 |
| spiv | lifeless: "cannot update remote workingtree" warning | 02:13 |
| lifeless | meep yes I saw that | 02:14 |
| lifeless | what was it? | 02:14 |
| spiv | push explicitly checks for a working tree so that it can issue that warning, and we have no HPSS way to find a working tree. | 02:14 |
| spiv | It doesn't actually care what format or anything it is, just whether or not there is one. | 02:15 |
| spiv | So I've made a new BzrDir.open verb that returns a yes/no for the presence of a workingtree in this bzrdir. | 02:16 |
| lifeless | +1 | 02:16 |
| lifeless | have you seen spurious outputs of that warning btw? | 02:16 |
| spiv | I could have made a has_workingtree verb, but may as well cut out the roundtrip and take the opportunity to slightly decruft the BzrDir.open verb :) | 02:16 |
| spiv | No, I don't think so. | 02:17 |
| lifeless | so, I think has_workingtree would be more precise | 02:17 |
| lifeless | but as we don't support working with them remotely anyway | 02:17 |
| lifeless | doing what you've done is fine | 02:17 |
| spiv | Right. | 02:18 |
| lifeless | what cruft are you deing? | 02:18 |
| lifeless | [if its the declarative capabilities, I'm not sure we want to remove them] | 02:18 |
| spiv | The current BzrDir.open verb squashes some error conditions into just 'yes'/'no', for backwards-compat reasons. | 02:18 |
| lifeless | I see, cool. | 02:19 |
| igc | poolie: one thing I forgot to discuss on the phone: elmo's email re the karmic chroot | 02:20 |
| igc | poolie: one of us should reply | 02:20 |
| zsquareplusc | hmm, why does multi-pull try to pull data from a file URL when i want to fetch from a bzr+ssh URL? even worse, it sees the path the branch was on the other machine from which i first pushed it up | 02:23 |
| spiv | zsquareplusc: it uses the remembered pull locations, IIRC. You can use "bzr pull --remember NEW_URL" in those branches to change that. | 02:24 |
| zsquareplusc | hm, doesn't this make the multi-pull more or less useless? it apparently manages to find these branches on the remote URL but then it turns to a completely different location to download?!? | 02:26 |
| spiv | zsquareplusc: no, it just does the same as "bzr pull" with no arguments would do in each of the individual branches. | 02:27 |
| spiv | Which is often the right thing, and if it's not it's usually easy to use either --remember or edit your locations.conf to make it do the right thing. | 02:28 |
| spiv | It would be nice to have a "pull all of these from *over there* just this once" feature too, though. | 02:28 |
| zsquareplusc | well the branches were created on one machine, converted from CVS. i pushed them to a repo on sf.net. so i have to manually touch each of these again, re-push etc :( | 02:30 |
| zsquareplusc | spiv: i disagree that it is doing the right thing in this case. i have no local copy yet, just and empty shared repo. i'd certainly expect that multi-pull downloads from the URL i'm giving it not from anywhere else. | 02:33 |
| zsquareplusc | how do i see the saved push location? bzr info? | 02:36 |
| zsquareplusc | because i don't see it there on the branch i pulled (one of those were multi-pull failed) | 02:36 |
| spiv | zsquareplusc: if you don't have a branch yet, then pull (and multi-pull) aren't the commands you need. | 02:38 |
| zsquareplusc | i don't see a multi-branch :/ | 02:38 |
| spiv | Yeah :( | 02:38 |
| spiv | I agree there are things we could support better, I'm just explaining that multi-pull is doing what it was designed to do. It would be nice to have multi-branch or similar. | 02:39 |
| spiv | We're actually planning to rethink how we deal with groups of branches for 3.0, because we know we're a bit lacking. | 02:40 |
| zsquareplusc | well if it would just fail, OK. what's irritating me is that it somehow remembers a local path on my other machine | 02:40 |
| zsquareplusc | i ran a bzr info on the branch i originally pushed, it has that file URL there listed as parent | 02:41 |
| spiv | zsquareplusc: that does sound weird. multi-pull walks all the subdirectories of the directory you run it in looking for branches to pull, perhaps one of those has a branch with that info? | 02:42 |
| spiv | Whatever multi-pull does with an individual branch you ought to be able to reproduce with plain "bzr pull" on that branch. | 02:42 |
| zsquareplusc | i gave it the URL of the remote repo, so it apparently walks trough those :/ | 02:43 |
| spiv | Oh! | 02:43 |
| spiv | That does sound likely to confuse, yes. | 02:43 |
| spiv | I guess that's like doing "bzr pull -d REMOTE_URL"... | 02:43 |
| zsquareplusc | that the branches remember that file:// parent does not hurt? at least the fresh branch i made from the remote repo (using bzr branch) does not list it anymore, it has the remote repo URL as parent, which makes more sense | 02:47 |
| zsquareplusc | and is there a special reason that when i bzr branch, that same URL is not right away saved as push, pull and merge location? at least the way i was using it, that would have been helpful | 02:49 |
| SamB_XP_ | spiv: yeah, it does seem a bit silly for it to be attempting to pull *into* an HTTP url ;P | 02:56 |
| spiv | SamB_XP_: there might be a smart server there :P | 03:01 |
| zsquareplusc | it was a bzr+ssh URL | 03:01 |
| SamB_XP_ | oh, that's a bit less dumb then | 03:02 |
| lifeless | I thought that the bug with bzrlib/bzrlib/*.so was fixed? | 03:09 |
| zsquareplusc | hmm. getting access denied on c:\...\temp\xxx.pag | 03:10 |
| zsquareplusc | i made a bash script that does several bzr branch(es) now when i run it under cygwins bash it prints that its connected using ssh and then the error about access denied on the temp file :( | 03:16 |
| zsquareplusc | when i run the command manually it fails the same way - when run in a bash shell. it works in a cmd.exe :/ | 03:24 |
| zsquareplusc | it seems to be paramiko/win_pageant.pyo:121 that causes the error (official bzr 1.15 windows distribution) | 03:35 |
| === timchen1` is now known as nasloc__ | ||
| * igc lunch | 04:48 | |
| poolie | spiv btw bug 432993 is the kind of thing i was referring to earlier | 05:13 |
| ubottu | Launchpad bug 432993 in bzr "TooManyConcurrentRequests when failing to connect over ssh" [High,Confirmed] https://launchpad.net/bugs/432993 | 05:13 |
| * igc medical appointment - bbl | 05:38 | |
| thumper | i can haz hard linkz agan plz? | 06:01 |
| lifeless | poolie: you're working on a bug script? | 06:01 |
| lifeless | thumper: what do you want them for? | 06:02 |
| poolie | i am | 06:02 |
| thumper | lifeless: hardlinking working copy files is not currently supported in <WorkingTree6 of /home/tim/src/lp/bmp-notification-recipients> | 06:02 |
| thumper | lifeless: just how I work | 06:02 |
| lifeless | thumper: tell me more | 06:03 |
| thumper | lifeless: I have light weight checkouts of devel | 06:03 |
| lifeless | many? | 06:04 |
| thumper | lifeless: and I build new branches using 'cbranch --lightweight --hardlink' | 06:04 |
| thumper | lifeless: now about 20 | 06:04 |
| lifeless | have you considered using switch ? | 06:04 |
| thumper | yes | 06:04 |
| thumper | I use pipelines | 06:04 |
| lifeless | What doesn't it do/does wrong for you? | 06:04 |
| thumper | but I like to keep my work in meaningful directories | 06:05 |
| thumper | it adds context for me | 06:05 |
| lifeless | sure | 06:05 |
| thumper | I started with switch originally | 06:05 |
| lifeless | so I use meaningful directories | 06:05 |
| thumper | but I found I had too many copies on the go | 06:05 |
| lifeless | and switch | 06:05 |
| lifeless | do you mean 'you forgot where you were' | 06:05 |
| lifeless | or 'you actually needed multiple work areas at once due to $thing' | 06:06 |
| thumper | lifeless: it had to do with work that was in various states of review | 06:06 |
| thumper | lifeless: I often have tests running in one branch | 06:06 |
| thumper | while hacking in another | 06:06 |
| poolie | 888 Confirmed | 06:06 |
| poolie | 353 Triaged | 06:06 |
| poolie | 265 New | 06:06 |
| poolie | 147 Incomplete | 06:06 |
| poolie | 47 In Progress | 06:06 |
| poolie | 17 Fix Committed | 06:06 |
| thumper | or even running LP locally in another | 06:06 |
| lifeless | poolie: welcome to API's | 06:06 |
| poolie | mm, i have poked at them before | 06:07 |
| thumper | lifeless: I also found that using TAGS, with multiple directories, I need different emacs buffers | 06:07 |
| poolie | the vodka is strong but the meat is no good | 06:07 |
| thumper | lifeless: or I can get jumped around into the wrong directory | 06:07 |
| lifeless | thumper: would it be a good idea for 'bzr switch' should incremental-update TAGS? | 06:08 |
| lifeless | thumper: here's where I'm coming from: we're doing UI overhaul around groups of branches. | 06:08 |
| thumper | I don't pretend to understand TAGS | 06:08 |
| thumper | I know | 06:09 |
| lifeless | thumper: I suspect many folk have 'lightweight + switch' as key building blocks in how they want to tackle that. | 06:09 |
| thumper | I guess I use my checkouts as a kinda "work in progress" list | 06:10 |
| lifeless | thumper: so I want to understand the friction you felt more | 06:10 |
| thumper | I delete them when they are merged | 06:10 |
| thumper | I use multiple checkouts for various reasons | 06:10 |
| thumper | I like to be able to run against trunk without switching my current work | 06:10 |
| poolie | thumper: so just click affectsmetoo on the bug and then... oh :) | 06:10 |
| thumper | to perhaps test stuff | 06:10 |
| poolie | more seriously, we could look at in content filtering | 06:11 |
| thumper | and sometimes running long tests locally while wanting to hack other stuff | 06:11 |
| thumper | so I need more than one concurrent checkout | 06:11 |
| thumper | one I had more than one | 06:11 |
| thumper | I found that I wanted meaningful directory names | 06:11 |
| thumper | the easiest way I found was to have lightweight checkouts for my work | 06:12 |
| thumper | and moved to cbranch | 06:12 |
| thumper | from there to hardlink | 06:12 |
| thumper | perhaps having a way to tag branches in a local repo as in various states would help me | 06:12 |
| thumper | so I could easily see which branches I have locally that aren't merged | 06:13 |
| thumper | without having them all in their own checkouts | 06:13 |
| mwhudson | fwiw, i work almost exactly like thumper | 06:13 |
| thumper | as long as I could list them easily | 06:13 |
| lifeless | thumper: I use directories to tag branches | 06:13 |
| thumper | lifeless: inside the repo? | 06:13 |
| lifeless | thumper: mkdir pending; mkdir review; mkdir experimental | 06:13 |
| abentley | fwiw, thumper works almost exactly like me :-) | 06:14 |
| lifeless | yup | 06:14 |
| mwhudson | i don't actually have any real problems with bzr here, as 'make build' takes far longer than tree building :( | 06:14 |
| thumper | I don't have trees in my repo | 06:14 |
| thumper | it seems ick to me | 06:14 |
| thumper | mwhudson: true | 06:14 |
| lifeless | thumper: thats not anything to do with trees :) | 06:14 |
| lifeless | thumper: I put branches under there | 06:14 |
| thumper | lifeless: but if you have a lightweight checkout, and you move the branch | 06:15 |
| thumper | lifeless: how do you reconcile that? | 06:15 |
| lifeless | bzr switch --force | 06:15 |
| lifeless | but it happens rarely | 06:15 |
| lifeless | as I have only a few checkouts | 06:15 |
| lifeless | and usually state changes are also when I need to stop editing (or conversely start editing) branches | 06:16 |
| thumper | lifeless: I got my workflow from jamesh | 06:16 |
| thumper | lifeless: when I first started using bzr | 06:16 |
| lifeless | thumper: I'm not criticising it! | 06:16 |
| thumper | lifeless: I'm not saying you are | 06:16 |
| thumper | lifeless: I'm trying to give context | 06:16 |
| lifeless | thanks ;) | 06:17 |
| thumper | lifeless: part of it is "this is how I was taught" | 06:17 |
| lifeless | righto | 06:17 |
| thumper | lifeless: I have thick skin, you have to be a hell of a lot more direct for me to think you are criticising :) | 06:17 |
| lifeless | All the rugby | 06:18 |
| thumper | lifeless: I didn't start rugby until I worked in the UK | 06:18 |
| thumper | lifeless: never played in NZ before that | 06:18 |
| thumper | :) | 06:18 |
| RenatoSilva | what's the recommended workflow when working on a feature branch while trunk keeps actively updated? | 06:36 |
| lifeless | hack;hack; commit; merge trunk; check for regressions; commit; hack; hack; loop | 06:37 |
| RenatoSilva | I'm using launchpad, I have one branch in rev 18, and other in rev 21 which is the trunk. I'm afraid that when I merge the former (likely to keep at rev 18) with the latter, that could be at rev 25 for example, well I'm afraid I have problems... | 06:39 |
| RenatoSilva | what are regressions? | 06:39 |
| lifeless | when things stop working | 06:39 |
| RenatoSilva | and so I need to keep in sync with the target branch? | 06:39 |
| lifeless | up to you | 06:40 |
| lifeless | you asked for recommended ;) | 06:40 |
| RenatoSilva | hum so it is recommended to avoid regression? | 06:40 |
| RenatoSilva | the more diffs between branches, the more likely the merge will break code? | 06:40 |
| * RenatoSilva how merges are get done is still an enigma for him | 06:41 | |
| bob2 | RenatoSilva: avoiding regressions is a fancy way of saying 'don't introduce bugs' :) | 06:46 |
| bob2 | RenatoSilva: I dunno if falling behind and having to do larger merges is more likely to introduce bugs (probably), but it's also harder and more likely to conflict | 06:47 |
| lifeless | and bugs can happen when you merge. | 06:47 |
| spiv | RenatoSilva: basically, bzr compares the history of all the changes in the two branches, and applies the changes that are present in the merge source but not yet present in the target. | 06:47 |
| RenatoSilva | bob2: yeah, I don't know about bugs either (generated by the merge itself?) | 06:48 |
| spiv | RenatoSilva: but bzr is just software; the way it understands changes is by seeing which lines of text have changed, rather than understanding that e.g. "function X was renamed to Y", so it's possible that the result bzr merge will produce something other than what a human would have done if they were applying those changes manually. | 06:49 |
| bob2 | RenatoSilva: by combining your code with the trunk - e.g. if you modified some function to introduce a bug | 06:49 |
| mwhudson | RenatoSilva: the classic thing is stuff like adding a required argument to a function in one branch while adding a call to that function in another | 06:49 |
| mwhudson | RenatoSilva: both branches are correct, but the combination is not, and you'd need to be waaay cleverer than any vcs tool is today to figure that out automatically | 06:50 |
| RenatoSilva | spiv: that's what I imagined, for example if I merge branch X in rev 19 with trunk rev 21, where they have diverged at rev 17, so bzr will take revs 18 and 19 and try to apply the diffs to rev 21 on the trunk, right? | 06:50 |
| spiv | RenatoSilva: and sometimes changes in the two branches are simply incompatible as-is, e.g. one branch may add a new argument to a function, and the other may add a different new argument instead. (or mwhudson's example, which is similar) | 06:51 |
| lifeless | RenatoSilva: the mechanics of the merge - bzr will merge unmerged work. | 06:51 |
| lifeless | RenatoSilva: you should just try; nothing like experimentation to help you see | 06:51 |
| spiv | RenatoSilva: if you merge X into trunk, then yes. | 06:51 |
| spiv | RenatoSilva: (although not via diffs, precisely; diffs don't handle renames and bzr does, for instance) | 06:52 |
| spiv | Hmm, well, I guess diffs can do renames. | 06:52 |
| spiv | diffs aren't so good for changes to symlinks or binary files, though :) | 06:53 |
| Peng_ | Well, merging isn't so good for symlinks or binary files..... | 06:55 |
| RenatoSilva | spiv: ok I don't mean `diff`s are generated, I just think it's sort of magic :) | 06:55 |
| spiv | Peng_: yeah, but at least it DTRT when only one side has changed them. | 06:56 |
| Peng_ | spiv: Oh, cool. | 06:56 |
| RenatoSilva | Peng_: for bin files you have to choose between one and another versions right? there's no merge for them ... | 06:56 |
| Peng_ | RenatoSilva: Well it's totally theoretically possible to develop merge tools for binary files. | 06:57 |
| Peng_ | RenatoSilva: Merging really isn't scary, and it's a major part of using a DVCS. | 06:57 |
| Peng_ | RenatoSilva: Even if things go horribly wrong, you can just "bzr revert". | 06:57 |
| RenatoSilva | lifeless: well I have merged a few times, I just see it as magic :) (just curious about how it works -- because of the initial issue) | 06:58 |
| RenatoSilva | spiv: well I think something similar to a merge-directive is used | 07:01 |
| spiv | RenatoSilva: well, if a file originally had a series of lines ABCD, and one branch changed it to ABC, and the other changed it to AECD, then merge would result in AEC. | 07:01 |
| RenatoSilva | spiv: except that the commits are "packaged" under another one | 07:01 |
| RenatoSilva | spiv: AEC? weird, so bzr tries to do same-line merges? o.O | 07:02 |
| spiv | RenatoSilva: no, by "ABCD" I mean four lines | 07:03 |
| spiv | RenatoSilva: just using a very compact notation because IRC isn't really designed for multi-line examples :) | 07:03 |
| RenatoSilva | ok :) | 07:04 |
| RenatoSilva | so it is recommended that as I update trunk, I do a bzr pull in the other branch? | 07:04 |
| lifeless | no, you can't | 07:05 |
| spiv | (In principle a merge algorithm can work with sequences of bytes rather than sequences of lines, but for various reasons lines tend to be a good tradeoff for performance and human-intelligible results for source code) | 07:05 |
| lifeless | because the other branch has different changes | 07:05 |
| igc | back | 07:06 |
| RenatoSilva | lifeless: hum you can't pull from a diverged branch, right | 07:07 |
| RenatoSilva | so what should I do? | 07:07 |
| RenatoSilva | merge trunk into the other? | 07:07 |
| lifeless | yes; as I said waaaay above :) | 07:07 |
| RenatoSilva | let's use an example | 07:08 |
| RenatoSilva | branch X rev 19, diverged from trunk at rev 17, and trunk is at rev 21 | 07:09 |
| RenatoSilva | so I merge trunk into X, and X get a new rev 20 { trunk 18-21 } ? | 07:09 |
| lifeless | RenatoSilva: yes | 07:09 |
| lifeless | cd X; bzr merge trunk; <check for regressions>; bzr commit -m 'merge trunk' | 07:10 |
| RenatoSilva | and when I'm done I merge X into trunk, that gets a rev 22 { X 18, 19, 20 { trunk 18-21 } } ? | 07:11 |
| RenatoSilva | * trunk, which gets | 07:11 |
| spiv | Not sure exactly what you mean by that notation. | 07:11 |
| RenatoSilva | spiv: that's the only way I can see it :( | 07:12 |
| spiv | It's tip revision, rev 22, would have two parents, trunk's 21 and X's 20. | 07:12 |
| RenatoSilva | spiv: rev 22 of trunk will contain 3 revs from X: 18, 19 and 20, where 20 is a merge with trunk | 07:12 |
| spiv | RenatoSilva: "contain" isn't really the right relation. | 07:12 |
| spiv | RenatoSilva: "has parent" is the relation. | 07:13 |
| RenatoSilva | what's a tip revision? | 07:13 |
| spiv | RenatoSilva: the most recent revision in that branch. The "tip" of the branch :) | 07:13 |
| lifeless | the most recent commit on a branch | 07:13 |
| spiv | Also known as "head" | 07:13 |
| spiv | RenatoSilva: have you seen the output of "bzr viz" (if you have the bzr-gtk plugin) or "bzr qlog" (if you have qbzr)? | 07:14 |
| RenatoSilva | spiv: I think if you explain me using my notation I could easily understand :) | 07:14 |
| * RenatoSilva trying to understand "It's tip revision, rev 22, would have two parents, trunk's 21 and X's 20." | 07:15 | |
| spiv | RenatoSilva: I can't, because I think the way you read your notation presumes a view of the system that isn't accurate | 07:15 |
| lifeless | poolie: so whats your bug thing? | 07:15 |
| davidstrauss | spiv: I'm pretty sure that notation means rev 22, which contains X's 18, 19, 20. X's 20 contains trunk's 18-21. | 07:15 |
| lifeless | davidstrauss: contains is the problem though :) | 07:15 |
| lifeless | davidstrauss: as revisions are not containers for revisions | 07:15 |
| davidstrauss | lifeless: what does it mean when they're nested in the log output, then? | 07:16 |
| spiv | davidstrauss: a) what lifeless said, b) that reading would confirm my suspicion that it's an inaccurate model for bzr | 07:16 |
| lifeless | davidstrauss: non-left hand parent | 07:16 |
| lifeless | davidstrauss: e.g. a merge occured, and the revision that is indented was not present in the left hand ancestor of the above revision | 07:17 |
| RenatoSilva | lifeless: last time I saw a merge commit the revisions merged were showing "inside" the merge revision | 07:17 |
| spiv | RenatoSilva: so, a commit has links its parent(s), and they are links rather than copies. | 07:17 |
| spiv | RenatoSilva: and those parents in turn have links to *their* parent(s), and so on. | 07:18 |
| RenatoSilva | lifeless: I have never seen one for the scenario I mentioned though | 07:18 |
| lifeless | RenatoSilva: yes, they will show like that; this indicates 'merged by' not 'contained within' | 07:18 |
| poolie | lifeless: i'd like to make the state of the queues more visible | 07:18 |
| poolie | maybe with a graph of open bugs etc | 07:18 |
| poolie | and to have a list of tags perhaps | 07:19 |
| spiv | RenatoSilva: so you can draw a diagram of the revision ancestry back to the start (a revision with no parents) by repeatedly following those links. | 07:19 |
| poolie | and just generally get a better feel for how much things can be extended using apis | 07:19 |
| lifeless | poolie: what I'd love: a google appengine web page; showing the bzr project [perhaps project-group even] bugs in my preferred sort order | 07:19 |
| davidstrauss | spiv: so replace "contains" with "has children linking to it, which are:" | 07:19 |
| davidstrauss | spiv: is that accurate? | 07:20 |
| spiv | davidstrauss: if so, that notation is inaccurate, and should be trunk 22 { X 20, trunk 21 } | 07:20 |
| poolie | lifeless: yeah me too but small steps | 07:20 |
| vila | hi all | 07:20 |
| poolie | i'd like to prototype some kind of dashboard | 07:21 |
| davidstrauss | spiv: why would a single revision have children from two different branches? | 07:21 |
| spiv | davidstrauss: and expanded out one more level would be trunk 22 { trunk 21 { trunk 20 }, X 20 { X 19, trunk 21 } } | 07:21 |
| davidstrauss | spiv: I mean, direct childred | 07:21 |
| davidstrauss | children* | 07:21 |
| spiv | davidstrauss: that's what a merge is | 07:21 |
| davidstrauss | spiv: A merge pulls in revisions from one other branch | 07:21 |
| spiv | davidstrauss: also, "parent", not "children", unless you're asking a different question to what I think you are? | 07:22 |
| davidstrauss | spiv: which may have children from other branches still | 07:22 |
| poolie | lifeless: i guess overall the thing is that all the data is there, but the tools for querying it are not so great | 07:22 |
| poolie | for something as simple as 'how many bugs are open in bzr' you need to iterate them | 07:22 |
| poolie | which is the opposite of what you want | 07:22 |
| davidstrauss | spiv: but if i merge from another branch and commit as rev 22, revision 22 should only have direct child revisions from one other branch | 07:23 |
| lifeless | poolie: meep, theres no __len__ on search results? | 07:23 |
| spiv | davidstrauss: it will have two parents | 07:23 |
| spiv | davidstrauss: and no children (yet) | 07:23 |
| davidstrauss | spiv: so, the indented revisions below a merge revision in log are *parents*? | 07:23 |
| lifeless | poolie: the API folk have expressed a strong desire to be told about issues | 07:24 |
| spiv | davidstrauss: those parents will be the previous tip of the branch you just committed in, plus the revision you merged in from the other branch. | 07:24 |
| spiv | davidstrauss: have you seen "bzr viz" or "bzr qlog"? | 07:24 |
| RenatoSilva | trunk 22 { X 20, trunk 21 }? | 07:24 |
| davidstrauss | spiv: haven't used any gui tools | 07:24 |
| spiv | davidstrauss: the history is a DAG, and those tools do a good job of visualising it | 07:24 |
| spiv | davidstrauss: "bzr log" makes an attempt to represent some the structure of that DAG in plain ascii, which is inevitably a bit hard in complex cases :) | 07:25 |
| RenatoSilva | spiv: I'll jsut keep X updated by merging trunk into it regularly, then when I'm done I'll merge X into trunk, and then see what happens in log/qlog :) | 07:25 |
| spiv | davidstrauss: if you pass --show-ids to log it will explicitly give the "parent:" links for each revision. | 07:26 |
| spiv | RenatoSilva: good idea :) | 07:26 |
| davidstrauss | spiv: ok, so let me rephrase my previous statement. "rev 22, which has parents {X's 18, 19, 20}. Also, X's 20 has parents {trunk's 18-21}. | 07:26 |
| Peng_ | A revision only has 1-2 parents. But its parents have their parents, and on up the chain. | 07:27 |
| davidstrauss | spiv: I still don't see how a revision could have parent revisions other than (1) in the same branch and (2) in one other branch | 07:27 |
| spiv | davidstrauss: "rev 22, which has parents {trunk 21, X 20}." | 07:27 |
| lifeless | Peng_: N parents | 07:27 |
| Peng_ | (Not that it has to be restricted to a simple chain.) | 07:27 |
| lifeless | Peng_: hg has the 2 thing | 07:27 |
| davidstrauss | spiv: Is rev 22 in X? | 07:27 |
| Peng_ | lifeless: Oh, I thought bzr did too. | 07:27 |
| spiv | davidstrauss: "and consequently some of its ancestors are X 19, X 18, etc." | 07:27 |
| Peng_ | Bazaar supports octopus merges? | 07:27 |
| spiv | Peng_: yes | 07:27 |
| lifeless | Peng_: nope, 0 through to 'overflow a 4K b+Tree zlib page' | 07:27 |
| lifeless | Peng_: which is 'many' | 07:27 |
| RenatoSilva | davidstrauss: this stuff is really ahrd to understand :) | 07:28 |
| RenatoSilva | hard | 07:28 |
| davidstrauss | RenatoSilva: Is rev 22 on branch X? | 07:28 |
| Peng_ | lifeless: I hope that doesn't mean there will be some obscure index exception instead of a simple WhatTheHellAreYouDoingError. | 07:28 |
| Peng_ | "bzr merge" will let you do it? | 07:29 |
| lifeless | Peng_: it will except on commit; and yes bzr merge will let you do it - --force | 07:29 |
| RenatoSilva | davidstrauss: I mean the whole subject | 07:29 |
| davidstrauss | Given that rev 22 has parents X:22 and trunk:21 (according to spiv), it should follow that rev 22 is either on branch X or trunk, correct? | 07:29 |
| RenatoSilva | davidstrauss: I can't see it as anything different from the weird rev 22 { X 18, 19, 20 { trunk 18-21 } } | 07:29 |
| davidstrauss | I meant "Given that rev 22 has parents X:20 and trunk:21 (according to spiv), it should follow that rev 22 is either on branch X or trunk, correct?" | 07:29 |
| RenatoSilva | davidstrauss: I'll just try to do it in pratice and see what happens | 07:30 |
| Peng_ | lifeless: Cool. I always figured --force would lose the other revision information or something, like with a cherrypick. | 07:30 |
| spiv | davidstrauss: yes, I'm talking about the example where X is merged into trunk | 07:31 |
| spiv | davidstrauss: e.g. "cd trunk; bzr merge path/to/X; bzr ci" | 07:32 |
| davidstrauss | spiv: OK, this suddenly makes a bunch more sense. | 07:32 |
| davidstrauss | spiv: I was assuming rev 22 was on yet another branch | 07:32 |
| spiv | Which AIUI was the example under discussion | 07:32 |
| spiv | But I might be wrong :) | 07:32 |
| spiv | davidstrauss: phew :) | 07:32 |
| davidstrauss | spiv: and that's why i couldn't understand how it could have parents on two other branches | 07:32 |
| lifeless | spiv: it was trunk to X | 07:33 |
| spiv | lifeless: hmm, skimming scrollback, I see both | 07:35 |
| spiv | lifeless: the most proximate to where I started clarifying notation was X to trunk, though :P | 07:36 |
| lifeless | spiv: no its not :) | 07:36 |
| davidstrauss | It seems more likely that it's X->trunk, given that one of the parents is rev 21 on trunk. | 07:36 |
| lifeless | spiv: :08 RenatoSilva asked, 5 lines later or so you said you didn't get the notation :) | 07:36 |
| davidstrauss | (And knowing that the new revision is 22) | 07:36 |
| poolie | lifeless: https://edge.launchpad.net/hydrazine | 07:37 |
| poolie | barely anything there | 07:37 |
| lifeless | a foaming agent huh? | 07:37 |
| davidstrauss | If it were trunk->X, the new revision (22) would have to have rev 21 on X as a parent | 07:37 |
| lifeless | by definition, yes. | 07:38 |
| lifeless | branch contents are recursively defined | 07:38 |
| lifeless | rev 21 is the first parent of rev 22 | 07:38 |
| RenatoSilva | so it really is trunk's 22 { X's 18, 19 and 20 { trunk's 18, 19 } } ? | 07:39 |
| poolie | lifeless: 'dangerously unstable'... 'used in various rocket fuels' | 07:39 |
| poolie | ' These reactions are extremely exothermic (the catalyst chamber can reach 800 °C in a matter of milliseconds,[22]) and they produce large volumes of hot gas from a small volume of liquid hydrazine,[23] making it a fairly efficient thruster propellant ' | 07:40 |
| lifeless | :) | 07:40 |
| poolie | i aspire to making a fairly efficient propellant | 07:41 |
| poolie | we shall see | 07:41 |
| davidstrauss | When is the current "edge" version of LP going stable? | 07:41 |
| poolie | 3.0 is targeted for the end of this week | 07:41 |
| davidstrauss | nice | 07:41 |
| poolie | and it'll run bzr 2.0.0 to | 07:42 |
| poolie | too* | 07:42 |
| spiv | lifeless: yes, I see :08, but :11 is more proximate to me :P | 07:42 |
| davidstrauss | poolie: Is there a comprehensive listing of changes? | 07:43 |
| poolie | in lp? or in bzr? | 07:43 |
| davidstrauss | poolie: in lp | 07:43 |
| poolie | i don't know, sorry | 07:43 |
| davidstrauss | poolie: bzr 2.0 is pretty obvious with the changelogs | 07:43 |
| poolie | well, the branch is public | 07:44 |
| RenatoSilva | what's the recommended comment when commiting a merge with a lp branch? "merge with lp:project" ? | 07:44 |
| poolie | https://code.edge.launchpad.net/~launchpad-pqm/launchpad/devel | 07:45 |
| poolie | RenatoSilva: i guess that's fine, but maybe say why | 07:45 |
| davidstrauss | RenatoSilva: Given that the merge will always be directly on "lp:project," it would mean every merge commit would be identically explained. | 07:45 |
| davidstrauss | RenatoSilva: It's best to list any bug or question that's related. | 07:45 |
| RenatoSilva | always be directly on "lproject," ? | 07:46 |
| spiv | RenatoSilva: that's fine, or even "merge from trunk", although as poolie says you're probably doing the merge for a reason, so stating that reason in the commit message is a good idea. | 07:46 |
| davidstrauss | RenatoSilva: "Merge changes from branch lp:~davidstrauss/pressflow/blah to fix LP #23424" | 07:46 |
| ubottu | Launchpad bug 23424 in pango1.0 "Opentype Latin fonts poorly handled" [Medium,Fix released] https://launchpad.net/bugs/23424 | 07:46 |
| spiv | RenatoSilva: e.g. "Merge from blah to get bugfix for 1234" | 07:46 |
| RenatoSilva | davidstrauss: the reason for merging is always the same: to keep up-to-date with trunk | 07:46 |
| davidstrauss | RenatoSilva: Oh, you mean a merge from trunk into your feature branch | 07:47 |
| davidstrauss | RenatoSilva: I was assuming this would be into trunk from a feature branch | 07:47 |
| spiv | But personally I've often done just "Merge from trunk", and left the rationale implicit (keeping up to date to minimise integration headaches) | 07:47 |
| davidstrauss | Yeah, it's not important to be too detailed when merging from trunk to keep a feature branch updated. | 07:48 |
| davidstrauss | The opposite direction is where the commit messages matter more than anywhere | 07:48 |
| spiv | If I'm merging from an unusual source or for an unusual reason I would say why, though. | 07:48 |
| RenatoSilva | davidstrauss: yes, X into trunk would be "merge with lp:~user/project/subject", and I think bug numbers and explanations they're all in the branch, the problem is if it is deleted after merging | 07:49 |
| RenatoSilva | doesn't source branch go automatically into commit metadata? | 07:49 |
| davidstrauss | RenatoSilva: Merged revisions retain all data post-merge | 07:49 |
| RenatoSilva | davidstrauss: Merged revisions retain all data post-merge? | 07:50 |
| RenatoSilva | Aren't I repeating info when typing branch name in commit? | 07:50 |
| spiv | RenatoSilva: merge copies all the revisions that are referenced (and not already present) | 07:50 |
| Peng_ | I prefer commit messages like "AutoWidget 3.0 support (Some User, #12345)". | 07:50 |
| Peng_ | I guess it would make sense to include the branch URL too, though. | 07:50 |
| RenatoSilva | Peng_: doesn't it go into commit metadata? | 07:51 |
| davidstrauss | RenatoSilva: The branch URL isn't the same as the branch short name | 07:51 |
| RenatoSilva | ok url is better | 07:51 |
| spiv | RenatoSilva: (and recursively, so parents of parents of parents, etc, will be copied. So if you merge a branch to trunk it is possible to later rebranch that old branch from trunk) | 07:51 |
| RenatoSilva | if url is stored, then no need of even the word merge | 07:52 |
| RenatoSilva | you just say "fix for problem x" or "new feature y", it doesn't matter whether it is a merge or regular revision | 07:52 |
| spiv | RenatoSilva: basically, whatever works well for you :) | 07:53 |
| RenatoSilva | I just think it's a bit weird having to put any message for just keeping up-to-date with trunk | 07:53 |
| RenatoSilva | spiv: but I want to know if urls are stored or not :) | 07:53 |
| spiv | RenatoSilva: No | 07:53 |
| spiv | Not in the history. | 07:53 |
| davidstrauss | RenatoSilva: you might prefer rebase | 07:54 |
| RenatoSilva | spiv: so it says it is a merge, but don't say a merge with what? | 07:54 |
| davidstrauss | RenatoSilva: I personally hate rebase | 07:54 |
| RenatoSilva | what's rebase? | 07:54 |
| davidstrauss | RenatoSilva: Please use google | 07:54 |
| spiv | RenatoSilva: the history has a full copy of all the revisions from the source branch that you merged from. | 07:54 |
| spiv | davidstrauss: hmm, I don't see how rebase would help here | 07:55 |
| RenatoSilva | spiv: i know | 07:55 |
| RenatoSilva | spiv: but you don't know from where they came from if you don't have urls | 07:55 |
| davidstrauss | spiv: It would eliminate RenatoSilva having to write commit messages for merging from trunk | 07:55 |
| spiv | True, but why do you need where they came from if you have the commits themselves already? | 07:55 |
| davidstrauss | RenatoSilva: It's literally impossible for bzr to guess the canonical URL for a branch at merge time | 07:56 |
| spiv | I.e. what information does "where they came from" tell you that can't already get from the commit messages, authors, etc in the actual commits? | 07:56 |
| spiv | davidstrauss: oh, I see. I think that would be the tail wagging the dog, personally. | 07:56 |
| davidstrauss | spiv: Indeed. | 07:57 |
| RenatoSilva | I'm thinking of a workaround: merge X into trunk locally, delete lp's X, push local trunk as X. How about it :) | 07:57 |
| davidstrauss | So, if Launchpad is launching with bzr 2.0 this week, does that mean bzr 2.0 is going stable, too? | 07:58 |
| davidstrauss | RenatoSilva: How does that change anything? | 07:58 |
| RenatoSilva | davidstrauss: humm, true :( | 07:58 |
| lifeless | 2.0 is already stable | 07:59 |
| RenatoSilva | I just think up-to-date merging is not natural | 07:59 |
| davidstrauss | RenatoSilva: Rather, it would just create a very confusing history. | 07:59 |
| davidstrauss | RenatoSilva: What do you consider a natural alternative? | 07:59 |
| lifeless | RenatoSilva: you don't need to delete lp's x; just push over it | 07:59 |
| lifeless | RenatoSilva: I think you could do your workaround; it will look very similar, but you won't be able to as easily tell where you merged trunk, which means you won't know why a bug was introduced. | 08:00 |
| RenatoSilva | davidstrauss: well s/merge X into trunk/bzr send X > trunk, how about it | 08:00 |
| RenatoSilva | a natural way is one just like I'm cerating X NOW | 08:01 |
| davidstrauss | lifeless: I disagree. There's a big problem with the proposed workaround: every time he updates from trunk, the commit history for his feature branch gets buried in the parents of a merge revision. | 08:01 |
| RenatoSilva | and applying the changes, that before were revs 18, 19 and now would be palin revs 22, 23 | 08:01 |
| davidstrauss | lifeless: It creates a history with a depth at least as many parents deep as the number of merges with trunk | 08:02 |
| RenatoSilva | Imagine I can get X and extract the changes on raw diffs | 08:02 |
| RenatoSilva | then I bzr branch trunk and manually apply the diffs | 08:02 |
| RenatoSilva | and commit | 08:03 |
| RenatoSilva | just like I'm cerating X today | 08:03 |
| davidstrauss | RenatoSilva: "bzr send" is just a tool for packaging merge data | 08:03 |
| RenatoSilva | davidstrauss: well it would not work as the branches have diverged | 08:03 |
| davidstrauss | RenatoSilva: What does "send" have to do with the branches diverging? | 08:03 |
| RenatoSilva | davidstrauss: I'd pry to bzr pull md.diff | 08:03 |
| RenatoSilva | try | 08:03 |
| davidstrauss | RenatoSilva: I think you should look at http://bazaar-vcs.org/Rebase before trying such an ill-advised workflow | 08:04 |
| davidstrauss | RenatoSilva: Taking a fresh branch, applying the old diff, and committing is just a bad approximation of rebase | 08:05 |
| RenatoSilva | ok thanks | 08:05 |
| RenatoSilva | as I have a commit prompt in my front, I'll just type merge with trunk by now :) | 08:06 |
| davidstrauss | RenatoSilva: Rebase treats updating a feature branch from trunk as fundamentally different from merging | 08:06 |
| davidstrauss | RenatoSilva: I advise against using the language "with" for bzr merges | 08:06 |
| RenatoSilva | merge from trunk? | 08:07 |
| davidstrauss | RenatoSilva: In Bazaar, merges are directional. Branch A can be merged into B, or B into A, but there is no single operation that does both | 08:07 |
| davidstrauss | RenatoSilva: Either "merge from trunk" or "merge trunk into _____" | 08:07 |
| RenatoSilva | merge trunk into here | 08:07 |
| davidstrauss | RenatoSilva: "From" is generally best because the "to" is obvious | 08:07 |
| davidstrauss | RenatoSilva: "To" is always the current branch | 08:08 |
| RenatoSilva | with is obvious too | 08:08 |
| RenatoSilva | merge with trunk cannot mean merge this into trunk | 08:08 |
| davidstrauss | RenatoSilva: Not really. Once your revisions get merged back into trunk, the "merge with trunk" commit messages may be a bit ambiguous | 08:08 |
| RenatoSilva | because the comment would be in trunk, not in this branch :) | 08:08 |
| RenatoSilva | ok ok, not that bad to be clearer anyway | 08:09 |
| davidstrauss | RenatoSilva: Remember that every commit you create on the feature branch will be browsable on the trunk after the feature branch is merged back into trunk. | 08:10 |
| RenatoSilva | ok | 08:10 |
| RenatoSilva | "Merging trunk changes" | 08:11 |
| RenatoSilva | how about it | 08:11 |
| RenatoSilva | or "Trunk changes merge" | 08:12 |
| davidstrauss | RenatoSilva: "Merge from trunk" is my usual one | 08:12 |
| RenatoSilva | Maybe rebase or something similar could be in bzr as default | 08:12 |
| davidstrauss | RenatoSilva: "changes" is redundant. All revisions and merges are of "changes" | 08:12 |
| davidstrauss | RenatoSilva: rebase is distributed with most bzr installs | 08:13 |
| RenatoSilva | I don't like 'from' | 08:13 |
| davidstrauss | RenatoSilva: Is there a reason why? | 08:13 |
| RenatoSilva | why don't you like rebase? | 08:13 |
| davidstrauss | RenatoSilva: http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar | 08:14 |
| RenatoSilva | Merging trunk --> trunk changes into here or here's changes into trunk??? Merging trunk changes ----> oh, trunk changes were merged (obviously, into here) | 08:14 |
| === weigon_ is now known as weigon | ||
| RenatoSilva | bookmarked your link, thanks | 08:17 |
| * vila . o 0 (God bless people that fix loom test failures :-) | 08:18 | |
| davidstrauss | vila: Is Looms being actively developed? | 08:19 |
| vila | davidstrauss: supported rather than developed, but it's here to stay under one form or another if that's what you care about | 08:21 |
| davidstrauss | vila: What's the preferred option, that other one that works among multiple branches? | 08:21 |
| vila | davidstrauss: I use loom or regular branches myself, but some people seem more at ease with bzr-pipeline (if that's what you're referring to :) | 08:22 |
| vila | davidstrauss: I don't have an opinion on their respective merits since I use only loom but I heard that pipeline were fitting its users needs | 08:23 |
| vila | davidstrauss: both are work in progress AIUI | 08:23 |
| davidstrauss | Pipeline looks like a crappy copy of the git branching interface | 08:24 |
| davidstrauss | :-( | 08:24 |
| RenatoSilva | http://img24.imageshack.us/img24/1857/imagemxv.png ---> WEIRD ! | 08:24 |
| davidstrauss | RenatoSilva: Looks normal to me | 08:25 |
| RenatoSilva | davidstrauss: hard to understand, I mean | 08:25 |
| davidstrauss | RenatoSilva: Granted, I've never used this application before, but this is what I see: | 08:26 |
| RenatoSilva | absolutely crazzy actually | 08:26 |
| davidstrauss | (1) upserprefs is branched from trunk | 08:26 |
| davidstrauss | at 17 | 08:26 |
| davidstrauss | (2a) Revs 18-21 get made on trunk | 08:26 |
| davidstrauss | (2b) The theme prefs work gets committed to userprefs. | 08:26 |
| davidstrauss | (3) Merge from trunk -> userprefs | 08:27 |
| davidstrauss | (4) Merge from userprefs -> trunk | 08:27 |
| davidstrauss | RenatoSilva: right? | 08:27 |
| spiv | davidstrauss: right :) | 08:27 |
| RenatoSilva | davidstrauss: humm :) | 08:27 |
| RenatoSilva | how about the numbers 17.1.1 and 17.1.2 | 08:27 |
| davidstrauss | It's unclear (and irrelevant) whether 2a or 2b happened before one another | 08:27 |
| davidstrauss | RenatoSilva: The first number means you merged from a branch that was originally branched at revision 17. | 08:28 |
| spiv | RenatoSilva: those are just the revision number's bzr assigns those revisions; http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#understanding-revision-numbers | 08:29 |
| RenatoSilva | ok I just mean weird numbers | 08:29 |
| davidstrauss | RenatoSilva: the revision numbers are unique for all numbers on the trunk | 08:30 |
| davidstrauss | RenatoSilva: unique and stable | 08:30 |
| RenatoSilva | I'd use 22.1 and 22.2 instead of 17.1.1 and 17.1.2 | 08:30 |
| RenatoSilva | what does the red lines and circles mean? | 08:31 |
| davidstrauss | RenatoSilva: The red line is the merge into trunk from the feature branch | 08:31 |
| davidstrauss | RenatoSilva: The red circles are unique revisions on the feature branch | 08:32 |
| spiv | RenatoSilva: I think the colours are just to help you associate revisions from the same branch | 08:32 |
| RenatoSilva | ok | 08:32 |
| spiv | RenatoSilva: so qlog has arbitrarily chosen grey/black for trunk and red for userprefs, I think. | 08:32 |
| RenatoSilva | maybe I get those numbers better later | 08:33 |
| spiv | RenatoSilva: you can ignore the numbers if you like, you probably don't need to use them. | 08:33 |
| davidstrauss | RenatoSilva: If we numbered like 22.1 and 22.2, the numbering wouldn't actually provide any useful data about the source of the revisions | 08:33 |
| davidstrauss | RenatoSilva: spiv is right; you can just treat the numbers as opaque strings | 08:34 |
| spiv | davidstrauss: (actually, I usually am more interested in when revisions got merged than when they were branched, but that's another discussion...) | 08:34 |
| RenatoSilva | ok guys | 08:34 |
| davidstrauss | spiv: But it's obvious where revisions got merged in the bzr log --include-merges | 08:34 |
| spiv | (and either way, a graphical tool like qlog is probably a nicer solution than interpreting dotted revnos) | 08:34 |
| spiv | davidstrauss: ah, but that presumes I know when the revision was merged ;) | 08:35 |
| spiv | davidstrauss: or requires me to log all of history | 08:35 |
| davidstrauss | spiv: You mean by time? | 08:35 |
| davidstrauss | spiv: Are you trying to answer, "Given revision ID X (and no other data), I want to know where it was merged into my current branch." | 08:36 |
| spiv | davidstrauss: yes | 08:37 |
| davidstrauss | spiv: There's no way to look that up with the log tool? | 08:37 |
| spiv | davidstrauss: qlog or similiar does a good job of it (I haven't looked recently, so pardon my lack of precision), but not in core "bzr log", no :( | 08:38 |
| spiv | Actually, qannotate is probably what I'm thinking of. | 08:39 |
| RenatoSilva | what about bzr log --include-merges ? | 08:39 |
| spiv | The use case is usually "look at annotations, see a line of interest, and wonder a) what the original commit that introduced that line was, and b) when it landed in this branch" | 08:39 |
| spiv | And qannotate handles that very very nicely, IIRC. | 08:40 |
| spiv | RenatoSilva: that will show all revisions, including merges, but I'd rather not have to grep all of history if I can help it :) | 08:41 |
| davidstrauss | spiv: Actually, you can. It's just two steps. | 08:43 |
| davidstrauss | spiv: bzr log -rX --show-ids | 08:43 |
| davidstrauss | spiv: bzr log -rrevid:[parent-from-last-command-results] | 08:44 |
| davidstrauss | wait | 08:44 |
| davidstrauss | spiv: sorry | 08:44 |
| davidstrauss | spiv: that's just the source | 08:44 |
| spiv | davidstrauss: right :) | 08:44 |
| spiv | davidstrauss: given that qannotate exists and works so well I'm probably not going to scratch this itch any time soon, but it probably wouldn't be so hard to extend log somehow to handle this. | 08:45 |
| spiv | Possibly with mainline:REV revisionspec or something. | 08:46 |
| davidstrauss | spiv: Looking into the bzr architecture, it appears that there's no way to directly determine the children of a revision. | 08:46 |
| spiv | Right. | 08:46 |
| davidstrauss | spiv: It has to be constructed by iterating through the mainline | 08:46 |
| spiv | Yes, graph-walking is required. But that's how bzr determines the x.y.z revno anyway. | 08:46 |
| davidstrauss | spiv: How does the second number of a merged revision get set if I branch from A->B, then B->C, and then merge C->A? | 08:47 |
| vila | lifeless: bug #433843 and associated fix in lp:~vila/qbzr/433843-fix-isolation-breaks | 08:47 |
| ubottu | Launchpad bug 433843 in qbzr "test failures trying to escape isolation" [Undecided,Fix committed] https://launchpad.net/bugs/433843 | 08:47 |
| lifeless | vila: is there a merge proposal? | 08:48 |
| davidstrauss | spiv: s/second number of a merged revision/second number of the merged revisions/ | 08:48 |
| vila | lifeless: permit_dir('/') sounds like the easiest way to fix it and not being that heretic | 08:48 |
| lifeless | vila: I'll need to look | 08:48 |
| vila | lifeless: it's in qbzr just as sec | 08:48 |
| davidstrauss | spiv: Oh, bzr must just assign that number at merge time | 08:48 |
| spiv | davidstrauss: So multiple levels of merge between mainline and that rev, you mean? | 08:48 |
| davidstrauss | spiv: nevermind | 08:48 |
| spiv | ok :) | 08:48 |
| vila | lifeless: https://code.edge.launchpad.net/~vila/qbzr/433843-fix-isolation-breaks/+merge/12148 | 08:49 |
| davidstrauss | spiv: I was trying to figure out how the second number (which is the ordinal of branches off the revision in the first number) was assigned when branching is read-only and transitive | 08:49 |
| davidstrauss | spiv: But it's clear there's no way that could happen until merge-time | 08:49 |
| spiv | davidstrauss: right | 08:51 |
| ngnp | I want to merge 2 websites codebase. Yesterday I upgraded 1 website. Added a 'before upgrade'. Now I want to start working on site 2 with that tag. | 09:00 |
| ngnp | Can I continue working in the same directory? I still not understand bzr branching :( | 09:00 |
| ngnp | s/Added a/Added a tag/ | 09:01 |
| RenatoSilva | thanks everybody | 09:02 |
| davidstrauss | ngnp: Don't your sites have different directories? | 09:02 |
| ngnp | davidstrauss: partly ... but the main code is the same | 09:03 |
| davidstrauss | ngnp: you can branch from the tag | 09:03 |
| ngnp | in the same working dir? | 09:03 |
| davidstrauss | ngnp: i would use a different dir | 09:03 |
| ngnp | otherwise I have to reconfigure apache :( | 09:04 |
| ngnp | davidstrauss: I guessed I had to. I hoped for a 'switch to' tag | 09:04 |
| davidstrauss | ngnp: you can revert to a tag | 09:05 |
| ngnp | and then merge later with current .bzr or through a push | 09:05 |
| davidstrauss | ngnp: I'm still not clear on your workflow | 09:07 |
| ngnp | davidstrauss: me neither ... with eclipse/svn i'm used to 'switch to' and then continue working on that older/newer version. Code stays in same dir. But that is with central repo. Now I have a local. So I guess I need more experience with bzr ... | 09:10 |
| ngnp | Tnx for your time :) | 09:10 |
| davidstrauss | ngnp: you can't switch to tags in bzr | 09:10 |
| davidstrauss | ngnp: tags are merely aliases for revision numbers | 09:10 |
| ngnp | ic ... so I have to "bzr pull -r 7" then upgrade site 2, then merge with site 1? | 09:12 |
| davidstrauss | ngnp: I still don't understand your upgrade workflow, but I have to head off. | 09:13 |
| davidstrauss | ngnp: Sorry :-/ | 09:13 |
| ngnp | np .. cy | 09:13 |
| bialix | heya | 09:14 |
| trondn | why do bzr status show unknown filenames from the root (if my cwd isn't root of the repository), and if I try to add them it only tries to do so relative from my cwd??? | 09:21 |
| bialix | trondn: this is old bug | 09:24 |
| trondn | bialix: ah.. ok.. just got bitten by it... | 09:24 |
| bialix | heh | 09:24 |
| * igc dinner | 09:33 | |
| igc | bialix: 429911 has some further info now -bbl | 09:34 |
| bialix | igc: hi | 09:35 |
| bialix | ubottu, say me please URL for bug 429911 | 09:36 |
| ubottu | Launchpad bug 429911 in bzr-explorer "BZR > Explorer > UnicodeDecodeError" [High,New] https://launchpad.net/bugs/429911 | 09:36 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 09:36 |
| lifeless | trondn: its a mismatch | 09:36 |
| bialix | good ubottu, take a cookie | 09:36 |
| lifeless | trondn: there is a desire to have commands report paths from the root; but its [fairly clear to me] that this doesn't work well with paths users type in from their shell | 09:36 |
| lifeless | trondn: and commands like add work from that basis | 09:36 |
| bialix | igc: re that bug, we seems to get mbcs encoding path to wordpad.exe. we need to cast it to unicode. | 09:37 |
| trondn | lifeless: I would expect that I could use the output from one command as the input to the next one without having to change directory.. That said, its not that big of a problem :) | 09:38 |
| lifeless | trondn: me too! | 09:38 |
| lifeless | vila: sorry, was on a call | 09:44 |
| vila | lifeless: no worries | 09:44 |
| lifeless | vila: MemoryTransport | 09:45 |
| lifeless | vila: someone may have a branch at / | 09:45 |
| bialix | vila: check isolation is bad idea | 09:45 |
| lifeless | bialix: its a very good idea; its telling you about latent bugs in your test suite | 09:45 |
| vila | lifeless: in theory yes, that's why I restricted the permit_dir('/') to very very narrow tests | 09:46 |
| lifeless | vila: they look like they should cope with MemoryTransport, no ? | 09:46 |
| vila | they all want to check a '/not/existant/branch' | 09:46 |
| bialix | aaron insists that MemoryTransport is not very well | 09:47 |
| vila | bialix: MemoryTransport is not *yet* very well, it doesn't mean we can't take it there | 09:47 |
| bialix | vila: does your patch compatible with bzr 2.0? | 09:47 |
| lifeless | bialix: he's asserted that MemoryTree is a problem; its not very complete which I agree with, but PreviewTree writes to disk so is slow. | 09:47 |
| bialix | vila: or more precisely: with 1.17 API? | 09:48 |
| lifeless | MemoryTransport is fully compatible with Transport, I'm not aware of any issues with it. | 09:48 |
| vila | bialix: does your test suite pass ? | 09:48 |
| bialix | vila: I'm using 1.18.1 | 09:48 |
| lifeless | bialix: that patch won't be comaptible with < 2.1 | 09:48 |
| bialix | vila: test suite pass for me | 09:49 |
| bialix | vila: w/o your patch | 09:49 |
| vila | bialix: feel free to delay landing that patch, I'm not going to play tricks to guarantee API backward compatibility for potentially borken tests... | 09:49 |
| bialix | you can make self.permit_dir optional | 09:50 |
| NET||abuse | hey folks,, looking for an article on using bzr in deployment of web site code. | 10:17 |
| NET||abuse | i saw an article before where you setup a bare repository on your webserver, then you setup some kind of hook which exports the code straight to the site working directories on pushing up from your local branch. | 10:18 |
| NET||abuse | does anyone know of this technique or know where the article might live.. google isn't getting me there today. | 10:18 |
| Kinnison | Personally I use a cron job | 10:19 |
| Kinnison | because my site needs an amount of 'building' before it can go live. | 10:20 |
| Kinnison | My cronjob pulls, if any updates happened, it runs 'make check' and then rsyncs the content | 10:20 |
| NET||abuse | the site i'm working on doesn't need any building like that, just need to export 2 tree paths to locations in the website accounts directories. | 10:31 |
| NET||abuse | just looking for a way to push it up to the webserver | 10:31 |
| vila | bialix: I'm not part of qbzr-devs 8-) I can't supersede my own submission :D | 10:37 |
| vila | lifeless: nice suggestion, works like a charm | 10:38 |
| vila | lifeless: (MemoryServer is needed instead of MemoryTransport of course, but that was semi-obvious ;-) | 10:39 |
| vila | bialix: bah forget my last remark, the UI has changed again and I thought I couldn't resubmit where in fact hte button has just been moved | 10:40 |
| fullermd | Oh good. I was just thinking, "Gee, bzr _seems_ like a decent project, but where are the long license discussions?" | 10:47 |
| bialix | vila: so what should I do? | 10:47 |
| vila | fullermd: bzr is a GNU project :-D | 10:47 |
| rusty | Hi all... Can I just double-check: .bzrignore files must be in top level of project, right? And there's no comment syntax? | 10:47 |
| Peng_ | rusty: 1.) Right. 2.) Comments start with # | 10:48 |
| rusty | Peng_: ah, thanks... I couldn't find any documentation on that point. | 10:48 |
| vila | bialix: well, I applied to join the team, feel free to approve me :-D As for the patch, I think I addressed all concerns raised by lifeless and you, so again, feel free to approve and merge :-P | 10:48 |
| rusty | Peng_: does \ escape # then? | 10:48 |
| Peng_ | rusty: Noo idea. | 10:49 |
| spiv | fullermd: haha | 10:49 |
| Peng_ | rusty: Try it and see! :D | 10:49 |
| bialix | vila: so I should feel free as twice as usual? | 10:49 |
| lifeless | rusty: hi | 10:49 |
| fullermd | Now all it needs to do is read email, and it'll be a Real Opensource Project. | 10:49 |
| spiv | rusty: I suppose [#] would work too... | 10:49 |
| lifeless | rusty: you pung me about subunit; did you get my replies ? | 10:49 |
| rusty | lifeless: hi! Just back on the .vcignore tradmill... | 10:49 |
| vila | bialix: yeah, welcome to free software world :D | 10:49 |
| bialix | triple free | 10:49 |
| bialix | ta-da | 10:50 |
| rusty | lifeless: yep! But then I went away for 3 weeks, and the draft sitting there when I got back today seemed stale :)_ | 10:50 |
| lifeless | rusty: I'm doing a subunit talk @ LCA | 10:50 |
| lifeless | rusty: so the more adoption between now and then the better :) | 10:50 |
| bialix | we decided to make part of our new project free (LGPL) | 10:50 |
| rusty | lifeless: I've pretty much decided to go with libtap for the moment, but the API could be easily changed to output subunit directly (rather than via tap2subunit) | 10:50 |
| spiv | rusty: in fact, I see that the default ~/.bazaar/ignore uses [#] to escape a rule :) | 10:50 |
| lifeless | rusty: whats the usecase/situation? | 10:51 |
| bialix | vila: if you join qbzr-dev you'll get all bugmails | 10:51 |
| rusty | spiv, bialix: \# works too. | 10:51 |
| rusty | Oops, I mean Peng_ | 10:52 |
| vila | bialix: ha, right :-/ | 10:52 |
| Peng_ | rusty: Cool. (You mean it does what you want, right?) | 10:52 |
| rusty | Peng_: I'm compiling a table of the different VC systems ignore semantics, that's all! | 10:52 |
| vila | bialix: there should an option somewhere that allow me to unsubscribe to these mails, otherwise, I'll filter them, anyway, I think I better join anyway | 10:54 |
| lifeless | rusty: so, tell me more about where you're choosing between tap/subunit | 10:55 |
| lifeless | rusty: or I'll have to supply you with beer and ask you @ LCA | 10:55 |
| bialix | vila: ok, be good boy and don't commit wild code then. | 11:11 |
| bialix | vila: approved, welcome to the club | 11:12 |
| vila | bialix: :-D | 11:12 |
| rusty | lifeless: because I maintain libtap? :) | 11:12 |
| lifeless | rusty: :P | 11:12 |
| lifeless | rusty: then I should talk to you about how subunit is an improvement over tap :) | 11:13 |
| lifeless | rusty: however, you said something about samba? | 11:13 |
| rusty | lifeless: naah, line-at-a-time rules :) | 11:13 |
| SamB_XP | and here I thought tap was to do with ethernet ... | 11:13 |
| lifeless | rusty: shame that it can't detect unfimished | 11:14 |
| rusty | lifeless: well, it can if you have a plan... | 11:14 |
| SamB_XP | rusty: you mean, like a plan to cook and eat you ? | 11:14 |
| lifeless | rusty: I know :> [tap2subunit handles that] | 11:15 |
| rusty | lifeless: yes, I want to put some unit test infrastructure into the samba tree. They already use subunit, so makes sense to aim for that. | 11:15 |
| lifeless | rusty: they have a thing called libtortue | 11:15 |
| lifeless | sorry | 11:15 |
| lifeless | libtorture | 11:15 |
| lifeless | have you found that? | 11:15 |
| rusty | lifeless: yeah, but it confuses torture testing and performance testing with correctness and unit testing. | 11:16 |
| lifeless | ah | 11:16 |
| lifeless | jelmer: ^ | 11:16 |
| rusty | lifeless: I really want just unit tests, ie. "hey, I really screwed this up" :) | 11:16 |
| lifeless | rusty: so I think a good reason to use libsubunit for stuff in the samba tree is because it's easier ;) | 11:17 |
| lifeless | rusty: tap2subunit isn't ugly, but its not brilliant either. Much better to start with the same protocol, unless you have some external code you're just exposing. | 11:17 |
| rusty | lifeless: my tdb and talloc tests are already using libtap tho :) | 11:17 |
| rusty | (CCAN went for libtap) | 11:18 |
| lifeless | are you at all interested in being able to drop maintenance of libtap ? | 11:18 |
| rusty | lifeless: TBH I think subunit is a YA project. Tap is nice and browsable, and simple. | 11:19 |
| lifeless | SamB_XP: http://en.wikipedia.org/wiki/Test_Anything_Protocol | 11:19 |
| SamB_XP | rusty: young adult ? | 11:19 |
| lifeless | SamB_XP: yet another | 11:19 |
| SamB_XP | ah | 11:20 |
| NET||abuse | yarg,, keyserver down? | 11:20 |
| lifeless | SamB_XP: pejorative sometimes, sometimes adopted such as 'yaml' - yet another meta language | 11:20 |
| SamB_XP | yeah, I've seen many programs whose names start with "ya" for that reason | 11:20 |
| rusty | lifeless: my main issue with TAP is lack of nesting, which is finally being fixed... | 11:21 |
| lifeless | rusty: I disagree rather strongly there; taps simpleness pushes burdens onto the programmer/editor; I can go into some detail of the things it inhibits another time | 11:21 |
| rusty | lifeless: In my limited experience it has been sufficient. I don't like complex tests :) | 11:22 |
| lifeless | rusty: this isn't about the test though - its about what you do with them | 11:23 |
| SamB_XP | rusty: it's not so much complex tests as nested test suites, I think | 11:23 |
| lifeless | rusty: taps not introspectable; you can't run - or even sensibly approach the problem - of running just a single thing from tap in an edit-test cycle, as a for-instance. | 11:24 |
| rusty | SamB_XP: yes, I agree. Which is why I'm happy about the nested TAP implementation. I have exactly this issue with ccanlint, in fact. | 11:24 |
| lifeless | rusty: anyhow, you're happy with tap - great. Let me know of any bugs or glitches you have with tap2subunit and I'll fix em. | 11:25 |
| rusty | lifeless: unit tests should be so fast you don't need to :) | 11:25 |
| SamB_XP | rusty: yeah right! | 11:25 |
| lifeless | rusty: ack; see my blog recently ;) | 11:25 |
| SamB_XP | some of us use finite-clocked computers | 11:26 |
| lifeless | rusty: but, you shouldn't have to change test _protocol_ to work with integration tests, acceptance tests, and so forth. | 11:26 |
| SamB_XP | have to admit bzr does a pretty good job of using the same framework for acceptance-type tests as for plain-old unit tests ;-) | 11:27 |
| lifeless | when you change protocols you change toolchains; unless one toolchain is a strict superset and can read the other protocol | 11:28 |
| rusty | lifeless: it's not clear why that universal protocol shouldn't be TAP tho! | 11:28 |
| SamB_XP | rusty: well, not having enough features might do it ;-) | 11:29 |
| SamB_XP | lifeless: maybe you should write a blog entry about it ;-) | 11:29 |
| lifeless | SamB_XP: I have a 'real testing needs XXX' list to finish; my most recent post to the TIP list was one of the items on that list. | 11:30 |
| SamB_XP | tip list? | 11:30 |
| lifeless | SamB_XP: when I get those items checked off, I'll feel confident going 20 rounds vs TAP anyday :) | 11:30 |
| lifeless | SamB_XP: testing-in-python@lists.idyll.org | 11:30 |
| SamB_XP | ah | 11:30 |
| jelmer | rusty: I think you mean smbtorture | 11:33 |
| lifeless | rusty: there are a bunch of reasons that make it clear to me ;). it can't tell the different between streaming & trailing plans - unless its told at the front :P. fixtures aren't addressable; the model it encodes isn't comaptible with xUnit(arguably _way_ more successful than TAP), it can't attach [for transport] test artifacts (neither can subunit, in progress), it can't provide progress [unless it has an up front plan] | 11:33 |
| jelmer | rusty: libtorture is just a unittest framework | 11:33 |
| lifeless | hmm, did that cut off ? | 11:33 |
| jelmer | hi, btw :-) | 11:34 |
| lifeless | hi jelmer :) | 11:34 |
| lifeless | jelmer: where did that run-on paragraph end for you jelmer ? | 11:34 |
| jelmer | "front plan] | 11:35 |
| lifeless | oh cool | 11:35 |
| rusty | jelmer: hi :) Yes, smbtorture conflates a lot of different tests. I'm mainly concerned about the lib/ dir; it'd be nice to have good unit tests for stuff in there. | 11:35 |
| lifeless | rusty: jelmer wrote a *separate* think 'libtorture' - its not smbtorture | 11:36 |
| lifeless | s/think/thing/ | 11:36 |
| jelmer | lifeless: some things in smbtorture use libtorture though | 11:36 |
| lifeless | sure, but rusty is seeking pure unittesting, which is what I thought, and you're confirming, libtorture is | 11:37 |
| jelmer | lifeless: initially we just had very big functions that would return 0 or 1 depending on whether all of the hundreds of subtests they ran succeeded | 11:37 |
| jelmer | lifeless: right | 11:37 |
| jelmer | rusty: there are some things that do have tests | 11:38 |
| jelmer | rusty: in particular for some of the functions in lib/util/ we have basic unit tests | 11:38 |
| jelmer | rusty: see lib/util/tests | 11:39 |
| lifeless | rusty: there's more, but its not really a 'quick over IRC' discussion, so I'm inclined to shelve it until either I get time to write a serious blog post on it (and endure any flames :P) or we're face to face and I can show you stuff | 11:39 |
| lifeless | rusty: you might like to watch the SLUG talk I did a couple of months back; it was a 'oh we need a speaker urgently' deal, but not bad all the same | 11:40 |
| rusty | lifeless: sure... I've been happy with tap. But I *always* use a plan. The arbitrary numbering of tests, rather than being explicitly labelled: well, you should see what libtorture does :) | 11:41 |
| lifeless | rusty: I'm happy for users to make their life as hard as they want :) | 11:43 |
| rusty | lifeless: ccan uses a simple system where independent test cases go in separate source files. So ideally only dependent tests are in a single file. It works quite well for isolating tests (though a gdb helper to stop on the first fail would be a win). | 11:44 |
| rusty | lifeless: for CCAN, I want any idiot to be able to write tests. libtap has the benefit of simplicity. libtorture starts to push the curve, *and* you don't get "addressable fixtures" (if that means what I think it means?) | 11:47 |
| jelmer | rusty: libtorture does give you all that's required for addressable fixtures (if I am guessing right what they are) | 11:47 |
| jelmer | rusty: addressable fixtures just aren't implemented yet | 11:48 |
| lifeless | an addressable fixture is just naming a single test | 11:49 |
| lifeless | rusty: I'm not sure I want idiots writing C code :) but I agree with the desire for simplicity | 11:51 |
| rusty | lifeless: right,that's what I figured. tap uses numbers, which is a movable feast unless you have the source in front of you. | 11:51 |
| rusty | lifeless: (and even then, figuring out the 113th test can be nontrivial) | 11:51 |
| lifeless | precisely | 11:51 |
| rusty | lifeless: but in libtap the test name (if using "ok1" which is the simplest) is the code, which is the same as libtorture's torture_assert(). | 11:53 |
| lifeless | rusty: interesting | 11:54 |
| lifeless | rusty: have you seen check ? | 11:54 |
| lifeless | rusty: you'll probably hate it, because it needs some boilerplate to insert it into a project, but I'm curious :) | 11:55 |
| rusty | lifeless: no? | 11:55 |
| lifeless | https://sourceforge.net/projects/check/ | 11:55 |
| lifeless | (or apt-get install check) | 11:56 |
| lifeless | its an xUnitish C unittesting library | 11:56 |
| lifeless | forks() before fixtures | 11:56 |
| lifeless | supports some half decent higher order assertions - not brilliant though | 11:56 |
| rusty | lifeless: this is *not* helping me get through my email backlog!! | 12:00 |
| lifeless | rusty: phfhtaw | 12:02 |
| Alcmene_ | Eer... Hello? :) | 12:21 |
| Alcmene_ | Is there anyone here available to give a little bit of help for a problem with bzr on OS X, whose cause is an upgrade from 1.13 to 1.17? | 12:22 |
| Peng | I probably can't help, but I'm curious what your problem is. | 12:22 |
| Alcmene_ | well, mostly the fact that I get the following notice every time I use bazaar : | 12:23 |
| Alcmene_ | "Key 'foreign-mapping-upgrade' already registered" | 12:23 |
| Alcmene_ | Unable to load plugin 'rebase' from '/Library/Python/2.5/site-packages/bzrlib/plugins' | 12:23 |
| Alcmene_ | fact is, the rebase plugin exists in the given directory | 12:23 |
| jelmer | Alcmene_: you have incompatible versions of svn and rebase | 12:23 |
| Alcmene_ | so, the problem is with svn and not bzr ? | 12:24 |
| Alcmene_ | anyway, I've been living with this notice for two weeks, so it's not the main problem | 12:24 |
| Alcmene_ | the big one happened when I tried to use the "push" command | 12:25 |
| Alcmene_ | bzr: ERROR: The API for "<module 'bzrlib' from '/Library/Python/2.5/site-packages/bzrlib/__init__.pyc'>" is not compatible with "(1, 13, 0)". It supports versions "(1, 17, 0)" to "(1, 17, 0)". | 12:25 |
| jelmer | Alcmene_: with bzr-svn | 12:25 |
| Alcmene_ | I therefore assume that the upgrade from 1.13 to 1.17 didn't go totally well, which I already suspected before | 12:25 |
| Alcmene_ | unfortunately, I haven't found any way to uninstall bazaar completely | 12:26 |
| Alcmene_ | since I haven't found a full list of all installed data | 12:26 |
| Alcmene_ | jelmer: isn't the bzr-svn plugin packaged with the bzr isntaller itself? I don't understand why I should upgrade it on its own :s | 12:27 |
| Peng_ | 'bzr plugins -v' shows their paths. | 12:28 |
| Peng | So will the traceback in .bzr.log (use 'bzr version' to see where that's located). | 12:28 |
| jelmer | Alcmene_: I'm not saying you should upgrade bzr-svn necessarily, just that the versions of bzr-svn and bzr-rebase you have installed are incompatible with each other | 12:28 |
| * Alcmene_ is checking the log | 12:30 | |
| Alcmene_ | jelmer: are you sure about that? Cause the log says "Plugin name svn already loaded", which is quite the same as "Key 'foreign-mapping-upgrade' already registered": makes me think that I have a plugin duplicate, one from 1.13, and one from 1.17. How does this sound to you? | 12:33 |
| Alcmene_ | Furthermore, the "IncompatibleAPI" message I gave earlier says that (unless I misunderstand something) my bzrlib module expects bzr to be 1.17 and not 1.13... While my bzr _is_ 1.17! | 12:36 |
| === mrevell is now known as mrevell-lunch | ||
| fullermd | No, that's just unclarity of the message. It means SOMETHING expects bzrlib 1.13 and got 1.17. | 12:38 |
| Alcmene_ | fullermd: mmh, that's interesting. Thanks! | 12:39 |
| Alcmene_ | Examinating the log, it seems that bzr-svn is called when trying to use "push" | 12:40 |
| Alcmene_ | so I think we have spotted our guilty module | 12:40 |
| Alcmene_ | however, if someone could tell me why the hell bazaar calls bzr-svn when pushing a bzr branch to an ftp server... :s | 12:40 |
| jelmer | Alcmene_: it's not called, but loaded nonetheless | 12:44 |
| jelmer | (all plugins are loaded when bzr is started) | 12:44 |
| Alcmene_ | I agree, it's always loaded (that's the cause of the notice I get every time), but it is actually used when using push | 12:45 |
| Alcmene_ | because it's only when using this command that svn-bzr outputs to the log | 12:46 |
| Alcmene_ | ...and only with it that I get an error and not just a warning | 12:46 |
| jelmer | Alcmene_: it might be trying to see if the remote location happens to contain a svn repo | 12:48 |
| Alcmene_ | might be, yeah | 12:49 |
| Alcmene_ | anyway, I have the trace now, so perhaps I'll take a look at it | 12:49 |
| Alcmene_ | this IRC is logged and archives are publicly available, isn't it? | 12:49 |
| Lo-lan-do | Hi all | 12:50 |
| === pwolanin is now known as pwolanin|afk | ||
| Lo-lan-do | Is there a way to do a bzr push without remembering the address of the pushed-to branch? | 12:50 |
| Alcmene_ | Hi Lo-lan-do | 12:51 |
| === doko_ is now known as doko | ||
| bob2 | Lo-lan-do: when you first push, bzr remembers that url and should use it in future if you just run 'bzr push' | 12:53 |
| Lo-lan-do | bob2: Yes, and I'd like to avoid that in some circumstances :-) | 12:53 |
| Alcmene_ | bob2: he asks for the opposite ;) | 12:53 |
| bob2 | Lo-lan-do: sorry, totally missed the '-out' | 12:54 |
| Alcmene_ | Lo-lan-do: do you want to sometimes push to another server and have bzr remember the previous one instead? | 12:54 |
| Alcmene_ | Or do you want it to not remember at all? | 12:54 |
| Lo-lan-do | Alcmene_: I want it to not remember at all. | 12:54 |
| Lo-lan-do | The context is that I want to mirror a local repo into a remote one with pushes. | 12:54 |
| Alcmene_ | and don't want bzr to push every time you commit ? | 12:55 |
| Lo-lan-do | Some of my local branches have push addresses memorised, which is fine. | 12:55 |
| Lo-lan-do | Others don't, and then my mirror script will remember unwanted addresses. | 12:55 |
| Lo-lan-do | Alcmene_: No, this is a maintenance script I intend to run from time to time only. | 12:55 |
| Lo-lan-do | (I know about bound branches :-) | 12:56 |
| Alcmene_ | Lo-lan-do: (couldn't know, had to try ;) ) | 12:56 |
| Alcmene_ | well, have you tried --no-remember? | 12:56 |
| Alcmene_ | cause the help tells you about --strict and --remember | 12:57 |
| Alcmene_ | but the --no-strict option exists, even though it is not listed | 12:57 |
| Lo-lan-do | Ho-hum. | 12:57 |
| Lo-lan-do | Good to know, let me try that. | 12:57 |
| Alcmene_ | perhaps have they implemented it too? | 12:57 |
| Lo-lan-do | push --no-remember doesn't give an error message, but it still remembers the URL :-/ | 12:58 |
| Alcmene_ | :/ | 12:58 |
| Alcmene_ | from the doc: | 13:00 |
| Alcmene_ | If there is no default push location set, the first push will set it. After that, you can omit the location to use the default. To change the default, use --remember. The value will only be saved if the remote location can be accessed. | 13:00 |
| Alcmene_ | doesn't seem like they've thought that someone would _not_ want it to be remembered | 13:00 |
| Lo-lan-do | I'll just have to patch it :-) | 13:01 |
| Lo-lan-do | (someday) | 13:01 |
| Lo-lan-do | In the meantime, I'll sed on the branch.conf | 13:01 |
| Alcmene_ | (omission that I totally understand, BTW ;) ) | 13:01 |
| Alcmene_ | Ok, so, just in case all of this is logged and someone happens to have the same problem as I had: the problem was an obsolete bzr-svn version | 13:24 |
| Alcmene_ | I know, sounds obvious :( | 13:25 |
| Lo-lan-do | diff size stuff? | 13:25 |
| fullermd | Lo-lan-do: You can set the push loc in the branch.conf to an empty string, and then it won't be touched (except by --remember)... | 13:48 |
| Lo-lan-do | fullermd: But then IÂ lose the automatic remembering next time IÂ do a manual push. | 13:54 |
| Lo-lan-do | But thanks for the idea :-) | 13:55 |
| Alcmene_ | well, you could add the --remember option to the default ones in the conf | 13:56 |
| Alcmene_ | or you could also, with your script, save the previous location, do the push, and re-write the previous location back | 13:56 |
| jelmer | hi Lo-lan-do | 13:57 |
| Lo-lan-do | Hi jelmer | 13:59 |
| Lo-lan-do | Alcmene_: I think it might be simpler to just implement a working --no-remember option :-) | 14:00 |
| Tak | hello jelmer | 14:01 |
| Alcmene_ | Lo-lan-do: might be, yeah ;) | 14:04 |
| jelmer | hi Tak | 14:06 |
| jelmer | Tak: Feel free to merge your branch into lp:monodevelop-bzr - I've approved it | 14:07 |
| Tak | oh, ok | 14:08 |
| Tak | I'm not overly familiar with how that works on launchpad :-) | 14:08 |
| Tak | do you have any thoughts on how "Review Changes" should act when there are pending merges? | 14:08 |
| jelmer | Tak: it should probably list the pending merges somewhere | 14:09 |
| Tak | hmm...I don't have a ton of control over how that works without completely overriding/rewriting the UI for that panel | 14:11 |
| Tak | I suppose I could try creating a dummy diffset with the merges grouped together | 14:13 |
| Lo-lan-do | Can bzr reconcile fix "inconsistent parents" errors? | 14:18 |
| fullermd | Yes. | 14:19 |
| Lo-lan-do | Thanks, I'll try that. | 14:19 |
| Lo-lan-do | I'm getting a KnitCorrupt error when pushing to a branch that has them. Hopefully a reconcile will allow me to push again. | 14:20 |
| === mrevell-lunch is now known as mrevell | ||
| fullermd | Lo-lan-do: I doubt the two are related. | 15:31 |
| Lo-lan-do | fullermd: Indeed, the push failed. I'm trying to start afresh. | 15:35 |
| Tak | so how do I do a merge on launchpad? normal branch,merge,commit,push? | 15:56 |
| beuno | Tak, yes | 15:57 |
| Peng | beuno: So what did become of the t-shirt? | 16:21 |
| beuno | Peng, I can't ship to the US, so I'm trying to score one in the London office, and send to you via snail mail | 16:22 |
| Peng | beuno: Ah. That sounds complicated.. | 16:24 |
| beuno | Peng, it is, but I will eventually win | 16:24 |
| Peng | How do t-shirts normally make it to the U.S.? | 16:25 |
| Tak | so how does that interact with the merge proposal stuff? or are merge proposals just formalities? | 16:25 |
| Peng | Tak: Merge proposals are an administrative thing, so people can work together to get a branch ready to merge. | 16:26 |
| Tak | ok, so it's technically unrelated to the actual merging | 16:26 |
| Peng | Tak: They're of great value, but they're completely disconnected from runn -- yeah. | 16:27 |
| * Tak nod | 16:27 | |
| Peng | That could be changed in the future, of course. | 16:27 |
| Tak | I was wondering if I was missing the big green MERGE! button | 16:27 |
| Peng | There already is...something to help automatically merge things, but I don't remember the name. | 16:28 |
| fullermd | Oh, there's your problem. It's chartreuse. | 16:29 |
| Peng | What's chartreuse? | 16:29 |
| Lo-lan-do | Chartreuse is a problem? | 16:29 |
| Lo-lan-do | Try Génépi instead. It even tastes better. | 16:29 |
| fullermd | The big MERGE! button. | 16:29 |
| Peng | Oh! | 16:30 |
| * Peng looks up chartreuse on Wikipedia. | 16:30 | |
| Peng | Yellow-green? I did not know that. | 16:31 |
| fullermd | Think of how much happier you were 3 minutes ago :p | 16:32 |
| Peng | Now that LP is open-source, I can go download it and change it to chartreuse and set up my own instance, right? | 16:32 |
| fullermd | Only if you GFDL it. | 16:33 |
| * SamB_irssi wonders why bzr-search creates so many files in /tmp in the process of indexing a branch... | 16:36 | |
| Peng | It does? | 16:37 |
| SamB_irssi | Peng: it sure seems to! | 16:37 |
| SamB_irssi | try it with a branch of lp:coq | 16:38 |
| SamB_irssi | it keeps waffling between files like "/tmp/bzr-index-B4Xk5c" and files like "/tmp/tmpoubU4Q" | 16:40 |
| jam | SamB_irssi: I believe when we create a btree index, we build the content in tmp | 16:46 |
| jam | and then copy the bytes to the final location | 16:46 |
| jam | That way we don't hold the whole content in memory | 16:46 |
| jam | and we can be sure that we can 'seek', etc. | 16:46 |
| Tak | that explains why I didn't see it - my font color is already set to chartreuse | 16:53 |
| === deryck is now known as deryck[lunch] | ||
| SamB_irssi | jam: makes sense ... but you repeatedly open new BTree files in /tmp ... like, way faster than I can run ls | 17:47 |
| SamB_irssi | that part, not so much | 17:48 |
| jam | SamB_irssi: this is while building the index, right? | 17:49 |
| jam | I believe bzr-search creates 1 index per prefix, or something like that | 17:49 |
| jam | I don't know the specific storage mechanism | 17:49 |
| jam | but it creates a *lot* of little indexes | 17:49 |
| SamB_irssi | jam: a buttload, yeah | 17:50 |
| jam | and puts them all together and then indexes that, I believe | 17:50 |
| SamB_irssi | why does it put them each in a file before indexing it ? | 17:50 |
| jam | the file you see *is* the index | 17:54 |
| jam | we just write it to a temp file | 17:54 |
| jam | and then move it across | 17:54 |
| jam | i think | 17:54 |
| jam | I haven't researched the bzr-search code much | 17:54 |
| jam | I also believe it builds the index 2k revs at a time | 17:54 |
| Peng | That's right. | 17:55 |
| jam | search seems to generate... 4 different indexes | 18:00 |
| jam | revisions, terms, documents, terms2 | 18:00 |
| jam | and that may just be the top level view and those themselves have sub indexes | 18:01 |
| Peng | Indexilicious. Or something. | 18:01 |
| jam | well, it has the low level data, then indexes those, shoves all of that data into a '.pack' file as a series of indexes, then creates a 'names' file which is yet another index... | 18:02 |
| jam | interesting poking at the code a bit | 18:05 |
| jam | it uses 'make_mpdiffs()' to be able to figure out what actual content was introduced in a revision | 18:05 |
| jam | walking the diff hunks | 18:05 |
| jam | also interesting is that it doesn't seem to index non-ascii data | 18:05 |
| jam | _tokeniser_re = re.compile("[^A-Za-z0-9_]") | 18:06 |
| Peng | That would be a good place for one of bzr's lazy regexes, no? | 18:08 |
| jam | Peng: it probably would, but it is done inside an "_ensure_regexes()" so it is already lazy | 18:08 |
| Peng | "_ensure_regexes()" seems more error-prone than a lazy regex to me. | 18:09 |
| Peng | Anyway, not the point. | 18:12 |
| jam | Peng: Sure, probably mostly because of timing | 18:12 |
| jam | lazy may not have been available | 18:12 |
| Peng | True. | 18:12 |
| jam | also, bzr the command line replaces the regex compiler so that *all* re.compile() statements are lazy | 18:12 |
| === mrevell is now known as mrevell-dinner | ||
| jam | more interesting is that bzr-search does a lot of work to make its content compact | 18:17 |
| jam | using offsets to produce simple integers to do lookups between the different indices | 18:18 |
| jam | I wonder if that is obsolete with btree indices but was never updated to follow suite | 18:18 |
| Lo-lan-do | Any idea why loggerhead would be generating links like <a href="http://zforge.org, zforge.org/scm/loggerhead/testbzr/download/..."? | 18:20 |
| Lo-lan-do | (Note duplication of host) | 18:20 |
| Lo-lan-do | It seems to do it when proxied through Apache but not when IÂ hit it directly. | 18:21 |
| Lo-lan-do | Nevermind, it seems the Apache config does Funny Stuff. | 18:30 |
| Lo-lan-do | Seems maybe I shouldn't try and cascade two levels of proxying… | 18:31 |
| Peng | Two levels of proxying does...that? | 18:31 |
| Peng | I guess it gives the hostname at each level of proxying, in case they're different? | 18:32 |
| Lo-lan-do | Loggerhead receives only one Host: header, but "X-Forwarded-Host: zforge.org, zforge.org" (and same for X-Forwarded-Server) | 18:36 |
| Peng | Ah. | 18:37 |
| Lo-lan-do | I'll debug that after food. | 18:41 |
| Peng_ | Prob'ly a Paste thing. | 18:42 |
| === deryck[lunch] is now known as deryck | ||
| servilio | hi! I have a lot of changes in a project that I'd like to partition across a series of commits, is there a tool that helps on this? | 18:51 |
| Tak | shelve/unshelve? | 18:52 |
| phinze | servilio: yup, shelve/unshelve works or if you prefer there's an interactive commit plugin that's pretty nice | 18:53 |
| phinze | http://bazaar.launchpad.net/~asabil/bzr-interactive/trunk | 18:53 |
| servilio | phinze: thanks! | 18:54 |
| LeoNerd | I quite like shelve/unshelve, although annoyingly shelve(2) doesn't do partial interactive unshelve, as unshelve1 had | 18:54 |
| * servilio goes to look at bzr-interactive | 18:54 | |
| LeoNerd | So you either have to shelve up in reverse order, each set of changes, or.. shelve the lot, commit, unshelve, then reshelve again | 18:54 |
| Lo-lan-do | Peng_: Prob'ly, yes. Any idea how to be sure? | 18:57 |
| SamB_irssi | jam: I'm talking a bajillion different files created in /tmp -- not just a few hundred | 19:00 |
| jam | SamB_irssi: are they being deleted? | 19:02 |
| SamB_irssi | jam: of course, yes | 19:04 |
| SamB_irssi | there only ever seems to be one at a time ... | 19:05 |
| jam | SamB_irssi: then i'm not very surprised | 19:05 |
| jam | bzr-search generates a lot of tiny indices | 19:05 |
| jam | when it is done, you could try doing | 19:06 |
| Peng_ | Lo-lan-do: Sorry, I don't, except for lots of digging around in the code. | 19:06 |
| jam | grep 'Graph Index' .bzr/bzr-search/indices/*.pack | 19:06 |
| jam | and you'll see how many it created | 19:06 |
| jam | also note that it has some logic for combining indices | 19:06 |
| jam | I don't know the frequency, etc | 19:06 |
| jam | but there is a possibility of having significantly more created than the final number | 19:07 |
| jam | SamB_irssi: On my simple index of bzr-search itself (which is a rather tiny project), I have 2928 indices | 19:07 |
| SamB_irssi | % grep 'Graph Index' .bzr/bzr-search/indices/*.pack -c | 19:08 |
| SamB_irssi | .bzr/bzr-search/indices/1aa4b32392ac306a517bbde1541c6156.pack:69833 | 19:08 |
| SamB_irssi | .bzr/bzr-search/indices/1cc10f06974551571a251c2b615a7ecd.pack:42632 | 19:08 |
| SamB_irssi | .bzr/bzr-search/indices/3428b8cb5c8ca0c0ce6fbd3e77440b24.pack:45649 | 19:08 |
| SamB_irssi | .bzr/bzr-search/indices/50ad99ed8415ebe08ff77c5ba0ff2efd.pack:33426 | 19:08 |
| SamB_irssi | .bzr/bzr-search/indices/9b494322bed23caf692fbfb91adea948.pack:47050 | 19:08 |
| SamB_irssi | .bzr/bzr-search/indices/cc5a9bde095ed3939a49a73f1fabb749.pack:42741 | 19:08 |
| bialix | igc: hi | 19:08 |
| jam | SamB_irssi: that isn't a bajillion, that is only about 200k | 19:08 |
| jam | well off of a bajillion | 19:09 |
| bialix | hello all | 19:09 |
| jam | but yes, all 200k of those will have created a temp file | 19:09 |
| SamB_irssi | that's still a heck of a lot of temp files! | 19:09 |
| Peng | 200k temp files? That's healthy... | 19:09 |
| bialix | 200k -- what the hell? | 19:13 |
| jam | bialix: 'bzr-search' while generating the search index creates a *lot* of temp files | 19:14 |
| bialix | oh no | 19:14 |
| jam | only 1 at a time | 19:14 |
| jam | but a lot in a row | 19:15 |
| bialix | this will be major overkill on windows | 19:15 |
| jam | SamB_irssi: actually, looking at the code, we may be creating 2 temp files per index | 19:16 |
| jam | hence why you saw the bzr-index and the plain tmp- | 19:16 |
| jam | we create a temp per row, and then one temp for the root | 19:16 |
| jam | well, temp per row, and then a temp for the final output | 19:16 |
| Peng_ | That's, um, a lot of writing. | 19:18 |
| jam | SamB_irssi: out of curiosity, what is the total size of your .pack files? | 19:23 |
| jam | I'm just curious what the average index size is | 19:23 |
| SamB_irssi | jam: the index ones ? | 19:24 |
| jam | SamB_irssi: yeah | 19:24 |
| jam | du .bzr/bzr-search/indices | 19:24 |
| alf | Hello all, is there a way to tell bzr-svn to have dpush-like behaviour in checkouts (not use bzr metadata)? | 19:24 |
| SamB_irssi | jam: 55 megs, apparently, or 56028 for the command you gave | 19:27 |
| jam | hmm... 288 bytes each | 19:27 |
| jam | lots of small ones :0 | 19:27 |
| SamB_irssi | alf: that would be excessively evil | 19:28 |
| alf | SamB_irssi: why is that? | 19:30 |
| servilio | SamB_irssi: why would that be? for me it would make sense if you are trying to commit to a repo you don't own and don't want to create noise | 19:30 |
| SamB_irssi | I personally think binding to a remote branch is evil period ... | 19:31 |
| Tak | hmm, how much does the post-dpush rebase load the server? | 19:32 |
| SamB_irssi | no, I mean I think you should look at your commit and make sure you did it right before pushing to the remote ;-) | 19:33 |
| Lo-lan-do | Peng_: Too lazy to debug myself, but I found a workaround by deleting the header in the Apache configuration. | 19:34 |
| jam | SamB_irssi: You may be interested in: lp:///~jameinel/bzr/2.1.0b1-small_btree_no_disk | 19:36 |
| jam | That uses an in-memory object until the btree > 1 page (4k bytes) | 19:36 |
| jam | the time for 'bzr index bzr-search' drops from 4s => 1.0s for me | 19:36 |
| Lo-lan-do | http://zforge.org/scm/browser.php?group_id=9 now works :-) | 19:37 |
| ereslibre | ideas on this guys ? http://pastebin.com/m37a7deec | 19:37 |
| jam | ereslibre: upgrade your bzr-gtk | 19:38 |
| jam | ereslibre: the ProgressBarStack was deprecated for a long time before bzr-gtk was updated | 19:38 |
| jam | (which didn't happen until we finally removed it :) | 19:39 |
| bialix | jam: senior Fuente insists on newer subvertpy in windows installer. can you update it and provide new installer? | 19:39 |
| ereslibre | jam: thx :) | 19:39 |
| jam | SamB_irssi: on my Windows laptop, that change makes a world of difference in the OS | 19:43 |
| jam | without it, the System overhead goes through the roof, and my machine is a bit unresponsive | 19:43 |
| jam | with the change, the cpu load goes up, but without a corresponding IO overhead | 19:43 |
| jam | bialix: I'm happy to change it, but what am I changing it to? | 19:44 |
| NET||abuse | hey guys.... trying to update from my laptop to my windows desktop,,, c:\devel\myproject>bzr update "bzr: ERROR: [Error 123] The filename, directory name, or volume label syntax is incorrect" | 19:45 |
| NET||abuse | htis is when it gets down to a file that is in a tmp directory which should be ignored. | 19:45 |
| jam | SamB_irssi: by comparison, I can index all of bzr.dev in 5m2s, with temp files I was at only 22MB/65MB after 4min | 19:49 |
| Peng_ | I'm glad I usually have /tmp as a tmpfs. | 19:52 |
| alf | I was just trying to commit to a checkout of a simple SVN repo and got "bzr: ERROR: exceptions.TypeError: unsupported type None" (along with the traceback). | 19:55 |
| alf | I am using 1.17 (debian). Is this something known/fixed or should I file a bug? | 19:55 |
| davidstrauss | alf: Always upgrade before asking/filing a bug | 19:56 |
| bialix | jam: buildout.cfg: subvertpy-release = 0.6.9 | 19:56 |
| jam | alf: I'm pretty sure that is a known and fixed issue | 19:57 |
| jam | bzr-svn was trying to set a revision property to None | 19:57 |
| jam | rather than an empty string, etc. | 19:57 |
| jam | bialix: what about the version of bzr-svn itself? | 19:57 |
| bialix | jam: I dunno | 19:57 |
| bialix | jam: jelmer is not very specific | 19:57 |
| bialix | jam: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=recall&rev=234 lists bzr-svn 0.6.5 as latest | 19:58 |
| jam | I think we want to release the 1.0 series with 2.0 if possible | 20:01 |
| jam | but I don't know where jelmer is in finishing 1.0 | 20:01 |
| jam | k, I believe Naoki also wanted us to try out tbzr 0.3 | 20:02 |
| jam | rc2-5 ... coming up | 20:02 |
| bialix | thx jam | 20:04 |
| alf | davidstrauss: using bzr 2.0rc2 and latest bzr-svn I am still getting a crash, although I am not sure if it is a bug in bzr or bzr-svn... | 20:26 |
| davidstrauss | alf: Why are you asking me, in particular? | 20:26 |
| alf | davidstrauss: only because you were the first to answer me before, sorry | 20:29 |
| davidstrauss | alf: Sorry, but I don't know anything about bzr-svn :-/ | 20:29 |
| alf | davidstrauss: no problem | 20:30 |
| denys | hmm... just checking: there is no way I can migrate history to a SVN server to which I only have HTTPS access, right? | 20:44 |
| Lo-lan-do | denys: If your history is linear, yes you can. | 20:45 |
| Lo-lan-do | If you have write access. | 20:45 |
| denys | Lo-lan-do: what's the trick? | 20:45 |
| Lo-lan-do | And if you have a non-linear history, then you can only move one part of it. | 20:45 |
| Lo-lan-do | You can push to svn repositories. | 20:46 |
| denys | Lo-lan-do: you mean: I replay the history? | 20:47 |
| denys | Lo-lan-do: bzr-svn + push (I am sorry if this is a stupid question, but I have never done that) | 20:48 |
| denys | Lo-lan-do: I have to migrate a CVS module to a SVN server, and I only have HTTPS access to the SVN server | 20:48 |
| zsquareplusc | really? can't you ask the admin to import a dump of a svn repository? there are cvs2svn tools that work well, you do not need to do the extra conversion through bzr. | 20:50 |
| denys | zsquareplusc: no, unfortunately, there is NO WAY they will allow anything to execute locally on the server. | 20:51 |
| === oink is now known as kiko | ||
| zsquareplusc | denys: svn can dump a repository to a xml file and svnadmin can mport those again. of course the admins would need to run that, not you. i would hope they already to use that to backup their servers.. | 20:52 |
| denys | zsquareplusc: I know this would be possible, but the admins are extremely paranoid and not exactly willing to go out of their way to help. so, that option is unfortunately out. hence my enquiry :-( | 20:54 |
| zsquareplusc | sounds like an IT department of a larger company ;-) | 20:56 |
| Lo-lan-do | Maybe tailor is able to push to a remote SVN repository? | 20:56 |
| denys | just an IT at a modest university | 20:56 |
| zsquareplusc | denys: do you really need to use their svn server? use bzr right away ;-) | 20:57 |
| denys | Lo-lan-do: things is, I could not see how it could be done using svn functionality - I just wanted to check with others | 20:57 |
| denys | zsquareplusc: it has been a 3 years battle just to get svn with external access. I would love to get bzr, but that is still "FUTURE WORK" | 20:58 |
| Lo-lan-do | Ideally, you'd pull from CVS into a bzr branch that's bound to an SVN branch with bzr-svn. | 20:58 |
| Lo-lan-do | But that sounds like a lot of complication. | 20:59 |
| denys | Lo-lan-do: the problem is just preserving history with a reasonably accurate timeline (timestamp-wise) | 21:01 |
| zsquareplusc | denys: well with a distributed system like bzr you don't have to integrate that tightly with system administration. having a smart server may be nice, but bzr also works if you just have webspace where you can push to using sftp :-) | 21:01 |
| denys | zsquareplusc: yes, but the issue is that research oriented projects should be hosted at the university (this is an essential part of the valorization of the work beeing done here). hosting elsewhere is possible (I have done it) but that's not desirable. furthermore, sftp cannot work for external collaborations, because there is no way that the university will grant ssh access (even restricted, even when run in VMs as we do) to non-local | 21:06 |
| denys | personel. | 21:06 |
| zsquareplusc | the external participants would need to host their branches elsewhere ("outside") so that you can merge them in that case. so the "trunk" could be at your place | 21:08 |
| zsquareplusc | denys: hey you came to bzr so we at least have to try to sell it ;-) you can of course also try to import your code into the SVN repo. bzr-svn may work and there may also be other tools that can accomplish this. | 21:10 |
| denys | they would still need to authenticate to get locally hosted branches - and that is a problem | 21:10 |
| zsquareplusc | http+password is possible | 21:10 |
| denys | only if you are in control of the server, which we are not | 21:11 |
| denys | I have NO access to the server but HTTPS | 21:11 |
| zsquareplusc | its the same setup as you would do for https for svn, only that its not the svn backend but a simple forder you have write access to | 21:12 |
| denys | but I have NO access. not to a folder. not to anything. its HTTPS or nothing. | 21:13 |
| zsquareplusc | so you do not even have a web page for your project where you can upload files? | 21:14 |
| denys | no, uploading is also extremely difficult. you need to setup a tunnel through 2 specific gateways. _I_ can do that, but none of my colleagues could. and the pain, the pain... | 21:18 |
| RenatoSilva | I want to have software version in each text file of my application automatically. Is it possible? Just like those $xxx$ comments in CVS | 21:25 |
| fullermd | "Keyword expansion" is the ... well, keyword, you're looking for. | 21:29 |
| fullermd | There's a plugin for it, but it's not practically usable. Needs various bugfixes. | 21:29 |
| RenatoSilva | so bzr doesn't have it in core? | 21:29 |
| fullermd | No. | 21:31 |
| Lo-lan-do | It causes large amounts of headaches in CVS. Would it be better in Bazaar? | 21:33 |
| fullermd | Everything's better in bzr. | 21:33 |
| fullermd | Ponies get distorted by RCS files, y'know. | 21:33 |
| Lo-lan-do | Don't belittle RCS files. RCS files are going to make me rich. | 21:35 |
| Lo-lan-do | Well, they'll make me money, at least. | 21:36 |
| RenatoSilva | how to know what rev a file belongs to? I mean, the rev that was the latest to change that file? | 21:36 |
| Lo-lan-do | (Large migration from CVS to Bazaar planned at a client.) | 21:36 |
| fullermd | "I am Sub Version, the widow of the late Premier of CVS. On his death, he left TEN MILLION DOLLARS in his RCS files. I require your help to move this out of the country..." | 21:36 |
| Lo-lan-do | RenatoSilva: bzr log $file | 21:37 |
| Lo-lan-do | fullermd: :-) | 21:37 |
| zsquareplusc | fullermd: you get too much spam ;-) | 21:37 |
| fullermd | Well... I have an email address. It's tautological. | 21:38 |
| alf | Hello, I am trying to understand why bzr dpush needs a rebase afterwards. Can someone point me to an explanation (preferably containing a simple example)? | 21:39 |
| fullermd | alf: AIUI, because what dpush does IS actually a sort of rebased push. I don't know any details beyond that vague sense though. | 21:41 |
| zsquareplusc | after the dpush it has to make your local revisions carry the ID of the remote branch again, as otherwise they would not look at being the same? the changesets get a new ID when they are integrated in the other VCS. (maybe this, i don't really know) | 21:44 |
| zsquareplusc | so it integrates all your changes in the other repository and the rebase makes your local branch look as it were checked out from the new head of the remote repo. (?) | 21:45 |
| alf | zsquareplusc: the devil is in the details :) | 21:46 |
| RenatoSilva | Lo-lan-do: thanks | 21:47 |
| alf | Let's say that the svn repo contains revision A-B and you dpush additional revisions C-D. | 21:51 |
| alf | Then the local branch will contain A-B-C-D and the remote A-B-C'-D' (?) | 21:52 |
| alf | How then is the rebasing performed? I must be missing something. | 21:54 |
| zsquareplusc | after rebasing, your local repository will also contain A-B-C'-D' - same contents so they are "in sync" | 21:55 |
| alf | Can rebasing delete revisions (eg C-D)? | 21:57 |
| dsuch | hmm is anyone working on a bzr book? | 21:58 |
| fullermd | Depends on your opinion on the Great Detroying History question. | 21:58 |
| fullermd | It doesn't delete them from the repository, no. But they're no longer in your ancestry. | 21:58 |
| RenatoSilva | not following rebase discussion but I have a question about the one from a time ago | 22:01 |
| RenatoSilva | merge from trunk for just updating versus rebase (which I have not used yet) | 22:02 |
| RenatoSilva | isn't the former a mess with your history? | 22:02 |
| zsquareplusc | when you work with bzr on both ends you usually don't need rebase i guess | 22:03 |
| RenatoSilva | because in pratice if you're working on a feature branch, you just want to keep it up-to-date with trunk | 22:03 |
| RenatoSilva | I'm just worried about the mess in mistory | 22:04 |
| RenatoSilva | we'll have seevral artificial commits "merge with trunk" | 22:04 |
| zsquareplusc | why artificial? it was a change in the history of your branch | 22:05 |
| RenatoSilva | is keeping the exact history of what happened, even if it includes those artifical merges (for update purpose), the only reason for preferring the former not the latter? | 22:05 |
| RenatoSilva | zsquareplusc: artificial in the sense that you'd get the same result if you instead of merging from trunk, remove changes, pull from trunk, then apply changes (I think this is rebase) | 22:06 |
| RenatoSilva | zsquareplusc: the question is: is it just about keeping a history??? | 22:06 |
| zsquareplusc | rebase rewrites your branches history. so you may get different revision numbers. with merge you do not have this problem. you just get an increment when you commit the merge | 22:07 |
| RenatoSilva | so you may get different revision numbers? for example? | 22:08 |
| zsquareplusc | in a rebase that can happen. as you can make it base on a different history | 22:09 |
| * RenatoSilva is back (conn problems) | 22:11 | |
| NET||abuse | when you checkout code from a remote system, do you have to specify an absolute path? eg,,, bzr init; bzr pull bzr+ssh://me@ipaddr/home/me/code/project1 or can you just specifiy a location relative to your home on the remote system after the host address? | 22:29 |
| fullermd | Full path, until the server's running 2.1. | 22:31 |
| zsquareplusc | 1) i'd just cd to to local directory with your projects and use bzr branch | 22:31 |
| fullermd | (or you're using sftp) | 22:31 |
| RenatoSilva | fullermd: so rebase... | 22:31 |
| RenatoSilva | fullermd: I was disconnected | 22:31 |
| RenatoSilva | fullermd: what's the problem of rebase | 22:31 |
| === mrevell-dinner is now known as mrevell | ||
| fullermd | Oh, no. I'm not getting drawn into THAT discussion again. | 22:32 |
| NET||abuse | fullermd, ahh,, ok i'm only running 1.18 | 22:32 |
| RenatoSilva | fullermd: our conversation was interrupted | 22:32 |
| fullermd | I wasn't in that conversation. | 22:32 |
| RenatoSilva | fullermd: my point is that rebasing (if I understand it correctly) makes the history more natural, even if not that precise | 22:33 |
| RenatoSilva | fullermd: sorry if you wasn't, I thought it was you who wss talking to me | 22:33 |
| fullermd | No, you were talking with zsquareplusc. After the 15th or 20th time I watched that discussion unfold, I decided it was an utter waste of time. | 22:34 |
| fullermd | If you already agree with $ME (for any value of), there's nothing to discuss, and if you don't, nobody is going to change their mind. | 22:35 |
| fullermd | It's more productive to debate whether god exists, and if so, whether he supports $POLITICAL_PARTY. | 22:35 |
| RenatoSilva | I think you're confusing me to someone wanting a flame war, REALLY | 22:37 |
| RenatoSilva | fullermd: if you were here yesterday or so you'd know why I was asking | 22:37 |
| fullermd | Yeah, that's what everybody says when they open up topics like that :p | 22:37 |
| RenatoSilva | fullermd: I don't even know how to use rebase or what it is exactly, I just think the idea is good | 22:37 |
| RenatoSilva | fullermd: ok forget the word rebase, I'll explain the problem more strictly | 22:38 |
| RenatoSilva | fullermd: ok forget the word rebase, I'll explain the problem more strictly (ignore if you wish) | 22:39 |
| NET||abuse | hmm, i have .bzrignore in the root directory of my WT, is that that right location for my ignore list? | 22:40 |
| NET||abuse | i'm finding that some files matching my pattern aren't being ignored. | 22:40 |
| fullermd | It is. | 22:40 |
| fullermd | What suggests they aren't being ignored? | 22:41 |
| NET||abuse | they're appearing in unknown | 22:41 |
| fullermd | Oh. That's a good indication 8-} | 22:41 |
| NET||abuse | ahhh wait, they're in another tmp dir near the other tmp dir.... ;P | 22:41 |
| NET||abuse | there's tmp for uploads, and a tmp for captcha's,, i forgot to ignore jpg's in the captcha tmp.... oops | 22:42 |
| RenatoSilva | 1) I have feature branch fb cerated from trunk rev 10 2) I submit a few revisions to trunk, which is now at rev 15 3) at the same time I commit to fb, which is now in rev 12 and done 4) I merge fb into trunk and the result is... | 22:42 |
| NET||abuse | bzr: ERROR: [Errno 2] No such file or directory: u'C:/Users/Me/Documents/devel/project.com/.bzr/checkout/limbo/new-2/web/public/shared/js/jquery.form.js?2.31" | 22:43 |
| NET||abuse | what's this about??? | 22:43 |
| NET||abuse | trying to pull down from repo on my linux box. | 22:43 |
| NET||abuse | windows version i'm getting this error on is 1.18.1 and linux version is 1.18 | 22:44 |
| === verterok_ is now known as verterok | ||
| fullermd | Got me. There've been occasional weird issues with files being/not being in limbo where they shouldn't/should, but they were mostly older versions. | 22:48 |
| fullermd | Is it happening consistently? | 22:48 |
| NET||abuse | yeh, i completely deleted the copy on the windows machine, then re-init'd an empty branch, and tried to pull into that branch again. | 22:49 |
| NET||abuse | is it something to do with the ? in the file name perhaps? | 22:49 |
| fullermd | Possible, I guess, if that's illegal on Windows. But I thought all those cases were handled. | 22:50 |
| fullermd | Any particular reason you're init/pull'ing instead of branch'ing? | 22:50 |
| NET||abuse | oh, tried just branching also and it broke. | 22:50 |
| NET||abuse | was first try to just branch. | 22:50 |
| NET||abuse | just as alternate method tried init/pull | 22:50 |
| NET||abuse | didn't try a shared repo yet,,, but i feel this is something to do with the file or that character, rather than antyhing like branch locaiton. | 22:51 |
| jam | morning lifeless | 22:51 |
| fullermd | No, shared repo wouldn't much matter. That's all happening in limbo (building the working tree) | 22:51 |
| fullermd | Can you make filenames with question marks in them? | 22:51 |
| fullermd | jam may be more helpful than I... | 22:52 |
| NET||abuse | i'm actually just deleting the file from the branch on linux machine, and trying now, it was just a copy of the downloaded jquery.form 's plugin. | 22:52 |
| jam | fullermd: ? is illegale | 22:52 |
| jam | \ / * : ? | " < > are all illegal | 22:53 |
| poolie | hello | 22:53 |
| poolie | hi jam | 22:53 |
| jam | hey poolie | 22:53 |
| fullermd | Well, that would 'splain it then. | 22:53 |
| fullermd | Though I thought we had traps to give more pointed errors in cases like that. | 22:53 |
| jam | NET||abuse: I would agree with fullermd that I thought we would at least give a nice error for this case. But we can't create them so you need to delete them on another machine (for now) | 22:54 |
| NET||abuse | eh, yeh,,, problem solved... hmmmm so no ? marks in windows version. | 22:54 |
| NET||abuse | guess it could be an ntfs problem. | 22:55 |
| NET||abuse | restricted characters | 22:55 |
| jam | poolie: let me know when/if you want to call | 22:55 |
| poolie | jam, hi, i do want to call | 22:56 |
| poolie | i'm just finishing something up here and i'll call in a few minutes | 22:56 |
| poolie | skype/home/mobile? | 22:56 |
| jam | home is probably easiest, but skype is fine too | 22:56 |
| lifeless | hi jam | 23:01 |
| lifeless | so the cStringIO thing; my original thought was 'probably won't hit disk', I think. | 23:01 |
| lifeless | jam: but I'm glad to have it be nicer for windows ;) | 23:01 |
| jam | lifeless: well, it has to allocate an inode, etc | 23:01 |
| jam | I'll try checking it on a linux box | 23:01 |
| lifeless | allocating the inode doesn't have to hit disk, until fsync on the containing dir | 23:02 |
| lifeless | anyhow, I've +1'd | 23:02 |
| jam | yeah, I sawthat | 23:02 |
| poolie | jam, calling | 23:02 |
| NET||abuse | huh.. when i have parent branch: bzr+ssh://me@ipaddr/path/to/repo but then bzr push says no push location | 23:10 |
| NET||abuse | sorry for the basicness of this, it's just a bit of a confusion | 23:10 |
| fullermd | push doesn't use the parent location by default. | 23:11 |
| fullermd | It has its own. | 23:11 |
| NET||abuse | ohhh,, how do i set that then? | 23:11 |
| fullermd | You can use the saved loc shortcut to set it quick (`bzr push :parent`) | 23:11 |
| NET||abuse | ahhh, ok | 23:13 |
| NET||abuse | bit confusing though isn't it? | 23:13 |
| fullermd | The operative theory is that push'ing to somewhere other than you branch'd from is a very common case. | 23:14 |
| fullermd | (e.g., you might often branch from a location you can't write to) | 23:14 |
| NET||abuse | ahah,, that's true. | 23:15 |
| NET||abuse | i guess.. it's just more a ,, where do i look for those instructions? | 23:15 |
| NET||abuse | they're not very obvious, even after reading the workflows documentation. | 23:15 |
| fullermd | Contrast with merge, which also has its own stored location, but will use the pull loc if that's not set. | 23:15 |
| zsquareplusc | hm. when that :parent shortcut works in such cases, it would be worth mentioning that in the error message of push when it has not yet a saved location | 23:15 |
| fullermd | First, merge'ing from your original base is more common, and second, if it's NOT what you want, accidentally doing so isn't near as harmful. | 23:16 |
| fullermd | (if you accidentally push somewhere you didn't intend, it can be much harder to undo) | 23:16 |
| fullermd | Not sure what instructions you mean. If you mean having to supply a location when none is saved, that's common to pretty much any command (including pull). | 23:16 |
| fullermd | If you mean the shortcut names, last I heard they weren't documented. | 23:17 |
| fullermd | Their existence is mentioned buried in NEWS, but last time I wanted to know what the choices were I had to dig into the code. | 23:17 |
| fullermd | That was a while ago, though. Maybe they're in the manual. | 23:17 |
| zsquareplusc | well i did not know about it, i always had to specify the same URL 3 times.. branch then pull/merge and push :/ | 23:17 |
| jam | lifeless: so on an old linux box, indexing 'bzr-search' itself: 4.894s => 2.426s | 23:17 |
| lifeless | cool | 23:18 |
| fullermd | (I haven't followed the progression of the documentation as closely as I should :| ) | 23:19 |
| fullermd | zsquareplusc: You certainly shouldn't have to specify it on pull after branch. branch sets the parent loc. | 23:20 |
| zsquareplusc | fullermd: with instructions i mean instead of just "bzr: ERROR: No push location known or specified." it could additionally mention what's possible | 23:20 |
| fullermd | Well, what's possible is specifying it. Trying to describe all the possible forms that can take is *way* out of scope for an error message. | 23:21 |
| fullermd | It _should_ (in the sense of 'out to', not 'I think is') be in the docs. | 23:22 |
| fullermd | Holy crow. "ought to". My fingers are not my friends today. | 23:22 |
| zsquareplusc | i'd not mind short usage tips when i'm doing something wrong. better than nothing and "good look to find it in the manual" | 23:23 |
| fullermd | Giving useful tips in a situation like that is bzr-dwim territory ;) | 23:24 |
| alf | I am experimenting with bzr-svn and have created a branch of an svn repo. I have commited something on local branch and something in the svn repo so they have diverged. | 23:25 |
| zsquareplusc | well an an option is when the help is built in to give at least a hint on how to get that help, e.g. if there were a "bzr help location" it could direct the user to read that. | 23:26 |
| alf | I am trying to push to the svn and of course I cannot due to the branches having diverged. So I merge from svn to the local branch. | 23:28 |
| alf | Now when I try to push to the svn it says that Operation denied because it would change the mainline history... | 23:29 |
| alf | I am wondering in what way my push will change the history on the svn. | 23:30 |
| fullermd | svn can't represent the history bzr has, and the standard projection into lower dimensions (as it were) differs from the existing history. | 23:31 |
| zsquareplusc | so is this one of the use cases for rebase? | 23:34 |
| alf | so if svn and its bzr branch have diverged, is there a way to perform the merge from the branch->svn without changing the mainline? | 23:34 |
| alf | (I mean the mainline history) | 23:35 |
| fullermd | Generally, by doing the merge the other way around, so the svn history and bzr mainline coincide. | 23:36 |
| alf | I don't think I got that. If my branch and svn have diverge what steps do I have to take to get my branches changes to svn (without history changing)? | 23:39 |
| fullermd | Merge the bzr changes into the svn changes, rather than the other way around. | 23:40 |
| fullermd | e.g., have a checkout (not a branch) of the svn branch, and a bzr branch in which you do the work. To land it, merge it into the checkout and commit it. | 23:40 |
| alf | ahh, ok | 23:41 |
| fullermd | (you could use a branch instead of a checkout of course, but a checkout can be conceptually more accurate) | 23:41 |
| fullermd | Basically, you want to end up with "merge my-changes ; push" rather than "merge upstream-changes ; push" | 23:41 |
| alf | if I use a branch isn't the situation the same as the one we have been talking about? | 23:42 |
| fullermd | No, it's not really branch vs checkout, it's a question of which side of the merge you're on. | 23:43 |
| fullermd | Checkout just conceptually fits what you're doing (merging stuff into the svn 'branch') and suits staying in lockstep. | 23:44 |
| RenatoSilva | I'd appreciate very much if you could read this http://pastie.org/625271 :) | 23:46 |
| RenatoSilva | http://pastie.org/625271 - update-merges vs. rebase | 23:46 |
| RenatoSilva | that's an example where I put how would it be in both cases | 23:47 |
| alf | fullermd: thanks for the explanation, I think after some processing on my part things will become clear | 23:48 |
| zsquareplusc | RenatoSilva: i don't think that this will work in all cases. you known that with rebase, you can run into conflicts while rewriting the history? | 23:52 |
| RenatoSilva | zsquareplusc: see I'm not agueeing, I'm learning. No I don't know | 23:54 |
| RenatoSilva | zsquareplusc: what proplems in that example could get wrong? | 23:54 |
| RenatoSilva | * argueeing | 23:54 |
| RenatoSilva | * arguing | 23:55 |
| RenatoSilva | zsquareplusc: in that example specifically, no history is really rewritten, it's just like starting the work again after each update in trunk | 23:57 |
| RenatoSilva | zsquareplusc: e.g. you could replace steps 3.[2,3].2 with "forget it all, do the same code changes again manually" | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
