| igc | poolie, spiv: call on today? | 00:04 |
|---|---|---|
| poolie | igc, yes, but i can't get in | 00:05 |
| poolie | still trying | 00:06 |
| igc | poolie: I'll hang up in case that helps | 00:06 |
| * spiv hangs up too | 00:07 | |
| schierbec1 | jelmer: ping | 00:07 |
| igc | poolie: I got straight back in ok | 00:08 |
| igc | is it your local phone maybe? | 00:08 |
| poolie | it might be my phone | 00:12 |
| poolie | when i tried i got through to varying extents | 00:12 |
| poolie | anyhow | 00:12 |
| poolie | let's just catch up here on irc? | 00:13 |
| spiv | Sounds good. | 00:13 |
| igc | me too | 00:13 |
| poolie | so i think the PPA stuff is all settled now | 00:13 |
| igc | today, I'm planning to review patches, particularly the xml8 serializer one | 00:14 |
| poolie | i'm going to look at what bugs i currently have assigned to me and either finish some of them, do reviews, or do startup time hacking | 00:14 |
| igc | I need to learn more about that so reviewing that patch will help me | 00:14 |
| poolie | i'd like to suggest the whole project do a bug day tomorrow, will send mail about that | 00:15 |
| poolie | also i seem to have some Ubuntu bugs atm | 00:15 |
| poolie | so will file them | 00:15 |
| igc | poolie: were you planning to tweak james_w's patch on lp: urls or shall I do that? we both voted tweak | 00:16 |
| poolie | i'll do that | 00:16 |
| igc | thanks | 00:16 |
| poolie | also when lifeless is back i'll call him re his conference submission | 00:17 |
| poolie | and i owe thumper a call or sketch of the branch listing page | 00:17 |
| igc | if you get a chance, I'd like some feedback on my hook patch/rfc too | 00:17 |
| spiv | I've sent off the core bits of the fix for bug 207558. I want to do a little more on it (as mentioned in the most recent email to the list about it), but it's essentially done. | 00:18 |
| ubotu | Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558 | 00:18 |
| poolie | ok | 00:18 |
| poolie | i'll try to read that for you spiv | 00:18 |
| poolie | what is next for you? | 00:18 |
| spiv | So today will be mainly server-side hooks. | 00:18 |
| igc | poolie: another thing for me today - kill & resume the OOo import | 00:20 |
| igc | it's at 157k out of 305k, taking 18 minutes per 100 revisions so dog slow | 00:21 |
| igc | I took the call to enable_cache out of the code yesterday at lifeless' request so I'll resume it with that code gone and see if it helps | 00:22 |
| poolie | ok, good | 00:31 |
| lifeless | igc: We should find what the cache was masking and fix it. | 00:39 |
| lifeless | igc: I strongly suspect that using commit builder will give you better performance and let you get to an incremental-change approach safely for the importer | 00:44 |
| lifeless | igc: with appropriate tweaks to the builder of course; but thats what its meant to be used for - install_revisions shouldn't, IMO, need to exist. | 00:45 |
| igc | lifeless: maybe. commit-builder currently does things much slower than the importer does | 00:46 |
| igc | it simply can't make some of the assumptions than an importer can | 00:47 |
| igc | which make big differences to speed | 00:47 |
| lifeless | igc: without details I can't comment; but if we're to continue to accelerate commit, commit builder has to learn how to work with very smart trees; which an import source can be considered to be. | 00:48 |
| lifeless | igc: in dealing with merge revisions, if commit builder is slower, I have to assume that the importer is wrong :> | 00:48 |
| lifeless | I'm going to do a couple of spikes today | 00:48 |
| lifeless | and get back to VF this afternoon | 00:48 |
| lifeless | I chatted with benno last night about python performance | 00:50 |
| lifeless | and he concurred with my import analysis, gave some commentary on os call performance readdir etc | 00:50 |
| lifeless | so I'm going to do this long threatened import hook | 00:50 |
| spiv | lifeless: based on my stracing and experiments in London, I'm only expecting a very modest win (300ms improvement in cold cache time). I'll be interested to see if the reality is different. | 00:53 |
| lifeless | spiv: strace doesn't show how much time python spends marshalling | 00:55 |
| lifeless | spiv: I suspect that there is some compiler overhead that won't be addressed by a simple import hook | 00:55 |
| lifeless | holy cow 'import bzrlib' hits a lot of shit | 00:59 |
| lifeless | 34 modules | 00:59 |
| poolie | yes, i know | 00:59 |
| lifeless | many are demand load stubs I think | 01:00 |
| lifeless | or something strange | 01:00 |
| lifeless | -weird | 01:01 |
| lifeless | >>> type(sys.modules['bzrlib.struct']) | 01:01 |
| lifeless | <type 'NoneType'> | 01:01 |
| spiv | That's expected. | 01:02 |
| spiv | When a module inside the bzrlib package tries "import struct", python first treats it as a relative import. | 01:03 |
| spiv | And when an import fails, it caches misses as well as hits in sys.modules. | 01:03 |
| lifeless | ah good | 01:03 |
| spiv | (Bring on python 2.5...) | 01:04 |
| lifeless | 12 real modules imported then | 01:04 |
| spiv | lifeless: I see 58 new modules imported by "import bzrlib" with bzr.dev. (Only 12 with http://people.ubuntu.com/~andrew/bzr/faster-startup, though...) | 01:20 |
| spiv | (as measured with PYTHONPATH=. python -c "import sys; get_mods = lambda: set(name for name, mod in sys.modules.items() if mod is not None); before = get_mods(); import bzrlib; after = get_mods(); print len(after - before)") | 01:21 |
| === mwhudson_ is now known as mwhudson | ||
| === kiko is now known as kiko-zzz | ||
| lifeless | spiv: what does your faster-startup branch do ? | 01:27 |
| lifeless | spiv: (I am only planning to alter the behaviour of bzrlib specific imports) | 01:27 |
| spiv | lifeless: basically, various hackery to defer unnecessary imports | 01:28 |
| spiv | (or avoid) | 01:28 |
| spiv | lifeless: it's cumulatively a few hours of iterating on "bzr --profile-imports" on simple commands like "rocks" and "status" and seeing what cheap wins I could get. | 01:29 |
| lifeless | has anyone tried running freeze on bzr ? | 01:30 |
| spiv | Oh, and specifically also reducing the amount of the universe that "import bzrlib" imports :) | 01:30 |
| lifeless | e.g. making *everything* import and running freeze | 01:30 |
| lifeless | spiv: so my thesis is that we should make importing everything fast | 01:31 |
| === bigdo2 is now known as bigdog | ||
| lifeless | because in the general case most of the code is needed | 01:31 |
| lifeless | spiv: what do you mean about 2.5? | 01:46 |
| mwhudson | i don't think he meant 2.5 | 01:46 |
| mwhudson | at some point, imports written the normal way will be absolute | 01:47 |
| mwhudson | which means less looking for things like bzrlib.struct | 01:47 |
| spiv | I meant file:///usr/share/doc/python2.5/html/whatsnew/pep-328.html | 01:49 |
| spiv | 2.5 introduces "from __future__ import absolute_import" | 01:49 |
| mwhudson | oh, heh | 01:50 |
| mwhudson | shows when i stopped paying microscopic attention to python development | 01:50 |
| lifeless | damn, pkgutil doesn't exist in 2.4 | 01:54 |
| lifeless | so, I'm saving 130/4900 open calls | 02:08 |
| lifeless | all of which look like failures | 02:08 |
| LaserJock | question, how do I change the "parent branch" of a branch? | 02:18 |
| poolie | igc, is there a BB enttry for the patch from james_w you mentioned before? | 02:19 |
| poolie | igc, i take it you were referring to the one to give a warning when getting a readonly transport? | 02:20 |
| igc | poolie: that's right | 02:20 |
| * igc looks | 02:21 | |
| igc | http://bundlebuggy.aaronbentley.com/request/%3C1205831646.7247.295.camel@flash%3E | 02:21 |
| igc | poolie: ^^^ | 02:21 |
| poolie | thanks | 02:22 |
| lifeless | LaserJock: pull --remember | 02:23 |
| LaserJock | lifeless: awesome | 02:26 |
| * igc lunch | 02:35 | |
| * mwhudson tries to work out if it's strange or not for merge --preview to complain about uncommitted changes | 02:46 | |
| spiv | mwhudson: there was a thread about that on the list recently | 02:51 |
| spiv | mwhudson: it shouldn't complain, IIRC | 02:51 |
| mwhudson | there was? must have missed that in my catchup | 02:51 |
| lifeless | mwhudson: it should tell you, and take your changes as part of the merge | 03:04 |
| lifeless | mwhudson: IMO | 03:04 |
| mwhudson | i guess that makes sense | 03:06 |
| lifeless | ok, I now have my code being called consistently | 03:14 |
| abentley | lifeless: well, I'm not convinced. | 03:21 |
| abentley | It's not a very accurate preview that way. | 03:21 |
| lifeless | abentley: why is it less accurate? | 03:21 |
| abentley | because merge won't make any of those changes. It will barf. | 03:23 |
| poolie | abentley: thanks for the review ofthe help change | 04:07 |
| abentley | np | 04:07 |
| abentley | Something else I meant to mention is that people will still get criss-cross warnings if they are using --weave or --lca | 04:08 |
| abentley | Even though those algorithms handle criss-cross better. | 04:09 |
| abentley | So perhaps it should say not to remerge if you're already using --lca or --weave. | 04:10 |
| poolie | so would you overall suggest using remerge, or revert and merge again? | 04:10 |
| lifeless | back in a few minutes; getting lunch | 04:13 |
| abentley | poolie: I'd suggest revert and merge. | 04:24 |
| abentley | Fewer commands to learn that way. | 04:25 |
| lifeless | abentley: when is remerge a good thing to learn and use then ? | 04:29 |
| abentley | I generally use it when I've got a single file with really wacky conflicts, and I want to try out a bunch of different mergers to get the best result I can. | 04:30 |
| abentley | If there are basic, intermediate, and advanced commands, I'd consider it intermediate. | 04:31 |
| lifeless | ok | 04:31 |
| lifeless | one thing I've found with loom is that there was a bunch of 'when I use it' implicit in the thing that I hadn't written down. | 04:31 |
| lifeless | I think we may have something similar here. | 04:31 |
| poolie | that is basically when i use remerge too | 04:32 |
| poolie | rarely on the whole tree | 04:32 |
| poolie | could we at least make it fail safe on looms - like give an error rather than mess things up? | 04:33 |
| abentley | lifeless: are you familiar with the problem? | 04:34 |
| lifeless | abentley: no, I've never used remerge like that | 04:35 |
| lifeless | oh, you mean with looms - I've seen the bug report | 04:35 |
| abentley | So the problem is that remerge assumes the .THIS file coresponds to the left workingtree parent. | 04:36 |
| abentley | but with up-thread, it is actually the rightmost parent. | 04:37 |
| lifeless | I think the things are about-face for performance | 04:37 |
| lifeless | I didn't want to transform; then merge | 04:37 |
| abentley | I'm not sure your approach is wrong. A different approach might lead to more conflicts. | 04:38 |
| lifeless | its on my long todo to teach bzr's merge the ability to be told different file suffixes | 04:39 |
| lifeless | so we can drop the 'right files' in the right places | 04:40 |
| lifeless | and give better herringbone labels | 04:40 |
| abentley | You'd also want to swap the conflict markers. | 04:40 |
| abentley | :-) | 04:40 |
| lifeless | I'd actually like to call them by their thread names | 04:40 |
| fullermd | Speaking of merge, did --reprocess stop doing its thing sometime? Or did it just never really cut things down a lot? | 04:40 |
| abentley | Sure. | 04:40 |
| lifeless | fullermd: I think it became default | 04:41 |
| poolie | abentley: could you suggest some better help text? | 04:41 |
| poolie | should we say "use remerge FILE, or revert and merge again?" | 04:41 |
| abentley | Let's say "revert and merge again". | 04:42 |
| abentley | lifeless: So we understand the problem-- is there a short-term fix we can do like poolie suggested? | 04:42 |
| abentley | fullermd: I don't think it became the default. But it only helps a narrow class of merges, and only applies to --diff3 | 04:43 |
| abentley | lifeless: The problem so far is that we can't even tell that the merge was different. | 04:44 |
| fullermd | I've got kernel configs in bzr to easily merge upstream changes, and every time I do (last was some months ago), I get hyuge spurious conflicts that it doesn't help. | 04:45 |
| === mw is now known as mw|out | ||
| abentley | fullermd: line endings? | 04:53 |
| fullermd | No, but changes in single lines ended up resurrecting giant blocks that I'd deleted. | 04:53 |
| awmcclain | Imagine we pushed some changes for April Fools day. Like, 4 revisions. What would the easiest way, hypothetically, to check an older revision to head? | 04:53 |
| fullermd | I guess it's some artifact of the diff hunk for the revs where I whacked the blocks. | 04:54 |
| spiv | awmcclain: bzr push -r NNN --overwrite | 04:55 |
| spiv | awmcclain: (NNN == -4, I guess...) | 04:55 |
| awmcclain | spiv: And if it's a bound branch, can we do bzr ci -r NNN --overwrite? | 04:55 |
| abentley | fullermd: I'd normally offer to help, but I'm behind already. | 04:56 |
| spiv | awmcclain: ah, with a bound branch, use uncommit | 04:56 |
| awmcclain | spiv: 4 times? | 04:56 |
| spiv | awmcclain: which also takes a -r arg. | 04:56 |
| spiv | Or just run it 4 times, sure. | 04:56 |
| awmcclain | spiv: Gotcha! | 04:56 |
| fullermd | Or just pull -r-4 --overwrite . | 04:56 |
| spiv | fullermd: heh. | 04:56 |
| lifeless | fullermd: pull overwrite affects master branch :) | 04:56 |
| fullermd | abentley: *shrug* It's not that big a deal. Bugs me for 30 seconds or so a couple times a year when I do it. Hasn't been a high enough priority for me to build up a test case for it. | 04:57 |
| abentley | fullermd: You might try --lca. It's kinda got --remerge built in. | 04:57 |
| abentley | s/--remerge/--reprocess | 04:57 |
| fullermd | Last time I tried was probably pre-lca; I tried both diff3 and weave, with/out reprocess; came up the same every time. | 04:58 |
| awmcclain | But if I want to commit _over_ the current changes, not remove them.. could i bzr revert -r NNN then ci? | 04:58 |
| fullermd | I'll try getting creative next time it comes up. | 04:58 |
| spiv | awmcclain: right | 04:58 |
| poolie | abentley, BB seems to be stuck, can you whack it? | 04:59 |
| abentley | poolie: did it give you a lock error? | 05:00 |
| spiv | abentley: I'm currently getting 502 Proxy Error | 05:01 |
| spiv | "Reason: Error reading from remote server" | 05:02 |
| igc | abentley: me too | 05:04 |
| igc | " The proxy server could not handle the request GET /." | 05:04 |
| abentley | I have increased the database timeout to unreasonable levels. | 05:05 |
| abentley | So there's an active lock, but I'm not sure whether it will resolve itself. | 05:05 |
| abentley | The last time I got a 502, it did. | 05:06 |
| poolie | same | 05:07 |
| lifeless | you're using sqlite right? | 05:07 |
| abentley | Okay, whacked. | 05:07 |
| abentley | lifeless: right | 05:07 |
| lifeless | there is something funny in the python bindings AFAICT | 05:08 |
| bob2 | sqlite3? | 05:08 |
| poolie | abentley: how about this: | 05:08 |
| poolie | In complex merge cases, `bzr merge --lca` or `bzr merge --weave` may give | 05:08 |
| poolie | better results. You may wish to `bzr revert` the working tree and merge | 05:08 |
| poolie | again, or use `bzr remerge` on particular conflicted files. | 05:08 |
| poolie | i feel kind of reluctant not to mention remerge because it's what i usually run myself | 05:09 |
| poolie | i see your point though about involving less commands | 05:09 |
| abentley | Okay, fair enough. | 05:09 |
| poolie | and if they did help criss-cross just after the failure they will not lose anything | 05:09 |
| abentley | Perhaps we should omit the revert; remerge thing. | 05:09 |
| abentley | Pardon? | 05:09 |
| abentley | lifeless: Any suggestions on a band-aid for up-thread? | 05:10 |
| lifeless | abentley: w.r.t remerge ? | 05:11 |
| abentley | Yes. | 05:11 |
| lifeless | I don't think there is a good band-aid; I think it just needs the bzrlib work done. | 05:11 |
| poolie | """In complex merge cases, `bzr merge --lca` or `bzr merge --weave` may give | 05:11 |
| poolie | better results. You may wish to `bzr revert` the working tree and merge | 05:11 |
| poolie | again. Alternatively, use `bzr remerge` on particular conflicted files. | 05:11 |
| poolie | "'" | 05:12 |
| * poolie reads fix for 207558 | 05:21 | |
| lifeless | poolie: call ? | 05:23 |
| poolie | in 6m? | 05:23 |
| lifeless | sure | 05:23 |
| abentley | poolie: re that TT bug, it's due to adding a file to a deleted directory, when the deleted directory was the root directory. | 05:38 |
| poolie | ! | 05:39 |
| poolie | ok | 05:39 |
| lifeless | spiv: ping | 05:40 |
| abentley | Anyhow, now that I can reproduce it, it shouldn't be a hard fix. | 05:40 |
| lifeless | I have a 'wtf' moment with my import hook | 05:40 |
| poolie | lifeless: your phone's engaged? | 05:41 |
| lifeless | its trying to import 'debian_bundle' from '' in the Numeric path path_hook object | 05:41 |
| lifeless | poolie: no?? | 05:41 |
| spiv | lifeless: pong | 05:44 |
| lifeless | does Numeric do crack? | 05:44 |
| spiv | lifeless: I don't know if Numeric does crack or not. | 05:59 |
| mwhudson | beuno: around? | 06:00 |
| lifeless | spiv: you have mail | 06:13 |
| lifeless | spiv: should be self evident if you want to apply it to bzr.dev and play | 06:13 |
| lifeless | spiv: I get quite reduced syscalls with this but its buggy :/ | 06:14 |
| jamesh | lifeless: bzr-gtk has now been updated so that it functions correctly with my bzr-dbus patches, btw | 06:38 |
| jamesh | they're waiting on you for review though. | 06:39 |
| lifeless | thanks | 06:40 |
| spiv | abentley: bb seems to be wedged again | 06:51 |
| === mwhudson_ is now known as mwhudson | ||
| vila | lifeless: regarding loom-specific conflict markers, please be sure you won't break external tools that are looking for them (i.e. may be *add* thread name after the usual markers instead of replacing MERGE-SOURCE and/or TREE) | 07:34 |
| Egotrip | Want to make $$$ just by clicking? Sign up on http://bux.to/?r=eg0trip, and begin recieving checks! | 07:52 |
| james_w | no thanks | 07:54 |
| Egotrip | yes you do | 07:54 |
| mdke | lifeless: still around? | 08:04 |
| lifeless | dunno who egotrip was, but we don't want spam here. | 09:03 |
| fullermd | He didn't explain himself very well, certainly. I kept clicking, but I got @@@ instead of $$$ :| | 09:08 |
| jamesh | and I'd prefer to receive cheques rather than checks | 09:15 |
| yacc | Hmm, how can I force a baseless merge with bzr? | 09:30 |
| schierbeck | jelmer: ping | 09:32 |
| yacc | schierbeck: I second that: ping jelmer | 09:32 |
| schierbeck | :) | 09:32 |
| yacc | schierbeck: what's it for you? In my case bzr-svn seems to have forgotten about branch relationships ;( | 09:32 |
| schierbeck | tough luck | 09:33 |
| schierbeck | nah, i just want him to give his 2 cents before i send in a merge request | 09:33 |
| james_w | yacc: merge -r1..-1 | 09:34 |
| yacc | james_w: is that a good idea, considering that the branch contains the same revisions as the remote one? (bzr just seems to think that they are unrelated) | 09:35 |
| james_w | yacc: probably not | 09:35 |
| james_w | how did you create your local branch? | 09:35 |
| yacc | bzr branch svn+https://... | 09:35 |
| james_w | from the same branch you are trying to merge now? | 09:36 |
| yacc | Look at: https://bugs.launchpad.net/bzr-svn/+bug/210705 | 09:37 |
| ubotu | Launchpad bug 210705 in bzr-svn "bzr-svn forgets relationship" [Undecided,New] | 09:37 |
| yacc | james_w: but basically yes. | 09:37 |
| yacc | james_w: => it remembers where it pulled from, and pushed to in the past. | 09:38 |
| yacc | james_w: just when doing a merge it complains about being unrelated. | 09:38 |
| yacc | Oh, bzr missing lists all revisions as missing on both sides, plus the one that I did commit locally, which is only listed on one side. | 09:38 |
| yacc | but the merge did not help anything, it still misses 3/4 revisions ;( | 09:39 |
| yacc | james_w: despite the above merge -r1..-1, it still claims that the branches are diverging. | 09:40 |
| james_w | yacc: can you pastebin a bzr missing --show-ids | 09:40 |
| yacc | james_w: just a moment, first I'm curious ;) | 09:40 |
| yacc | james_w: they don't match :( | 09:42 |
| yacc | http://rafb.net/p/a1aZXh19.html | 09:42 |
| yacc | james_w: guess that is what jelmer meant with the ids can change? | 09:43 |
| yacc | jelmer!!!!!!!!!!!!!!! | 09:43 |
| james_w | they don't match is the reason that you are seeing this issue. | 09:43 |
| james_w | calm down, he's been highlighted, if he's around he'll see it | 09:43 |
| yacc | james_w: yeah, BUT: I had to change the scheme to include new trunks | 09:44 |
| yacc | revision-id: svn-v3-list-QlpoOTFBWSZTWTtPdCgAACpRgAAQAAK3r94gIABIbVT1Mj0QeptEEpAAANMcdP3o3SqXf2KNSpL4ShxMTeA8adCslybHoqgxGgqoZA-LuSKcKEgdp7oUAA..:3e2713fb-81e7-48d5-8ee4-88d6b0cf85af:trunk%2Flogs%2Flookery-memberfind:56 | 09:44 |
| yacc | revision-id: svn-v3-list-QlpoOTFBWSZTWYDqAEcAADdRgAAQAAK3r94gIABISkMo0zUaemoEkkaZMAm1IM83f4FQYGxfzVWsvATONoa96yIoS8IEx1BxVRIGB_MCYIMwX5NxaET_F3JFOFCQgOoARw..:3e2713fb-81e7-48d5-8ee4-88d6b0cf85af:trunk%2Flogs%2Flookery-memberfind:56 | 09:44 |
| yacc | see the base64 encoded list of paths <= I had to change that to accomodate a new branch. | 09:45 |
| james_w | you changed the svn branching scheme? | 09:45 |
| yacc | james_w: list-path1-path2 => list-path1-path2-path3 <= I had to add path3 because it's a new branch I need access to? | 09:45 |
| yacc | james_w: basicaly the revids for branch X contain the a list of all other branches that I'm accessing in the given SVN repo. | 09:47 |
| yacc | james_w: Hmmm, I think the fix would be to make bzr-svn use svn-v3-list-$PATH_USED_IN_THIS_CASE instead of svn-v3-list-$PATH_OF_THE_COMPLETE_SCHEME? | 09:48 |
| yacc | james_w: Any explanation what the different branching schemes are good for? | 09:50 |
| james_w | yeah, so it's caused by the change to the branching scheme | 09:53 |
| james_w | the scheme is to tell bzr-svn which paths in svn to consider branches | 09:54 |
| yacc | yeah, but the problem is, appending one new "path" in the repository is a quite expected thing to do. | 09:56 |
| yacc | It should not break all branches/checkouts in the wild, just because I need to track one additional location? | 09:56 |
| james_w | yacc: add this information to the bug report. | 09:57 |
| yacc | Already done so. | 09:57 |
| yacc | james_w: single would mean that I can only access exactly one path inside the svn repo? | 10:00 |
| james_w | I think so | 10:00 |
| yacc | Hmmm. | 10:01 |
| yacc | So basically I would need to parametrize the "schema name for property name" lookup thing. | 10:01 |
| yacc | It basically needs to take the URL being accessed into account ;( | 10:02 |
| * yacc wonders what the schemes are good for at all? | 10:06 | |
| igc | james_w: I'm hoping to review that gnome bug tracker patch tomorrow | 10:10 |
| igc | if you put through abentley's tweak tonight, that would be nice ... | 10:10 |
| igc | though I realise you may not have time | 10:10 |
| igc | I'm heading off now | 10:10 |
| igc | night all | 10:10 |
| james_w | igc: thanks, I'll try and get to it. | 10:11 |
| james_w | night | 10:11 |
| jml_ | lifeless: ping | 10:13 |
| yacc | jelmer: ping | 10:22 |
| yacc | jelmer: would it be ok by you to implement a "EveryPathIsABranchScheme"? | 10:27 |
| AnAnt | Hello, when using bzr, can't I checkout just a single folder instead of the whole branch ? | 10:40 |
| luks | right, you can't | 10:41 |
| luks | bzr can only work with whole branches | 10:41 |
| AnAnt | unlike svn | 10:42 |
| luks | svn doesn't have branch :) | 10:43 |
| luks | *branches | 10:43 |
| yacc | luks: and branches is (almost) all that bzr has ;) | 10:44 |
| yacc | How do I make bzr send my local commits as a patch to the maintainer? | 10:44 |
| luks | bzr send | 10:45 |
| yacc | I just discovered that just switching schemes won't work => the svn repos contains pointers to the old scheme name, ... | 10:46 |
| yacc | My only hope for a sane scheme is rapidly crashing. | 10:47 |
| yacc | jelmer: ping | 10:51 |
| ChriS_T | I am trying to convince a colleague to use bzr for our collaboration. However, he has a mac OSX 10.4 intel. Is there a ready to use disk image for that machine ? | 11:05 |
| james_w | there's a macport I think | 11:13 |
| ubotu | New bug: #210665 in bzr-svn "bzr svn-import fails" [Undecided,New] https://launchpad.net/bugs/210665 | 11:18 |
| ubotu | New bug: #210705 in bzr-svn "bzr-svn forgets relationship" [Undecided,New] https://launchpad.net/bugs/210705 | 11:20 |
| ubotu | New bug: #210723 in bzr "Some tests failed when selftest is invoked with -v" [Low,Confirmed] https://launchpad.net/bugs/210723 | 11:21 |
| jelmer | yacc: pong | 11:22 |
| jelmer | yacc: EveryPathIsBranchingScheme will be incredibly slow | 11:23 |
| yacc | jelmer: why? | 11:24 |
| yacc | jelmer: and it misses to_list, which makes --set break, but I guess it breaks for other schemes too. | 11:25 |
| jelmer | yacc: When searching for revision ids, bzr-svn checks every possible branch path for properties | 11:25 |
| yacc | Well, it seems the that list paths get embedded in the properties somehow, so just doing a fresh branch with the ammended paths is not an option either. | 11:26 |
| jelmer | in the case of EveryPathIsBranchingScheme that means one call per file/directory in the remote repository | 11:26 |
| yacc | And let me guess it does not cache the results in any way ;) | 11:27 |
| jelmer | it does cache the results | 11:27 |
| jelmer | but that's still too slow | 11:27 |
| yacc | brb | 11:28 |
| yacc | so how to fix the list scheme then? | 11:32 |
| jelmer | how do you mean? | 11:34 |
| yacc | Well, the list scheme embeds the paths in the revision stuff. | 11:52 |
| yacc | Meaning that when somebody adds a new path (because a new path got added), bzr-svn implods. | 11:53 |
| yacc | jelmer: : #210705 | 11:53 |
| yacc | jelmer: easy to demonstrate: with a branch that uses a list scheme, add another path to the list => et voila, bzr thinks that the svn remote branch and your local bzr branch do not share any history. | 11:54 |
| yacc | Which is wrong. | 11:54 |
| yacc | Considering the fact that some svn users use very very creative directory setups, ... | 11:55 |
| jelmer | yacc: that's correct because they have a different branching scheme | 11:55 |
| yacc | Ok, so how do I handle the case that my upstream project just got a new subproject? | 11:55 |
| jelmer | yacc: What you really want is a fix for bug 130372 | 11:55 |
| ubotu | Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372 | 11:55 |
| jelmer | yacc: you can use wildcards in listbranchingscheme | 11:55 |
| yacc | jelmer: Only if I would have started with wildcards. Take a look at the later comments in 210705 and you'll notice that it seems impossible to switch the scheme for a given repo and recreate the bzr branch | 11:56 |
| jelmer | yacc: yes, that's correct | 11:57 |
| jelmer | yacc: that's why there's bug 130372 | 11:57 |
| ubotu | Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372 | 11:57 |
| yacc | so what do I do? write myself scripts that replace ~/.bazaar/subversion.conf based on the directory I'm in when calling bzr? | 11:58 |
| jelmer | yacc: The error fetching after changing branching schemes is a bug | 12:00 |
| yacc | So I open up a time loop window, and go studying the source code to fix that bug? <= I mean the scheme is part of the revision IDs? | 12:01 |
| yacc | Serious, new bug or known bug? | 12:05 |
| jelmer | yacc: the branching scheme is part of the revision id | 12:06 |
| jelmer | yacc: that's bug 130372 I mentioned earlier | 12:06 |
| ubotu | Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372 | 12:06 |
| yacc | jelmer: 130372 is not about a bug fix, it's about joined branches, right? Meaning that you could drop to supporting only trunk/none for bzr-svn and make the people use split out parts of these repositories, right? | 12:07 |
| jelmer | yacc: no, it's about abandoning branching schemes completely | 12:08 |
| jelmer | as soon as by-value branches are supported | 12:08 |
| jelmer | well, replacing branching schemes with a "repository layouts", which are not included in the revid | 12:09 |
| yacc | So nothing simple for a newbie that has only a limited understanding of bzr internals might want to tackle ;( | 12:11 |
| jelmer | yacc: not really, though it should be possible to get that "not present in "... error fixed | 12:13 |
| jelmer | I'll see if I can fix that | 12:13 |
| rexbron | hey everyone, the docs on this function are a little bit unclear in what order the branch and tree objects are returned | 12:14 |
| rexbron | http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.bzrdir.BzrDir.html#open_tree_or_branch | 12:14 |
| rexbron | I think it is mentioned at the end, but I am still unsure | 12:14 |
| jelmer | rexbron: tuple with tree and branch | 12:15 |
| rexbron | jelmer: K, it mainly that the other funtions make that more clear | 12:15 |
| bob2 | the first sentence should be fixed then | 12:16 |
| yacc | How do I undo local commits? | 12:17 |
| rexbron | yacc: bzr uncommit? | 12:17 |
| rexbron | or revert | 12:17 |
| rexbron | bob2, jelmer: I think it should be changed to something like the method below: Returns (tree, branch) | 12:18 |
| bob2 | famen | 12:18 |
| bob2 | tr -d f | 12:18 |
| spiv | yacc: in bzr.dev, "bzr uncommit --local" | 12:19 |
| spiv | I don't think that's in a release yet, though :( | 12:19 |
| yacc | spiv: Well, uncommit seems to have worked :) | 12:19 |
| james_w | rexbron: tree will be None if there isn't one if you hadn't figured that out yet. | 12:19 |
| spiv | yacc: oh good :) | 12:20 |
| rexbron | james_w: I think I need to refresh exactly what the difference between a branch on the file system and a workingtree (beyond different methods for those objects) | 12:20 |
| james_w | rexbron: i see ":return: (tree, branch)" for that method | 12:20 |
| james_w | rexbron: you can have a branch with no tree | 12:20 |
| james_w | i.e. you have .bzr/branch/ | 12:20 |
| james_w | but there are no files in the working directory, and there will be no .bzr/checkout/ | 12:21 |
| rexbron | james_w: My comment was that it could be more clearly stated, like in the other functions | 12:21 |
| rexbron | james_w: ok | 12:21 |
| james_w | you can get this with bzr remove-tree, or with a treeless repository | 12:21 |
| bob2 | james_w: the furst sentence says the opposite, and I don't think it's unreasonable to assume that it should be correct also :-) | 12:21 |
| james_w | and it will also happen for remote trees. | 12:21 |
| james_w | bob2: that's true | 12:21 |
| james_w | rexbron: that is markup that used to denote the return value. | 12:21 |
| rexbron | james_w: is the doc system supposed to format it differently that it currently is? | 12:22 |
| james_w | ah, it appears to be spelt wrong, as other functions have it formatter | 12:22 |
| === mrevell is now known as mrevell-lunch | ||
| james_w | see open_containing_from_transport | 12:23 |
| rexbron | http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.bzrdir.BzrDir.html#open_repository seemes to also have a formatting issue | 12:24 |
| rexbron | for :param _unsupported: | 12:24 |
| rexbron | now that I look for it, I see a lot of method docs that are (perhaps) not formatted correctly | 12:26 |
| james_w | yeah, they do seem to be a bit bad. | 12:26 |
| james_w | the API documentation is very hit and miss | 12:27 |
| rexbron | james_w: what system is being used, as I would be happy to submit patches | 12:29 |
| rexbron | ok, looks like pydoctor | 12:30 |
| sabdfl | is mail from the bazaar list getting doubled up? | 12:31 |
| yacc | :) | 12:32 |
| james_w | sabdfl: I don't see it, you mean you receive multiple copies? | 12:33 |
| rexbron | Is there a page which documents the syntax for pydoctor? or is it the same as something else? | 12:34 |
| james_w | rexbron: I think it uses the pydoc ones or whatever they are. | 12:34 |
| james_w | rest markup in python docstring might get you some useful pages from google. | 12:35 |
| sabdfl | james_w: yes, i do get multiple copies | 12:35 |
| sabdfl | peregrine% ./bzr pull | 12:35 |
| sabdfl | Using saved location: http://bazaar.launchpad.net/~bzr/bzr/trunk/ | 12:35 |
| sabdfl | bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~bzr/bzr/trunk/". | 12:35 |
| sabdfl | anybody know what would cause this? | 12:35 |
| sabdfl | when I go to that URL I see the loggerhead page | 12:36 |
| spiv | sabdfl: you're using bzr.dev | 12:36 |
| james_w | sabdfl: I think the default is for the list software not to forward it's copy to you if you are already in the to list, but it sounds like it's all mail. | 12:36 |
| spiv | sabdfl: the fix is on the list | 12:36 |
| sabdfl | ok thanks spiv | 12:36 |
| spiv | sabdfl: the bug is 207558 | 12:36 |
| spiv | ubotu: bug 207558 | 12:36 |
| ubotu | Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558 | 12:36 |
| rexbron | hmm, I can not seem to find what markup syntax bzr is using to generate the api docs | 12:42 |
| rexbron | pydoctor's site does not really mention anything | 12:42 |
| spiv | rexbron: epydoc | 12:43 |
| bob2 | epydoc | 12:43 |
| spiv | (the ReST variant of it, IIRC) | 12:43 |
| james_w | rexbron: http://epydoc.sourceforge.net/manual-epytext.html | 12:48 |
| rexbron | james_w: | 12:48 |
| james_w | but it uses : to start, rather than @ | 12:48 |
| rexbron | ya, I found that | 12:48 |
| james_w | it is the rest variant it uses, but that seems to suggest other markup. | 12:48 |
| rexbron | From a quick look, the reason some is being formatted correctly and others not is a lack of a blank line | 12:49 |
| schierbeck | jelmer: i've made the bugs tab look good: lp:~dasch/bzr-gtk/revisionview-bugs-page | 13:10 |
| schierbeck | what do you think? | 13:10 |
| jelmer | schierbeck: yeah, that's definitely an improvement | 13:16 |
| jelmer | hmm, the bug isn't clickable anymore | 13:17 |
| schierbeck | try double-clicking | 13:17 |
| schierbeck | i'll fit a button in there | 13:17 |
| schierbeck | for now, i removed the status string, since "fixed" is the only one supported... | 13:17 |
| jelmer | double-clicking doesn't work | 13:18 |
| jelmer | schierbeck: I'd rather keep it in there and make the message say something like "This revision changes the affects one or more bugs." | 13:19 |
| === mrevell-lunch is now known as mrevell | ||
| schierbeck | jelmer: the status message? | 13:19 |
| schierbeck | i think we should only do that when bzr supports more than one type | 13:20 |
| jelmer | yeah, or otherwise we should be making sure the status message == "fixed" | 13:20 |
| schierbeck | i could do that | 13:20 |
| jelmer | otherwise if bzr supports more than one type in the future, users will get very confusing errors | 13:20 |
| schierbeck | jelmer: okay | 13:22 |
| schierbeck | jelmer: i think the bugs tab should always be visible | 13:23 |
| schierbeck | it's pretty confusing when ui elements magically appear on the screen | 13:24 |
| jelmer | I'd be fine with having it insensitive | 13:26 |
| jelmer | if there are no bugs | 13:26 |
| jelmer | but one of the nice things now is that you don't actually have to switch to the bugs tab to see if a revision touches any bugs | 13:26 |
| schierbeck | okay | 13:26 |
| schierbeck | jelmer: the same thing applies for signatures | 13:26 |
| schierbeck | but if the user is not able to open the tab, he may think that he needs to install something | 13:27 |
| jelmer | schierbeck: Alternatively, we could show an icon in the branchview to indicate a revision touches bugs | 13:30 |
| schierbeck | jelmer: just my thought | 13:30 |
| schierbeck | i just need a smaller icon then | 13:31 |
| schierbeck | currently i just copy-paste from the shared icons i've got lying around... | 13:31 |
| schierbeck | hope i don't get in any trouble | 13:31 |
| jelmer | schierbeck: yeah, we need to check what the license on those icons is.. | 13:32 |
| schierbeck | i'll get on it before we release, but most likely it won't be an issue | 13:33 |
| ignas | are there any documents on how to solve permission problems with shared repositories? i have a group stbaz that can commit to the shared repository, but it seems that after bzr push'es or bzr commits from a lightweight repos using sftp | 13:34 |
| ignas | some files get owned by my user | 13:34 |
| ignas | both as a user and as a group | 13:34 |
| Invisionfree | Hi, I was just wondering, does BZR work with Kerberos? | 13:35 |
| bob2 | it doesn't have specific kerberos support, afaik, but it would work with kerberised ssh | 13:36 |
| jelmer | yeah, I used it with kerberized ssh without problems | 13:37 |
| jelmer | kerberized ftp is not supported yet though (kerberized sftp should be fine) | 13:38 |
| james_w | ignas: have you set g+s on the directories? | 13:39 |
| ignas | yes, it seems so | 13:40 |
| ignas | let me check | 13:40 |
| schierbeck | jelmer: okay, i've pushed the changes to lp | 13:40 |
| james_w | ignas: there's also a limitation of sftp in this area, bzr+ssh will serve you better. | 13:41 |
| ignas | james_w: oh, i see, do i need to do something special? or just replace sftp with bzr+ssh and that's it? | 13:41 |
| james_w | ignas: you need bzr installed on the server | 13:42 |
| james_w | but otherwise probably not | 13:42 |
| ignas | i see | 13:42 |
| james_w | (the exception would be if you had bzr installed somewhere outside the $PATH on the server) | 13:42 |
| ignas | it's in $PATH | 13:42 |
| ignas | by the way - is there a way to get something like a lightweight checkout | 13:43 |
| ignas | that would not need network connection | 13:43 |
| ignas | for bzr status or bzr diff | 13:43 |
| james_w | bzr checkout --lightweight | 13:43 |
| ignas | i am using --lightweight | 13:43 |
| ignas | but every operation like bzr st or bzr diff seems to be connecting to the server | 13:44 |
| james_w | oh, not need network connection, sorry. | 13:44 |
| bob2 | that's the 'lightweight' - most stuff is on the server | 13:44 |
| Peng | s/most/all/. | 13:44 |
| james_w | you can use a normal, non lightweight, checkout. | 13:44 |
| ignas | well - i want a compromise | 13:44 |
| ignas | something that is not 70mb | 13:45 |
| ignas | and does not need network to tell if i have changed a file | 13:45 |
| ignas | like with svn ;) | 13:45 |
| james_w | that puts all of the data on your local disk, but pushes it to the server when you commit, so you only need network access for write operations. | 13:45 |
| Peng | ignas: There is nothing like that yet. | 13:45 |
| ignas | i see | 13:46 |
| ignas | :/ | 13:46 |
| Peng | ignas: All or nothing. | 13:46 |
| ignas | ouch | 13:46 |
| bob2 | how far along are lifeless's shallow branches? | 13:46 |
| * Peng points out that 70 MB isn't huge. | 13:46 | |
| james_w | bob2: quite close I think, it's just a case of making everything "stackable-on" | 13:46 |
| james_w | the smart server for one thing I think | 13:47 |
| bob2 | ah | 13:47 |
| bob2 | hopefully 1.4 then | 13:47 |
| jelmer | schierbeck: I think the message in the bugs tab should say "This revision fixes one or more bugs." since we're not showing the status anymore | 13:48 |
| abentley | bob2: They aren't shallow branches. | 13:48 |
| schierbeck | jelmer: i'm editing it as we speak :) | 13:49 |
| bob2 | abentley: oh | 13:49 |
| abentley | They're not intended to allow you to work when the source branch is unavailable. | 13:49 |
| bob2 | ah | 13:50 |
| schierbeck | jelmer: should we use "fixes" or "claims to fix"? | 13:50 |
| abentley | Stacked branches are mostly a storage optimization. | 13:50 |
| bob2 | sounds about equivalent to co's bound to a shared repo? | 13:51 |
| schierbeck | jelmer: for now i'll go with "claims to fix", as we don't really know | 13:52 |
| abentley | Well, stacked could let you create a checkout of emacs without downloading all its revisions. And diff/status would be zippy. But log would not be. | 13:54 |
| bob2 | ah, of course | 13:56 |
| jelmer | schierbeck: yeah, claims to fix sounds fine | 14:04 |
| abentley | In a true shallow checkout, non-local revisions would be handled as ghosts, so log would be speedy but short. | 14:06 |
| bronger | Is "bzr branch" identical to "bzr init" + "bzr pull"? | 14:07 |
| fog | re | 14:11 |
| TFKyle | bronger: I wouldn't think so, but I could be wrong | 14:12 |
| gioele | hello | 14:21 |
| bronger | The background of my question is: If I want to update a remote SVN repo, I can create a branch of it locally, merge the new changes and pull it back. Would it be different in any way if I pulled it to an empty revisioned directory first? | 14:21 |
| bronger | Sorry "... push it back" | 14:22 |
| gioele | what is a "submit branch"? | 14:28 |
| gioele | is it another name for a "push branch"? | 14:28 |
| bronger | gioele: It may also mean a commit in the branch is bound. | 14:31 |
| bronger | "... if the branch is bound" | 14:32 |
| === kiko-zzz is now known as kiko | ||
| gioele | bronger: bzr info in a bound branch (a checkout) says | 14:33 |
| gioele | Location: | 14:33 |
| gioele | light checkout root: . | 14:33 |
| gioele | checkout of branch: http://... | 14:33 |
| gioele | is that the submit branch? | 14:33 |
| james_w | bronger: init + pull is the same as branch, yes. | 14:35 |
| gioele | ah, the submit branch is the location where "bzr send" sends changes | 14:36 |
| bronger | james_w: Thank you! | 14:43 |
| gioele | is there a revspec with the meaning "last time it was changed"? | 14:45 |
| gioele | For example, current revision is 20 and file foo has been modified at revision 12 and 8. Is there a revspec that I can use instead of 12 and 8 in "bzr diff -r 8..12 foo" | 14:45 |
| Peng | That would be useful, but I don't know of one. | 14:46 |
| Peng | The docs list all the types of revspecs. | 14:46 |
| * Peng goes back to bed. | 14:46 | |
| schierbeck | jelmer: ping | 14:47 |
| jelmer | schierbeck: pong | 14:47 |
| schierbeck | jelmer: do you think we should rename the "Signature" tab to "Authenticity"? | 14:47 |
| james_w | gioele: I don't think there is one. | 14:47 |
| schierbeck | after all, that's really all it's about | 14:47 |
| jelmer | schierbeck: We need to verify the testament first | 14:49 |
| jelmer | schierbeck: but otherwise, sounds fine to me | 14:49 |
| schierbeck | jelmer: yeah, i was gonna ask that, too | 14:51 |
| antoranz | Hi, guys! | 15:10 |
| mw-home | morning | 15:11 |
| antoranz | I was merging the changes from another branch yesterday (both local FS branches) and I got an error and don't know if It's a bug in bazaar | 15:11 |
| antoranz | I had made a post in linuxquestions but nobody replyed to it, that's why I looked if there was an IRC channel... and so I'm here. | 15:12 |
| gioele | antoranz: link? | 15:13 |
| antoranz | the post is here: http://www.linuxquestions.org/questions/linux-software-2/problem-with-bazaar-632262/ | 15:13 |
| bob2 | in future, I'd say that posting to the list is a lot more likely to find someone who knows bzr thatn linuxquestions :) | 15:13 |
| gioele | list = mailing list on bazaar-vcs.org | 15:13 |
| antoranz | k | 15:14 |
| bob2 | someone reported almost that exact error yesterday | 15:14 |
| bob2 | bzr in gutsy? | 15:14 |
| antoranz | mmm........... yes, it's gutsy | 15:14 |
| gioele | I think this deserves a bug at https://bugs.launchpad.net/bzr/+filebug | 15:16 |
| === mw|out is now known as mw | ||
| james_w | there's already a bug for it I think | 15:17 |
| bob2 | try upgrading (add 'deb http://ppa.launchpad.net/bzr/ubuntu gutsy main' to /etc/apt/sources.list, 'sudo aptitude update', 'sudo aptitude dist-upgrade') | 15:18 |
| james_w | I don't think it's fixed | 15:18 |
| bob2 | ah, ok | 15:18 |
| bob2 | I forget the conversation yesterday, but did -q workaround? | 15:19 |
| antoranz | what's the problem? My use of "á" in the directory name or something? | 15:19 |
| antoranz | cause I haven't had a problem so far with it in the branch where I created it committing to it. | 15:19 |
| antoranz | is that repository stable? | 15:20 |
| james_w | bob2: I think this is a different location to yesterday's | 15:21 |
| james_w | https://bugs.edge.launchpad.net/bzr/+bug/135320 | 15:22 |
| ubotu | Launchpad bug 135320 in bzr "bzr merge - exceptions.UnicodeDecodeError" [Undecided,New] | 15:22 |
| antoranz | I'll append my info to that bug. | 15:23 |
| antoranz | The bug a little old though | 15:28 |
| antoranz | anyway... I've already appended my trace to it. | 15:29 |
| gioele | How do you debug bzr plugins? | 15:30 |
| gioele | Is there a way to make the plugin hook the eric debugger at a certain point? Any other IDE is OK | 15:30 |
| antoranz | I'll try changing the name of the directory to see what happens | 15:31 |
| antoranz | F***! It failed when I tried to commit the mv | 15:32 |
| antoranz | all I did was: $ bzr mv doc/Cities/Bogotá/ doc/Cities/Bogota | 15:33 |
| ignas | Peng: by the way - if 70 mb is not much, why is it taking ~30 minutes or more tu make a branch :/ how long does it take with "much" ;) | 15:38 |
| james_w | antoranz: can you pastebin the traceback you get for that please? | 15:39 |
| james_w | gioele: what I normally do is edit the source and add "import pdb; pdb.set_trace()" where I want it | 15:40 |
| james_w | if the problem is a plugin not loading then ~/.bzr.log will have the error. | 15:40 |
| antoranz | sure | 15:40 |
| gioele | james_w: is there an API documentatio for bzrlib? | 15:41 |
| antoranz | I'm filling for a new bug including both bugs in https://bugs.launchpad.net/bzr/+filebug. Want to see it? | 15:41 |
| james_w | gioele: sort of yes | 15:41 |
| antoranz | Here it is: https://bugs.launchpad.net/bzr/+bug/210838 | 15:42 |
| ubotu | Launchpad bug 210838 in bzr "Problems with non-ascii characteres in names" [Undecided,New] | 15:42 |
| james_w | http://starship.python.net/crew/mwh/bzrlibapi/ | 15:42 |
| antoranz | that was fast! :-D | 15:42 |
| james_w | there's also http://bazaar-vcs.org/Integrating_with_Bazaar | 15:42 |
| james_w | antoranz: he responds to what you say | 15:43 |
| james_w | they'll be the new bug notification in a minute or two | 15:43 |
| bob2 | ignas: btw, cp -r is a valid way to branch a standalone branch to anothoer standalone branch | 15:44 |
| ignas | bob2: i know, but cp -r does not work if your branch is on launchpad | 15:45 |
| bob2 | ah | 15:45 |
| antoranz | ignas: that was good! | 15:45 |
| ubotu | New bug: #210838 in bzr "Problems with non-ascii characteres in names" [Undecided,New] https://launchpad.net/bugs/210838 | 15:51 |
| antoranz | I'll try the repository you provided mye with... hold on to your butts. :-) | 15:55 |
| antoranz | hell! I tried to commit just like that and it "added" the directory (didn't move it) | 15:58 |
| antoranz | I just checked the repository and I have 5 inconsistent parents | 15:59 |
| antoranz | how do I get rid of those "parents"? | 16:00 |
| schierbeck | jelmer: what do you think about a "Tags" page in the revision view? i think it would boost the discoverability. | 16:05 |
| schierbeck | i know they belong in the branch, but to the user who wants to add a tag to a revision, it's natural to select that revision in the viz and go from there. | 16:05 |
| jelmer | schierbeck: tags are already shown in the revisionview, in the main tab | 16:06 |
| schierbeck | jelmer: yeah, but i'm thinking more like a treeview, where you can "rename" and add tags | 16:06 |
| antoranz | can I delete .bzr/branch/lock so I get rid of the lock on the repository? | 16:07 |
| schierbeck | jelmer: the current ui doesn't allow for deleting tags in the revisionview | 16:07 |
| antoranz | I've already done it, so I think it's safe, right? | 16:07 |
| jelmer | schierbeck: yeah, makes sense | 16:08 |
| schierbeck | jelmer: let's get the bugs and signature page branches merged first, then i'll refactor the revision view and go from there | 16:08 |
| abentley | antoranz: You're supposed to use the bread-lock command. | 16:09 |
| schierbeck | jelmer: do you think there's anything missing from those two branches? i've already sent a mail to the tag icon artist | 16:09 |
| antoranz | I've should know better, wasn0't I? after I removed the lock (by deleting, by the way :(), I was able to commit into the stable branch even with the names with non-ascii characters | 16:10 |
| antoranz | my godness... what a gramatical mess did I write! :-D | 16:10 |
| jelmer | schierbeck: the signatures branch disables the signature tab | 16:10 |
| jelmer | schierbeck: but that still says "this revision has one or more signatuers" | 16:10 |
| schierbeck | schierbeck: huh? | 16:11 |
| jelmer | schierbeck: that's all I can think of right now | 16:11 |
| schierbeck | jelmer: the seahorse-integration branch? | 16:11 |
| schierbeck | i think that's the one we should ship | 16:11 |
| antoranz | I think my repository got completely busted (both the stable and the development one... as a matter of fact, I deleted the developemt one and can't branch from the stable) | 16:17 |
| antoranz | I just noticed I lost quite some hours of work goys | 16:18 |
| antoranz | say-.... 2 days of work | 16:20 |
| kohwj | hi, can i get bzr serve to prompt clients for a password? | 16:21 |
| antoranz | there's something strange going on here. | 16:23 |
| antoranz | I was able to commit the changes brought from the development branch in the stable branch.... I can see the diffs applied | 16:24 |
| antoranz | however, there are not "efective" in the physical files of the stable repository | 16:25 |
| antoranz | they, I mean | 16:25 |
| schierbeck | jelmer: okay, i've sent in the merge requests | 16:46 |
| schierbeck | once they're approved, i'll start refactoring the revision view | 16:47 |
| gioele | schierbeck: olive? gtk? | 16:48 |
| schierbeck | gioele: bzr-gtk | 16:49 |
| schierbeck | the bottom part of the viz | 16:49 |
| gioele | I love viz | 16:50 |
| gioele | How do I get the arguments passed to bzr from my RevisionSpec? | 16:51 |
| ignas | why is bzr push to a remote repository is a mega pain? and what should I do instead? | 16:52 |
| snod | unter linux siehts auf jeden fall anders aus | 16:53 |
| snod | fc | 16:53 |
| ignas | i checkout the "trunk", checkout the branch, bzr merge the branch into the trunk, and am trying to bzr push the mainline back so everyone (especially our mega release tools) would see the changes... | 16:53 |
| ignas | bzr push seems to be taking ages | 16:53 |
| ignas | even though there was only 1 small change made to the trunk | 16:54 |
| bob2 | are they the same branch formats (should be unless you use a shared repo) | 16:58 |
| ignas | hmm, ok it seems that it was taking so long because it was synchronizing the fact that i have enabled tags on the remote repository | 16:58 |
| ignas | i am using a shared repository | 16:58 |
| ignas | for my remote branch | 16:59 |
| ignas | because all the release branches will be stored in the same location | 16:59 |
| ignas | but yes, now that the first push got through it is bearable (takes only 10-20 seconds) | 16:59 |
| ignas | what can I do about "Value "bzr+ssh://schooltool.org/var/local/bzr/schooltool/lyceum/trunk/" is masked by "bzr+ssh://bazaar.launchpad.net/%7Eignas/schooltool/lyceum/" from locations.conf"? | 17:02 |
| ignas | and where is that locations.conf thing? | 17:03 |
| ignas | i have tried doing "bzr push --remember bzr+ssh://schooltool.org/var/local/bzr/schooltool/lyceum/trunk/" | 17:03 |
| === kiko is now known as kiko-afk | ||
| gioele | ~/.bazaar/locations.conf | 17:06 |
| * gioele wonders when bzr will conform to XDG Base Dir spec | 17:07 | |
| ignas | emm, why is it there? and why is it overriding parameters i am passing through command line? | 17:08 |
| ignas | i mean - maybe there is a reason, and i am doing something wrong... | 17:08 |
| gioele | that file is used for the parameters that you didn't specify on the cmd line | 17:08 |
| ignas | so when i do "bzr info" | 17:09 |
| ignas | paths are taken from that file | 17:09 |
| ignas | not from some place in .bzr ? | 17:09 |
| luks | ignas: old branch formats used to save it to locations.conf, new formats use .bzr/branch/branch.conf | 17:09 |
| ignas | oh, i see | 17:09 |
| ignas | so i should upgrade my branch and remove that file? | 17:09 |
| luks | if it was complaining about masked location, your branch is probably already upgraded | 17:10 |
| luks | you can just remove the branch from locations.conf | 17:10 |
| ignas | ok | 17:11 |
| schierbeck | jelmer: ping | 17:24 |
| jelmer | schierbeck: hi | 17:24 |
| schierbeck | jelmer: i've got permission to use the tag icon | 17:25 |
| jelmer | cool | 17:25 |
| schierbeck | can i get you to review the merge request? | 17:25 |
| jelmer | yeah, just give me a few minutes | 17:25 |
| schierbeck | okay | 17:25 |
| ignas | how do i convert a branch into a checkout? | 17:27 |
| schierbeck | ignas: bzr help bind | 17:28 |
| ignas | schierbeck: thanks | 17:29 |
| === schierbeck is now known as schierbeck_afk | ||
| === Peng__ is now known as Peng_ | ||
| eddyMul | how do I "un-add" files? | 18:21 |
| antoranz | revert | 18:26 |
| eddyMul | antoranz: ah! thanx! | 18:26 |
| antoranz | if you haven't commited | 18:26 |
| eddyMul | antoranz: no, I haven't. :) | 18:27 |
| antoranz | there you go then. | 18:28 |
| === weigon_ is now known as weigon | ||
| gioele | hello | 19:00 |
| gioele | does the mailing list accept mails from Gmane? | 19:01 |
| ubotu | New bug: #210938 in bzr "bzr status -v should show also non-modified files" [Undecided,New] https://launchpad.net/bugs/210938 | 19:16 |
| james_w | gioele: I don't know. The list is moderated, so it might be that. | 19:29 |
| gioele | james_w: no, it passed fine. Maybe Gmane is a bit slow today | 19:36 |
| === mw is now known as mw|food | ||
| james_w | ah, ok | 19:39 |
| bialix | hi, I have question about merge.py | 20:02 |
| bialix | abentley, may I ask you about merge.py? | 20:05 |
| abentley | Sure. | 20:05 |
| bialix | there is Merger, Merge3Merger and others | 20:06 |
| bialix | it seems like Merger is main of them | 20:06 |
| bialix | it's correct? | 20:06 |
| abentley | Yes. It's been suggested that Merger should be renamed to MergeController. | 20:06 |
| bialix | so, it's always created Merger instance for merge operations? | 20:07 |
| abentley | Yes. It's not required, but I believe all callers do go through Merger. | 20:08 |
| bialix | my actual question is: where I should put my code for support merge of file properties | 20:08 |
| === mw|food is now known as mw | ||
| bialix | is it Merger correct place, or Merge3Merger? | 20:09 |
| abentley | Probably in Merge3Merger. | 20:09 |
| bialix | i.e. actual merge done in Merge3Merger, right? | 20:09 |
| abentley | Yes, the actual operation is handled by Merge3Merger or a subclass. | 20:10 |
| bialix | all other merge types is subclased Merge3 as I could see. | 20:11 |
| abentley | Right. | 20:11 |
| bialix | okay, thank you. | 20:11 |
| abentley | np | 20:12 |
| === kiko-afk is now known as kiko | ||
| Verterok | moin | 20:17 |
| abentley | eddyMul: More specifically, you use "bzr remove --keep --new". That will avoid reverting any other changes. | 20:19 |
| eddyMul | abentley: I used `bzr revert specific_files`, and it worked for me. | 20:23 |
| eddyMul | abentley: judging from `bzr help remove`, it appears like `bzr remove --keep --new` is the like the "anti" of `bzr add`. Very handy. Thanx! | 20:24 |
| abentley | np | 20:24 |
| james_w | hi bialix, Verterok | 20:31 |
| bialix | hi james_w | 20:32 |
| james_w | bialix: sorry I haven't had a chance to look over your file properties mail yet | 20:32 |
| bialix | it seems like nobody have this chance yet | 20:33 |
| bialix | there was a lot of people who cry without line-endings support | 20:33 |
| Verterok | james_w: hi | 20:33 |
| james_w | bialix: yeah, it would be great to have. | 20:33 |
| bialix | they already worked | 20:34 |
| bialix | I need only to beat merge and to teach it write files to disk with proper eol | 20:36 |
| bialix | abentley: Merge3Merger.__init__: has arguments working_tree, this_tree, base_tree, other_tree -- what's difference between working_tree and this_tree? it's not the same? | 20:39 |
| abentley | this_tree is the input tree that you read from in order to calculate the merge. working_tree is the output tree that you write the changes to. | 20:41 |
| abentley | They are commonly the same, but this_tree is sometimes a RevisionTree. | 20:41 |
| bialix | in which case? | 20:42 |
| bialix | I see in constructor's code: self.this_tree = working_tree | 20:46 |
| bialix | and it seems like this_tree argument is not used actually | 20:46 |
| bialix | so I'll ignore it. | 20:46 |
| abentley | Don't be a jerk. | 20:49 |
| james_w | abentley: as far as I can see the "this_tree" argument to Merge3Merger is not used in Merge3Merger.__init__, and none of the subclasses in the same file override __init__. | 20:55 |
| db-keen | Why can't I bzr mv from one branch in a repository to another? | 20:55 |
| james_w | so is it just there in case a subclass wants to? | 20:56 |
| mwhudson | db-keen: because bzr is not like subversion? | 20:56 |
| abentley | james_w: WeaveMerger used to do that, and future mergers may also do that. It's quite likely to be a performance win. | 20:56 |
| james_w | ah, ok, thanks | 20:56 |
| === Toksyuryel` is now known as Toksyuryel | ||
| poolie | db-keen: well it's more complicated for us than for svn | 20:56 |
| poolie | we should make it possible | 20:56 |
| gioele | is there a way to have "external" branches inside a branch? | 20:56 |
| james_w | abentley: I think your reaction might have been a bit strong then, but maybe I misread it | 20:57 |
| db-keen | I'm trying to take a project and split it into smaller branches, what's the best way to do this? | 20:57 |
| james_w | db-keen: are you splitting on directory boundaries? | 20:58 |
| abentley | james_w: If writes to this_tree or reads from working_tree, I'll veto his patch so fast his teeth will shake. | 20:58 |
| db-keen | my initial reaction was to create new branches and move stuff from the old large one into these new small ones, but obviously that doesn't work | 20:58 |
| db-keen | james_w: mostly | 20:58 |
| james_w | db-keen: there's a split command that may help | 20:59 |
| james_w | abentley: but the default mergers read from working_tree? | 20:59 |
| abentley | No | 20:59 |
| abentley | They read from this_tree | 20:59 |
| james_w | abentley: they read from self.this_tree, which working_tree is assigned to in the constructor | 21:00 |
| abentley | which is entirely different. | 21:01 |
| poolie | thumper: hi, are we meeting now? | 21:02 |
| thumper | poolie: yeah | 21:02 |
| james_w | abentley: well, I don't still fully understand, even with the extra discussion, so I still think your response was too strong. | 21:02 |
| abentley | james_w: think what you like. When people ask me for advice, I expect them not to ignore it. | 21:06 |
| dato | james_w: I guess that the API/contract is that you read from this_tree, without caring what gets assigned to it before. or so. from my limited understanding. :) | 21:08 |
| abentley | They may decide that they don't agree, or that it doesn't apply. But it's not okay if they just ignore it. | 21:08 |
| james_w | I read his statement as ignoring this_tree, just like the existing code does, not ignoring your answer, but I don't know what he meant | 21:09 |
| abentley | The existing code does not ignore this_tree. | 21:10 |
| james_w | maybe I am wrong to say ignore, but the this_tree parameter passed to Merge3Merge.__init__ is unused as far as I can see. This may well be because working_tree fulfils the contract of this code just as well as this_tree. | 21:14 |
| abentley | We're not talking about constructors, so when you say this_tree, I assume you mean self.this_tree | 21:20 |
| james_w | sorry for the misunderstanding then, I tried to be clear that I was talking about this_tree passed to the constructor as opposed to self.this_tree | 21:23 |
| abentley | So it looks like the Merge3Merge constructor is a bit broken. | 21:25 |
| hmeland_ | Regarding the "fix botched log-message" discussion: Does any of the storage mechanisms actually have an API for "turn revision X into a ghost"? | 21:26 |
| abentley | It's probably due to the shuffling around we did to enable merge previews. | 21:26 |
| abentley | hmeland_: No, all of our formats are append-only. | 21:26 |
| abentley | You would need to create a new repository, and not add those revisions. | 21:27 |
| hmeland_ | Right. | 21:27 |
| hmeland_ | In principle you could repair revision X by adding a X' (which has X and the parent(s) of X as its parents) with the fix, convert X into a ghost, and repeat for all revisions that are descendants of X. | 21:32 |
| hmeland_ | But without an easy way to do the "convert X into a ghost" step, that sounds somewhat cumbersome. | 21:33 |
| hmeland_ | The approach might also have bad (performance) implications for e.g. merge, especially if such fixing were to be as common as I gather git's "commit --amend" is. | 21:35 |
| james_w | "commit --amend" only works for the tip of the branch, and is another form of rebase. | 21:37 |
| hmeland_ | Ah, good. | 21:37 |
| james_w | I think there are two cases being discussed, one is the "nuclear launch codes" and the "abusive commit message" case, and the other is the "spelling mistake case" | 21:38 |
| dato | "abusive commit message"? | 21:39 |
| james_w | the latter could be solved by just adding a note somewhere saying "when displaying it, set the message of X to Y" | 21:39 |
| james_w | dato: it's an example from the list of where there was evidence of sexual harrasment in a commit message. | 21:39 |
| dato | oh, wow, I missed that | 21:39 |
| hmeland_ | james_w: I think *abusive* commit message is a form of nuclear launch codes, actually. | 21:40 |
| james_w | hmeland_: yes, it is, but I was just using the two examples from the list discussion. | 21:40 |
| hmeland_ | OTOH, an *incorrect* commit message might be solvable in the way you describe. | 21:40 |
| james_w | for the former you need to remove X from history so that it is unreachable. | 21:41 |
| james_w | so this could either be a rebase type operation, or introducing a ghost, both of which have their issues. | 21:41 |
| hmeland_ | Yes. Both NLC and ACM goes in the former category, to my mind. | 21:42 |
| hmeland_ | The nice thing about the ghost-introduction solution is that other existing branches would still be related to the original branch. | 21:43 |
| james_w | exactly | 21:43 |
| hmeland_ | You might have to take care that merges from any such branches didn't re-introduce the ghosted revisions, though. | 21:44 |
| james_w | however, currently ghosts have no information whatsoever, not even their parents, which means that you can't get at the history previous to the ghost. | 21:44 |
| james_w | and it would also be information disclosure, which some people in some circumstances wouldn't accept. | 21:45 |
| === schierbeck_afk is now known as schierbeck | ||
| hmeland_ | If you branched from revision Y, which has now been converted into a ghost, there will be a new revision Y' in the source branch, whose mainline history will take you all the way back to before the fixed revisions. | 21:46 |
| james_w | hmeland_: no, when you branch you are based of Y still | 21:47 |
| james_w | it's not like svn where you have to make a commit to start a branch. | 21:47 |
| james_w | but you are right, I think care would have to be taken not to get unwanted ghosts again when merging. | 21:47 |
| hmeland_ | Yes, that's what I'm saying. In the *source* branch there will be a Y'. | 21:47 |
| james_w | hmeland_: ah, in your proposal for creating Y' from Y, sorry | 21:48 |
| james_w | there would be the peverse case where you made Y a plain ghost, as now you can't do 3 way merging as you can't get the text from the base revision. | 21:49 |
| lifeless | hmeland_: the conversion of X's descendants to X''s descendants will not propogate | 21:52 |
| hmeland_ | james_w: Right, you'd have to pull before merging, I think. | 21:52 |
| hmeland_ | lifeless: In the case of multiple fixes, you mean? | 21:53 |
| hmeland_ | X' will have (X + parents(X)) as parents. X'' will have (X' + parents(X')) as parents. | 21:54 |
| james_w | hmeland_: you can't pull before merging, if you have diverged then pulling is not allowed. | 21:54 |
| james_w | hi lifeless | 21:54 |
| lifeless | hi james_w | 21:54 |
| lifeless | hmeland_: no, I mean in the case of having more than one repository which needs the correction done | 21:55 |
| lifeless | hmeland_: all other repositories will have the original X as their semi-ultimate descendant | 21:55 |
| hmeland_ | Not X, but the tip of the branch X was in when X was fixed, I think? | 22:00 |
| hmeland_ | But yes, ghosts do not propagate. | 22:00 |
| schierbeck | jelmer: ping | 22:04 |
| jelmer | schierbeck: pong | 22:04 |
| schierbeck | I've fixed the remaining issues with the Seahorse integration branch, and I've sent in an updated merge request. Could I get you to take a look at it? | 22:05 |
| lifeless | hmeland_: and neither does the conversion to 'fixed' revisions, only the ones actually fixed will propogate | 22:11 |
| schierbeck | wow, apparently you can be allergic to electricity... | 22:15 |
| schierbeck | that's pretty f****d up! | 22:15 |
| jelmer | schierbeck: Iyou don't appear to be catching the errors if there is no seahorse interface | 22:17 |
| schierbeck | jelmer: have you tested it? i check for the seahorse service name | 22:19 |
| schierbeck | if seahorse is installed, the object paths and interfaces should be there | 22:19 |
| schierbeck | it worked when i uninstalled seahorse... | 22:19 |
| hmeland_ | lifeless: Assuming a mainline-only history: If you actually fix revision 2 by introducing 2' (with 2 (now ghosted) and 1 as parents), and "fix" revision 3 by introducing 3' (with 3 (now ghosted) and 2' as parents), wouldn't a branch at e.g. 3 doing a pull cause both 2' and 3' to propagate? | 22:20 |
| jelmer | schierbeck: ah, I missed that - sorry | 22:20 |
| schierbeck | jelmer: :) | 22:20 |
| jelmer | schierbeck: any chance you can make two more changes? | 22:20 |
| jelmer | schierbeck: I'll reply to the email | 22:21 |
| schierbeck | jelmer: which? | 22:21 |
| schierbeck | ok | 22:21 |
| lifeless | hmeland_: a new branch from 3' will take 3' of course. But *all* the other existing branches won't be fixed. | 22:27 |
| james_w | I think the suggestion is to mark some ghosts as propagating, so the next merge or pull will fix them | 22:28 |
| hmeland_ | james_w: That's not what I'm suggesting; I'm just trying to understand if the algorithm I suggested above might be a viable starting point for the requested functionality. | 22:30 |
| james_w | ah, ok, sorry | 22:31 |
| lifeless | the general thing here is that revisions are immutable | 22:31 |
| lifeless | having efficient, safe trustable mutable revisions is possible, buts its a lot of complexity | 22:32 |
| lifeless | you basically need a meta-timeline for versioning revisions too | 22:32 |
| hmeland_ | If you the requires-fixing revision is present in branches you don't control, I'm leery of trying to propagate the fix to them automatically. | 22:32 |
| hmeland_ | lifeless: Yeah. So I'm trying to see whether the "convert to ghost and add alternative timeline" approach could get us at least some of the benefits without all the complexity. | 22:37 |
| hmeland_ | Anyway, thanks for the input, I guess I'll sleep on it and see if I can come up with something. | 22:40 |
| xma | 'lo #bzr | 22:52 |
| lifeless | hi | 22:55 |
| schierbeck | jelmer: okay, i've sent in yet another iteration | 22:55 |
| schierbeck | i've also contacted the author of the bug icon | 22:56 |
| jelmer | schierbeck: ah, thanks | 23:02 |
| jelmer | schierbeck: (wasn't strictly necessary btw, I voted bb:tweak) | 23:02 |
| xma | is it me or the proportion for BB to be unavailable is increasing day after day ? | 23:04 |
| jelmer | it's been months since I've seen bundlebuggy downtime for bzr.dev | 23:05 |
| igc | morning | 23:14 |
| yacc | Hmmm, does anyone maintain a bzr branch of the current Python code? | 23:15 |
| yacc | I'm not completly sure if branching the svn URL would be a very enjoyable experience. | 23:15 |
| jelmer | yacc: it's not too bad with 0.4.9 | 23:17 |
| radix | yacc: you mean CPython? I'm pretty sure I've heard others talking about such a thing, but I'm not sure where. | 23:20 |
| mwhudson | yacc: you mean like http://www.python.org/dev/bazaar/ ? | 23:20 |
| yacc | jelmer: you are trying to sell me on going back to using a released version of bzr-svn ;) | 23:25 |
| jelmer | yacc: :-) | 23:26 |
| jelmer | yacc: If performance or reliability matters to you, you should be using a release | 23:26 |
| jelmer | performance certainly matters for the python repo, given its size | 23:26 |
| yacc | jelmer: does it support bzr 1.3? | 23:26 |
| jelmer | yacc: yep | 23:26 |
| yacc | jelmer: And I ended up using a trunk scheme, so I guess this should work too? | 23:27 |
| bob2 | yacc: http://www.python.org/dev/bazaar/ | 23:27 |
| jelmer | yacc: yep | 23:28 |
| bob2 | oh, oops, too slow | 23:28 |
| mwhudson | bob2: well, maybe he'll tell _you_ why that isn't what he wants :) | 23:37 |
| jelmer | bob2: what's too slow? | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!