| lifeless | poolie: review done | 00:02 |
|---|---|---|
| lifeless | poolie: I haven't made a vote as such, I'll leave it up to you. I would consider it needs-fixing if I were to vote | 00:03 |
| poolie | k | 00:03 |
| poolie | is this the same one ian reviewed? | 00:03 |
| lifeless | yes | 00:03 |
| lifeless | I didn't comment on the stuff he caught | 00:04 |
| poolie | k | 00:04 |
| poolie | i'm going to try to close mail soon and do that | 00:04 |
| lifeless | I'm going to look at this mv a b; mv b a; fail bug | 00:10 |
| lifeless | as I have dirstate paged in currently | 00:10 |
| lifeless | then onto commit via deltas | 00:10 |
| kenichi | i need help understanding the difference between rebase and merge --remember. the situation is 3 unbound branches, A, B, C. C was branched from A, A got merged to B, and C wants to get all of B's changes from now on. | 00:16 |
| LeoNerd | It's about tree topology | 00:16 |
| LeoNerd | merge joins two branches of a tree back together | 00:16 |
| LeoNerd | rebase pretends there wasn't a branch at all | 00:16 |
| kenichi | IIUC, rebase would make C look like it branched from B *today* and replay all of C's changes after that. | 00:16 |
| LeoNerd | Yup | 00:16 |
| kenichi | and merge --remember would apply the changes and set parent_location for future use. | 00:17 |
| LeoNerd | merge: -----<======\---- | 00:17 |
| LeoNerd | rebase: -------\_________ | 00:17 |
| LeoNerd | (by terrible ASCII-art) | 00:17 |
| lifeless | poolie: when thinking about testing | 00:18 |
| kenichi | s/terrible/awesome/ | 00:18 |
| lifeless | poolie: do remember that running the whole stack is very expensive | 00:18 |
| lifeless | poolie: I hope that many easy bugs are best tested via tweaks to existing tests rather than new tests | 00:19 |
| kenichi | LeoNerd: thanks | 00:20 |
| MT- | any ideas what this error means? bzr: ERROR: bzrlib.errors.NotLefthandHistory: Supplied history does not follow left-hand parents | 00:21 |
| poolie | lifeless: running the whole stack in the sense of run_bzr? | 00:23 |
| lifeless | yes | 00:23 |
| lifeless | we say somewhere in our testing notes | 00:23 |
| poolie | mt-: um, it depends on the context | 00:23 |
| poolie | yes i do remember that | 00:23 |
| lifeless | that best practice for blackbox tests is to use the low level API for setting up the scenario | 00:24 |
| lifeless | and only use the full stack when we're testing it | 00:24 |
| MT- | poolie: http://paste.ubuntu.com/218399/ | 00:26 |
| MT- | poolie: somebody else is doing that. It works fine when I do it :S | 00:27 |
| poolie | lifeless: yes, that's pretty much what i said in my mail | 00:28 |
| igc | morning all | 00:29 |
| poolie | i'm not ignorant of that | 00:29 |
| lifeless | poolie: ok cool | 00:29 |
| poolie | i'm just questioning whether it is worth trading some of that off against having: | 00:29 |
| poolie | better illustrations of what happens | 00:29 |
| igc | hi poolie, lifeless | 00:29 |
| poolie | and easier approachability for people writing tests | 00:29 |
| poolie | casually | 00:29 |
| poolie | whether the second would actually happen enough to be worthwhile is uncertain | 00:29 |
| poolie | hello igc | 00:30 |
| lifeless | I am skeptical. We have lots of contributors that have wafted up and cloned tests very successfully | 00:31 |
| poolie | MT-: that would seem to be a bug, perhaps provoked by something in the source branch | 00:31 |
| lifeless | hi igc | 00:31 |
| poolie | MT-: the first thing i would try is going to a more recent bzr | 00:31 |
| MT- | poolie: I'll try that, thanks | 00:33 |
| lifeless | poolie: https://bugs.edge.launchpad.net/bzr/+bug/395556 - you say in there you'll merge some tests. Have you? | 00:37 |
| ubottu | Ubuntu bug 395556 in bzr "bzr mv (rename in place) causes commit to fail depending on specific filenames" [High,Confirmed] | 00:37 |
| poolie | so, we also have lots of contributors who balk at writing a test | 00:37 |
| poolie | possibly they would do that even if testing was zero effort at all | 00:38 |
| lifeless | we can test this cheaply | 00:38 |
| lifeless | by writing the tests ourselves, but *not* fixing up fallout | 00:38 |
| lifeless | by cheaply I mean, without inventing infrastructure that might not be used. | 00:39 |
| poolie | that's a factor too | 00:39 |
| lifeless | if the contributors don't follow up and fix the regressions we find, then its pretty certain they wouldn't test that will regardless | 00:39 |
| poolie | will? | 00:40 |
| lifeless | e | 00:40 |
| poolie | anyhow, yes | 00:40 |
| poolie | it may be that in fact they've put up a patch that doesn't actually work | 00:40 |
| poolie | i'm just trying to think of some answer to "testing is too hard" beyond "suck it up" | 00:40 |
| poolie | :? | 00:40 |
| poolie | also, in reviewing aaron's patch, i do think it's suboptimal that there is no clear demonstration of how it actually works | 00:41 |
| lifeless | I agree with that | 00:41 |
| poolie | like the idea that lp should put screenshots of the proposed fix on bugs | 00:41 |
| poolie | heh, the analogy is interesting | 00:41 |
| poolie | because testing by comparing to screenshots is pretty sucky | 00:42 |
| lifeless | we do have the ability, in run_bzr, to provide inputs to commands | 00:42 |
| poolie | as a stdin stringio? | 00:42 |
| lifeless | poolie: the tests for bug 395556, did they land? and where can I find them - are they XFAIL's? | 00:42 |
| ubottu | Launchpad bug 395556 in bzr "bzr mv (rename in place) causes commit to fail depending on specific filenames" [High,Confirmed] https://launchpad.net/bugs/395556 | 00:42 |
| poolie | i'll check, was talking to someone :-P | 00:43 |
| lifeless | poolie: yes, though I think we provide glue to make it easier to use than that | 00:43 |
| poolie | i think i submitted them | 00:43 |
| poolie | yes, there are knownfailure tests in trunk | 00:44 |
| poolie | grep for that bug number | 00:44 |
| lifeless | thanks | 00:44 |
| kenichi | LeoNerd: i went with merge --remember, but the parent_location of the branch did not change upon commit... what am i misunderstanding? | 00:45 |
| poolie | one way to look at it is i'm suggesting more or higher-quality glue | 00:45 |
| poolie | input as blah(... stdin="y\n\n\n\r\n") is not so easy to review | 00:45 |
| poolie | improving that can be done stepwise | 00:46 |
| poolie | without going away from the other things that are good in our test suite | 00:46 |
| poolie | and i think not at a terribly high cost | 00:46 |
| poolie | spiv, re https://code.edge.launchpad.net/~mbp/bzr/391411-reconfigure-stacked/+merge/8527 | 00:47 |
| poolie | would making RemoteRepository be a Repostiory subclass be very traumatic? | 00:48 |
| * jml -> chatswood for breakfast. | 00:51 | |
| spiv | poolie: not sure. Well, I'm sure there was a reason why it wasn't done like that initially. | 00:53 |
| spiv | Perhaps a good starting point would be to create a new common base class for RemoteRepository and Repository, and gradually move things into that? | 00:53 |
| spiv | Perhaps we'll be able to collapse that base class and Repository fairly rapidly. | 00:54 |
| poolie | heh, that's what i was doing | 00:54 |
| poolie | lifeless didn't like it :) | 00:54 |
| spiv | Heh. | 00:54 |
| poolie | but maybe with a comment it would get by | 00:54 |
| spiv | It is a little odd to me that we have Branch and BzrBranch, but no similar split for Repository. | 00:54 |
| GungaDin | Has anyone here used bzr from a virtual machine? | 00:55 |
| lifeless | so | 00:56 |
| lifeless | I don't recall any good reason for them being different | 00:56 |
| lifeless | I think it is worth doing a test run with RR as a subclass of Repository | 00:56 |
| lifeless | it will answer the question much faster than speculation | 00:56 |
| lifeless | its true that there is potential for confusion, having a proxy object subclass the thing it proxies | 00:57 |
| lifeless | but that shouldn't be worse than with Branch | 00:57 |
| lifeless | spiv: we do have a split in the repository classes | 00:57 |
| lifeless | spiv: Repository is the abstract interface - we have wildly different subclasses | 00:58 |
| lifeless | GungaDin: yes, people have used bzr from vms | 00:58 |
| lifeless | GungaDin: some of the core developers do so regularly. | 00:58 |
| GungaDin | and they're able to checkout stuff without problems? | 00:59 |
| GungaDin | with bzr+ssh? | 00:59 |
| lifeless | yes and yes | 01:00 |
| lifeless | I really encourage you to file a bug so that *all* the developers can help you, rather than just the ones that see what you type here. | 01:01 |
| GungaDin | I also installed Ubuntu in VirtualBox... and the problem persists. | 01:01 |
| GungaDin | btw.. I was able to checkout with https... but not with bzr+ssh. | 01:01 |
| GungaDin | well, I can't be sure it's a bug. | 01:02 |
| GungaDin | at least not necessarily in Bazaar. | 01:02 |
| lifeless | thats fine | 01:03 |
| lifeless | bug trackers are a place to discuss problbems | 01:03 |
| lifeless | there is no requirement that everything in them be known to be a bug prior to putting the thing in the bug tracker | 01:04 |
| lifeless | if there was such a requirement, very few bugs would ever be put in bugtrackers | 01:04 |
| GungaDin | ok | 01:05 |
| GungaDin | I don't think it's bzr... | 01:05 |
| GungaDin | now for the first time it's gone past this stage... | 01:05 |
| GungaDin | and it'sa ctually building the tree... | 01:05 |
| lifeless | its happening to bzr | 01:06 |
| GungaDin | what the hell is going on... | 01:06 |
| GungaDin | ?! | 01:06 |
| lifeless | even if its not bzr we'd like to know whats going on | 01:06 |
| MT- | I have a section of a bug tracker that's almost entirely used for discussions and notes.. | 01:06 |
| lifeless | so that we can advise other people if they have these symptoms | 01:06 |
| GungaDin | lifelfess - I'd like to file as much as i can... but it's happening at my work... so I'm a bit limited getting all the info. | 01:06 |
| lifeless | or perhaps we can come up with a change to bzr to reduce this happening | 01:06 |
| lifeless | GungaDin: I can appreciate that | 01:07 |
| GungaDin | what would you have me do, then? | 01:07 |
| lifeless | file a bug :) | 01:08 |
| lifeless | tell us what you can | 01:09 |
| lifeless | this will let folk that are not here right now chime in | 01:09 |
| lifeless | it sounds like it just worked for you though? | 01:09 |
| GungaDin | ok, I filed a bug report. | 01:18 |
| GungaDin | yes, now it just worked.... | 01:19 |
| lifeless | well thats some good news:) | 01:19 |
| poolie | see? isn't filing bugs good? :) | 01:20 |
| GungaDin | anyway, thanks for your help. | 01:26 |
| garyvdm | Hi igc - I'm finished everything I wanted to on the TreeWidget. Any thoughts on what to tackle next? | 01:39 |
| lifeless | igc: I've pushed all my inventory delta prophylactic code btw | 01:41 |
| igc | hi garyvdm! | 02:13 |
| garyvdm | Hi Ian | 02:14 |
| igc | garyvdm: the next thing I was hoping you'd work on was ... | 02:14 |
| igc | a better revision widget | 02:14 |
| igc | or was it a better branch widget? I forget | 02:14 |
| igc | anyhow, one or both of them given ... | 02:15 |
| garyvdm | branch widget? | 02:15 |
| igc | numerous q* commands use those | 02:15 |
| igc | garyvdm: I'd need to look over my notes but ... | 02:16 |
| igc | I think the main issue was being able to select a merge directive, not just a directory | 02:16 |
| garyvdm | Ok - Let me look at the revision selector. | 02:17 |
| igc | garyvdm: thanks. I suspect it was far more important than the branch one | 02:18 |
| igc | garyvdm: there were also some small qbzr issues that someone (perhaps you?) could fix soon: | 02:19 |
| igc | 1. the compatibility with bzr-pipeline issue | 02:19 |
| igc | 2. qinfo working on a shared repo | 02:19 |
| igc | 3. qrevert dropping pending merges | 02:20 |
| garyvdm | igc: if you have a chance - please try out lp:~garyvdm/qbzr/newwtlist | 02:20 |
| igc | garyvdm: I'll take a look at those next week say if no-one gets to them | 02:20 |
| igc | garyvdm: I need to focus on some 2.0 stuff this week but I promise I'll take a (another) look this weekend say | 02:22 |
| garyvdm | igc: Np - I understand. | 02:22 |
| igc | (my nights are pretty full this week with family stuff) | 02:22 |
| garyvdm | igc: For no. 3 - I posted a mockup to the bug. How does that look? | 02:23 |
| igc | garyvdm: that looks good | 02:24 |
| garyvdm | Cool - I get that done. | 02:24 |
| garyvdm | First - a itch scratch - Spell checker suggestions in qcommit :-) | 02:25 |
| igc | garyvdm: also, did you see the comments from lifeless re register_lazy_decorated? | 02:26 |
| igc | garyvdm: I'm reviewing that now btw | 02:26 |
| igc | garyvdm: if you're in agreement with Robert's comments, I'll defer my review till you've done those changes | 02:27 |
| garyvdm | Yes - but unfortunately - that won't really help to solve the bzr-pipeline compatibility problem. It's a bit more complex. | 02:27 |
| === TDJACR is now known as TheDJACR | ||
| igc | garyvdm: so pipeline and qbzr are both overriding the merge command from what I've been told | 02:34 |
| igc | garyvdm: if that's right, why does qbzr need to? | 02:34 |
| garyvdm | qbzr adds merge --qpreview | 02:35 |
| garyvdm | which shows the preview in qdiff | 02:35 |
| jml | poolie, thanks for the prompt & clear metronome response | 02:40 |
| poolie | thanks for the metronome | 02:40 |
| poolie | also for the "these people are wrong" :-) | 02:40 |
| jml | so, I'm thinking of not RMing 1.17+1 | 02:46 |
| jml | I'd really like to get back into actually writing code. | 02:46 |
| igc | garyvdm: so I think we need to rethink qdiff launching actually | 02:51 |
| garyvdm | qdiff or qpreview? | 02:51 |
| igc | garyvdm: I like qdiff but sometimes I really want to use meld for a period of time, e.g. when doing a complex review | 02:52 |
| igc | garyvdm: if I configure meld as a diff tool, then qcommit (say) still launches qdiff but then let's me launch meld from there IIUIC | 02:52 |
| igc | garyvdm: I kind of think it should just launch meld directly | 02:53 |
| garyvdm | igc - You can make meld the default. Then if you click on diff in any of the qbzr windows, if will open meld | 02:53 |
| igc | garyvdm: also, maybe "merge -qpreview" is better as "merge --review --using qdiff" or something like that | 02:54 |
| igc | garyvdm: I tried that and it didn't seem to work for me. I'll try again soon | 02:54 |
| garyvdm | igc - yes | 02:54 |
| garyvdm | igc - it won't (go straight to meld) if you just run bzr qdiff - so we probably need to make things like bzr explorer aware of the qdiff config. | 02:57 |
| igc | garyvdm: what about making qdiff smarter and getting it to launch the right default diff tool? | 03:12 |
| igc | garyvdm: I can make epxlorer smarter but those smarts need to also go into ... | 03:12 |
| igc | TortoiseBzr, qbzr-eclipse, etc. | 03:13 |
| igc | garyvdm: seems better to just make qdiff Do The Right Thing IMO | 03:13 |
| garyvdm | igc - 1. If you do that, and you make some other tool the default, how do you get into qdiff? | 03:14 |
| garyvdm | Maybe add a option to qdiff: bzr qdiff --usingconfigdefault | 03:15 |
| garyvdm | 2. - err forgot what 2 was. | 03:15 |
| igc | garyvdm: 1. not sure. Adding an option would work fine (either way). | 03:16 |
| dash | hm | 03:18 |
| dash | I did 'bzr uncommit' and now I regret it. however, the revision id that uncommit gave me has scrolled off my terminal. is there any way to get it back? :) | 03:19 |
| garyvdm | dash: install bzrtools plugin | 03:20 |
| dash | done | 03:20 |
| garyvdm | dash: run bzr heads --dead | 03:20 |
| * igc lunch then back onto reviewing apply-inv-delta patch from lifeless | 03:21 | |
| dash | ach. this is branched from SVN | 03:22 |
| dash | and i'm getting an error from the svn server as a result of that command | 03:22 |
| dash | (not a checkout, not a lightweight checkout, a branch) | 03:22 |
| garyvdm | dash: sorry - not sure then. | 03:23 |
| dash | pretty weird =/ | 03:25 |
| dash | thanks for the pointer anyway | 03:25 |
| === _thumper_ is now known as thumper | ||
| === garyvdm_ is now known as garyvdm | ||
| === ja1 is now known as jam | ||
| dash | heh, ran some of the code from the heads plugin mnually | 03:41 |
| dash | got it back :) | 03:41 |
| dash | hooray for bzr. | 03:42 |
| poolie | lifeless: why remove the branches? because they're no longer playing the same role of being canonical and primary? | 04:51 |
| lifeless | poolie: several reasons; its faster to pull from lp; lp has a branch viewer; we don't point people at the directory anyway - we have a wiki page listing the urls | 04:52 |
| poolie | this seems like a reason to change the wiki not remove them | 04:53 |
| lifeless | changing the wiki is implicit | 04:53 |
| lifeless | by which I mean the wiki page should point at the primary location | 04:54 |
| poolie | is bug 399540 the guy who was talking to you before here? | 04:54 |
| ubottu | Launchpad bug 399540 in bzr "bzr works strangely in a virtual machine guest" [Undecided,New] https://launchpad.net/bugs/399540 | 04:54 |
| poolie | what a weird bug | 04:54 |
| lifeless | I think so | 04:54 |
| poolie | igc, i've updated the spreadsheet, review it at your convenience | 05:27 |
| * poolie crosses off another item | 05:27 | |
| igc | poolie: thanks | 05:41 |
| poolie | lifeless, spiv, igc, i'm out for a bit, online again after 5 | 06:44 |
| lifeless | poolie: I'll be gone by then; ciao. | 06:44 |
| igc | ok | 06:44 |
| === abentley1 is now known as abentley | ||
| lifeless | so, 3 bugs fixed. | 07:00 |
| lifeless | sent up for review. | 07:00 |
| lifeless | ciao y'all | 07:11 |
| vila | hi all | 07:26 |
| * spiv ducks out to shops | 07:41 | |
| jelmer | mwhudson: hey | 08:08 |
| jelmer | mwhudson: Are the git revisions imported one-by-one by launchpad? | 08:09 |
| mwhudson | jelmer: no | 08:09 |
| mwhudson | well, what do you mean? | 08:09 |
| jelmer | mwhudson: I'm subscribed to the samba branch, and woke up to find 750 new emails waiting for me... | 08:09 |
| mwhudson | jelmer: the emails are done one by one and the import was broken for a few weeks | 08:09 |
| mwhudson | jelmer: there's nothing special about git imports here | 08:09 |
| mwhudson | (we should probably avoid this sort of flood somehow though) | 08:10 |
| jelmer | mwhudson: that'd be nice | 08:15 |
| jelmer | mwhudson: does this also happen for "native" bzr branches, if somebody pushes multiple revisions to them? | 08:16 |
| mwhudson | jelmer: yes | 08:16 |
| phurl | hi all | 08:16 |
| phurl | i have a launchpad branch i would like to merge to | 08:16 |
| jelmer | mwhudson: ah, ok | 08:16 |
| jelmer | mwhudson: It's just a temporary thing then I guess, since this branch got "unbroken" because of the new bzr-git | 08:16 |
| mwhudson | jelmer: right | 08:17 |
| mwhudson | jelmer: it makes rebasing a bit interesting! | 08:17 |
| phurl | what is the syntax of that? do i got to my existing branch and say bzr merge ****** | 08:17 |
| jelmer | phurl: bzr merge lp:~username/projectname/branchname | 08:23 |
| phurl | thanks | 08:24 |
| jelmer | mwhudson: did something just land that makes sure the cache is kept? | 08:33 |
| jelmer | mwhudson: I was a bit surprised to see the samba branch working now | 08:33 |
| mwhudson | jelmer: yes | 08:35 |
| jelmer | mwhudson: \o/ | 08:40 |
| johnskulski | can anyone point me to documentation about keeping one bzr branch in another? | 08:48 |
| johnskulski | say I have project1/ and module1/ and I want to keep a copy of module1 within project1 | 08:48 |
| johnskulski | is this a vendor branch | 08:49 |
| === abentley1 is now known as abentley | ||
| jml | johnskulski, the feature is known as 'nested trees', and it's not implemented in Bazaar (yet) | 08:51 |
| johnskulski | jml:: i see. is there a workflow without using 3rd party tools? | 08:52 |
| LarstiQ | johnskulski: with bzr-scmproj | 08:53 |
| johnskulski | have you all used either that or config-manager? are they solid? | 08:53 |
| jml | johnskulski, it depends on what you mean by 'third party tools' and what you're exact use case is. You can do a pretty good job with symlinks & a couple of simple shell scripts | 08:53 |
| LarstiQ | johnskulski: I've used scmproj, but most people get by without anything of the sorts | 08:54 |
| johnskulski | hm ok | 08:54 |
| asabil | oui ? | 08:54 |
| asabil | sorry wrong window :) | 08:54 |
| jml | johnskulski, I haven't used config-manager directly, but I'm told that the Launchpad development team use it. | 08:54 |
| johnskulski | thanks for you advice. | 08:55 |
| johnskulski | it would be great to push back changes from individual projects | 08:56 |
| johnskulski | jml:: what would the shell scripts do? | 08:56 |
| johnskulski | generate and apply patches? | 08:56 |
| jml | uhh, they'd reimplement config-manager :) | 08:57 |
| johnskulski | hehe | 08:58 |
| jml | or as much of it as you actually need for what you want to do. | 08:58 |
| johnskulski | jml:: i'm confused on what commands would accmplish what I'm trying to do | 09:03 |
| johnskulski | (new to bzr) | 09:03 |
| jml | johnskulski, what are you trying to do? | 09:04 |
| johnskulski | project/ is a bzr repository, module1/ is a bzr repo, i would like to have project/module1/ be a branch of module1 such that i can add it to the project repos (so another branch will have that) and push changes back to module1/ (bug fixes, the module is shared among other projects) | 09:06 |
| jml | wow... getting acf locally! | 09:07 |
| johnskulski | acf? | 09:07 |
| jml | johnskulski, not related to our conversation, but related to the channel more generally :) | 09:08 |
| jml | (I'm multitasking a little atm) | 09:08 |
| johnskulski | ah | 09:08 |
| johnskulski | no worries :) | 09:08 |
| jml | johnskulski, so, what you'd do is have a script or a make step or something in project/ that run 'bzr branch central-copy:module1' | 09:09 |
| jml | johnskulski, that is, there'd be no tightly defined relationship between project/ & module1/ in bzr itself, it would be a part of your build scripts. | 09:10 |
| johnskulski | jml:: i am not sure what central-copy: means | 09:10 |
| johnskulski | i am not find it in the docs | 09:10 |
| jml | there's going to be a canonical location for module1 right? | 09:11 |
| jml | on one of your servers or launchpad or whatever | 09:11 |
| jml | the thing that's 'trunk' for that module. | 09:11 |
| johnskulski | yeah this will all be on a local filesystem | 09:11 |
| johnskulski | right | 09:11 |
| jml | johnskulski, is it just you working on the project? | 09:11 |
| johnskulski | something liek /var/bzr/shared/module1 | 09:11 |
| johnskulski | jml:: no about 12 of us | 09:12 |
| johnskulski | all diferent projects | 09:12 |
| johnskulski | usually sperately | 09:12 |
| jml | why are you sharing a filesystem? | 09:12 |
| johnskulski | central dev | 09:12 |
| jml | can't you afford hard drives? | 09:12 |
| jml | anyway, that's off topic | 09:12 |
| johnskulski | we have a centralized development server | 09:13 |
| johnskulski | same machine | 09:13 |
| jml | you can't run the project on your local machines? | 09:13 |
| igc | night all | 09:13 |
| johnskulski | jml:: it doesn't matter :) | 09:13 |
| jml | so, as I was saying, you'd have something in your build scripts that says, 'bzr branch file:///var/bzr/shared/module1' | 09:14 |
| jml | or a variation on that. | 09:15 |
| johnskulski | let me tyr this, thanks! | 09:16 |
| jml | I work on Launchpad. We have a bunch of dependencies that we manage in branches. We pull those from a server using a script, and then whenever we create a branch locally, we run another script to symlink those branches into that new branch. | 09:16 |
| jml | (because we tend to have one branch per feature/bugfix) | 09:16 |
| johnskulski | jml, do you work with applications? | 09:24 |
| jml | johnskulski, I don't follow. I work on Launchpad itself. :) | 09:25 |
| johnskulski | my set up is: we are a webapp shop and generally we work on 8-10 projects at a time all based off a standard framework, on top of that we have modules that we would like to include in each projects. it would be a great win if say i'm working a project and could push back changes to the framework or module | 09:26 |
| johnskulski | maybe another set up is more appropriate | 09:26 |
| johnskulski | launchpad itself? the webapp? | 09:26 |
| jml | johnskulski, yes. | 09:26 |
| fullermd | I tend to just merge in modules that I use in multiple places. That doesn't work well for the case where you want to work ON the module in the context of a given project, and then push those module changes back upstream though. | 09:28 |
| fullermd | But I don't do that very often, so dealing with it manually in those cases works well enough for me. | 09:28 |
| johnskulski | jml:: we don't do builds, which may be something we could switch to | 09:28 |
| johnskulski | fullermd:: so if you fix something in the module, you generate a patch and apply it to it manually? | 09:30 |
| === abentley1 is now known as abentley | ||
| fullermd | johnskulski: In one form or another, yah. | 09:37 |
| fullermd | Most of the time I just work on changes directly in the module though (and the ones that make that hard, I have on my list to improve so that it's not) | 09:38 |
| LarstiQ | johnskulski: seriously, have a look at scmproj | 09:38 |
| fullermd | Yah. The 'by-reference' style nested tree work will be most like what you want, and scmproj is a variant of that. | 09:40 |
| johnskulski | LarstiQ:: yes this looks great | 09:52 |
| johnskulski | thanks | 09:52 |
| johnskulski | this channel proves helpful everytime, thanks! | 09:52 |
| === mario__ is now known as pygi | ||
| === beuno_ is now known as beuno | ||
| eyda|mon | can someone remind me what plugin is required to get the webserve thing going? | 13:23 |
| vila | loggerhead ? | 13:24 |
| eyda|mon | yes, thanks | 13:25 |
| eyda|mon | how do I use this thing? | 13:30 |
| eyda|mon | how do I see what plugin commands are avail? | 13:31 |
| luks | bzr plugins | 13:38 |
| === Pilky_ is now known as Pilky | ||
| eyda|mon | luks: that tells me what plugins are available, not what the commands are | 13:53 |
| spiv | eyda|mon: bzr commands, although that will list builtin commands. | 13:54 |
| luks | oh, sorry, I misread the question | 13:54 |
| spiv | But will include the plugins too :) | 13:54 |
| eyda|mon | luks: no worries | 13:54 |
| luks | bzr help commands | 13:54 |
| spiv | Er, sorry: bzr help commands | 13:54 |
| eyda|mon | so there's no specific command to just list the ones for a specific plugin | 13:54 |
| luks | bzr help commands | grep PLUGINNAME :) | 13:54 |
| eyda|mon | I'm trying to use the loggerhead but there are no instructions on their site | 13:55 |
| LarstiQ | bzr help plugins/<plugin> ? | 13:55 |
| eyda|mon | grep works :) | 13:55 |
| luks | that shows you the help page, not a list of commands | 13:55 |
| LarstiQ | luks: sure, but it is probably more helpful | 13:55 |
| LarstiQ | luks: seeing as loggerhead doesn't feature in commands, but does mention how it works in the plugin help | 13:56 |
| LarstiQ | luks: to be fair, eyda|mon asked the wrong question ;) | 13:57 |
| luks | I know nothing about loggerhead, just answering questions :) | 13:57 |
| LarstiQ | eyda|mon: found the `bzr serve --http`? | 13:57 |
| eyda|mon | LarstiQ: to be fair, eydaimon didn't know what question to ask because the plugin setup isn't obvious | 13:57 |
| * LarstiQ nods at eyda|mon | 13:57 | |
| eyda|mon | LarstiQ: yes, thanks | 13:57 |
| spiv | eyda|mon: also, the README file might help: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/annotate/head%3A/README | 13:57 |
| LarstiQ | eyda|mon: asking the right question is not easy to do | 13:58 |
| eyda|mon | I was after what I thought would be a common interface on how to use plugins | 13:58 |
| eyda|mon | or to find out their usage anyway | 13:58 |
| spiv | Plugins can do quite a wide variety of things :) | 13:58 |
| LarstiQ | eyda|mon: I usually look at the README | 13:58 |
| eyda|mon | that's why I think it would be nice if I could just do bzr plugins PLUGIN and it would tell me the avilable commands | 13:59 |
| spiv | Some add commands, some extend existing commands, some add hooks, some add new formats, etc... | 13:59 |
| LarstiQ | eyda|mon: but I think stressing something useful in the online help system is a good idea | 13:59 |
| eyda|mon | and that includes extending, adding, hooks etc :) | 13:59 |
| eyda|mon | ok | 14:00 |
| eyda|mon | LarstiQ: are you suggesting I file a ticket? | 14:00 |
| spiv | eyda|mon: that's "bzr help plugin/<foo>" at the moment. | 14:00 |
| LarstiQ | eyda|mon: I didn't yet, but yes please :) | 14:01 |
| spiv | Perhaps "bzr plugins" should suggest that, it's not particularly discoverable at the moment. | 14:01 |
| * LarstiQ nods at spiv | 14:01 | |
| fullermd | There is no help plugin/XYZ... | 14:01 |
| fullermd | There's plugin_s_/XYZ, but that just gives the 1-liner. | 14:01 |
| spiv | fullermd: sorry, typo. Thanks | 14:01 |
| spiv | fullermd: try plugins/svn or plugins/gtk | 14:02 |
| LarstiQ | or plugins/loggerhead | 14:02 |
| spiv | fullermd: it's not necessarily a one-liner. | 14:02 |
| fullermd | Sure, but that's only if the plugin lists it. bzrtools frex tells you nothing. | 14:02 |
| spiv | File a bug on bzrtools :) | 14:02 |
| eyda|mon | you guys are missing the help plugins :) | 14:03 |
| eyda|mon | seems like something so useful as loggerhead should be included in bzr | 14:04 |
| spiv | eyda|mon: yeah, that's been discussed occasionally. I don't recall the outcome, though. | 14:05 |
| fullermd | Well, once you add up all the so-useful-to-$PERSON's, you end up with a real big tarball ;) | 14:05 |
| eyda|mon | fullermd: I'm more important than others so, my useful-to-eydaimon should be considered very carefully | 14:06 |
| spiv | I know we would like to make it easy to do something like "bzr serve --http" to run up a quick and simple bzr+http smart server with loggerhead. | 14:06 |
| spiv | eyda|mon: :) | 14:06 |
| eyda|mon | yeah, like mercurials | 14:07 |
| fullermd | eyda|mon: Oh, I didn't realize it was YOU. Carry on. | 14:07 |
| eyda|mon | nothing fancy, but it works | 14:07 |
| eyda|mon | fullermd: there we go :) | 14:07 |
| * eyda|mon wonders when people will start to grasp his importance | 14:07 | |
| fullermd | Probably not 'till after they give up on their screwed up sleep schedules and just synchronize with mine. | 14:08 |
| * fullermd still vaguely wishes to be able to sufficiently flexibilate URL handling on bzr+http. | 14:09 | |
| fullermd | (and flexibilate is totally a word. You can look it up. In my brain.) | 14:10 |
| * eyda|mon makes a new port for SimpleTAL since macports doesn't have one. | 14:12 | |
| eyda|mon | feels like I'm ALWAYS making new ports | 14:12 |
| fullermd | Hey, welcome to MY life... | 14:12 |
| hmeland_ | I've had a look at one of the 'easy' open bugs, namely #72227 -- but I am unable to reproduce the problem with the current bzr (1.17~rc1+4531+117 from the nightly ppa). | 14:15 |
| hmeland_ | Does anyone know if the problem still is present? | 14:16 |
| fullermd | bug 72227 | 14:16 |
| ubottu | Launchpad bug 72227 in bzr "should avoid loading modules from working directory" [High,Confirmed] https://launchpad.net/bugs/72227 | 14:16 |
| fullermd | Seems like I heard it mentioned just last week or so, biting somebody. | 14:16 |
| LarstiQ | ehm, that one is not actually easy | 14:17 |
| fullermd | Hey, paramiko moved to git... | 14:17 |
| LarstiQ | hmeland_: it certainlly still happens. Do you have access to Windows? | 14:18 |
| hmeland_ | LarstiQ: Yes, I can install Bazaar in my XP virtualbox. Is the problem only happening on Windows, though? | 14:19 |
| LarstiQ | hmeland_: no, it happens everywhere | 14:19 |
| LarstiQ | well, maybe not everywhere then | 14:21 |
| hmeland_ | A transcript of (one of) my attempts at reproducing it can be found here: http://pastebin.ubuntu.com/218919/ | 14:21 |
| hmeland_ | Where am I going wrong? | 14:21 |
| LarstiQ | hmeland_: some but not all python installations add '' to the path | 14:23 |
| * LarstiQ looks for one of the duplicates | 14:23 | |
| hmeland_ | According to http://docs.python.org/library/sys.html#sys.path , the '' stuff should only happen if "the script directory is not available". | 14:25 |
| hmeland_ | Are you saying that some Python versions are getting this wrong, or is it stuff that some distributions of Python get wrong (e.g. in their site.py)? | 14:27 |
| LarstiQ | hmeland_: https://bugs.edge.launchpad.net/bzr/+bug/304891 | 14:27 |
| ubottu | Ubuntu bug 304891 in bzr "bzr doesn't work in parent directories of python packages with certain names (dup-of: 72227)" [Undecided,New] | 14:27 |
| ubottu | Ubuntu bug 72227 in bzr "should avoid loading modules from working directory" [High,Confirmed] | 14:27 |
| LarstiQ | hmeland_: one of those I guess | 14:27 |
| eyda|mon | alright, port submitted | 14:28 |
| eyda|mon | now to continue on with the installation of loggerhead :) | 14:28 |
| LarstiQ | hmeland_: I personally can't get it to reproduce on Lenny either | 14:28 |
| LarstiQ | hmeland_: but I've witnessed it in the past | 14:28 |
| LarstiQ | eyda|mon: thanks :) | 14:28 |
| LarstiQ | hmeland_: you could ask wgrant | 14:28 |
| eyda|mon | LarstiQ: it was the port for simpletal. I guess I could make for loggerhead too | 14:29 |
| LarstiQ | eyda|mon: is that MacPorts? | 14:31 |
| eyda|mon | LarstiQ: yes | 14:33 |
| eyda|mon | argh! | 14:33 |
| eyda|mon | the loggerhead tarball untarred a bunch of files in the extract dir | 14:33 |
| * eyda|mon whines | 14:33 | |
| eyda|mon | it does have a setup.py though. that will make it easy to install at least the libs | 14:34 |
| wgrant | LarstiQ: I'm confused - I know nothing about that bug, so why am I suggested? | 14:41 |
| LarstiQ | wgrant: eek, sorry :/ | 14:43 |
| wgrant | LarstiQ: 'tis no problem. I'm just intrigued as to why me. But I'm half asleep, so I'm also intrigued as to why I'm not in bed yet. | 14:47 |
| * wgrant goes to bed. | 14:47 | |
| LarstiQ | wgrant: because in my memory it was you, and I glossed over the reports name starting with a W but being different | 14:48 |
| fullermd | All then W's look alike to me... | 14:48 |
| === ddaa1 is now known as ddaa | ||
| eyda|mon | bzr serve --http | 15:12 |
| eyda|mon | bzr: ERROR: No module named config | 15:12 |
| eyda|mon | You may need to install this Python library separate | 15:12 |
| eyda|mon | any idea what's missing here? | 15:12 |
| eyda|mon | it's not listed in depenency for loggerhead | 15:13 |
| LarstiQ | eyda|mon: could you pastebin the backtrace from .bzr.log? | 15:13 |
| eyda|mon | ok | 15:14 |
| eyda|mon | http://pastie.org/546808 | 15:14 |
| LarstiQ | woo, that is not supposed to happen | 15:15 |
| eyda|mon | heh | 15:16 |
| LarstiQ | eyda|mon: is there a 'loggerhead' directory in your cwd? | 15:17 |
| eyda|mon | no | 15:20 |
| LarstiQ | ah | 15:20 |
| LarstiQ | eyda|mon: how did you install loggerhead? It looks you might have one layer of hierarchy too much in ~/.bazaar/plugins/loggerhead/loggerhead/ | 15:21 |
| LarstiQ | eyda|mon: if ~/.bazaar/plugins/loggerhead/ only contains the loggerhead directory, move that one up | 15:21 |
| eyda|mon | ok | 15:22 |
| eyda|mon | let me wipe it and start over | 15:22 |
| eyda|mon | maybe the port installed another one | 15:22 |
| LarstiQ | how I would install it: `bzr branch lp:loggerhead ~/.bazaar/plugins/` | 15:23 |
| eyda|mon | yeah, but I'm making a port since I'm at it | 15:24 |
| * LarstiQ nods | 15:24 | |
| LarstiQ | eyda|mon: in that case, the right location is probably bzrlib/plugins/ | 15:24 |
| eyda|mon | can I find that path out from running some bzr cmd? | 15:25 |
| LarstiQ | eyda|mon: `bzr --version` should tell you | 15:25 |
| eyda|mon | meh, I'll need to parse that output with tcl | 15:26 |
| eyda|mon | who chooses tcl.. gree | 15:26 |
| eyda|mon | grr | 15:26 |
| eyda|mon | i don't suppose loggerhead itself knows where to install itself | 15:26 |
| eyda|mon | oh, there's a gtk port | 15:27 |
| eyda|mon | I can see how they did it | 15:27 |
| fullermd | There's probably a bzrtools port too, which may be quicker to read. | 15:27 |
| eyda|mon | there is | 15:28 |
| eyda|mon | doesn't look like it does anything special to install.. maybe it's setup.py takes care of it for it. | 15:29 |
| fullermd | Yah, setup.py does all that fiddling... | 15:29 |
| eyda|mon | but it doesn't do that for loggerhead | 15:30 |
| eyda|mon | same with gtk | 15:30 |
| LarstiQ | so where does gtk end up then? | 15:31 |
| eyda|mon | bzrlib/plugins | 15:31 |
| eyda|mon | I have to go. I guess I will resume this later. | 15:34 |
| LarstiQ | eyda|mon: ah, I think it might be the packager_dir/packages pointing to bzrlib.plugins? | 15:34 |
| LarstiQ | eyda|mon: k | 15:34 |
| === kiko-afk is now known as kiko | ||
| jnz_ | Hi, when I type `bzr send -o ~/filepath' there's are some errors: http://www.nopaste.com/p/aoIFcyzjab | 16:23 |
| vila | jnz_: wow, 'bzr version' , 'bzr info' please | 16:25 |
| jnz_ | 1.14.1, http://www.nopaste.com/p/ajijogjifb | 16:27 |
| vila | jnz_: hmm, sorry, 'bzr info -v' | 16:28 |
| jnz_ | http://www.nopaste.com/p/afSnRrj2cb | 16:30 |
| vila | jnz_: anyway, the warnings are ugly enough, file a bug, | 16:30 |
| vila | jnz_: Can you try to upgrade to a more recent version of bzr ? | 16:31 |
| vila | jnz_: Also, have a look in .bzr.log, there may be more detailed info there | 16:32 |
| jnz_ | ok, I'll try. If I still have the problem, I should open a file? where? (sorry I'm new to bzr) | 16:33 |
| vila | https://bugs.launchpad.net/bzr/+filebug | 16:34 |
| vila | jnz_: np, welcome on board :) | 16:34 |
| jnz_ | ah right | 16:34 |
| jnz_ | thanks :) | 16:34 |
| _gpg_ | hello | 17:32 |
| _gpg_ | is it possible to have the latest release (and updates) for ubuntu 8.04 ? | 17:35 |
| luks | use the ppa? | 17:40 |
| vila | _gpg_: https://edge.launchpad.net/~bzr/+archive/ppa and take your pick | 17:40 |
| _gpg_ | vila, thank you | 17:42 |
| _gpg_ | vila, i have seen it just before your post :) | 17:43 |
| jnz_ | ok, I've resolved upgrading to 1.16.1 :> | 17:48 |
| cellofellow | I'm trying to push a bzr branch to an svn repository. The bzr branch has about five revisions that need to be pushed. I got this error: bzr: ERROR: Operation denied because it would change the mainline history. Set the append_revisions_only setting to False on branch "http://runningmethod.com/svn/runningmethod/mrc/trunk" to allow the mainline to change. | 18:37 |
| cellofellow | Is there a way to push my changes as one svn revision? | 18:37 |
| jelmer | cellofellow: yes, set the append_revision_only setting to False | 18:39 |
| jelmer | cellofellow: as the error message indicates :-) | 18:39 |
| cellofellow | where's that setting? | 18:39 |
| jelmer | cellofellow: in locations.conf, subversion.conf or bazaar.conf | 18:41 |
| cellofellow | ok, added to bazaar.conf | 18:41 |
| fullermd | I didn't know you COULD pivot the mainline history in svn... | 18:42 |
| cellofellow | :/ | 18:43 |
| cellofellow | can I wrap up all my revisions into one somehow? | 18:43 |
| Luke-Jr | jelmer: why does bzr-svn never seem to work for anything other than the simplest stuff? :þ | 19:15 |
| jelmer | Luke-Jr: what's not working? | 19:15 |
| Luke-Jr | pushing a merge | 19:16 |
| jelmer | Luke-Jr: what about it is not working? | 19:16 |
| Luke-Jr | bzr: ERROR: exceptions.AssertionError: path: path/to/THIS/branch, 197 ≥ 471 | 19:16 |
| jelmer | Luke-Jr: what version? | 19:16 |
| Luke-Jr | bzr: ERROR: exceptions.AssertionError: path: path/to/THIS/branch, 197 >= 471 | 19:16 |
| Luke-Jr | bzr 1.15.1; bzr-svn 0.6.1 | 19:17 |
| jelmer | Luke-Jr: please try 0.6.2 or the 0.6 branch, if that doesn't work please file a bug | 19:17 |
| Luke-Jr | -.- | 19:17 |
| Luke-Jr | tell bzr overlay guy to update? :þ | 19:17 |
| jelmer | Luke-Jr: it might just be that the existing data in your repository is broken and that's continuing bzr-svn to break | 19:17 |
| Luke-Jr | better not be :þ | 19:18 |
| Luke-Jr | this isn't even the same repository that was giving me problems before | 19:19 |
| jelmer | does the other repository work now? | 19:20 |
| Luke-Jr | using 0.6.2, get a different error | 19:20 |
| Luke-Jr | no idea | 19:20 |
| Luke-Jr | bzr: ERROR: Tags not supported by SvnBranch('svn+https://svn.openmethodscorp.com/svn/SoftPhone/Harte-Hanks/CTI/Cvlan-Server'); you may be able to use bzr upgrade. | 19:20 |
| Luke-Jr | err, ignore the paths in that of course ☺ | 19:20 |
| Luke-Jr | jelmer: so am I just not allowed to tag things? :þ | 19:21 |
| jelmer | Luke-Jr: that one isn't a bug | 19:21 |
| jelmer | Luke-Jr: your local branch has tags but bzr-svn doesn't know where to store the tags in the svn repositories | 19:22 |
| Luke-Jr | neither do I | 19:22 |
| Luke-Jr | I don't see a push option to omit tags | 19:22 |
| jelmer | Luke-Jr: there isn't one | 19:22 |
| Luke-Jr | so how do I get past this? | 19:22 |
| Luke-Jr | ideally without losing my local tags | 19:23 |
| jelmer | Luke-Jr: remove your local tags | 19:23 |
| Luke-Jr | :/ | 19:23 |
| Luke-Jr | seriously? | 19:23 |
| jelmer | Luke-Jr: or modify your configuration to indicate where the tags are in svn | 19:23 |
| Luke-Jr | nowhere :þ | 19:23 |
| Luke-Jr | can't it just be lossy in that regard? | 19:23 |
| jelmer | Luke-Jr: bzr would need infrastructure for that first | 19:23 |
| jelmer | Luke-Jr: this is unrelated to bzr-svn | 19:24 |
| Luke-Jr | sigh | 19:24 |
| Luke-Jr | fine, how do I make it put them in a tags dir? | 19:24 |
| jelmer | Luke-Jr: set the tags option in the configuration | 19:24 |
| Luke-Jr | what configuration? | 19:24 |
| jelmer | Luke-Jr: subversion.conf or locations.conf | 19:25 |
| Luke-Jr | <.< | 19:26 |
| Luke-Jr | [svn+https://svn.openmethodscorp.com/svn/SoftPhone/Harte-Hanks/CTI/*Server*] | 19:28 |
| Luke-Jr | tags = svn/SoftPhone/Harte-Hanks/CTI/Server-tags/* | 19:28 |
| Luke-Jr | still does the same thing | 19:28 |
| jam | hey jelmer how's it going? | 19:29 |
| jelmer | hey jam | 19:29 |
| jelmer | jam: pretty good, hanging out in Madrid | 19:29 |
| jam | sounds like fun | 19:30 |
| jam | I was wondering if you had a chance to look at the small patches to bzr-svn and bzr-rewrite to get them to work properly with bzr 1.17 (especially when bundled for windows) | 19:30 |
| jelmer | Luke-Jr: try running "bzr svn-layout" on that URL, that should tell you where it will store the tags | 19:30 |
| jelmer | jam: I already applied an alternative fix to the bzr-svn one | 19:31 |
| jelmer | not sure about bzr-rewrite | 19:31 |
| jam | jelmer: did you make a release? | 19:31 |
| Luke-Jr | bzr: ERROR: Not a Subversion branch or repository. | 19:31 |
| jam | I didn't see a new release on Launchpad at least | 19:31 |
| Luke-Jr | -.- | 19:31 |
| jam | mwhudson: I have a partial fix for bug #393366. There are some edge cases it doesn't quite handle, so I was wondering if you could determine how often those edge cases occur | 19:32 |
| ubottu | Launchpad bug 393366 in bzr "KeyError in knit.simple_annotate running annotate on a stacked branch" [High,Fix committed] https://launchpad.net/bugs/393366 | 19:32 |
| jam | (bug #399884) | 19:32 |
| ubottu | Launchpad bug 399884 in bzr "get_record_stream(..., 'topological', True) in pre 2.0 formats does not preserve topological sorting across stacking boundaries" [Low,Triaged] https://launchpad.net/bugs/399884 | 19:32 |
| Luke-Jr | Repository root: svn+https://svn.openmethodscorp.com/svn/SoftPhone | 19:32 |
| Luke-Jr | Layout: CustomLayout(['Harte-Hanks/CTI/Cvlan-Server'],[]) | 19:32 |
| Luke-Jr | Branch path: Harte-Hanks/CTI/Cvlan-Server | 19:32 |
| Luke-Jr | Project: Harte-Hanks/CTI/Cvlan-Server | 19:32 |
| Luke-Jr | bzr: ERROR: Layout CustomLayout(['Harte-Hanks/CTI/Cvlan-Server'],[]) does not support custom branch paths. | 19:32 |
| Luke-Jr | jelmer: … | 19:41 |
| jelmer | jam: no I haven't made a release yet | 20:29 |
| Luke-Jr | jelmer: poek | 20:30 |
| jelmer | Luke-Jr: the URL you're specifying should be the URL of the repository | 20:31 |
| Luke-Jr | yes, I did that, see above? | 20:32 |
| Luke-Jr | [13:32:44] <Luke-Jr> Repository root: svn+https://svn.openmethodscorp.com/svn/SoftPhone | 20:33 |
| Luke-Jr | [13:32:44] <Luke-Jr> Layout: CustomLayout(['Harte-Hanks/CTI/Cvlan-Server'],[]) | 20:33 |
| Luke-Jr | [13:32:44] <Luke-Jr> Branch path: Harte-Hanks/CTI/Cvlan-Server | 20:33 |
| Luke-Jr | [13:32:44] <Luke-Jr> Project: Harte-Hanks/CTI/Cvlan-Server | 20:33 |
| Luke-Jr | [13:32:44] <Luke-Jr> bzr: ERROR: Layout CustomLayout(['Harte-Hanks/CTI/Cvlan-Server'],[]) does not support custom branch paths. | 20:33 |
| jelmer | so what did you set exactly? | 20:34 |
| Adys | Hmm | 20:36 |
| SamB | hmm ... is there someone I could ask for the "~/.bzr.log" for a consistantly failing mirrored branch? | 20:36 |
| Adys | Getting this on anything I do in my repo: bzr: ERROR: Cannot lock LockDir(file:///home/adys/src/bzr/sigrie/.bzr/checkout/lock): Permission denied: "/home/adys/src/bzr/sigrie/.bzr/checkout/lock/drthu03p89.tmp": [Errno 13] Permission denied: '/home/adys/src/bzr/sigrie/.bzr/checkout/lock/drthu03p89.tmp' | 20:36 |
| jelmer | SamB: I think the .bzr.log file is provided on the website | 20:37 |
| SamB | jelmer: really? | 20:37 |
| jelmer | yeah, there should be a link to view the log | 20:37 |
| SamB | I don't see anything on https://code.launchpad.net/~dvc-dev/dvc/main :-( | 20:38 |
| Luke-Jr | jelmer: | 20:39 |
| Luke-Jr | [svn+https://svn.openmethodscorp.com/svn/SoftPhone/Harte-Hanks/CTI/*Server*] | 20:39 |
| Luke-Jr | tags = Harte-Hanks/CTI/Server-tags/* | 20:40 |
| Luke-Jr | branches = Harte-Hanks/CTI/*Server* | 20:40 |
| Luke-Jr | override-svn-revprops = svn:date | 20:40 |
| jelmer | Luke-Jr: that's not the repository root | 20:40 |
| Luke-Jr | ? | 20:40 |
| jelmer | Luke-Jr: [svn+https://svn.openmethodscorp.com/svn/SoftPhone/Harte-Hanks/CTI/*Server*] | 20:42 |
| Luke-Jr | jelmer: meaning? | 20:42 |
| jelmer | is not the repository root | 20:42 |
| Luke-Jr | ok? | 20:42 |
| Luke-Jr | it only applies to those paths | 20:42 |
| Luke-Jr | svn+https://svn.openmethodscorp.com/svn/SoftPhone/Harte-Hanks/CTI/foobar could be entirely different | 20:43 |
| djahandarie | Hello... I'd like some opionios on how to structure our bzr repo. I've already read the section on this in the intro guide. | 20:44 |
| djahandarie | Basically, I'm working with a web application. Therefore local 'compiling' is worthless at this point. | 20:45 |
| djahandarie | I have three servers currently: 'development', 'testing', and 'production'. | 20:45 |
| djahandarie | Would it be best to have branches of these? A central repo? Hooks? | 20:46 |
| djahandarie | I'm new to bazaar so anyone's opinion would be great! | 20:46 |
| Luke-Jr | djahandarie: not sure, you might try asking in an anime channel | 20:48 |
| * djahandarie stabs Luke-Jr | 20:48 | |
| Luke-Jr | XD | 20:48 |
| mwhudson | jam: how can i do that? | 20:48 |
| jam | mwhudson: for branches which are failing, run that code with "bzr annotate $PATH" | 20:49 |
| jam | mwhudson: you're on your own for figuring out what was failing, :) | 20:51 |
| mwhudson | jam: probably a bit of a fiddle to do automatically, i'll see what i can manage | 20:51 |
| mwhudson | (after i've finished getting up :) | 20:51 |
| Luke-Jr | jelmer: so what SHOULD I be putting? | 20:51 |
| jam | mwhudson: well, I made it work for the one you mentioned | 20:51 |
| jam | I don't know about others | 20:51 |
| jelmer | Luke-Jr: the repository root as reported by e.g. bzr info | 20:52 |
| mwhudson | right | 20:52 |
| djahandarie | So, anyone got any ideas as to how to format the centralized repository to handle my 3-tiered server install? | 20:53 |
| Luke-Jr | jelmer: ok, I'll ignore the obvious problems with that for a minute-- it still doesn't work | 20:54 |
| Luke-Jr | [svn+https://svn.openmethodscorp.com/svn/SoftPhone] | 20:54 |
| Luke-Jr | tags = Harte-Hanks/CTI/Server-tags/* | 20:54 |
| Luke-Jr | branches = Harte-Hanks/CTI/Cvlan-Server | 20:54 |
| Luke-Jr | Repository root: svn+https://svn.openmethodscorp.com/svn/SoftPhone | 20:55 |
| Luke-Jr | Layout: WildcardLayout(['Harte-Hanks/CTI/Cvlan-Server'],['Harte-Hanks/CTI/Server-tags/*']) | 20:55 |
| Luke-Jr | Branch path: Harte-Hanks/CTI/Cvlan-Server | 20:55 |
| Luke-Jr | Project: Harte-Hanks/CTI/Cvlan-Server | 20:55 |
| Luke-Jr | bzr: ERROR: Layout WildcardLayout(['Harte-Hanks/CTI/Cvlan-Server'],['Harte-Hanks/CTI/Server-tags/*']) does not support custom branch paths. | 20:55 |
| djahandarie | Luke-Jr, pastebin | 20:55 |
| djahandarie | -_- | 20:55 |
| jelmer | Luke-Jr: that looks right, except for that last bit | 20:56 |
| djahandarie | I feel like I'm going to have to abandon the practice of making a seperate repo for every feature, because every time I push to that repo I'll need to merge it with the dev repo as well to actually test it. | 20:56 |
| Luke-Jr | djahandarie: why would it be any different from normal software production? | 20:57 |
| Luke-Jr | jelmer: so... :/ | 20:57 |
| djahandarie | Luke-Jr, well, you can compile locally when normally working. But now you'll have to upload all your changes to the testing server every time to test something. | 20:57 |
| Luke-Jr | djahandarie: rsync works well | 20:59 |
| djahandarie | rsync what? | 20:59 |
| djahandarie | The central repo to the server? | 20:59 |
| Luke-Jr | rsync ./ devserver:/var/www/bla/htdocs/…/ -av | 20:59 |
| djahandarie | Luke-Jr, uh, so I'd end up having files on the server that have nothing to do with the central repository? | 21:00 |
| djahandarie | This is for a team enviornment | 21:00 |
| Luke-Jr | djahandarie: guess you shoudl setup local webservers | 21:00 |
| djahandarie | Luke-Jr, can't. | 21:00 |
| djahandarie | I was thinking about making the central repo have 3 branches: 'development', 'testing', 'production'. | 21:01 |
| jelmer | Luke-Jr: not sure what that's about, I'll go check | 21:02 |
| djahandarie | And then you'd merge your change locally into the right branch, commit to the central repo, and then the central repo would have a hook to automatically update the servers. | 21:03 |
| Luke-Jr | djahandarie: pretty sure bzr doesn't support such hooks | 21:03 |
| djahandarie | Luke-Jr, it does. | 21:04 |
| Luke-Jr | and you should really test things before committing | 21:04 |
| djahandarie | Luke-Jr, the point is that testing it is impossible. | 21:04 |
| Luke-Jr | nah | 21:04 |
| jelmer | Luke-Jr: Sorry, this doesn't seem to be implemented yet for WildcardLayout | 21:06 |
| jelmer | Luke-Jr: for CustomLayout it should work without problems | 21:06 |
| jelmer | Luke-Jr: I *think* | 21:06 |
| Luke-Jr | … | 21:06 |
| Luke-Jr | meaning? | 21:06 |
| jelmer | Luke-Jr: layout/standard.py:344 | 21:06 |
| Luke-Jr | from an end user perspective? | 21:06 |
| jelmer | Luke-Jr: I don't think this works yet, unfortunately so please file a bug | 21:07 |
| djahandarie | The only annoying part about how I'm doing this is that when a change is made in a feature branch, you'd need to 1. save the file 2. merge the feature branch with the development branch 3. commit the development branch 4. check | 21:07 |
| djahandarie | So feature branchs would be a huge hassle until you actually push the changes to testing, and then production. | 21:07 |
| djahandarie | But if I didn't do feature branchs, then I'd have to cherry-pick the correct things into the testing/production branches, which would suck even more. | 21:08 |
| Luke-Jr | djahandarie: s/push/merge | 21:08 |
| djahandarie | Yeah, sorry, merge* | 21:08 |
| Luke-Jr | djahandarie: seems to me your development model is inherently flawed | 21:08 |
| djahandarie | Luke-Jr, yes, because of the fact you can only test it in one place. | 21:09 |
| djahandarie | So a DVCS is hard to work with/ | 21:09 |
| djahandarie | But trying to do crazy merging with SVN sucks so I stayed away from that | 21:09 |
| fullermd | I've occasionally taken contracts that required working on code that could only be worked on in one place. I've never done so and not regretted it, though... | 21:10 |
| Luke-Jr | djahandarie: "only test it in one place" is inherently bad | 21:10 |
| djahandarie | Ideally, the solution for this would be that 'feature branchs' automatically merge into the 'development' branch. | 21:11 |
| djahandarie | Luke-Jr, I know, but that's the environment I'm working with here, so stop making me feel even worse about it, alright? | 21:11 |
| fullermd | If every commit has to be made and then stuck in dev before it can even be tested, it would be a lot easier to just eschew feature branches and work right in dev, I'd think. | 21:11 |
| fullermd | I mean, you're basically talking about making a commit at a time, and merging them individually before moving on to the next one anyway. So you're not in essence using another branch ANYway. | 21:12 |
| === beaumonta is now known as abeaumont | ||
| djahandarie | fullermd, right, but then how would I push the feature to testing/production? | 21:13 |
| djahandarie | Without cherry-picking | 21:13 |
| fullermd | Presumably, the same way you would've yanked the feature from the feature branch to dev, with a merge. | 21:13 |
| djahandarie | fullermd, wait, I thought you just said to scrap feature branches? | 21:14 |
| fullermd | Hence "would've" rather than "did" :p | 21:14 |
| djahandarie | fullermd, ah. | 21:14 |
| djahandarie | But then I would have to move ALL of development into testing/production | 21:15 |
| djahandarie | Not the 'parts that work'. | 21:15 |
| djahandarie | i.e., totally ruining the whole point of using Bazaar | 21:16 |
| fullermd | Ah. Well, there's no getting around 'take it all' or 'cherrypick'; Excluded Middle. | 21:16 |
| djahandarie | Actually, does anyone know if a hook would be able to automatically merge the branch if the name of the branch isn't in [x,y,z]? | 21:16 |
| djahandarie | Because that would solve the problem. | 21:17 |
| djahandarie | It's just that the hook would have to be on every developer's local repo. | 21:17 |
| djahandarie | Hmmmm | 21:18 |
| fullermd | Well, with feature branches, you'd still have cherrypick issues, unless you started each branch from a GCA of the 3 dev/test/prod. And that's just going to be an ever-increasing nightmare scenario, even before taking into account the huge overhead your process imposes on feature branch work anyway. | 21:18 |
| djahandarie | GCA? | 21:18 |
| fullermd | I'd start by semi-eliminating the test/prod split, by making production be pull'd from test at "stable" points (that being the point of test). That at least drops you to 2 nightmares instead of 3... | 21:19 |
| fullermd | The latest common node in their combined DAGs. | 21:19 |
| fullermd | (DAGen? DOG?) | 21:19 |
| djahandarie | fullermd, well, then how would I do bug fixes on production? | 21:20 |
| fullermd | Well, the theory is that nothing ever goes to production until it's been vetted in test... | 21:20 |
| djahandarie | Testing is just to make sure feature X works with the rest of the system outside of the development enviornment. | 21:21 |
| fullermd | So you'd bring bugfixes into test (however you do that), and when it's solid, pull test over prod. | 21:21 |
| djahandarie | And there are always bugs even after the code is tested. | 21:21 |
| Luke-Jr | jelmer: so how do I get CustomLayout | 21:21 |
| djahandarie | Considering it's only going to be tested by the people here... | 21:22 |
| djahandarie | And we might miss something | 21:22 |
| Kobaz | so i have a strange problem | 21:23 |
| Kobaz | conflicts: Contents conflict in ViewerCdrs.fcgi | 21:23 |
| Kobaz | # bzr revert ViewerCdrs.fcgi | 21:23 |
| Kobaz | bzr: ERROR: Path(s) are not versioned: ViewerCdrs.fcgi | 21:23 |
| djahandarie | Bah, why does this have to be so complicated. -_- | 21:23 |
| fullermd | Well, my conception of such arrangements is that test is a staging area for production. In that case, having production be a [often out-of-date] mirror of test makes perfect sense, since it makes the VCS structure mirror the procedure. | 21:23 |
| Kobaz | how can i have a conflict in a file that's not versioned | 21:23 |
| fullermd | Well, obviously because (a) you have straitjacketish developmental constrants, and (b) you're trying to use a VCS as a deployment solution :p | 21:24 |
| djahandarie | fullermd, well, how would you recommend doing a bug fix on production when it's out of the VCS? | 21:25 |
| djahandarie | Because testing might have new features in it by that point | 21:25 |
| fullermd | Well, I don't, because I don't put up with dev structures like that :p | 21:25 |
| fullermd | I deploy a trunk, and other work is in a feature branch (or a degenerate version of such) until it's presumed ready for trunk. | 21:26 |
| djahandarie | Well, the thing is the feature branches can't be tested locally... | 21:26 |
| fullermd | Yeah, that's why I'm not working with you :) | 21:27 |
| djahandarie | -_- | 21:27 |
| djahandarie | Well, is there any other way to VCS a web application? | 21:27 |
| fullermd | Your problem is in trying to build a workflow around that. And however you do it is gonna suck. | 21:27 |
| fullermd | I tend to think it may be easier to NOT try and make the VCS handle part of that workarounding. | 21:28 |
| fullermd | Can, for instance, it REALLY only be tested in that one _place_, or can it be tested on that one _server_? | 21:28 |
| djahandarie | The server. | 21:28 |
| fullermd | OK. So, couldn't each dev get their own little sandbox on the server, in which they can setup their feature branches and work there on them, until they're ready to land? | 21:29 |
| djahandarie | How would I hook that into everything else? | 21:29 |
| djahandarie | I'm a bazaar and in general DVCS noobie, so I might be missing something | 21:29 |
| fullermd | Well, you wouldn't necessarily. That's where the D comes in :) | 21:30 |
| djahandarie | Well, I somehow need the local repo to get to files on the server | 21:30 |
| fullermd | Each dev would have their 1 or 2 or 10 feature branches in ~/work/damntheseconstraints/{one,two,tree,etc}, and work on them until they're ready to land. | 21:30 |
| fullermd | Then merge them into their ~/work/trunk/ checkout, or some such process. | 21:31 |
| lifeless | moin | 21:38 |
| * Luke-Jr mutters | 21:38 | |
| * SamB discovers that launchpad is apparantly not very good at preserving multiple spaces in the web rendering of a bug... | 21:41 | |
| * fullermd suspects LP is preserving them just fine, the SGML engin^W^Wcrapsoup parser in your browser just isn't. | 21:42 | |
| SamB | bug 399942 looks awful :-( | 21:42 |
| ubottu | Launchpad bug 399942 in bzr-svn "HTTP 403 during svn transport probe causes bzr to give up entirely" [Undecided,New] https://launchpad.net/bugs/399942 | 21:42 |
| SamB | fullermd: well, bad at instructing the browser to do so, then ... | 21:43 |
| SamB | not sure | 21:43 |
| SamB | might just be the browser ... | 21:43 |
| lifeless | it looks fne to me | 21:50 |
| lifeless | though very long :) | 21:50 |
| SamB | lifeless: yeah, I guess cgitb will do that ;-) | 21:51 |
| SamB | but for me the spaces between the line numbers and their code are all collapsed into one | 21:51 |
| lifeless | what browser? | 21:52 |
| SamB | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009061212 Iceweasel/3.0.11 (Debian-3.0.11-1) | 21:52 |
| lifeless | what font too | 21:53 |
| lifeless | might be a prop/non-prop thing | 21:53 |
| lifeless | I' using epiphany | 21:53 |
| SamB | it's showing in a fixed-width font | 21:53 |
| SamB | I have no idea how to get mozilla to tell me exactly what font | 21:53 |
| SamB | I looked for an add-on for that once, I think | 21:53 |
| SamB | couldn't find one :-( | 21:53 |
| lifeless | jam: if you're still around, I fixed three small dirstate/commit bugs yesterday | 21:54 |
| lifeless | jam: would love a rubberystampy | 21:54 |
| * SamB quits iceweasel in the hopes that starting it again cold will make it notice that he downgraded firebug again | 21:55 | |
| jam | lifeless: I'll try to give them a look | 21:56 |
| jam | investigating the absent-content-factory w/ bundles issues right now | 21:56 |
| lifeless | jam: they are all ~ 1 line fixes | 21:58 |
| jam | lifeless: well, they aren't all 1-line diffs. :) | 21:59 |
| * SamB wishes qemu supported reasonable acceleration | 21:59 | |
| lifeless | I know, which is why I'm telling you something diffstat doesn't ;) | 22:00 |
| SamB | ECHAN | 22:00 |
| jam | lifeless: what are you calling "forward edits" ? | 22:00 |
| lifeless | when something moves | 22:01 |
| lifeless | and something thats deeper in the old iterator gets changed by processing the item in the new iterator | 22:01 |
| lifeless | we then encounter the thing that moved again in the old iterator, but we were seeing the moved item, rather than the original old-state | 22:02 |
| lifeless | thats why 'mv b a' broke but not 'mv a b' | 22:02 |
| jam | so is it better to deepcopy the old iterator, or to copy the items themselves before we mutate them? | 22:03 |
| jam | the later seems to require less copying | 22:03 |
| lifeless | but more complex code | 22:03 |
| lifeless | I think we should do the simpler thing and then usertest to find out if it really matters perf wise | 22:03 |
| SamB | maybe you should stop mutating shit so much ;-) | 22:05 |
| * SamB <- Haskeller | 22:05 | |
| lifeless | heh | 22:06 |
| lifeless | so it might find this easier to do | 22:06 |
| lifeless | but we're updating a table | 22:06 |
| lifeless | by walking the table and a tree in parallel | 22:06 |
| lifeless | it would be arguably nicer to transform the new inventory into a delta against the old inventory and apply that | 22:07 |
| lifeless | but I am concerned that that might be slower | 22:08 |
| lifeless | without care | 22:08 |
| lifeless | so I wanted to fix the bug, and come back later and look at deleting a tonne of code; particularly if we can just remove callers to this method | 22:08 |
| lifeless | thanks jam! | 22:09 |
| jam | lifeless: while your head is in this code, I've noticed times where the auto-remove still fails if you delete the parent directory of a file | 22:09 |
| jam | (foo/bar/baz/bing, all of bar/baz/bing have been deleted) | 22:09 |
| jam | I'm pretty sure there is an open bug on it | 22:10 |
| lifeless | in commit? | 22:10 |
| jam | yeah | 22:10 |
| jam | if you do "bzr rm" then commit works | 22:10 |
| jam | but if you just "rm -rf foo/bar; bzr commit" it blows up | 22:10 |
| jam | I thought you looked a while ago about removing the strict ordering requirement | 22:10 |
| lifeless | I think thats bug 187207 | 22:11 |
| ubottu | Launchpad bug 187207 in bzr "Inconsistent deltas created when commiting and an implicit delete has happened" [High,Fix committed] https://launchpad.net/bugs/187207 | 22:11 |
| lifeless | I'll have a look for a bug | 22:11 |
| lifeless | unversion doesn't have a strict ordering requirement | 22:11 |
| lifeless | in fact, it setifies its inputs immediately | 22:11 |
| jam | lifeless: for https://code.edge.launchpad.net/~lifeless/bzr/bug-187207/+merge/8800 | 22:12 |
| jam | the big change is to only discard when it isn't already absent/renamed? | 22:13 |
| lifeless | right | 22:13 |
| lifeless | discardin the id stops us unversioning it again | 22:13 |
| lifeless | so we only discard when we actually unversion it | 22:13 |
| lifeless | finding it at an old path before we find it at a new path doesn't actually count as discarding | 22:13 |
| jam | lifeless: so since we were skipping , we leave the id around | 22:13 |
| jam | to be unversioned later? | 22:14 |
| lifeless | yes | 22:14 |
| lifeless | thats inside the code for deleting an entire block | 22:14 |
| eyda|mon | I've got two repos, A and B. B is a branch of A. I change file F1 and F2 in branch B. F1 has one comitt message, and F2 has commit message. I then merge to branch A, but then I revert the changes made to file F2 before I commit to branch A. bzr log will still show the commit messages made for file F2. Is that supposed to be like that? Those changes were just not part of branch A at all, but they still | 22:14 |
| eyda|mon | show up. | 22:14 |
| lifeless | where a subtree has been deleted | 22:14 |
| dash | eyda|mon: revert just changes the working copy | 22:14 |
| dash | eyda|mon: merge brings in the entire history | 22:14 |
| fullermd | eyda|mon: That's what merge does. (also, you don't (well, you may, but it's not relevant) have two repos, you have two branches) | 22:15 |
| lifeless | eyda|mon: thats normal yes; if you do a merge, and then change the merge to be different, then commit, bzr doesn't know the /meaning/ of the change you made | 22:15 |
| dash | eyda|mon: so the result is that the merge revision undoes the changes to F2 | 22:15 |
| eyda|mon | dash: but that still results in a very misleading log | 22:15 |
| dash | eyda|mon: well don't do that then :) | 22:15 |
| lifeless | eyda|mon: if you made separate commits, you can do something like 'bzr merge -r -2 B' in A | 22:15 |
| lifeless | which will merge all but the last commit | 22:16 |
| eyda|mon | i normally dont, but I was pushing changes to production, and I didn't want all those changes to production. | 22:16 |
| eyda|mon | lifeless: i see, ok, interesting | 22:16 |
| jam | lifeless: I think I have a basic handle on bug #393349 | 22:17 |
| ubottu | Launchpad bug 393349 in bzr "exceptions.AttributeError: 'AbsentContentFactory' object has no attribute 'get_bytes_as'" [Critical,Triaged] https://launchpad.net/bugs/393349 | 22:17 |
| jam | basically, the bundle code doesn't ensure the same state in a stacked branch | 22:17 |
| jam | that the fetch code does | 22:17 |
| lifeless | jam: might want to move all the dicussion to that bug :) | 22:17 |
| lifeless | jam: 390563 is the iter_interesting_changes bug | 22:18 |
| jam | so I was wondering what your thoughts might be about the proper fix | 22:18 |
| jam | is it a limitation of the bundle *generator* | 22:18 |
| jam | or the bundle *inserter* | 22:18 |
| jam | (or both :) | 22:18 |
| lifeless | I think the inserter should error-or-fix-on-the-fly | 22:19 |
| lifeless | thats for robustness | 22:19 |
| lifeless | it shouldn't fail late | 22:19 |
| lifeless | (maybe it isn't) | 22:19 |
| jam | it is failing during "check diff" which I think is later than it should be erroring | 22:20 |
| lifeless | but as the source isn't guaranteed to be around, if the best the inserter can do is error [without the source], then clearly we need to change the creator. | 22:20 |
| lifeless | so, sounds to me like the inserter can be improved | 22:20 |
| lifeless | I think we should make sure we're not creating partial rev inventory data etc as a priority | 22:20 |
| lifeless | and perhaps a fixup tool for existing damaged branches (tied into fetch perhaps - bzr fetch --ghosts <...>) | 22:21 |
| lifeless | and then move onto getting enough data sent in the first place | 22:21 |
| jam | hmm... at least here it is failing on "self._ensure_root()" which would say that the root chk isn't present at all... | 22:23 |
| lifeless | :> | 22:24 |
| lifeless | but the inventory is | 22:24 |
| jam | lifeless: there are 0 chk pages in the final result | 22:24 |
| lifeless | thats fairly corrupt | 22:24 |
| jam | yep | 22:25 |
| jam | lifeless: so the bundle generator code seems to directly access the inventory data | 22:28 |
| jam | and include it in the bundle | 22:28 |
| jam | but it *doesn't* include the chk data | 22:28 |
| jam | so it neither upcasts to an XML inventory | 22:28 |
| jam | nor includes chk | 22:28 |
| jam | so bundle generator w/ chk... completely broken | 22:29 |
| lifeless | heh | 22:31 |
| lifeless | I'm sure then that we want to make the inserter more paranoid | 22:31 |
| lifeless | and the generator fixed (perhaps upcast to XML for existing formats, and add a delta based one) | 22:31 |
| jam | lifeless: so I'm pretty sure that whatever I do, the new bundles won't be compatible with older bzr | 22:34 |
| jam | and if that is true | 22:34 |
| jam | then I'm thinking it may be time to change how we deal with bundles | 22:34 |
| jam | and go the full route into making them just a transport for a stream | 22:35 |
| lifeless | I think if you upcast to xml and did the existing bundle code, that will work with older bzr; could be wrong | 22:35 |
| lifeless | I'm pro doing the full mccoy | 22:35 |
| jam | lifeless: the existing code will try to insert those XML texts *into* repository.inventories | 22:35 |
| jam | as is | 22:35 |
| lifeless | hmm | 22:35 |
| jam | it doesn't go through Serializers at all | 22:35 |
| lifeless | so two things | 22:35 |
| lifeless | what about xml bundles from people using 1.9-rr to someone using 2a | 22:36 |
| lifeless | well, one thing really;) | 22:36 |
| lifeless | back shortly | 22:39 |
| jam | lifeless: ok. so it seems the existing code says "if serializer.format_num == bundle_serializer.format_num: _install_mp_records_keys" | 22:53 |
| jam | otherwise it assumes that it can apply the mpdiff directly to the parent inventory | 22:53 |
| jam | text | 22:53 |
| jam | ah, because it grabs the Inventory, then serializes it in the source format | 22:54 |
| jam | then reads it back in as a string | 22:54 |
| mwhudson | jelmer: https://code.edge.launchpad.net/~vcs-imports/openlibrary/trunk <- submodules! | 23:04 |
| lifeless | bah, my bug 395556 bugfix isn't complete. I'm going to have to look deeper. | 23:10 |
| ubottu | Launchpad bug 395556 in bzr "dirstate.set_state_from_inventory is broken with forward-edits." [High,Fix committed] https://launchpad.net/bugs/395556 | 23:10 |
| lifeless | The other two should be fine | 23:10 |
| lifeless | (395556 causes fallout) | 23:10 |
| === kiko is now known as kiko-afk | ||
| SamB | abentley: shouldn't bundle buggy provide a link to the superseding bundle if a bundle has a Status of Superseded ? | 23:37 |
| SamB | I'm looking at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3CE1MRCZb-0007ee-Kn%40hydrogen%3E and wondering what in the world it picked up as superceding that | 23:38 |
| SamB | oh ... I guess it picked up http://bundlebuggy.aaronbentley.com/project/bzr/request/<E1MQZOB-0003MV-Id%40hydrogen> ? | 23:40 |
| * SamB was given to understand that bundle buggy didn't take bundles with [PATCH] prefixes | 23:40 | |
| abentley | SamB: It should, but it doesn't. | 23:42 |
| SamB | abentley: did you just add support for [PATCH] prefixes or something? | 23:43 |
| SamB | or was bundle buggy down for a long while ? | 23:43 |
| abentley | SamB: It was down. | 23:43 |
| SamB | ah. | 23:43 |
| SamB | and whoever told me about that I needed [MERGE] was wrong ;-) | 23:44 |
| KhaZ | Hello. I'm contemplating an idea, and I'm curious if other people can shoot holes in it. At work we use Perforce, but I was thinking it would be nice to run a bzr depot locally to allow me to do multiple 'checkins' locally, and possibly share with other developers similary set up (via push/pull). I'd treat 'syncs' from Perforce as 'checkins' to bzr. Would this scheme break down fast, or would it give me the benefit of local changes, and pot | 23:48 |
| mwhudson | KhaZ: your message got truncated there | 23:49 |
| KhaZ | mwhudson: What'st he last bit you received? | 23:49 |
| KhaZ | *what's the? | 23:49 |
| thumper | KhaZ: line limits for irc | 23:50 |
| mwhudson | "nges, and po" | 23:50 |
| KhaZ | potentially the ability to 'share' code with other developers? | 23:50 |
| KhaZ | thumper: Weird. I would've figured irssi would've caught that for me. Oh well. Pardon me. | 23:50 |
| lifeless | KhaZ: I know of other people that do roughly what you describe; I don't know the details though | 23:51 |
| mwhudson | KhaZ: nothing about that sounds too insane | 23:51 |
| KhaZ | Hrmm. I might give it a shot. Maybe it'll give some adoption to other devs anyhow. I'm really sick of Perforce outages and slow syncs. :/ | 23:51 |
| mwhudson | KhaZ: the area you might have problems is when the changes you make in bzr end up in perforce and then you sync from perforce, you might get conflicts | 23:52 |
| lifeless | KhaZ: If I may be nosy, what organisation do you use p4 at? | 23:53 |
| SamB | KhaZ: it's nondeterministic, or something | 23:53 |
| SamB | the line-limit thing | 23:53 |
| SamB | I've seen the same text truncated to different lengths when sent twice in a row | 23:53 |
| * SamB isn't sure if it was by the same person or not, though -- that would make a difference | 23:54 | |
| KhaZ | lifeless: Well, in this case it's a company called Propaganda Games. But most gaming companies I've worked at use Perforce. | 23:54 |
| KhaZ | SamB: What is non-deterministic? | 23:54 |
| KhaZ | Oh, the line-limit thing. | 23:54 |
| lifeless | KhaZ: interesting :) - thanks for satisfying my curiosity. | 23:55 |
| SamB | I'm not sure if it is really nondet or not | 23:55 |
| SamB | but it acts like it to the naive observer ;-) | 23:55 |
| KhaZ | lifeless: No worries. Mind if I ask what made you curious about it? Sitting on this channel as you do, I'm sure you don't ask everyone what company they're at? :) | 23:55 |
| KhaZ | Right, makes sense SamB. | 23:56 |
| lifeless | only people that use p4 ;) | 23:56 |
| KhaZ | Hah. What's so curious about p4? I'd be more interested in knowing who's still using VSS! | 23:56 |
| lifeless | more seriously, if you were at one of the companies that I know people that use bzr w/p4 I would have tried to get you talking to a colleague. | 23:56 |
| KhaZ | lifeless: Ah, fair enough. | 23:57 |
| lifeless | but I couldn't ask them if they were happy to share the name immediately, and you were here ;) | 23:57 |
| KhaZ | Makes sense! Thanks for satisfying *my* curiousity. ;) | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!