| igc | morning all | 00:38 |
|---|---|---|
| jelmer | hi Ian | 00:42 |
| jelmer | lifeless: it looks ok, but it seems like the check patch is significantly changeed, not just polished? | 00:42 |
| igc | hi jelmer. Thanks that your reviews over the weekend. Much appreciated | 00:43 |
| igc | morning lifeless | 00:43 |
| jelmer | igc: svn-keywords is already partially working :-) | 00:44 |
| igc | jelmer: I'm actually keen to get bzr-keywords into the core as well, so you can assume that code is there and build on it | 00:44 |
| igc | jelmer: now that the fallback bit is in place, you'll only need to register how to expand the keywords I think | 00:45 |
| igc | jelmer: and you get the sweet publishing features in bzr-keywords for free as well | 00:45 |
| igc | next weekend maybe :-) | 00:46 |
| stbuehler | jelmer: saw my feedback for svn / dpush ? | 00:47 |
| jelmer | stbuehler: hi | 00:47 |
| jelmer | stbuehler: where? | 00:47 |
| jelmer | (I haven't seen anything yet) | 00:47 |
| stbuehler | jelmer: just wanted to give some feedback: bzr dpush does *not* give you the svn-revisions back, even if you had new commits pushed to upstream svn | 00:48 |
| stbuehler | perhaps that works if you never used the normal push, didn't try that | 00:49 |
| stbuehler | seems like i cannot force bzr to rebase to the svn branch | 00:49 |
| jelmer | stbuehler: no, it doesn't as that would require changing existing revisions; we can keep a map though and display that sort of information | 00:50 |
| lifeless | jelmer: yes, 0.9.5 to 0.9.6 added a special linker script | 00:51 |
| stbuehler | i wouldn't mind changing them, if it where an option :) | 00:51 |
| jelmer | stbuehler: can you please file a bug report about this? I'll try to get it fixed for the next version | 00:52 |
| stbuehler | jelmer: so dpush should change existing revisions? k, let me try :) | 00:53 |
| jelmer | stbuehler: yeah, dpush basically pushes all revisions into the remote repository | 00:54 |
| jelmer | stbuehler: and then fetches the revisions that were created remotely and overwrites the local revisions with them | 00:55 |
| jelmer | stbuehler: push (by definition) only changes the remote revision | 00:58 |
| jelmer | s/revision/branch/ | 00:58 |
| stbuehler | yes, that is perfectly valid :) | 00:59 |
| lifeless | jelmer: the 0.9.6 patch is polish from the subunit point of view, its just updating against the check project | 01:02 |
| jelmer | stbuehler: oh, maybe I misunderstood | 01:18 |
| jelmer | stbuehler: dpush won't change any previously "bzr push"'ed revisions of course | 01:18 |
| jelmer | it only affects revisions not yet in svn in any form | 01:19 |
| stbuehler | i mentioned i "dpush"ed new commits, which were not in svn | 01:23 |
| stbuehler | but maybe it only works if you never used "push" | 01:23 |
| jelmer | stbuehler: sorry | 01:24 |
| jelmer | stbuehler: it should work fine if older revisions were pushed | 01:25 |
| jelmer | stbuehler: is this repo public? | 01:25 |
| stbuehler | svn://svn.lighttpd.net/spawn-fcgi/trunk | 01:25 |
| jelmer | thanks | 01:26 |
| jelmer | stbuehler: ok, I figured out what's happening, this shouldn't be too hard to fix | 01:28 |
| jelmer | lifeless: btw, I hope to split out libtorture from samba at some point | 01:47 |
| jelmer | so we can use that in bitlbee, ctrlproxy, etc in favor of libcheck | 01:48 |
| lifeless | jelmer: thats your C testing infrastructure? | 01:48 |
| jelmer | lifeless: yep | 01:48 |
| jelmer | it already does subunit | 01:48 |
| lifeless | jelmer: I'd be inclined to put patches into libcheck, the fork isolation really is nice | 01:48 |
| jelmer | lifeless: is there any chance of your subunit patch actually making it into libcheck? | 01:49 |
| lifeless | jelmer: yes | 01:49 |
| lifeless | I've resubmitted it, chris pickett has ack'd that they were being overly nitpicky | 01:50 |
| jelmer | hmm | 01:51 |
| lifeless | entry point to the recent dicussion http://sourceforge.net/mailarchive/message.php?msg_name=1235597368.24285.63.camel%40lifeless-64 | 01:54 |
| lifeless | its a terrible list archive ui | 01:54 |
| jelmer | ah, cool | 01:59 |
| jelmer | bleh, sf svn is still slow :-( | 02:24 |
| jelmer | lifeless: you are using bzr-svn for check development, right ? >-) | 02:24 |
| lifeless | jelmer: yes, do you want me to push trunk in bzr format somewhere? | 02:24 |
| jelmer | lifeless: yes, if it's not too much trouble | 02:25 |
| lifeless | sure thing | 02:25 |
| jelmer | I can do a pull myself, but it looks like it's going to take at least 30 min at this rate.. | 02:26 |
| lifeless | there is a https://code.edge.launchpad.net/~vcs-imports/check/trunk :) | 02:27 |
| jelmer | lifeless: except that imports from CVS, and hasn't been updated since 2005 :-) | 02:28 |
| lifeless | heh. we should redirect it then :) . bzr+ssh://bazaar.launchpad.net/%7Elifeless/check/svn | 02:29 |
| lifeless | pushing my subunit branch now | 02:29 |
| jelmer | lifeless: thanks | 02:30 |
| lifeless | jelmer: bzr+ssh://bazaar.launchpad.net/~lifeless/check/subunit | 02:32 |
| jelmer | got it | 02:34 |
| jelmer | did launchpad just upgrade to 1.13 or something? | 02:34 |
| lifeless | not for 2 more days | 02:34 |
| jelmer | it's too freakishly fast all of a sudden | 02:35 |
| spiv | Last week bzr.dev got a fix for a performance bug when pushing to pre-1.13 servers, maybe it's that? | 02:38 |
| lifeless | I think jelmer was pulling :) | 02:38 |
| jelmer | well, pushing was the main thing that got faster | 02:39 |
| jelmer | I pushed a 130Mb repo to lp in < 1m | 02:39 |
| lifeless | that would be spiv's fix | 02:42 |
| spiv | :) | 02:45 |
| lifeless | lunch, back soon | 03:25 |
| jml | lifeless: the only subunit branch up for review I see is https://code.edge.launchpad.net/~radix/subunit/report-errors-better/+merge/4292 | 03:42 |
| lifeless | jml: jelmer reviewed the polish branch | 03:42 |
| jml | oh cool. | 03:42 |
| === timchen1` is now known as nasloc__ | ||
| lifeless | jml: if you didn't get notice about the subunit branch, are you subscribed appropriately to trunk ? | 04:02 |
| thumper | lifeless: what would cause a knit to become corrupt and raise SHA1KnitCorrupt when calling show_log? | 04:25 |
| lifeless | an actual knit? | 04:26 |
| lifeless | or something in a pack? | 04:26 |
| lifeless | thumper: ^ | 04:30 |
| ovnicraft | hi folks. is it posible configure bzr with emacs to commit comments? | 04:34 |
| bob2 | ovnicraft: recent emacs has vc-bzr built in | 04:43 |
| * igc lunch | 04:47 | |
| ovnicraft | bob2, yep i got it thx | 04:52 |
| beuno | igc, hi | 04:57 |
| beuno | I was looking at your mergeline cache RFC supersede your plugin? | 04:58 |
| lifeless | tracked down the commit failure | 05:01 |
| lifeless | [bah] | 05:02 |
| igc | hi beuno | 05:25 |
| beuno | hey igc | 05:31 |
| beuno | how are you? | 05:32 |
| igc | beuno: flat out - trying hard to make our next-gen the best it can be | 05:33 |
| igc | beuno: no, it doesn't supercede it - it helps it though | 05:34 |
| beuno | igc, I've seen. It's impressive work | 05:34 |
| beuno | ok, good, because I was about to spend the weekend working on loggerhead + your plugin to get them working well together | 05:35 |
| igc | beuno: there's still a need for caching the full history to make log *really* fast - that the revnocache | 05:35 |
| beuno | I obviously got sidetracked by RL, but was very clse :) | 05:35 |
| beuno | *cloase | 05:35 |
| igc | the mergeline case helps *one* special but importasnt case - lookup of a single non-mainline revno | 05:35 |
| beuno | hotcha | 05:35 |
| beuno | (typing sucking) | 05:36 |
| === abentley1 is now known as abentley | ||
| beuno | I see | 05:36 |
| beuno | brisbane-core is going to rock... | 05:36 |
| fullermd | Hmm. Is there some reason it can't help in other cases? | 05:37 |
| lifeless | igc: a 22K file is quite a lot of data to be updating on push/pull over the wire... I'm inclined to react cautiously and suggest taking the revnocache approach | 05:37 |
| fullermd | I can see that it wouldn't save you any total time on log (since you pull all the info anyway), but wouldn't it let you number and start displaying more quickly? | 05:38 |
| igc | lifeless: it doesn't get updated on push or pull | 05:39 |
| igc | lifeless: only the first time log is used on that remote branch | 05:39 |
| Stanlin | hi | 05:57 |
| lifeless | igc: I don't get the connection between my ocmment and your reply :) | 06:00 |
| Stanlin | May i use BZR with any kind of files? | 06:03 |
| igc | lifeless: log, status and diff are read operations | 06:04 |
| igc | you suggested not updating files during them | 06:05 |
| fullermd | bzr currently maintains an embargo against Cuban and North Korean files... | 06:05 |
| igc | I'm saying "that's the whole basis of the design" | 06:05 |
| igc | I'm now updating the mergeline-store file *outside* the read transaction | 06:05 |
| igc | so I think it's safe | 06:06 |
| igc | given I check the data is still current before saving it | 06:06 |
| igc | and lack of data there is handled without a drama | 06:06 |
| igc | lifeless: make more sense now? | 06:06 |
| igc | lifeless: and sorry if the reply wasc rushed - I'm tired today :-( | 06:07 |
| igc | s/wasc/was/ | 06:07 |
| lifeless | igc: well, its clearly vulnerable to race conditions | 06:10 |
| * fullermd is somewhat uncomfortable on principle with the idea of 'log' writing stuff... | 06:11 | |
| lifeless | igc: I assume I'm not understanding the cache, and I'm really concerned that this is being rushed into - we have only this week to freeze the bbc format, if I remember the dates | 06:11 |
| igc | lifeless: right. fwiw, I'm not doing anything that couldn't work on bzr.dev now - it's not tied to brisbane-core though I'm ok with doing that | 06:13 |
| lifeless | igc: this isn't clearly correct, and has serious potentially serious issues as all caches do. | 06:13 |
| lifeless | not to mention that writing during a read operation is simply impossible on e.g. http:// urls, so its entirely useless there | 06:14 |
| fullermd | Are serious potentially trivial issues more or less hazardous than trivial potentially serious issues? | 06:14 |
| igc | lifeless: true. But the important case if local so we could easily restrict it to that | 06:14 |
| igc | s/if/is/ | 06:14 |
| igc | and remove any network concerns | 06:14 |
| lifeless | igc: I'm finding the discussion hard, it feels like you're presenting this as all-or-nothing, and already-analysed-this-is-right, rather than engaging | 06:15 |
| igc | lifeless: sorry - I'm not meaning to come across like that | 06:15 |
| igc | lifeless: and I'm very interested in how you think it's subject to race conditions and/or ought to proceed | 06:16 |
| lifeless | igc: so as a design principle we are trying to remove all our caches | 06:16 |
| lifeless | for instance, one possible cache that was proposed as an alternative to brisbane-core was to cache inventory deltass in commit objects | 06:17 |
| lifeless | we successfully avoided that while still getting good performance | 06:17 |
| lifeless | which means we get good performance on arbitrary tree deltas rather than only on adjacent ones | 06:17 |
| igc | lifeless: really? That's sounds crazy. Caches are necessarily bad. Even bash has them :-) | 06:18 |
| igc | s/are/aren't/ | 06:18 |
| bob2 | Stanlin: yes | 06:19 |
| lifeless | for this case, I'm interested in: what the root problem is. (is it revnos? is it index performance? something else?) I'm interested in why the operations are faster *overall* with this - what work is it actually saving, and why | 06:19 |
| lifeless | igc: caches increase data storage, add the opportunity for bugs relateed to coherency, increase writes needed and can often reduce performance overall | 06:20 |
| Stanlin | bob2: including graphics and big files?? | 06:20 |
| fullermd | Stanlin: It will _work_ for them (mod performance or memory issues with large files, anyway). Whether it's particularly _useful_ depends on your situation. | 06:21 |
| Stanlin | fullermd: awesome, ok so i can go ahead and use bzr for all my desktop | 06:22 |
| fullermd | If any files are a significant fraction of your available physical memory (ISO's and the like are common offenders), you're likely to hit some unpleasantness. | 06:23 |
| fullermd | And of course a number of operations (like merging) are a lot less useful with binary files. | 06:23 |
| Stanlin | fullermd: well for starters i just want to do it with small documents | 06:23 |
| Stanlin | fullermd: what is the best scenario to , use bzr, as server, and lets all users push and pull, without editors or any control? | 06:24 |
| lifeless | igc: so we really want caches where they really appear to be the best answer, not the first answer. | 06:25 |
| fullermd | Stanlin: That's way too broad a question to answer in general :) | 06:26 |
| lifeless | igc: and this one, given the data I have so far, appears to be the first answer with none of the deep questions answered | 06:26 |
| fullermd | Stanlin: Very dependant on exactly what your situation is. | 06:26 |
| Stanlin | is bzr superior to Git? | 06:27 |
| lifeless | igc: I may well be wrong and have missed the guts of the analysis | 06:27 |
| lifeless | Stanlin: we think so :) | 06:27 |
| fullermd | Yes and No and See Me Next Tuesday. | 06:27 |
| Stanlin | gnight all :D | 06:27 |
| lifeless | woo, faster commit landing | 06:29 |
| * Stanlin performs aptitude remove git | 06:30 | |
| igc | lifeless: it's very early days w.r.t the mergeline cache. It works but that doesn't make it the answer. Please don't reject it on principle though. From *my* analysis, it's the smallest amount of data needed to make some selected use cases perform well. I done lots in work in recent months on stuff like revnocache and this is the only part of that plugin that I've ever thought should go in the core | 06:35 |
| igc | And if it's not core-worthy, it will go into revnocache instead | 06:35 |
| lifeless | igc: I won't reject it on principle; but to put it in core I would want those deeper questions considered | 06:36 |
| igc | lifeless: sure, and I have considered cache currency in the design already, for example | 06:36 |
| lifeless | I need to head off; day is done and all | 06:37 |
| lifeless | http://pqm.bazaar-vcs.org/ | 06:37 |
| lifeless | record-iter-changes commit - landing now | 06:37 |
| igc | lifeless: well done and thanks no the commit stuff | 06:38 |
| igc | s/no/on/ | 06:38 |
| igc | and for playing devil's advocate :-) | 06:39 |
| fullermd | FWIW, I agree in principle too... | 06:40 |
| fullermd | I'd rather see fixable performance issues fixed (even if rather later) than papered over. | 06:40 |
| fullermd | Once papered over, fixes tend to get pushed back a long ways, and even when made, the papering often remains messing things up worse :| | 06:40 |
| fullermd | (this of course expresses no opinion whatsoever on where the current questions falls on that spectrum, since that's all the opinion I'm qualified to express...) | 06:41 |
| igc | fullermd: we currently cache the last revno and last-rev-id for the mainline | 06:43 |
| lifeless | igc: revno is a cache, last-rev-id isn't | 06:43 |
| lifeless | :) | 06:43 |
| * lifeless goes | 06:43 | |
| igc | fullermd: all I'm doing is extending the idea to each "mergeline" so finding a rev-id for x.y.z doesn't require a full graph build | 06:44 |
| fullermd | igc: Convincing me of the fitness or lack thereof of some internal mechanism is kinda wasted effort ;) | 06:45 |
| fullermd | I have pro and con feelings on the issue, but considering how drastically uninformed they are compared to anybody else you talk to about it... | 06:47 |
| igc | fullermd: thanks for the tip. I was being polite and offering an explanation in case you cared :-) | 06:51 |
| fullermd | Oh, I do appreciate that. It's why I'm here and occasionally even pay attention 8-} | 06:54 |
| fullermd | Just that pretty much any insight or judgement that might occur to me, lifeless already thought of 20 minutes before I read any descriptions, and either already brought up or mentally discarded as absurd. | 06:55 |
| vila | hi all | 07:41 |
| Peng_ | Good morning. | 07:42 |
| igc | hi vila | 07:43 |
| thumper | can someone tell me the difference between 1.13 and 1.13.1? | 08:09 |
| thumper | will it matter server side? | 08:09 |
| thumper | should LP use 1.13 or 1.13.1? | 08:09 |
| Peng_ | thumper: Look at the announcement: 1.13.1 fixes a version number mismatch in bzr vs. bzrlib, fixes an error in NEWS (I think), fixes 'merge --force', and bzr-1.13.tar.gz didn't include the Pyrex-generated C files. Does any of that matter for LP? | 08:17 |
| Peng_ | thumper: If LP doesn't use "bzr", doesn't use "bzr --force" and has Pyrex installed on the build machine or doesn't use the tarball in the first place, I guess it doesn't really matter. | 08:18 |
| thumper | Peng_: thanks, I think LP will stick with 1.13 | 08:26 |
| thumper | :) | 08:26 |
| Peng_ | Err, "bzr merge --force", I meant.. | 08:27 |
| spiv | thumper: I agree with Peng_'s assessment. Also, we write the NEWS file for a reason ;) | 09:03 |
| thumper | spiv: don't expect people to actually read NEWS, geez | 09:03 |
| thumper | spiv: what makes you think I have a copy of trunk? | 09:03 |
| spiv | thumper: Well, I'm reasonably sure you have a tool to browse files in branches online | 09:05 |
| spiv | thumper: but also the relevant parts of NEWS are sent in each release announcement | 09:06 |
| thumper | spiv: geez, why all this reading when someone can just ask :P | 09:06 |
| spiv | thumper: of course, http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/head:/NEWS would be even better if LP didn't time out trying to render it ;) | 09:07 |
| spiv | thumper: when you ask, all I do is go and read that file | 09:07 |
| spiv | thumper: so you might as well cut out the middle man :) | 09:07 |
| thumper | spiv: and save me the trouble :) | 09:07 |
| === serg_ is now known as serg | ||
| === AnMaster_ is now known as AnMaster | ||
| VSpike | Greetings. A general question. I have a project where parts of it are customized files for the end customer - e.g. web pages, set up files, theme files etc... | 12:09 |
| VSpike | I want to maintain these branches in parallel for the long term. Is there a way to make this easier, i.e. to ensure that some changes in a branch never get pushed to the parent? | 12:09 |
| VSpike | The other approach would be to treat all the customer specific files as a separate project under source control. | 12:10 |
| VSpike | But bzr doesn't seem to handle related sub-projects yet - unless that has change since I last checked? | 12:10 |
| yogsototh | VSpike: got the same problem with 3 différent environments. | 12:26 |
| yogsototh | I use 3 differents branches | 12:26 |
| yogsototh | And I never use pull nor push | 12:26 |
| yogsototh | but only merge | 12:26 |
| yogsototh | That should work just great | 12:27 |
| VSpike | yogsototh: do you mean that you never make code changes in the child branches that need go back to parent? | 12:38 |
| === beuno_ is now known as beuno | ||
| === ja1 is now known as jam | ||
| joie | Apologies if I'm asking the obvious - but I can't find it in the docs. Is there any way of finding out the common ancestor a merge command is using? | 13:20 |
| joie | (I'm kinda new to bzr - but been using baz for a long while, trying to make the switch!) | 13:21 |
| lifeless | joie: bzr find-merge-base | 13:21 |
| lifeless | joie: found in 'bzr help hidden-commands' | 13:22 |
| joie | Ahhah - sounds like a useful thing to know - thanks! | 13:22 |
| joie | I'm essentially trying to do the equivalent of a baz apply-delta to put all the work from one branch onto my working branch, and want to be sure that merge is doing the "right" thing! | 13:23 |
| james_w | jelmer: hey, thanks, I was just about to take another look at bzr 1.13.1 and I saw the ACCEPTED mail. | 13:43 |
| jelmer | james_w: it turned out there was a bug in the python2.6 package in experimental that I had instlaled | 13:56 |
| jelmer | james_w: uninstalling it made the problem go away | 13:56 |
| === thunderstruck is now known as gnomefreak | ||
| Tak | jelmer: hello | 14:05 |
| igc | night all | 14:13 |
| emmajane | igc, just got your email. The reason I emailed you back with the link was because I don't have time to do this right now. | 14:18 |
| liw | what's this mean: Unable to contact DBus session: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed. | 14:32 |
| jelmer | liw: bzr-dbus was unable to contact your local DBus | 14:36 |
| jelmer | liw: while attempting to signal that a new commit was made / branch was updated | 14:37 |
| liw | ok. why is dbus being contacted? I'm not running under X for that command (ssh into the machine; there is an open X session in the console, though) | 14:39 |
| jelmer | liw: you have bzr-dbus installed probably | 15:14 |
| jelmer | liw: newer versions of bzr-dbus will not show any error / output if it fails | 15:14 |
| liw | jelmer, ok, then I'll just ignore it, thanks | 15:22 |
| jam | vila: just a quick question, if you managed to fix the duplicate "CHKInventory" stuff. | 15:34 |
| vila | ajmitch: yu[ | 15:35 |
| vila | ajmitch: sorry wrong target | 15:35 |
| vila | jam: yes ? | 15:35 |
| jam | vila: ?? or 'yes' :) | 15:36 |
| vila | jam: I pushed --overwrite on vilajam | 15:36 |
| vila | jam: 'just quick question, if' I was waiting for the question :) | 15:36 |
| vila | jam: the fix may not be the cleanest one (you can still find the duplicate in a couple of revisions if you dig enough), but I think it's "good enough" | 15:41 |
| meuserj | Is there an existing plugin or other method for creating a default template for commit text? | 15:49 |
| jelmer | meuserj: there's no plugin yet, but there is a hook you can use if you're going to write such a plugin | 15:50 |
| vila | jam: in gc, _compress last returned value is length, documented as 'number of bytes accumulated in the group output so far' but the code seems to calculate the delta length instead | 15:55 |
| vila | vila: it seems to be used only in _insert_record_stream and even there that seems like a left over | 15:56 |
| jam | vila: so the return is currently (sha1, start_of_record, end_of_record, kind, length_of_record) | 16:03 |
| jam | the last part is obviously redundant with end_of_record - start_of_record | 16:03 |
| vila | jam: not so obviously :-) but thanks for confirming, it's not always the case for the python impl. but if the semantic is correct, I'll just delete it | 16:04 |
| vila | jam: can I get also get rid of the last_fulltext_len in _insert_record_stream ? | 16:05 |
| jam | vila: sure, I think there was something about returning the size of the fulltext that was being compressed, etc | 16:07 |
| jam | I would probably just get rid of 'length' | 16:07 |
| jam | (evolving interfaces :) | 16:07 |
| vila | jam: ok, doing it right now | 16:08 |
| jam | so stuff like last_fulltext_len was meant as a possible way to play with varying the compression decisions | 16:08 |
| vila | I can 1) get rid of it as well as length, 2) keep it and update it with end - start | 16:09 |
| jam | vila: We can always bring it back if we decide we want to use it | 16:10 |
| jam | for now, cleaner code is probably better for landing in bzr.dev | 16:10 |
| vila | ok | 16:10 |
| jelmer | jam: hi | 16:22 |
| jelmer | jam: How do I create a branch5 format programmatically? | 16:22 |
| jam | jelmer: in a test suite or just from bzrlib? | 16:31 |
| jelmer | jam: in a testsuite | 16:32 |
| jelmer | for other branch formats I can use ._matchingbzrdir | 16:33 |
| jam | jelmer: self.make_branch('dirstate' | 16:33 |
| jam | would probably be fine | 16:33 |
| jam | at least that was the last one to use Branch5 | 16:33 |
| jam | if you need more control than that, then I can go through it | 16:33 |
| jam | (that will be a knit format repo, with a branch5 branch) | 16:34 |
| jelmer | jam: is there any way to obtain that from a BranchFormat instance? | 16:34 |
| jam | jelmer: are you saying you need the name of the format? | 16:34 |
| jelmer | jam: I have a BranchFormat instance (BzrBranchFormat5) and need to create a branch that uses it | 16:35 |
| jam | bzrlib.branch.BranchFormat5.initialize() | 16:35 |
| jelmer | preferably as generic as possible, without special casing BzrBranchFormat5 | 16:35 |
| jelmer | This is for the InterBranch tests | 16:35 |
| jam | jelmer: my_format.initialiaze(a_bzrdir) ? | 16:35 |
| jam | my_format.initialize(a_bzrdir) ? | 16:35 |
| jelmer | jam: but in that case what format can a_bzrdir have? | 16:35 |
| jam | jelmer: there is only 1 'metadir' bzrdir format | 16:36 |
| jelmer | can I use a BranchFormat5 with a recent repo format? | 16:36 |
| jam | jelmer: yes | 16:36 |
| jam | it will "work" we just don't give you a way to specify that with a short name from 'init' | 16:36 |
| jelmer | ah, neat, I wasn't aware of that | 16:36 |
| jam | vila: so where are you at? I haven't seen your commit showing up yet :) | 17:14 |
| vila | I tracked down the unicode symlinks error back to bzr.dev@4216 :-/ | 17:15 |
| vila | Can you run ./bzr selftest -s bt.branch_implementations.test_sprout.TestSprout.test_sprout_with_unicode_symlink in your bzr trunk ? | 17:15 |
| vila | jam: ^ ? | 17:18 |
| jam | vila: currently on win32, I'm sure it will pass just fine :) | 17:19 |
| vila | jam: lol, yeah, but I don't understand how pqm let it pass | 17:19 |
| jam | vila: on my server, that test fails about 5 times | 17:21 |
| jam | 'ascii' codec can't decode byte 0xce | 17:21 |
| vila | yup, that one | 17:21 |
| jelmer | with or without the dirstate pyrex extensions? | 17:21 |
| jam | jelmer: both | 17:21 |
| vila | jelmer: both | 17:21 |
| jam | vila: maybe a python2.4 issue? | 17:22 |
| vila | revno 4215 succeeds, 4216 fails | 17:22 |
| vila | just reproduced it with 2.4 too 8-/ | 17:22 |
| jam | vila: so I could see where 'iter_changes' is accidentally using 8-bit symlink_target rather than unicode, but yeah, I don't see how pqm didn't fail just like us | 17:26 |
| vila | UnicodeFilenameFeature not available on pqm ? | 17:28 |
| jam | vila: certainly possible, I don't know | 17:28 |
| jam | actually, probably likely | 17:28 |
| jam | try setting LANG=fr | 17:28 |
| jam | or something | 17:28 |
| jam | rather than fr.UTF-8 | 17:28 |
| vila | EMYOSDOESNTSPEAKFRANCAIS :) | 17:29 |
| vila | LANG=en_US.UTF-8 | 17:29 |
| vila | always | 17:29 |
| jam | :) | 17:30 |
| jam | so LANG=en_US then :) | 17:30 |
| jam | vila: yeah, it passed with a skip here | 17:30 |
| vila | yup, tests are skipped in that case | 17:30 |
| vila | crap | 17:32 |
| vila | jam: by the way, I pushed my last changes at vilajam | 17:33 |
| vila | jam: you may want to pull --overwrite from there though | 17:34 |
| vila | jam: I mean, I you keep a mirror of that one | 17:34 |
| vila | jam: I mean, IFF you keep a mirror of that one | 17:34 |
| === solarion_ is now known as Solarion | ||
| jam | vila: well, I'm a bit saddened that you keep '--overwrite'ing all of my branches. You pushed up your history for brisbane-core, and vilajam... | 17:36 |
| vila | jam: ?? I try to respect the mainline most of the time, but here you had committed *on top* of the error, so I tried to get rid of the problem as best as I can :-/ | 17:37 |
| vila | jam: I tried alternate ways to fix it, but most of them ended up with the wrong annotation for both CHKInventory and CHKInventoryDirectory (all the lines were attributed to *me*), at least now the attributions are correct and your revisions still present | 17:39 |
| jam | not a big deal, really | 17:40 |
| jam | I was just surprised to see both mainlines changing to "merged bbc@" especially since it was the bbc trunk | 17:40 |
| vila | I thought correct annotations were more important than revision history :-/ | 17:40 |
| jam | vila: personally I use "bzr log" about 20x more than "bzr annotate", but as I said, in another week I won't even notice | 17:41 |
| vila | jam: and yes, the way I rebuilt my loom wasn't the clearest either :-/ | 17:41 |
| vila | jam: on the other hand, may be you should push to jamvila :) | 17:42 |
| jam | :) | 17:43 |
| vadi2 | does bzr use sha1 behind the scenes? | 17:51 |
| james_w | yes | 17:52 |
| === davidstrauss is now known as davidstrau | ||
| === davidstrau is now known as davidstrauss | ||
| === jfroy_ is now known as jfroy | ||
| luks | heh, python is going to use mercurual | 18:24 |
| cody-somerville | luks, its official? | 18:28 |
| cody-somerville | luks, link? | 18:28 |
| luks | http://mail.python.org/pipermail/python-dev/2009-March/087931.html | 18:28 |
| === jszakmeister is now known as jszakmeister|awa | ||
| === jszakmeister|awa is now known as jszakmeister | ||
| jszakmeister | yep, it's official. | 18:44 |
| cody-somerville | That sucks :( | 18:47 |
| cody-somerville | bzr rocks | 18:47 |
| * jszakmeister agrees | 18:48 | |
| cody-somerville | Is there an announcement or anything? | 18:48 |
| jszakmeister | It probably boiled down to performance... the email is a little vague, but I agree... a decision needed to be made | 18:48 |
| jszakmeister | luks put the url in IRC | 18:49 |
| cody-somerville | but bzr is fast now :( | 18:58 |
| BFrank | that is the joy of open source, you are free to choose amongst many good choices | 19:06 |
| cody-somerville | I can't wait until Launchpad supports git and mercurial imports | 19:08 |
| santagada | is the code for launchpad avaliable somewhere already? | 19:09 |
| cody-somerville | santagada, You might want to ask in #launchpad - this is #bzr | 19:09 |
| Toksyuryel | and each choice typically tries its best to make switching between choices as painless as possible | 19:09 |
| mwhudson_ | cody-somerville: soon! | 19:09 |
| mwhudson_ | for git | 19:09 |
| santagada | cody-somerville: no one here knows? I would supose it is pretty important | 19:09 |
| cody-somerville | santagada, Why? | 19:10 |
| cody-somerville | mwhudson_, :) | 19:10 |
| antoranz | when I pack, can I delete everything in .bzr/repository/obsolete_packs/? | 19:12 |
| beuno_ | antoranz, in general, yes | 19:12 |
| === beuno_ is now known as beuno | ||
| antoranz | ok | 19:12 |
| bialix | hi guys, in which time igc (Ian) will be here? | 19:19 |
| beuno | bialix, I'd say in about 3 hours or so | 19:20 |
| bialix | thanks. perhaps too late for me | 19:20 |
| BFrank | why doesn't it cleanup obsolete packs? | 19:21 |
| bialix | igc: I'd like to talk about eol labels and strategies with you tomorrow morning (~ 6-8 am UTC). OK? | 19:22 |
| beuno | BFrank, I don't know all the details, but it mostly has to do to ensure that we don't run into data loss | 19:22 |
| BFrank | hmm | 19:22 |
| bialix | igc: I'll be there tomorrow. | 19:22 |
| beuno | BFrank, there are some crazy scenarios where that happens | 19:22 |
| BFrank | when exactly does it cleanup the obsolote packs? | 19:22 |
| BFrank | shouldn't there be a point when it is safe for bazaar to clean them up? | 19:22 |
| james_w | it cleans them up before writing any more | 19:23 |
| james_w | so next time it does a "pack" operation it first removes the obsolete ones | 19:23 |
| BFrank | shouldn't it cleanup for other types of operations, where it won't create new ones? | 19:24 |
| BFrank | or do all operations create them? | 19:24 |
| james_w | no, just the ones you would expect | 19:24 |
| james_w | commit, pull, pack, merge, push into, etc. | 19:24 |
| === mwhudson_ is now known as mwhudson | ||
| BFrank | hmm | 19:25 |
| antoranz | what tool can I use to import a git repository into bzr? | 19:25 |
| mwhudson | antoranz: bzr-git or bzr-fastimport | 19:26 |
| antoranz | ok | 19:26 |
| mwhudson | antoranz: the latter is probably more robust at this point, but bzr-git is moving fast | 19:31 |
| antoranz | ok | 19:31 |
| jelmer | mwhudson: moin | 19:32 |
| mwhudson | jelmer: hi | 19:32 |
| jelmer | mwhudson: my git import now works on lp btw | 19:32 |
| mwhudson | jelmer: yes, i saw that | 19:32 |
| mwhudson | jelmer: did you find out what was going on when it was just showing 1000 revs? | 19:32 |
| === beuno_ is now known as beuno | ||
| jelmer | mwhudson: yes, I had only pushed 1000 revisions (bzr push -r1000) :-) | 19:33 |
| mwhudson | jelmer: hahahaha | 19:33 |
| mwhudson | jelmer: so if i wanted to make a bzr-svn import of pypy, what would i have to do? | 19:49 |
| mwhudson | jelmer: i remember you saying that i could probably hack something to ignore certain errors | 19:49 |
| === mtaylor_ is now known as mtaylor | ||
| jelmer | mwhudson: ah, yeah | 19:57 |
| jelmer | mwhudson: when it calls get_dir() | 19:57 |
| jelmer | you have to ignore 157002 errors | 19:57 |
| mwhudson | jelmer: alternatively | 20:15 |
| mwhudson | if i dump the repo, filter out the offending fileprops, recreate it locally | 20:15 |
| mwhudson | do the import from my local repo, will it be possible to update the import from codespeak? | 20:15 |
| jelmer | mwhudson: yes | 20:16 |
| mwhudson | jelmer: awesome | 20:21 |
| mwhudson | jelmer: do you happen to know how to filter a dumpfile? | 20:21 |
| jelmer | mwhudson: vi ? :-) | 20:25 |
| mwhudson | jelmer: heh | 20:25 |
| phinze | so i've got a meeting this afternoon about revising my group's code review practice, which currently consists of all devs (4-6 of them) sitting around a table and scrolling through one big diff that's getting deployed | 20:28 |
| phinze | wondering if anyone else using bazaar in a dev group can talk about what they do for code review? | 20:28 |
| phinze | we're hoping to move toward peer-review where one other dev signs off on each commit to trunk | 20:29 |
| james_w | phinze: that's what bzr does, as you probably know | 20:33 |
| phinze | yes bzr does PQM where what like at least one other dev must approve? | 20:33 |
| james_w | you work with much smaller, more targetted diffs, which is a big win | 20:34 |
| james_w | but there will some cross-change intricacies that can be missed | 20:34 |
| james_w | yeah, two core devs total, so you get two reviews of code from those that haven't been let in to that group yet | 20:34 |
| phinze | we're thinking of using PQM here too | 20:35 |
| james_w | I think that's a stricter requirement than a lot of open source projects, where once you are a core committer you can generally do what you like | 20:35 |
| phinze | yeah seems pretty strict but also seems like it works :) | 20:36 |
| phinze | so it's either BB:approve or BB:reject...? | 20:36 |
| james_w | e.g. in Ubuntu. What happens there is sometimes you request your changes are reviewed before uploading (committing to mainline). Some people watch the -changes list (equivalent to -commits) and review things that catch their eye | 20:36 |
| james_w | so it's much less comprehensive | 20:36 |
| james_w | but the volume of changes there is too large, and the expertise too thinly spread, to have bzr's system of review. | 20:37 |
| phinze | ahh yeah | 20:37 |
| james_w | there is BB:approve, BB:reject, BB:rebsubmit, BB:tweak, BB:comment and BB:abstain I think | 20:38 |
| phinze | lol abstain | 20:38 |
| james_w | where approve, resubmit and tweak are the most commonly used | 20:38 |
| phinze | how to resubmit/tweak work in that case | 20:38 |
| phinze | are they just different semantic keywords on top of reject? | 20:38 |
| phinze | s/to/do | 20:40 |
| james_w | reject is pretty final, "I don't want any change like this in bzr", for something like "remove bzr commit, make everyone commit by editing .bzr/repository" | 20:40 |
| phinze | :) | 20:40 |
| james_w | resubmit means, "I'm fine with where you are going, but there are some problems with your implementation, make some changes and ask for review again" | 20:41 |
| james_w | tweak means "basically fine, there's a typo here, fix that up and submit it, you don't need to get it re-reviewed" | 20:41 |
| phinze | from BB/PQM's perspective, though, it's just a "go/no go"? | 20:42 |
| james_w | BB tracks the votes, I'm not sure what algorithm it uses to decide, if any | 20:42 |
| james_w | PQM is not automatic, a developer has to submit each change | 20:42 |
| james_w | there's no link between them currently | 20:43 |
| phinze | ahh BB and PQM are two separate systems... i thought they were two head of one beast | 20:43 |
| james_w | PQM just saves you from having to wait for the testsuite before committing, you submit, and some time later get a mail telling you if it passed or not | 20:43 |
| james_w | nah, they could work more closely together, but it works fine to have them separate, so no-one put the effort in | 20:44 |
| mwhudson | jelmer: ok, i have a dump file, can you give me some clues what i'm looking for? | 20:57 |
| jelmer | mwhudson: look for the particular revision that was causing problems (I think I mentioned it in the bug report) | 21:00 |
| jelmer | You'll see entries in the dump file for each property change and each file change | 21:00 |
| jelmer | just remote the K ... / V ... bits for the problematic property (with a / in the name IIRC) | 21:00 |
| * mwhudson wonders about an appropriate tool for editing a 3.7 gig file | 21:02 | |
| stbuehler | "rm" :) | 21:03 |
| NfNitLoop | heh. | 21:04 |
| thumper | mwhudson: sed | 21:04 |
| mwhudson | thumper: you might be rite | 21:04 |
| thumper | mwhudson: or emacs :) | 21:04 |
| mwhudson | right | 21:04 |
| mwhudson | does emacs not load the entire file into ram? | 21:04 |
| mwhudson | i was ~sure it did | 21:04 |
| NfNitLoop | a friend of mine had to remove middle chunks of very large (gig+) files and ended up using head & tail. | 21:04 |
| thumper | mwhudson: I'm not sure | 21:05 |
| jelmer | mwhudson: there are some tools for editing svn dumps | 21:05 |
| jelmer | but I'm not familiar with them | 21:05 |
| jelmer | they do exist though :-) | 21:05 |
| mwhudson | ok | 21:08 |
| phinze | james_w: thanks for explaining all that; very helpful! | 21:08 |
| james_w | np | 21:10 |
| * mwhudson finds a perl thingy | 21:10 | |
| mwhudson | hang on | 21:14 |
| mwhudson | jelmer: can svn-import import from a dump file? | 21:15 |
| mwhudson | or | 21:16 |
| jelmer | mwhudson: it can import from a dump file but it will simply load the dump file into a repo and then import it | 21:16 |
| jelmer | mwhudson: actually, you should be able to import from that dumpfile directly | 21:16 |
| jelmer | mwhudson: as that problem only occurred over http | 21:16 |
| mwhudson | right | 21:17 |
| mwhudson | that was what i was thinking | 21:17 |
| === beuno_ is now known as beuno | ||
| * mwhudson plays the install dependencies game | 21:24 | |
| shtylman_ | I am looking to setup my own bzr server for a group I am working with. I wanted to do it using https transport to basically get pretty urls (ie. https://domain/repo/project) ... I know bzr can work over ssh, but then I don't get the pretty name...without putting the repo under root...which I would like to avoid...any suggestions/ideas? | 21:36 |
| === Pilky_ is now known as Pilky | ||
| NfNitLoop | shtylman_: You can use read-only "dumb servers" over HTTP trivially: | 21:50 |
| NfNitLoop | http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html | 21:50 |
| NfNitLoop | but ssh will probably be best (read: easiest) if you want to give people write access. | 21:50 |
| shtylman_ | NfNitLoop: I am aware of the "dumb" servers...and yea...I was thinking the same thing....but just wondering if I overlooked something simple | 21:56 |
| NfNitLoop | Not that I know of. | 21:57 |
| NfNitLoop | you could use `bzr serve`, but that's apparently only for a single repo. | 21:57 |
| LarstiQ | afaik bzr serve is for directory hierarchies, not repositories. | 21:59 |
| NfNitLoop | Oh. ok, misread that while skimming. | 21:59 |
| LarstiQ | so serving / would work | 21:59 |
| NfNitLoop | there you go then, bzr serve. | 21:59 |
| NfNitLoop | (though, you probably don't want to serve /) ;) | 21:59 |
| LarstiQ | shtylman_: you could use a chrooting ssh server to prettify your urls, just like launchpad does | 22:00 |
| mwhudson | jelmer: import to a brisbane-core format blew up in a really exciting way | 22:00 |
| shtylman_ | LarstiQ: will that interfere with the current ssh server on the machine? sounds like it will... | 22:01 |
| LarstiQ | shtylman_: it could | 22:01 |
| mwhudson | jelmer: http://pastebin.ubuntu.com/140987/ | 22:02 |
| * LarstiQ goes to bed | 22:02 | |
| mwhudson | jelmer: and then when trying to import into --1.9 http://pastebin.ubuntu.com/140995/ | 22:06 |
| === AnMaster_ is now known as AnMaster | ||
| jelmer | mwhudson: not sure any of those are bzr-svn issues | 22:25 |
| mwhudson | jelmer: what might they be? | 22:25 |
| mwhudson | the thread-starting one is pretty odd | 22:26 |
| jelmer | mwhudson: Does it start a very large number of threads or something like that? | 22:27 |
| mwhudson | jelmer: bit hard to tell, this is on a remote machine | 22:27 |
| mwhudson | which is an openaz slice, or something, so it's possibly a slightly strange environment | 22:28 |
| lifeless | shtylman_: you could put a symlink in the root | 22:28 |
| shtylman_ | lifeless: yep...decided on that few min ago :) | 22:29 |
| jam | jelmer: for the first pastebin, something is passing a 'key' that has a unicode string, which I don't think is allowed. Since both "file_id" and "revision_id" are declared to be utf-8 strings internally. | 22:33 |
| jam | Given that it is clearly an 'id' followed by a 'path' I'm a bit confused by it, though | 22:34 |
| jam | Though it also seems be failing in the middle of 'svn/errors.py ... convert' | 22:34 |
| jam | which sounds like an exception in the middle of reporting an exception. | 22:35 |
| mwhudson | jelmer: i'm tar tjf-ing the repo, will see if it ends up small enough to download to my laptop reasonably | 22:35 |
| mwhudson | cfj, obv | 22:36 |
| jam | anyway, I'm off for tonight, catch y'all later :) | 22:37 |
| lifeless | gnight jam | 22:38 |
| igc | morning al | 22:54 |
| igc | all | 22:54 |
| lifeless | hi igc | 22:56 |
| igc | hi lifeless | 22:57 |
| igc | lifeless, jam: I'm up at the hospital most of the day | 22:57 |
| lifeless | igc: good luck | 22:57 |
| igc | what code do you want me reviewing while I'm there? | 22:57 |
| igc | I'm thinking chk_map | 22:57 |
| igc | (groupcompress in out of my depth and we have 3 people who ought to know it reasonably well) | 22:58 |
| igc | s/in/is/ | 22:58 |
| lifeless | that would make sense; re the cache you are proposing, yes your mail comes across very strongly ;). I would like to note that AIUI the revnos do _not_ require the full graph to be traversed | 22:58 |
| lifeless | so if we strip the hyperbole we can be examining that part of the problem | 22:59 |
| * SamB_irssi begins to wonder why svn-import is only available for svn ... | 23:00 | |
| plexq | I'm trying to merge lots of subprojects into one big central project. Is there a way to do that? | 23:10 |
| plexq | should I just make one big honking bzr | 23:11 |
| lifeless | there is a merge-into plugin | 23:11 |
| plexq | or do subprojects like you can in svn | 23:11 |
| plexq | merge-into - yeah - I saw that - does it still work? i t hasn't been touched in 9 months? | 23:11 |
| lifeless | as far as I know it does work yes | 23:12 |
| lifeless | we have sub projects being worked on but its not really ready yet | 23:13 |
| plexq | kk | 23:14 |
| plexq | I'd heard a rumour that bazaar was going away because Gnome picked git, is there any truth to this? | 23:15 |
| SamB_irssi | I heard that Emacs is going to be switching to bzr soon ... | 23:15 |
| james_w | first I've heard of it | 23:15 |
| lifeless | plexq: no truth to it at all | 23:19 |
| lifeless | and yes, emacs are talking timeframes now | 23:19 |
| plexq | I know for us - it will depend on IDE plugins. We are using bazaar right now, but I've heard there is a pure Python version of git, and IntelliJ 8.1 now has a git plugin, but no good bazaar support :( | 23:20 |
| lifeless | plexq: the pure version of git is 'dulwich' a project started for 'bzr-git', our git interoperation plugin | 23:22 |
| plexq | heh | 23:23 |
| lifeless | eclipse has bzr support FWIW | 23:23 |
| plexq | yeah - but eclipse is a POS | 23:23 |
| plexq | it's horrible | 23:23 |
| plexq | took one look at IntelliJ and never looked back | 23:23 |
| === ovnicraft is now known as ovnicraft|gnuthi | ||
| === ovnicraft|gnuthi is now known as ovnicraft | ||
| * igc breakfast | 23:54 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!