| Leonidas | I have branched off some line of development with my own changes, now I'd like to get a complete, clean patch of my changes to the trunk revision. How to do that? | 00:03 |
|---|---|---|
| Leonidas | I tried with merge --preview, but it does not work, since I'm working treeless. And I don't really plean to do a merge anyway. | 00:04 |
| Leonidas | s/plean/plan/ | 00:04 |
| Peng | Leonidas: bzr send? | 00:05 |
| Leonidas | Furthermore, I'd like to merge in the latest trunk changes since branching, but they should not appear in my patch. | 00:05 |
| Peng | Leonidas: bzr send? | 00:06 |
| Leonidas | Peng: thanks. I'll see whether this is what I want. | 00:06 |
| james_w | Leonidas: there is also "bzr diff -r ancestor:URL" | 00:06 |
| Peng | Leonidas: 'bzr send' produces a bundle file, which by default includes a diff and the (base64-encoded) meta data. | 00:07 |
| lifeless | poolie: did you ring? | 00:09 |
| Leonidas | Peng: bzr send sounds good, but I'd need to get the patch only, since it's only me who is using bzr. The other people have no use for bundles. | 00:10 |
| Leonidas | bzr send --output=- is nice, now compine it with no-bundle | 00:11 |
| Leonidas | huh? Am I missing something? bzr send --no-patch --output=- works | 00:13 |
| Leonidas | bzr send --no-bundle --output=- does not. | 00:13 |
| Leonidas | bzr send --output=- does work and produces both patch & bundle. | 00:14 |
| spiv | Leonidas: I'm guessing "bzr send --no-bundle" is failing due to a lack of a public location for your branch. | 00:16 |
| spiv | Leonidas: if you just want a diff, you're better off using "bzr diff" directly, as james_w suggested. | 00:16 |
| Leonidas | spiv: right, it fails because there is no public location. But I don't see why it does not work like bzr send just without the bundle. I could use sed, though ;) | 00:17 |
| spiv | Leonidas: bzr send tries fairly hard to make sure that all the history is available to the recipient, either in the included bundle, or in a publically accessible branch if there is no bundle. | 00:18 |
| Leonidas | ah, that explains a lot! | 00:18 |
| poolie | lifeless: no | 00:18 |
| spiv | i.e. bzr send is designed as a way to send merge directives for branches, not as a way to generate diffs. Generating diffs is what "bzr diff" is for :) | 00:19 |
| Leonidas | spiv: ok, bzr diff -r ancestor:... works properly. Fine. | 00:19 |
| Leonidas | Thanks, also to james_w | 00:20 |
| Leonidas | I wonder what happens if I merge trunk :) | 00:20 |
| Leonidas | ok, works. Fine | 00:24 |
| igc | lifeless: I'm planning to tweak stacked branches today | 00:37 |
| igc | 1. move branch-location into branch.conf | 00:37 |
| igc | 2. rename shallow options and messages to stacked | 00:37 |
| igc | 3. ???? | 00:37 |
| igc | lifeless: is that ok? | 00:37 |
| poolie | igc, is the name really just branch-location? it needs a less ambiguous name... | 00:51 |
| igc | poolie: no. I was being lazy because I knew that lifeless knew what I meant | 00:53 |
| poolie | ok :) | 00:53 |
| abentley | jelmer: around? | 01:12 |
| jelmer | abentley, hi | 01:13 |
| jelmer | igc: 4. profit ? ;-) | 01:13 |
| abentley | jelmer: Can I ask some questions about samba? | 01:13 |
| jelmer | abentley: sure | 01:13 |
| Peng | jelmer: How stable is bzr-svn's 0.4 branch at the moment? | 01:15 |
| jelmer | Peng: stable | 01:15 |
| Peng | jelmer: So it's okay to use instead of 0.4.10? | 01:15 |
| abentley | jelmer: The main question is, is Samba suitable for sharing to linux clients? I.e. can it preserve users, modes, etc? | 01:15 |
| jelmer | Peng, at the moment, yes | 01:15 |
| abentley | I've only used it when the primary clients were win32. | 01:16 |
| Peng | jelmer: Are you planning to break it before the next release? :P | 01:16 |
| jelmer | abentley: Yes, when you're using a recent version of Samba and CIFS VFS (mount -t cifs rather than mount -t smbfs) | 01:16 |
| jelmer | Peng: no plans :-) but not guarantees either.. | 01:16 |
| abentley | jelmer: cool, thanks. | 01:17 |
| jelmer | abentley: It's more POSIX compliant than NFS3 and even more compliant than NFS4 in a lot of cases | 01:17 |
| Peng | Maybe I'll keep using 0.4.10 as long as it works with bzr.dev. If it still does. | 01:17 |
| abentley | jelmer: great. | 01:18 |
| Peng | Yeah, it does. | 01:19 |
| jelmer | Peng: 0.4.10 is broken with bzr.dev (push for example) | 01:20 |
| Peng | Oh. | 01:21 |
| Peng | Broken as in traceback or corruption? | 01:21 |
| jelmer | traceback | 01:25 |
| jelmer | corruption never happens because of mismatching versions | 01:25 |
| === mw is now known as mw|out | ||
| lifeless | poolie: found the plugin ? :P | 01:58 |
| lifeless | abentley: is branch.conf meant to be human edited or bzr edited? | 01:59 |
| abentley | lifeless: Yes. | 02:00 |
| lifeless | hmm | 02:00 |
| abentley | Same as bazaar.conf. | 02:00 |
| lifeless | what settings from it are copied on clone/sprout? | 02:01 |
| abentley | I can't think of any values that are copied. | 02:02 |
| lifeless | ok | 02:02 |
| === kiko is now known as kiko-zzz | ||
| lifeless | igc: go ahead | 02:02 |
| abentley | lifeless: It contains values like parent location, push location, bind location. | 02:03 |
| igc | lifeless: thanks | 02:03 |
| igc | lifeless: summary email on its way now too fwiw | 02:04 |
| lifeless | igc: thanks | 02:09 |
| lifeless | poolie: call? | 02:10 |
| mwhudson | beuno: are you still up? | 02:21 |
| ricardokirkner | hi everyone. I just wanted to know. Is olive-gtk currently the best available option for a gui interface to bzr? Or are there any better options? (I would prefer gtk over qt, but it' s entirely a matter of (visual) taste) | 02:22 |
| ricardokirkner | what I was looking for is some app that makes viewing change history easy (something like trac, but as a client app, instead of requiring a webserver) | 02:22 |
| beuno | mwhudson, yeap | 02:25 |
| mwhudson | beuno: cool | 02:25 |
| mwhudson | beuno: so my understanding, roughly speaking is that you have done four things to loggerhead recently: | 02:25 |
| mwhudson | 1) remove the use of deprecated methods | 02:25 |
| mwhudson | 2) switched to using zpts | 02:25 |
| mwhudson | 3) some ajax-y stuff for revision views | 02:26 |
| mwhudson | 4) use cleaner urls | 02:26 |
| mwhudson | beuno: would that be a fair summary? | 02:26 |
| beuno | mwhudson, generally, yes. Although 3) required generating a new controller from scratch for diff, and changing how the revision view is generated | 02:28 |
| mwhudson | ok | 02:28 |
| mwhudson | so what i would _like_ is to have one branch for each of these things :) | 02:28 |
| mwhudson | (they don't all have to be brances off trunk, i'd expect the branch for 3) to be a branch off that for 2), for example) | 02:29 |
| beuno | ah, good, was about to say that :) | 02:29 |
| beuno | and, well, 4) off 2) also, since it's mostly templating work | 02:29 |
| mwhudson | sure | 02:29 |
| beuno | ok, I can do that, now, where could I find a good VCS to help me with that... | 02:30 |
| mwhudson | heh heh | 02:30 |
| mwhudson | beuno: i'd like to review the branches for 1 and 2 today if i can | 02:31 |
| beuno | mwhudson, oh, sure. I'll get right on it. 1) would be with KID than? | 02:32 |
| beuno | *then | 02:32 |
| mwhudson | beuno: yeah, i think so, the changes are entirely independent of the templating stuff | 02:32 |
| mwhudson | and this branch is more urgent | 02:32 |
| beuno | yes, I see where you're going. I'll push em to LP and ping you | 02:33 |
| mwhudson | thanks a lot | 02:33 |
| mwhudson | you could even send merge requests to the bazaar list :) | 02:34 |
| beuno | sure, whatever is better. Will BB get confused if I send with [MERGE]? | 02:35 |
| mwhudson | yeah, i guess [loggerhead/MERGE] | 02:37 |
| mwhudson | hmm, is there anyway of running bzr viz in a repository? | 02:41 |
| mwhudson | (i.e. with multiple heads) | 02:41 |
| mwhudson | beuno: any idea how long this is going to take? i.e. a few minutes, an hour, tomorrow? | 02:45 |
| mwhudson | beuno: don't want to pressure, just want to know | 02:45 |
| beuno | mwhudson, I'll send 1) in a few minutes | 02:45 |
| mwhudson | cool | 02:46 |
| beuno | and 2) by the end of the day | 02:46 |
| beuno | as I see it, 3) and 4) stack up on top of 1) and 2) | 02:46 |
| fullermd | You can run viz on multiple branches... | 02:48 |
| mwhudson | fullermd: you can? | 02:48 |
| mwhudson | beuno: isn't it rather late for you already? :) | 02:49 |
| mwhudson | beuno: but sounds good | 02:49 |
| * mwhudson heads out to buy some chocolate to fuel the review | 02:49 | |
| beuno | mwhudson, I've seemed to moved to new zeland time zone these past weeks :) | 02:49 |
| mwhudson | beuno: heh | 02:49 |
| fullermd | Yah, just hand it a couple on the command line. | 02:50 |
| fullermd | (I haven't really used it, but I've done it) | 02:50 |
| mwhudson | fullermd: maybe my bzr-gtk is too old, it doesn't work for me | 02:51 |
| fullermd | NEWS says it was on 0.94.0 | 02:52 |
| mwhudson | 0.93.0 | 02:52 |
| mwhudson | oh well | 02:52 |
| lifeless | beuno: glad you like it | 02:54 |
| beuno | lifeless, I may even attempt to get it working within loggerhead, when I run into some free time | 02:56 |
| beuno | a pre-alpha version of it will be *way* better than what there is today :) | 02:57 |
| lifeless | :P | 02:59 |
| lifeless | surely not ? | 02:59 |
| beuno | mwhudson, we sould really disable full text indexing by default | 03:00 |
| beuno | it makes my core2duo 1.5gb of ram cry for a good hour on bzr.dev | 03:01 |
| lifeless | holy crap | 03:01 |
| lifeless | are you sure it only indexes the commit messages? | 03:01 |
| beuno | I promise :) | 03:01 |
| lifeless | how the hell can you spend more than a few seconds indexing bzr.dev's commit messages. | 03:01 |
| lifeless | I reckon you are missing a lock_read() or something similarly inane | 03:02 |
| beuno | I'd rather invest time in getting it to work with something new (bzr-search, for example) than fixing the horrid current sqlite thingie | 03:02 |
| lifeless | k | 03:03 |
| lifeless | (I'm sure the underpinnings are not that different though) | 03:03 |
| lifeless | poolie: bzrlib.tests.test_lockdir.TestLockDir.test_35_wait_lock_changing is failing sporadically for me. I mention this because I thought it was fixed? | 03:03 |
| mwhudson | lifeless: i think i already explained that loggerhead's text indexer is worse than you can possibly imagine, didn't i? | 03:05 |
| mwhudson | i wasn't kidding | 03:05 |
| * igc lunch | 03:07 | |
| beuno | mwhudson, patch for 1) sent off to the list | 03:07 |
| lifeless | mwhudson: I thought my imagination had more power | 03:08 |
| beuno | mwhudson, I'm off for ~2 hours, and I'll be back to send 2) with 1) merged into it, and other tweaks it needs to work properly | 03:09 |
| mwhudson | beuno: ok, have fun | 03:10 |
| beuno | lifeless, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/launchpad%40pqm.canonical.com-20080418101647-2k1lv1l0edudd191?file_id=textindex.py-20061219035715-norgqx0pl0hxdax8-1 | 03:11 |
| beuno | for your amusement :) | 03:11 |
| beuno | mwhudson, oh, and I just remembered, not sure what that list is for, but I also tried genshi as a templating engine, which failed miserably :) | 03:15 |
| mwhudson | beuno: right, i'm not expecting to merge that one :) | 03:16 |
| fbond | jelmer: thanks | 03:16 |
| * beuno is off | 03:16 | |
| lifeless | beuno: bye | 03:18 |
| lifeless | holy cow | 03:21 |
| lifeless | thats scary shit | 03:21 |
| lifeless | I mean, might want to tweak the term generator in bzr-search to combine robert's -> roberts rather than robert's -> robert, s | 03:22 |
| lifeless | but thats stemming which I punted on | 03:22 |
| synic | is there an IRC bot out there that'll watch bzr repos for changes? | 03:37 |
| lifeless | I believe so | 03:39 |
| mwhudson | so bookmarks and lp: urls don't really get on | 04:11 |
| bob2 | yay for stacking | 04:13 |
| poolie | lifeless: re that test - i have a patch that addresses it but there was some nontrivial review pushback, i need to revisit it | 04:29 |
| poolie | uh | 04:30 |
| poolie | i tried doing an incremental patch towards it, introducing a different error for "waiting for lock timed out" from "lock is not available at this instant" | 04:30 |
| poolie | which i think will make those tests clearer and not timing dependent | 04:30 |
| poolie | but the increment was not compelling by itself | 04:30 |
| lifeless | poolie: k | 04:44 |
| beuno | back | 05:18 |
| beuno | mwhudson_, so, 2) then? | 05:18 |
| mwhudson_ | beuno: yes please :) | 05:20 |
| beuno | on it | 05:21 |
| jml | hey guys | 05:35 |
| jml | when someone deletes a directory in bazaar and the directory has pyc files, I get conflicst | 05:35 |
| lifeless | yes | 05:35 |
| lifeless | known issue, no good answer so far | 05:36 |
| === lamont` is now known as lamont | ||
| jml | lifeless: ok. cool. | 05:40 |
| lifeless | (you need a way to separate 'my-bank-details.txt' which I ignored so it wouldn't be added from 'foo.pyc' wchich I ignored so it would not be added | 05:42 |
| bob2 | need to somehow consider the former to be...precious ;) | 05:43 |
| lifeless | or the latter to be junk | 06:00 |
| lifeless | but this has complexity impact | 06:01 |
| beuno | mwhudson_, do you want the 2) patch relative to 1) or trunk? | 06:12 |
| mwhudson_ | relative to 1) please | 06:12 |
| mwhudson_ | beuno: i | 06:13 |
| beuno | coming up | 06:13 |
| mwhudson_ | 'm not going to be working for much longer today, btw | 06:13 |
| mwhudson_ | i'll look at it first thing tomorrow | 06:13 |
| beuno | oh, but it's only 3k lines... :p | 06:13 |
| mwhudson_ | :) | 06:14 |
| === mwhudson_ is now known as mwhudson | ||
| mwhudson | i know, i'm lame | 06:14 |
| beuno | mwhudson, sent | 06:18 |
| beuno | I'll prepare the other 2 tomorrow | 06:19 |
| poolie | beuno, hi | 06:37 |
| beuno | hey there poolie | 06:37 |
| poolie | beuno: what a circus :-} | 06:41 |
| beuno | poolie, heh, the past weeks have been pretty active :) | 06:42 |
| lifeless | abentley: lol, I have this image of bb running around going 'I'm freaking out mAAAAAAN' | 07:02 |
| beuno | hahha, I was just thinking that. With ian's patch in it's hand | 07:03 |
| abentley | lifeless: hehe | 07:03 |
| fdv | Hi. Anybody know what 'KnitCorrupt: Knit <bzrlib.knit._PackAccess object at 0x870fc6c> corrupt: incorrect number of lines 221 != 152 for version {svn-v3-single1-dHJ1bmsvbWFpbg..:6226825f-cf0a-0410-9073-f4040cba8958:trunk%2Fmain:116353}' means? | 07:33 |
| beuno | I'm off to bed. G'night everyone | 07:37 |
| igc | night beuno | 07:40 |
| lifeless | fdv: my first thought would be a symlink with newlines in it in the source svn repo | 07:42 |
| fdv | lifeless: ah | 07:43 |
| lifeless | because I *think* bzr-svn generates its own knit hunks or something like that | 07:43 |
| fdv | that revision had broken symlinks, but I tried removing those nodes | 07:43 |
| lifeless | jelmer: ^ any thoughts | 07:43 |
| fdv | what are knit hunks, really? | 07:44 |
| spiv | fdv: records containing the lines added in a revision, basically. | 07:46 |
| fdv | ok.. | 07:47 |
| spiv | Usually just the new lines, and a record of the lines removed. Sometimes a full copy of a file is stored rather than just a delta, depending on various conditions. | 07:47 |
| fdv | right | 07:47 |
| spiv | Basically, low-level guts :) | 07:48 |
| fdv | I removed all the nodes containing these symlink edits from the dump file and repopulated the repo | 07:48 |
| fdv | and then tried pulling it again | 07:48 |
| abentley | igc: Do you have a clear idea what you need to do to generate a mergeable directive? | 07:48 |
| lifeless | fdv: did you clear the output repository? | 07:49 |
| lifeless | fdv: or remove the corrupt revisions copied into it? | 07:49 |
| fdv | lifeless: absolutely :) | 07:49 |
| igc | abentley: use bzr.dev as the submit_branch | 07:49 |
| fdv | lifeless: I couldn't remove the whole revisions | 07:49 |
| fdv | only the nodes affected | 07:49 |
| igc | abentley: I don't get hope to get the right preview diff though ... | 07:50 |
| abentley | igc: And you can use -r to specify the cherrypick you want | 07:50 |
| igc | so -rancestor:../foo.bar? | 07:50 |
| lifeless | igc: bzr send -r thread:..-1 | 07:50 |
| lifeless | igc: you should never need to touch -rancestor with send and a loom | 07:50 |
| igc | lifeless: I've exported the loom | 07:50 |
| lifeless | igc: oh, don't | 07:51 |
| lifeless | igc: :) | 07:51 |
| lifeless | igc: I send all my patches for loom-branches direct from the loom | 07:51 |
| igc | lifeless: I didn't know better and smart people told me to :-) | 07:51 |
| lifeless | AIUI export-loom exists solely for use with launchpads internal review system which is not loom aware | 07:51 |
| lifeless | BB doesn't have the same flaws | 07:52 |
| abentley | lifeless: Not true, also for dealing with PQM | 07:52 |
| lifeless | abentley: oh, I guess. I do all my merges via an integration branch, so it never occured to me | 07:52 |
| lifeless | abentley: (bzr pull $source --overwrite && push --overwrite && pqm-submit -m '...') | 07:52 |
| abentley | igc: Anyhow, are you able to get a reasonable preview diff? | 07:54 |
| igc | just trying now | 07:54 |
| igc | abentley: in the case of StackableBranch, not by using -rancestor:../Development1 :-( | 07:57 |
| igc | I guess the preview is the least important bit | 07:58 |
| igc | but it annoys people reviewing in the mailer | 07:58 |
| abentley | igc: The preview reflects the merge you are requesting. | 07:58 |
| abentley | If it's wrong, your request is wrong. | 07:58 |
| igc | abentley: the preview contains the right changes vs bzr.dev | 07:59 |
| igc | but it's more than I wanted in the preview because it includes the changes from 'threads' below | 07:59 |
| lifeless | igc: honestly, do the BB submissions direct from the loom | 07:59 |
| lifeless | igc: with 'bzr send -r thread:..-1' from within each thread. | 08:00 |
| lifeless | igc: it will JustWork | 08:00 |
| lifeless | (I mean, this is the sort of scut work that loom is _meant_ to manage for you) | 08:00 |
| * abentley has send -r thread: aliased as tsend | 08:00 | |
| igc | lifeless: understood. Why the ..-1 ? | 08:01 |
| lifeless | exactly | 08:01 |
| lifeless | current tip | 08:01 |
| abentley | igc: a -r spec generally specifies the tip. | 08:01 |
| lifeless | igc: you want from the thread below (thread:) to the last commit (-1). But giving send one revision says 'from bzr.dev to that revision) | 08:02 |
| abentley | So -r thread: specifies the tip to be the tip of the previous thread, which is wrong. | 08:02 |
| igc | ok | 08:02 |
| abentley | You can probably specify "-r thread:.." but I haven't tried that. | 08:02 |
| igc | I try sending from the loom now | 08:03 |
| abentley | Alternatively, you can specify the revision-ids from your previous submissions. i.e. "bzr send -r revid:ian.clatworthy@canonical.com-20080610013832-9dt6c5h67eckiezo..revid:ian.clatworthy@canonical.com-20080610045325-hi3yug3nasoe6e1h ../bzr.dev" | 08:05 |
| gour | will loom become part of bzr? | 08:05 |
| lifeless | gour: do you mean 'will it be part of the tarball' ? | 08:05 |
| lifeless | gour: if so, probably, we plan to roll popular plugins into the release tarballs. | 08:06 |
| gour | lifeless: yes. otoh, 'loom' is not listed at http://bazaar-vcs.org/BzrPlugins or i'm blind | 08:06 |
| fdv | lifeless: wrt. the knit error, could the revision be cached or already (half way) applied somehow, so that I don't get it from the new repo I set up, but still from the old one (which is broken)? | 08:08 |
| lifeless | fdv: yes | 08:08 |
| fdv | ah | 08:08 |
| lifeless | fdv: I would try importing to a fresh ('bzr init --rich-root-packs') tree | 08:08 |
| fdv | crap | 08:09 |
| fdv | that's three more days :p | 08:09 |
| lifeless | well | 08:09 |
| fdv | but if that's what it takes.. :) | 08:09 |
| lifeless | you have corrupt content in your target repo | 08:09 |
| lifeless | removing knit references is not the simplest thing to explain | 08:09 |
| fdv | I can't roll it back somehow? | 08:09 |
| fdv | that's all right | 08:09 |
| fdv | if it's the only feasible solution, I'll start from scratch | 08:09 |
| lifeless | we dont have an automated UI for removing single revisions at the moment | 08:10 |
| fdv | I think I have a corner case here :) | 08:10 |
| lifeless | oh, there is need for it | 08:10 |
| lifeless | it needs someone to write a ui for it using the low level primitives | 08:10 |
| fdv | I see | 08:11 |
| fdv | are there some docs anywhere? :) | 08:11 |
| lifeless | if you have a pack repository, pydoc bzrlib.repofmt.pack_repo | 08:11 |
| lifeless | (for a pack repo its basically 'copy everything to a new pack except hwat you want to remove, then discard the old packges') | 08:12 |
| abentley | igc: I'm off to bed. If in doubt, run a test against a local bzr.dev that doesn't use the same shared repo. | 08:12 |
| igc | ok | 08:12 |
| lifeless | for a knit repo its 'remove low level index entries' by doing the same on a per file-id basis | 08:12 |
| gour | svn folks released svn-1.5rc10 :-/ good luck to those living with such software | 08:13 |
| fdv | lifeless: ok, I'll try to have a look. Don't have too high hopes, thouhg :) | 08:13 |
| gour | ...requiring 10rcs | 08:14 |
| lifeless | fdv: don't stress about it :P | 08:16 |
| fdv | no, but it'd be interesting to have a look | 08:16 |
| === mneptok_ is now known as mneptok | ||
| vila | beuno: test a little, code a little :) I don't think you need to duplicate tests for a --dry-run option. TDD helps in *reducing* code duplication after all. Some blackbox tests should be enough. | 08:28 |
| lifeless | later all, dinner time | 08:28 |
| igc | ok, I think I've stopped BB freaking out now. Let's hope so. | 08:33 |
| igc | night all | 08:41 |
| gour | night | 08:41 |
| poolie | cheerio igc | 08:44 |
| === poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6beta2 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| poolie | 1.6b2 is out | 08:44 |
| toyto1 | hello guys, does bzr can be integrated with trac? | 08:55 |
| toyto1 | guys is launchpad.net seems to be like trac? | 09:01 |
| Peng | toyto1: There's a bzr-trac thingy, but I don't think it's 100%. | 09:08 |
| Peng | toyto1: And yeah, Launchpad has some similarities to Trac. No wiki though. | 09:08 |
| gour | seeing that trac-0.11 is still no out...hmm | 09:10 |
| poolie | night all | 09:11 |
| gour | toyto1: have you seen http://www.redmine.org/ ? | 09:13 |
| toyto1 | Peng: ah i see:) | 09:13 |
| toyto1 | gour: what's that? let me check | 09:13 |
| toyto1 | Peng: I didn't find how-to their with bzr-trac for integrating :( | 09:14 |
| gour | toyto1: it's what trac-2.0 will maybe become. it's RoR app, but still | 09:14 |
| toyto1 | gour: so you mean is that redmine is more advance than trac as of now? | 09:16 |
| gour | toyto1: yep, more support for SCM, multi-project etc. however, we choose roundup (http://roundup.sourceforge.net/) - no need for wiki | 09:16 |
| toyto1 | gour: I see thanks for the info :) | 09:22 |
| gour | ;) | 09:22 |
| mtaylor | help! | 09:32 |
| mtaylor | bzr: ERROR: Revision {foo@bar-20080606164431-373v96de5ba508yi} not present in "revisions.kndx". | 09:32 |
| weigon_ | ... at a bzr branch ... | 09:32 |
| james_w | mtaylor: https://bugs.edge.launchpad.net/bzr/+bug/232270 | 09:37 |
| ubottu | Launchpad bug 232270 in bzr "Cannot checkout -- KnitCorrupt: attempt to add line-delta in non-delta knit" [Undecided,New] | 09:37 |
| mtaylor | james_w: ah | 09:37 |
| james_w | are you using a smart protocol for whatever operation you are doing? | 09:37 |
| mtaylor | for that one. | 09:38 |
| mtaylor | it's possible someone used sftp or something though | 09:38 |
| weigon_ | james_w: it is all bzr+ssh:// | 09:38 |
| weigon_ | james_w: I have a 2nd tree that is a bit more up-to-date that has that rev-id and I can pull nicely into that tree | 09:39 |
| weigon_ | only if I use a tree that is "before" that rev-id the branch/pull/log/... all fail | 09:40 |
| james_w | if you use sftp:// it should work. | 09:40 |
| weigon_ | james_w: it does | 09:41 |
| weigon_ | and interestingly a $ bzr log --show-ids sftp:// shows me the {foo@bar-20080606164431-373v96de5ba508yi} | 09:41 |
| james_w | hang on, are you two working together on this? | 09:41 |
| weigon_ | james_w: yep :) | 09:41 |
| james_w | ah :-) | 09:42 |
| james_w | ok, it's some problem with the smart server, I've updated the bug report about it, you can subscribe if you wish to follow the progress. | 09:42 |
| james_w | a full traceback of the error would be very useful, you can find one in your ~/.bzr.log. | 09:43 |
| james_w | you can edit out the details, but the traceback would be really helpful. | 09:43 |
| mtaylor | so, there still isn't a pack-based format that you can upgrade to from dirstate-with-subtrees ? | 09:43 |
| james_w | you should be able to upgrade to --rich-root-pack if you don't actually have any subtrees I believe. | 09:44 |
| weigon_ | james_w: http://pastie.org/212084 | 09:45 |
| mtaylor | james_w: we don't _think_ we are using any (at least, we aren't on purpose) | 09:45 |
| weigon_ | this is the one for bzr log failing | 09:45 |
| mtaylor | james_w: but upgrade --rich-root-pack still b0rks | 09:46 |
| james_w | weigon_: thanks. That's a different error from the "bzr branch" error, could you possibly provide that one as well, it would be great to have as much information as possible. | 09:46 |
| weigon_ | sure | 09:47 |
| james_w | mtaylor: is it an error about this problematic revision, or something unrelated? | 09:47 |
| mtaylor | james_w: something unrelated - I was trying upgrading to packs to see if that would help ... but now I'm just fixed on the fact that I _can't) | 09:47 |
| james_w | heh :-) | 09:48 |
| james_w | sounds like it would be worth a separate error report then. | 09:48 |
| mtaylor | yay! two bugs in one swipe! | 09:49 |
| weigon_ | james_w: http://pastie.org/212087 | 09:49 |
| james_w | thanks team. | 09:50 |
| james_w | I'll put those in the bug report if you don't mind, as we don't have good info there yet | 09:50 |
| weigon_ | shall I add it so you have a reference for more info ? | 09:52 |
| james_w | I think there may be enough there to know what is going on. I'm no expert in this area though. | 09:53 |
| weigon_ | k | 09:53 |
| james_w | there's also a public branch there that is reported to exhibit the problem, so it can always be reproduced by the developer. | 09:53 |
| james_w | thanks for your help. | 09:53 |
| weigon_ | the sftp:// idea is good enough for now | 09:54 |
| weigon_ | thanks | 09:54 |
| weigon_ | james_w: the story goes on with $ bzr merge ... let me paste it | 09:57 |
| weigon_ | james_w: http://pastie.org/212089 | 09:59 |
| james_w | ok, do you understand what the error message is saying? | 10:01 |
| weigon_ | james_w: it tries to find the common ancestor where the two trees are related and can't find it | 10:11 |
| james_w | yup, are these two trees supposed to be related? | 10:12 |
| weigon_ | this is the same tree that has the other problems :) | 10:12 |
| weigon_ | they are related just a few revs before the unknown rev-id | 10:12 |
| weigon_ | I assume that this is just a side-effect, as bzr thinks it can't find one of the rev-ids along the way and jumps out | 10:13 |
| awilkins | gour: The SVN team have always been cautious about version numbers ; I remember how long it took them to get to 1.0 | 10:22 |
| === mwhudson__ is now known as mwhudson | ||
| blaudden | Hi, I'm getting extensive merge conflicts when merging two trees(383 conflicts). It feels like it select's a very old base. The manual hints about specifying a specific base to use. But I can't figure out how to do that. Any ideas? | 11:13 |
| blaudden | Have tried to remerge with "bzr remerge --weave <conflicted files>" and that will bring the number of conflicts down, but at the same time some changes will be lost and it's not possible to use "bzr extmerge" after that since ther is no .BASE, .OTHER and .THIS anymore. | 11:16 |
| === cprov is now known as cprov-lunch | ||
| spiv | blaudden: try --lca instead of --weave maybe | 11:56 |
| spiv | blaudden: I'm not sure what you mean by "some changes will be lost" | 11:56 |
| blaudden | spiv: yes, I tried --lca also | 11:57 |
| blaudden | spiv: When running the binary it wil crash and I find one place where the merge has removed two lines instead of conflict them. That makes me a little scared and I start to think about other places being merged that way but that doesn't cause an immediate crash. | 11:59 |
| fredreichbier | when i use bzr with http+ftp, does that create special traffic or abuse the sever?^^ | 12:03 |
| spiv | blaudden: that's always a risk with an automatic merge tool | 12:08 |
| blaudden | spiv: :) | 12:09 |
| spiv | blaudden: just because one branch adds a line here and another removes a line there, in non-overlapping parts of the code, doesn't mean there isn't a semantic conflict. | 12:09 |
| spiv | blaudden: a trivial example is a branch that adds an extra parameter to a function, and updates all the callsites to pass the new parameter. If you have a branch that adds another call to that function, then merge the first branch in, you probably won't get an automatic conflict. | 12:10 |
| spiv | blaudden: but the code won't work | 12:10 |
| spiv | blaudden: so you ought to run the test suite and/or review the diff and/or do some other QA to check that the result is sane. | 12:11 |
| blaudden | spiv: yes, that example seems resonable | 12:12 |
| Peng | fredreichbier: Do you mean ftp or http, or some ungodly hybrid of the two? ;P | 12:12 |
| spiv | fredreichbier: not sure what you mean by "special" traffic. It is just regular ftp/http, it doesn't do anything crazy. | 12:12 |
| spiv | You can abuse the server with regular traffic if you have enough of it, though ;) | 12:13 |
| Peng | fredreichbier: http mostly uses Range requests, which can confuse Squid. It also might make quite a lot of requests in a short amount of time, especially with a knit repo. | 12:13 |
| blaudden | spiv: In this example it's someone who changed part of the line, and in addition the order of that line and the line above has changed place in one of the branches. | 12:14 |
| fredreichbier | Peng: spiv: i mean http-pulling and ftp-pushing. thanks your your answer ;) | 12:14 |
| Peng | fredreichbier: You should use bzr+ssh or at least sftp. ftp sucks. It's not encrypted. | 12:15 |
| fredreichbier | Peng: i need access to the server to use bzr+ssh, and i don't have ,) | 12:15 |
| spiv | blaudden: please feel free to file a bug with that example if you think bzr ought to do better there, btw. | 12:15 |
| Peng | fredreichbier: What do you mean? | 12:15 |
| spiv | blaudden: our merges are generally very good, but there's always room for improvment | 12:16 |
| blaudden | spiv: ok, I'll see if I can make something reproducible... | 12:16 |
| fredreichbier | Peng: i thought i have to set up a bzr server (`bzr serve`?) on my server to use bzr+ssh, don't i? | 12:17 |
| spiv | fredreichbier: you just need bzr installed on the remote side | 12:17 |
| Peng | fredreichbier: For bzr+ssh, you need to have ssh access (duh), with bzr installed and in the PATH. | 12:17 |
| Peng | fredreichbier: bzr+ssh simply sshes in and runs "bzr serve --inet --directory=/". | 12:18 |
| Peng | fredreichbier: (Err, the process doesn't stay around like a normal "bzr serve". --inet causes it to close when you're done.) | 12:18 |
| spiv | Peng: (it also passes --allow-writes) | 12:19 |
| Peng | spiv: Oh, right. | 12:19 |
| fredreichbier | thanks Peng ;) I have a shared hoster without ssh access, that's the problem. | 12:20 |
| matkor | Hi ! What are options to make partial revert of file ? | 12:20 |
| matkor | I see that sb deleted too much changing few lines ... | 12:21 |
| Peng | fredreichbier: Um. You just have FTP? Hopefully not telnet.. | 12:21 |
| Odd_Bloke | matkor: 'bzr shelve' in the bzrtools plugin might help. | 12:21 |
| Peng | fredreichbier: You should tell your host that it's the 21st century now. | 12:22 |
| matkor | Odd_Bloke: tnx checking ... | 12:22 |
| === thekorn_ is now known as thekor | ||
| === thekor is now known as thekorn | ||
| spiv | matkor: you could also try "bzr cat -r 1234 FILE > FILE.older" then "meld FILE.older FILE" | 12:23 |
| spiv | (where 1234 is the revision number) | 12:23 |
| spiv | (Also depends a bit on what you mean by "revert" I guess...) | 12:24 |
| sabdfl | spiv: thanks and congrats on the results of your landings in 1.6 - network performance is transformed here | 12:24 |
| spiv | sabdfl: excellent! There's more to come. | 12:24 |
| sabdfl | pull is much faster - i'm close to the server in question so performance has never been an issue, but the change is noticeable nonetheless | 12:27 |
| fredreichbier | Odd_Bloke: :-) thanks | 12:32 |
| lifeless | sabdfl: thats great news | 12:55 |
| fredreichbier | uh. i did a wrong highlight :/ | 12:57 |
| sabdfl | lifeless: yes, i bet it's really noticeable from .au! | 13:42 |
| === _mathrick is now known as mathrick | ||
| sven_ | hi! i have a problem where 'bzr merge --weave' resolves more than it should. in branch_1, i permute line 5 and 6. In branch_2, i replace line 5 by line 5.1 . 'bzr merge --weave' does not give a conflict; instead it outputs line 5.1, line 6, and line 5, in that order. | 14:03 |
| sven_ | i would prefer to get a conflict. it is very dangerous to resolve like this without any human seeing it... | 14:04 |
| sven_ | what is your position on this? does it look like a bug? shall i create a bug report? | 14:08 |
| spiv | sven_: off the top of my head I suspect that's working as intended. To the merge algorithm a changed line looks like a delete and an add, so it would think both sides deleted the line (so they agree, no conflict), and then they both add some lines. | 14:13 |
| spiv | sven_: still worth a bug report, though. It would be good to make the merge better than it already is. | 14:14 |
| blaudden | spiv: thanks! sven_ is trying to help me figure out what could be the problems we experience | 14:14 |
| sven_ | spiv, thanks. yes, i suspected it was something like that. i'll file a bug | 14:14 |
| blaudden | spiv: how recomended is it wo use --weave ? | 14:14 |
| mtaylor | blaudden: still working on the ugly merge? | 14:15 |
| blaudden | blaudden: after having done it 20 times I start to learn :) | 14:15 |
| blaudden | mtaylor: ^ | 14:15 |
| mtaylor | hehe | 14:15 |
| mtaylor | we should give the bzr guys the two branches as the are now as a worlds-worst-merge test case :) | 14:16 |
| blaudden | mtaylor: ok, I'll check it in.... | 14:16 |
| mtaylor | hehe | 14:16 |
| mpt | Is there a quick way of asking bzr "Show me a diff of branch X compared to what branch Y would look like if branch Z was merged into it", without making a temporary branch that merges Z into Y? | 14:16 |
| radix | bzr merge --preview, maybe? | 14:16 |
| blaudden | bzr merge --preview ? | 14:16 |
| radix | It really only makes sense for two branches though | 14:17 |
| radix | like, "show me a diff of what branch X would look like if branch Y were merged into it" | 14:17 |
| mpt | hmm | 14:19 |
| spiv | mpt: You could get a very rough approximation with interdiff, I guess. | 14:19 |
| spiv | mpt: someone could probably write a plugin that does that operation for you without a temporary branch (although making it not simply hold the full temporary branch in memory would non-trivial)... | 14:21 |
| spiv | (but possible, I think) | 14:21 |
| mpt | meh, I'll just make the temporary branch :-) | 14:22 |
| spiv | mpt: yeah, I think that's the pragmatic answer :) | 14:24 |
| spiv | sven_: hmm, I cannot reproduce your bad merge | 14:24 |
| spiv | sven_: That is, I get a conflict on those lines. | 14:25 |
| sven_ | spiv, i'm using 1.3.1. trying with development version... | 14:25 |
| sven_ | spiv, did you use --weave? | 14:25 |
| spiv | sven_: I did. And tried with --lca, too. | 14:26 |
| spiv | sven_: with bzr1.3.1 | 14:26 |
| spiv | sven_: http://pastebin.com/m5efc4c3 | 14:26 |
| spiv | sven_: (I get the same result with bzr 1.6b2 FWIW) | 14:27 |
| blaudden | spiv: nice way to reproduce | 14:27 |
| spiv | blaudden: it was about as literal an interpretation of your scenario as I could think of :) | 14:28 |
| blaudden | spiv: ok, we'll come up with something worse soon... | 14:28 |
| spiv | blaudden: :) | 14:29 |
| sven_ | spiv, i reproduced it with this: http://pastebin.com/m48d554f9 | 14:31 |
| sven_ | spiv, by 'permute', i meant change the order of the lines without modifying the contents... | 14:31 |
| spiv | sven_: Oh I see | 14:32 |
| spiv | sven_: right, I can see why it does that | 14:33 |
| sven_ | spiv, ok, why? :-) | 14:34 |
| spiv | sven_: IIUC it correctly, because in branch_1 it sees a line removed between lines 4 & 6, and a line added after 6. In branch 2 it sees that same line removed between 4 & 6, and a new one added in the same place. | 14:36 |
| sven_ | spiv, right. | 14:37 |
| spiv | sven_: So the removal is done by both sides, which is not considered a conflict (both sides took an identical action), so the only differences are adding two lines. The two lines are added in different, i.e. non-conflicting, places. | 14:37 |
| spiv | And there's no ambiguity about where to insert those lines (the lines adjacent to the insertions didn't change). So it doesn't consider it a conflict. | 14:38 |
| sven_ | spiv, that makes sense from an algorithmic point of view. but still i think it is dangerous to merge this automatically. | 14:38 |
| spiv | sven_: all automatic merges are dangerous | 14:38 |
| Odd_Bloke | Danger, Will Robinson! | 14:39 |
| spiv | Many merge algorithms will tend conflict on this sort of change, because they will consider both sides doing the exact same thing as a conflict, so the parallel removals would cause a conflict here. (Although typically a hard to understand one, conflicts involving removed lines always look confusing because the conflicting bit isn't visible). | 14:40 |
| spiv | We generally consider that aspect to be a feature though (instead of a confusing conflict, you get a merge with what both sides tried to do anyway), it's almost always what you want in our experience so far. Maybe it'd be worth adding a --cautious or something, though | 14:42 |
| spiv | sven_: but there's nothing magic about line-based merging algorithms that can guarantee the result makes sense. | 14:42 |
| sven_ | spiv, of course not. | 14:43 |
| sven_ | spiv, but 'bzr merge' gives a conflict on these lines. however, we cannot use that since we have a criss-cross merge which results in 383 conflicts. otoh, we cannot use 'bzr merge --weave' if it does not give a conflict in this case... | 14:43 |
| spiv | Even when there's clearly no overlap in the lines touched you can have semantic conflicts. You can't rely on the automated merge tool to give you something that makes sense. | 14:43 |
| sven_ | spiv, i'm no merge algorithm expert, but could it be possible to give conflict if concurrent changes are "close" to each other (where "close" is a configurable number of lines)? | 14:43 |
| spiv | sven_: closeness doesn't matter | 14:44 |
| spiv | sven_: you can have incompatible changes in different files | 14:44 |
| spiv | sven_: i.e. one branch changes a function definition in one file to take a new parameter, another branch adds a new caller of that function using the old signature in a file the first branch doesn't touch. | 14:45 |
| spiv | sven_: any line-based merge will think there's no conflict there, as the changes aren't even in the same files. But the result is broken and needs conflict resolution. | 14:46 |
| spiv | sven_: Anyway, it might be possible to make --weave/--lca more cautious so that it gives a conflict in that case (without making it so conflict-prone that it's as bad as --merge3). So do file a bug, we want the tool to DWIM as much as possible. | 14:49 |
| sven_ | spiv, ok, i'll file a bug | 14:50 |
| sven_ | spiv, thanks for your help! | 14:50 |
| spiv | sven_: but it can never be perfect, unless you can supply it with an external merge tool that understands code rather than just lines of text :) | 14:50 |
| sven_ | spiv, of course :-) | 14:50 |
| === kiko-zzz is now known as kiko | ||
| spiv | sven_: another option is that maybe we could make merge report warnings when it's assuming that identical changes by both sides don't conflict, or similar, so humans have hints about what's perhaps most likely to need checking. | 14:52 |
| spiv | Although really it may as well just generate a conflict in that case... | 14:53 |
| spiv | sven_, blaudden: finally, even though --lca doesn't produce .BASE file (which unfortunately breaks extmerge, which is a bug in extmerge I think), you could still invoke something like meld manually with the THIS and OTHER file. | 14:54 |
| blaudden | spiv: oh really. that seems nice | 14:54 |
| blaudden | spiv: is that that same with --weave? | 14:55 |
| spiv | It's not as helpful as when there's a BASE file, but I'm fairly sure meld can still help when there's just two sides. | 14:55 |
| spiv | blaudden: right. --lca is basically always at least as good as --weave, btw. | 14:56 |
| spiv | (there's an obscure edge case it flat out can't handle yet which is why it isn't a total replacement, but in practice you might as well use --lca rather than --weave) | 14:57 |
| spiv | --lca is likely to become the default merge method in future. | 14:57 |
| blaudden | spiv: so you suggest that I try with "merge --lca" or just "remerge --lca" ? | 14:58 |
| blaudden | we should fix extmerge ... | 14:58 |
| pickscrape | I sent a patch through to the extmerge author a while back but it seems to have been ignored :( | 14:59 |
| pickscrape | (not for this problem, for something else) | 14:59 |
| blaudden | pickscrape: maybe it ws a problem with merging? :-) | 14:59 |
| pickscrape | :) | 14:59 |
| pickscrape | It was to give the use the option of which merge tool to use if he doesn't have one configured | 15:00 |
| pickscrape | Instead of the current hard-coded check order | 15:00 |
| spiv | pickscrape: that sounds useful. Is your branch/patch on launchpad somewhere? | 15:00 |
| mpt | jam, thanks for all your help yesterday. After the reconcile (which finished overnight) the branch worked fine. | 15:01 |
| spiv | mpt: ah, glad to hear your problem is finally sorted out | 15:01 |
| pickscrape | It's not... Would I need a new project for that, or can I just upload it to my own area without attaching it to any project? | 15:01 |
| jam | mpt: good, though you probably shouldn't have needed to wait for the full repository reconcile, unfortunately | 15:01 |
| jam | the branch fix takes like 2sec | 15:01 |
| spiv | pickscrape: there's already a bzr-extmerge project on launchpad | 15:02 |
| pickscrape | Oh there is? | 15:02 |
| pickscrape | Am I able to just randomly register a new branch and push to it on that project? | 15:02 |
| spiv | pickscrape: you can just do "bzr push lp:///~USERNAME/bzr-extmerge/my-branch". Or just file a bug and attach a patch :) | 15:02 |
| pickscrape | Ah right... I'll give that a go :) | 15:03 |
| spiv | Er, "lp:~USERNAME/bzr-extmerge/my-branch" would be fine, actually. Not sure why I put the /// in there... | 15:03 |
| pickscrape | spiv: lp:~pickscrape/bzr-extmerge/choose-mergetool | 15:04 |
| spiv | pickscrape: thanks! | 15:05 |
| mpt | spiv, well, it's fixed in *that* branch. :-) There's another branch that's pretty much hosed because I tried to fix it by copying in an old copy of .bzr, when one of the merges I'd done since then was merging mainline | 15:10 |
| mpt | So now there's dozens of unknown files in the tree, some of which should be there, and some of which shouldn't | 15:10 |
| lifeless | mpt: erm, wtf. let bzr manage .bzr, you manage your working tree | 15:10 |
| mpt | yeah, I know that now | 15:11 |
| lifeless | mpt: why was it not obvious (how can we prevent other users doing the same thing) | 15:11 |
| mpt | lifeless, because that's what someone told me to do for the same problem last week | 15:13 |
| lifeless | who? | 15:14 |
| * pickscrape just used the launchpad "Propose for merging" feature for the first time. | 15:15 | |
| jam | lifeless: when you have a broken dirstate (from a couple of older bugs) you can do "bzr co --lightweight" and then copy it back over | 15:53 |
| jam | it was the only recovery tool that we had | 15:53 |
| jam | I don't remember the specific problems | 15:53 |
| === kiko is now known as kiko-phone | ||
| sven_ | spiv, blaudden, i reported https://bugs.launchpad.net/bzr/+bug/238895 | 16:58 |
| ubottu | Launchpad bug 238895 in bzr "'bzr merge --weave' merges unsafely when branch_1 has permuted lines and branch_2 has modified same line" [Undecided,New] | 16:58 |
| sven_ | right | 16:58 |
| === kiko-phone is now known as kiko | ||
| whitelynx | i'm using Bazaar to manage several projects with multiple users, and I'm running into an issue; when someone pushes a new branch to our repository, the permissions are set so that nobody else can write to it, and I have to go manually fix permissions so others can push to it. Is there any way to set a umask or something in the Bazaar configuration? | 17:27 |
| whitelynx | Also, I had to make everyone part of the same group and have them all default to that group to make the pushed branches have the correct group; however, this means I can't use multiple groups to manage permissions for different projects because whenever someone pushes, it always pushes as their default group | 17:28 |
| === kiko is now known as kiko-fud | ||
| === BasicPRO is now known as BasicOSX | ||
| blaudden | sven_: I updatede your report with the result we get. | 18:11 |
| === mw|out is now known as mw | ||
| === bratsche is now known as bratsche_ | ||
| fredreichbier | if i try to push over sftp, i get an Permision Error with ".bzr/README.tmp.1213121278.758560896.7992.40354623", but it creates the branch directory. what can i do? | 19:09 |
| fdv | lifeless: I've been looking at this issue with the KnitCorrupt error I talked about earlier. Isn't what I want essentially 'unpull'? | 19:15 |
| fdv | lifeless: And couldn't this be accomplished somehow by a pull --overwrite with an appropriate revision range? | 19:19 |
| MvG | Is Jan Hudec present here? | 19:41 |
| === mw is now known as mw|food | ||
| tethridge | please excuse me for asking again, but does anyone know of a project similar to bzr-svn for clear case? | 21:32 |
| tethridge | Somebody told me that they had heard that somebody was using it internally at work, but they didn't know who. | 21:32 |
| tethridge | I've been asking through different times of the day in the hopes that somebody would know something. | 21:33 |
| === mw|food is now known as mw | ||
| mwhudson | tethridge: the most knowledgeable people are probably going to appear in 1-2 hours | 21:37 |
| tethridge | mwhudson, I'll try again then. Do you have some usernames that I should look for? | 21:38 |
| beuno | tethridge, actually, you might even get a better response from mailing to the list | 21:47 |
| beuno | morning mwhudson | 21:47 |
| tethridge | good idea | 21:47 |
| abentley | mwhudson: I wouldn't say that exactly. | 21:50 |
| tethridge | I'm going to try both | 21:50 |
| abentley | jam and I are pretty knowledgeable. | 21:50 |
| abentley | It's just that idling here isn't what I'm paid for. | 21:51 |
| tethridge | abentley, know anything about a clear case plugin? :-) | 21:52 |
| tethridge | oh, and you get paid? | 21:52 |
| abentley | tethridge: No, I haven't heard of any such thing. | 21:52 |
| tethridge | I'm getting screwed | 21:52 |
| abentley | tethridge: I work on the bazaar-launchpad team. | 21:52 |
| tethridge | ah | 21:53 |
| tethridge | just kidding | 21:53 |
| abentley | I'm not too up on the proprietary stuff. What is ClearCase again? | 21:53 |
| abentley | i.e. are you looking for an IDE plugin or an import/export plugin? | 21:54 |
| matkor | Hm. Why when I try bzr push lp:~matkor/wicd/experimental-matkor I get bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ematkor/wicd/experimental-matkor/.bzr/repository/lock): Transport operation not possible: http does not support mkdir ? Why bzr tries to use http ? | 21:57 |
| jelmer | matkor: the launchpad plugin uses http if you haven't logged in | 21:58 |
| jelmer | matkor: try " | 21:58 |
| jelmer | bzr lp-login" | 21:58 |
| jelmer | or something | 21:58 |
| matkor | jelmer: I see .. thanks a lot ! | 22:00 |
| mwhudson | oh man, i have some mailing list posts to write, it seems! | 22:37 |
| mwhudson | beuno: simpletal looks interesting | 22:44 |
| beuno | mwhudson, more than pylons + mako? | 22:45 |
| mwhudson | beuno: well, i dunno | 22:45 |
| mwhudson | as i said, i kind of hate non-tree templating | 22:45 |
| mwhudson | but if you're the one doing the work ... :) | 22:45 |
| mwhudson | beuno: what does pylons use for the http part? | 22:46 |
| mwhudson | (where turbogears uses cherrypy) | 22:47 |
| * beuno looks | 22:47 | |
| beuno | mwhudson, it seems to use wsgi | 22:49 |
| mwhudson | uhh | 22:50 |
| mwhudson | is that actually an answer to the question? | 22:50 |
| mwhudson | i guess it is | 22:50 |
| beuno | well, yes and no :) | 22:50 |
| beuno | "paste" | 22:50 |
| mwhudson | i guess it means you can plug in ~whatever http server you like | 22:50 |
| beuno | By default Pylons uses paste's httpserver | 22:51 |
| mwhudson | which would be good because cherrypy makes the baby jesus cry | 22:51 |
| beuno | "You could stick to it or use something different, say one from CherryPy 3.0" | 22:51 |
| mwhudson | cherrypy 3 is ok, afaict | 22:51 |
| beuno | so if you still feel like you need pain on a daily basis, we can stick with it :p | 22:51 |
| beuno | the cool thing is that pylons has kid/genshi too | 22:52 |
| mwhudson | well | 22:52 |
| mwhudson | i am still skeptical that loggerhead benefits from _anything_ that's in the django/turbogears/pylons/zope category | 22:52 |
| mwhudson | really SimpleHTTPServer + some templating engine should be enough | 22:53 |
| mwhudson | (for the plugin version, not what we do on lp) | 22:53 |
| beuno | yeah, SimpleHTTPServer would be the best way to go | 22:53 |
| mwhudson | i guess we may want slightly more sophistication, because we do want to set http headers occasionally | 22:54 |
| mwhudson | so maybe wsgi would be an appropriate interface to aim for | 22:54 |
| beuno | mwhudson, I believe the dependency issue for ZPT is enough reason to look into other options sooner than later. What do you think? | 22:56 |
| mwhudson | beuno: i think if simpletal can work, then that's a small enough dependency | 22:57 |
| beuno | mwhudson, I'll check and see what changes have to be made | 22:57 |
| mwhudson | beuno: *i* already have too many half-finished not-really-sure-if-it's-a-good-idea loggerhead branches around | 22:58 |
| mwhudson | beuno: i don't want you to start collecting them too :) | 22:58 |
| beuno | in fact, I'll do it now, while I wait for lifeless to wake up and I can complain about bzr-search | 22:58 |
| beuno | heh | 22:58 |
| beuno | ok, so you want the other 2 patches first :) | 22:58 |
| mwhudson | well, let's see about simpletal | 22:59 |
| beuno | the ZPT thing just itches too much, at least to move it into trunk | 22:59 |
| mwhudson | on first blush, it seems like the changes required would be fairly minor | 22:59 |
| beuno | ok, so I'll take a shot at simpletal now, and, if it's simple enough, I'll re-send the last patch with simpletal, and the other 2 | 23:00 |
| beuno | seem ok? | 23:00 |
| mwhudson | i will give turbogears some credit, it nicely encourages loose coupling | 23:00 |
| mwhudson | beuno: +1 | 23:00 |
| mwhudson | if nothing else, i think refactoring from the zpt templates to something else might be easier than refactoring the kid templates | 23:01 |
| mwhudson | because i think i cleaned up the templates a bit when i rewrote them | 23:01 |
| beuno | absolutely, I've been doing all my work based on your zpt branch | 23:01 |
| beuno | kid is a bit icky, but it may be the cleanup too | 23:02 |
| beuno | either way, there may be some portions of the zpt patch you may want to look at, the non-template bits | 23:02 |
| mwhudson | phone brb | 23:03 |
| beuno | ah, lifeless, finally :) good morning | 23:11 |
| jelmer | hmm, post-push hooks don't appear to be working when creating a new branch | 23:20 |
| mwhudson | beuno: ok, back | 23:25 |
| beuno | mwhudson, I can't find a clear way to use simpletal with TG... :/ | 23:26 |
| beuno | documentation on simpletal is a bit... "lacky" | 23:27 |
| mwhudson | well, i guess you need to hackerize the turbozpt package that zpt-templating includes | 23:27 |
| beuno | I can't get TG to use simpletal at all | 23:29 |
| beuno | and google isn't really being helpful | 23:29 |
| mwhudson | let me have a go | 23:29 |
| beuno | many people saying they want to move to, but none that actually did | 23:29 |
| mwhudson | i see | 23:30 |
| beuno | argh, simpletal is only available for 2.4... | 23:32 |
| beuno | packaged in Ubuntu at least | 23:32 |
| mwhudson | ? | 23:33 |
| mwhudson | mwh@grond:~/canonical/repos/loggerhead/trunk$ python2.5 -c 'import simpletal' | 23:33 |
| mwhudson | mwh@grond:~/canonical/repos/loggerhead/trunk$ | 23:33 |
| beuno | ah, no, ignore me | 23:33 |
| beuno | I really have to do a fresh install | 23:33 |
| beuno | anyway, there doesn't seem to be integration into TG, or am I missing something? | 23:34 |
| mwhudson | no, there probably isn't | 23:34 |
| mwhudson | but that's ok, we can write it | 23:34 |
| beuno | is it still worth it if we have to? | 23:36 |
| mwhudson | i really don't think it will take very long | 23:36 |
| tethridge | anybody heard of a clearcase plugin similar to bzr-svn? | 23:36 |
| tethridge | last time I'm asking | 23:36 |
| tethridge | :-) | 23:36 |
| jelmer | tethridge: I don't think there is one | 23:36 |
| tethridge | I was told that supposedly somebody was working on one for internal use at their company | 23:37 |
| tethridge | don't know who though | 23:37 |
| beuno | mwhudson, alright, I'm not very familiar with that area, but I'll give it a try | 23:37 |
| mwhudson | beuno: let me try first :) | 23:37 |
| beuno | yay! :) | 23:38 |
| mwhudson | beuno: is the latest version of the zpt branch on launchpad somewhere? | 23:38 |
| bob2 | tethridge: maybe someone on the list will know | 23:38 |
| tethridge | I'm going to try that | 23:38 |
| beuno | mwhudson, I have 3 zpt branches. 1) is that patch I sent to the list, which I can upload if you want. 2) is zpt+ajax+cleanups, 3) is list patch + cleaner URLs | 23:39 |
| mwhudson | beuno: ok, i'll use the bundle | 23:40 |
| mwhudson | bundles are awesome | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!