| sender | mgz: i have to go, thanks for the help, i'll try again tomorrow | 00:01 |
|---|---|---|
| spiv | lifeless: hmm, yes. Drat. | 00:42 |
| lifeless | spiv: can I suggest: | 00:43 |
| lifeless | - fix it well in testtools | 00:43 |
| lifeless | - depend on that | 00:43 |
| lifeless | - revert the bzr change | 00:43 |
| spiv | Well, it certainly has scenarios with (x,y), but I *think* it may have (x)(y) too. | 00:43 |
| spiv | I wouldn't expect the breakage to be silent, though, because the attributes would tend to be missing or None. | 00:43 |
| lifeless | spiv: would depend on the test code I guess | 00:44 |
| spiv | Yeah. | 00:45 |
| poolie | hi there spiv | 01:04 |
| spiv | Hi poolie | 01:05 |
| spiv | My fix for ssl.py got accepted into Python 2.7 upstream and python2.6 in Ubuntu. | 01:05 |
| lifeless | \o/ | 01:05 |
| lifeless | although, now yu don't know if 2.6 works everywhere :P | 01:06 |
| spiv | Well, the test failure it causes is intermittent IIRC (hooray threads :/) | 01:06 |
| poolie | good for you | 01:07 |
| poolie | i think i saw that bug a couple of times yesterday running my own tests | 01:07 |
| spiv | I guess I should nag about getting my paramiko IPv6 fix in upstream and maverick too. | 01:07 |
| poolie | could be good | 01:11 |
| poolie | i got a few pqm failures and review comments yesterday so i'm going to do them first | 01:11 |
| poolie | then push on detecting stale locks | 01:11 |
| poolie | also post "what do you do" | 01:11 |
| poolie | you should do that too spiv, if you didn't already | 01:11 |
| poolie | i'm happy to read it | 01:11 |
| maxb | Why does bzr selftest say ERROR when a test raises TestSkipped? | 01:21 |
| maxb | It's most unhelpful :-/ | 01:22 |
| lifeless | maxb: python 2.7? | 01:23 |
| maxb | 2.6 | 01:23 |
| lifeless | hmm | 01:23 |
| maxb | A fairly ordinary lucid installation, in fact | 01:24 |
| poolie | maxb i've never seen that | 01:40 |
| maxb | how bizarre. I wonder why my system is broken :-( | 01:44 |
| poolie | you can dig in to it... | 01:47 |
| maxb | I'm already digging into something that occurred whilst digging into something, my stack is overflowing :-) | 01:56 |
| poolie | maxb, np, then i'm inclined to write it off | 02:10 |
| poolie | if something weird occurs let me know | 02:10 |
| poolie | maybe you're using the wrong bzr? | 02:10 |
| poolie | i mean the wrong bzrlib | 02:14 |
| abadger1999 | Okay -- stupidity question time | 04:06 |
| abadger1999 | I just rm -rf 'd a branch that I had. | 04:06 |
| abadger1999 | But the branch was in a shared repository. | 04:07 |
| abadger1999 | Is there any way to recover my last commits? | 04:07 |
| abadger1999 | I figure I have in the neighborhood of five commits since my last push | 04:07 |
| fullermd | You can use heads to suss it out. | 04:07 |
| abadger1999 | k | 04:07 |
| * abadger1999 reads the man page on bzr heads | 04:07 | |
| fullermd | Then just something like `bzr init foo ; cd foo ; bzr pull -rwhatever .` to pull it up. | 04:08 |
| abadger1999 | <nod> | 04:08 |
| abadger1999 | fullermd: Thanks! | 04:09 |
| spiv | lifeless: https://code.edge.launchpad.net/~spiv/bzr/traceback-accumulation-2.2/+merge/35494 | 04:15 |
| abadger1999 | fullermd: Thanks, that seems to have worked. | 04:18 |
| poolie | lifeless: have you still got a traceback for bug 636946? | 06:27 |
| ubot5 | Launchpad bug 636946 in Bazaar "shelve NEWDIR/NEWFILE tries to shelve NEWDIR (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/636946 | 06:27 |
| poolie | i realize it's probably obvious where it's raised, but just in case | 06:27 |
| lifeless | no, rebooted since sorry | 06:35 |
| poolie | not in .bzr.log? | 06:36 |
| spiv | poolie: rt 41382 filed for news_merge on PQM | 06:52 |
| poolie | thanks | 06:54 |
| vila | hi all | 07:31 |
| poolie | hi vila, bialix | 07:32 |
| * poolie was just going to see about fixing bug 220463 | 07:33 | |
| ubot5 | Launchpad bug 220463 in libvirt (Ubuntu) "unable to boot linux vm's that are not Debian derived. (affected: 1, heat: 3)" [Undecided,Fix released] https://launchpad.net/bugs/220463 | 07:33 |
| poolie | bug 220464 actually | 07:33 |
| ubot5 | Launchpad bug 220464 in Bazaar "Bazaar doesn't detect its own stale locks (affected: 0, heat: 2)" [High,In progress] https://launchpad.net/bugs/220464 | 07:33 |
| bialix | hi poolie, vila and all-all-all | 07:34 |
| vila | poolie: oh, on that subject, how are would it be to make bzr-2.[01] accept (and ignored) more data in the lock info files ? | 07:34 |
| vila | s/how are/how *hard*/ | 07:34 |
| poolie | probably easy | 07:34 |
| poolie | they may already do it? | 07:34 |
| vila | poolie: that would allow bzr >= 2.3 to put more data there | 07:35 |
| spiv | vila: well, the fix to #619872 should have done that, if it wasn't already the case. | 07:35 |
| poolie | however if it does need a code change, it may be hard to make sure that everyone using those versions actually gets the code change | 07:35 |
| spiv | vila: (well, to be clear, the fix for 619872 should prevent bzr from blowing up if it can't parse the lock info file, I'm not sure whether new fields would affect the parsing or not) | 07:36 |
| vila | poolie: rats, right, but that would matter only for projects where people use a mix of < 2.0 and >= 2.0 | 07:36 |
| vila | spiv: that's where I started thinking about that, I think you made it more resistant to empty or null-filled info files but I'm not sure about additional fields | 07:37 |
| poolie | vila i'm pretty sure it will ignore extra fields | 07:37 |
| vila | ok (one off my head :) | 07:37 |
| spiv | vila: well, the intent was to cope gracefully with any error from reading and parsing the info file. | 07:39 |
| poolie | vila iow if you want to add data, just do it, and then check it with old code | 07:41 |
| vila | spiv: sure, not throwing stones, I didn't think about it before it landed anyway | 07:41 |
| poolie | but i'm pretty sure it will work | 07:41 |
| poolie | what did you want to add? | 07:41 |
| vila | <cough> can't remember at the moment :) I didn't forget the constraint though... | 07:42 |
| vila | I'll tell you when I remember :) | 07:42 |
| vila | The only thing that comes to mind right now is adding the command at the highest level but I'm pretty sure it was something else | 07:43 |
| poolie | if we know a lockdir holder is a dead process from the same machine, will it be ok to automatically break it? | 07:46 |
| vila | poolie: with a warning, yes | 07:48 |
| poolie | meaning we just print a message then do it? | 07:48 |
| vila | poolie: yup, if you want to be anal you can make it depend on config var for paranoids to set | 07:48 |
| poolie | good idea | 07:48 |
| poolie | vila, that's kind of a case where we could say "there is a ui confirmation, but it's turned off by default" | 07:54 |
| vila | poolie: yes, but a bit different than deny_action() or confirm_action(default=False) still | 07:55 |
| vila | break_lock=yes/no/sometimes/always/ask :) | 07:56 |
| vila | 5-values boolean ftw ! | 07:56 |
| vila | no. seriously. | 07:56 |
| vila | failing because a lock has been created by a process we're sure is dead is silly, | 07:57 |
| vila | "I can't lock, someone else did", "someone else is dead, break the lock manually" "are you sure you want to break the lock ?" | 07:58 |
| spiv | mutt has the concept of a "quadoption", which can be yes, no, ask-yes or ask-no. | 07:58 |
| vila | vs "I can't lock, someone else did ; it's dead, let's break the lock" | 07:58 |
| spiv | (ask-yes causes a prompt with a default answer of yes) | 07:59 |
| vila | the warning is there to help people tracking the root cause if it happens too often | 07:59 |
| poolie | so maybe yagni and i'll just give a warning | 07:59 |
| vila | poolie: yup | 08:00 |
| spiv | Fewer options is a good thing, when possible. | 08:00 |
| vila | Don't ask if you're going to accept a single answer too ;) | 08:00 |
| poolie | well, the answers are really "sure/wtf" | 08:01 |
| spiv | (a)bort/(r)etry/(w)tf? | 08:01 |
| vila | (W) to indicate the default | 08:01 |
| poolie | so i can think of cases where people have multiple machines all called 'ubuntu' | 08:03 |
| poolie | and the same account on each, all getting at the same branch | 08:04 |
| poolie | but, probably most of the time it's not wortwhile | 08:04 |
| spiv | poolie: in principle you could try some heuristics like "is the UUID of / the same?" | 08:07 |
| spiv | Or hardware addresses of network interfaces. | 08:08 |
| poolie | mm | 08:08 |
| spiv | http://docs.python.org/library/uuid.html#uuid.getnode looks almost-but-not-quite helpful | 08:11 |
| poolie | my ui-factory branch seems to be failing in test_delta | 08:15 |
| poolie | that's strange | 08:15 |
| poolie | ah i wonder if this could be somehow due to the test multiplication bug? | 08:33 |
| spiv | test_delta doesn't seem to use test multiplication, though? | 08:34 |
| poolie | test_diff is failing and that does ad-hoc multiplication by subclassing | 08:35 |
| poolie | i'm not sure how we would have broken that but i don't see how i would have broken it eithr | 08:36 |
| poolie | the symptom in all failures seems to be run_bzr(...retcode=1) fails because it seems to observe a return code of 0 | 08:36 |
| poolie | i don't know if that's every case but it's many of them | 08:36 |
| poolie | hm i wonder if it's trying to read a confirmation in a place it wasn't before, and therefore exiting early | 08:38 |
| spiv | Hmm, the test multiplication changes seem pretty unrelated to that. | 08:38 |
| spiv | If it's an unexpected confirmation prompt, then hopefully the test log will show that? | 08:38 |
| poolie | the failure i was getting in test_delta was | 08:40 |
| poolie | File "/home/pqm/bzr-pqm-workdir/home/+trunk/bzrlib/tests/test_delta.py", line 69, in assertReportLines | 08:40 |
| poolie | self.assertEqualDiff(expected_lines[i], result[i]) | 08:40 |
| poolie | and that's possibly because of unexpectedoutput | 08:40 |
| vila | poolie: teddy-bear for orphan config var ? | 08:43 |
| vila | jam (and I agree with him) wants a hook there, there may be a way to reconcile both but nothing really simple comes to mind, would you be ok to postpone that a bit ? | 08:44 |
| vila | your request seems tied to junk files which I'd prefer to address by refactoring ignores so we can reuse them for properly implementing junk | 08:45 |
| spiv | vila: what's the difficulty in making a hook? Does the orphaning happen at a fairly generic point in the treetransform code? | 08:46 |
| vila | spiv: well, there is TreeTransform and TransformPreview that both implement new_orphan | 08:47 |
| vila | the hook should be for new_orphan and TransformPreview should never be concerned (in theory) | 08:48 |
| vila | but poolie would like an easy way to preserver the old behavior and a hook is not "easy" to configure | 08:48 |
| vila | we can't put a callable there :) So this means a registry in addition to the hook. Not trivial. | 08:49 |
| spiv | I don't quite follow the last bit there... | 08:49 |
| vila | spiv: https://code.edge.launchpad.net/~vila/bzr/323111-orphan-non-versioned-files/+merge/35110 | 08:50 |
| spiv | Making a hook point and how configuration works are pretty unrelated concerns | 08:50 |
| vila | orphans unversioned files now | 08:50 |
| poolie | spiv so on at least some of these tests i see multiple tracebacks | 08:50 |
| poolie | but perhaps that's not really the reason for failures | 08:50 |
| spiv | poolie: the traceback fix is currently only on 2.2 | 08:50 |
| vila | spiv: how do you configure a hook ? | 08:50 |
| spiv | vila: e.g. see merge_file_content hook | 08:50 |
| spiv | vila: it was created to allow features like news_merge | 08:50 |
| poolie | it seems like many tests that expect a non-0 return code are failing | 08:51 |
| spiv | vila: but regular merge logic uses it too | 08:51 |
| poolie | perhaps i'll just bisect back to find it | 08:51 |
| poolie | vila, i guess it's just that if people really do have precious files | 08:51 |
| poolie | having them dumped in a bzr-orphans directory | 08:51 |
| spiv | vila: i.e. regular merge registers a hook function for that hook point too | 08:51 |
| poolie | is not really helpful | 08:51 |
| poolie | at least they're not totally lost but they'll need to manually move them back or whatever | 08:51 |
| poolie | which might be annoying | 08:51 |
| poolie | if we were sure there were no such people we could just delete the files | 08:52 |
| vila | poolie: less annoying than resolving a conflict that shouldn't occur otherwise ? | 08:52 |
| vila | poolie: handling junk files (not precious files) will mean bzr-orphans contains only precious files | 08:52 |
| vila | poolie: and they will be put there only when the user ask bzr to proceed with an action that render such precious files orphans | 08:53 |
| spiv | vila: I guess the thing I don't get is why you are asking "how do you configure a hook ?" at all. Providing config options for users anad providing hook points in the API (for plugins and/or internal code) are different issues without any real overlap. | 08:53 |
| vila | spiv: the overlap is poolie asking for a config option when we want to add a hook for which specifying which files are concerned is tricky | 08:54 |
| spiv | vila: I mean, perhaps core bzr code might look at a config variable and use that to influence what it registers with a hook | 08:54 |
| spiv | But that's just an implementation detail. | 08:54 |
| poolie | vila, the thing is | 08:54 |
| poolie | if people only have junk, they want it just deleted | 08:54 |
| spiv | (e.g. lock debugging) | 08:54 |
| poolie | if they have precious files, i guess they want them left where they are and a conflict | 08:54 |
| poolie | moving them to bzr-orphans is a bit of a compromise position | 08:55 |
| vila | "them left where they are and a conflict" or "moved out of the way and decide *at that point* how they want to make them versioned" | 08:55 |
| poolie | ie i don't know how many people actually want that | 08:56 |
| poolie | well in the second case you have to move them back | 08:56 |
| poolie | by hand, which seems annoying | 08:57 |
| vila | shudder, so I just reject the mp ? | 08:57 |
| vila | poolie: now, not back, this occur when the parent directory is *deleted* | 08:57 |
| vila | you have to decide *where* you want it to live then | 08:57 |
| vila | the directory hasn't been renamed | 08:57 |
| spiv | vila: so, hypothetically, you could provide a config var like "orphaned_files = move_to_bzr_orphans" or "orphaned_files = conflict_parent_dir". | 08:58 |
| vila | there is a hole there I think between people wanting to have precious files, don't want to version them, yet, ask bzr to move them around | 08:58 |
| spiv | vila: and then provide a way for a plugin to register other policies | 08:59 |
| vila | spiv: exactly, hook + registry + config var | 08:59 |
| spiv | vila: e.g. a plugin that provides "orphaned_files = delete" | 08:59 |
| vila | spiv: and a bzr core implementation with at least two policies to start with | 09:00 |
| spiv | But there's nothing in that that I would describe as "configuring a hook" | 09:00 |
| vila | hence my teddy-bearing about: "Isn't handling junk files right more important ?" | 09:00 |
| spiv | (Or at least, not in the usual ways that I think we use those terms :) | 09:01 |
| vila | poolie: "i don't know how many people actually want that" I agree, I have no idea on who want what. Only that the actual behavior is a pain. | 09:02 |
| poolie | yes, what spiv said | 09:02 |
| poolie | i guess also, i think the handling here ought to be modularised enough that adding the config should not be too hard | 09:03 |
| poolie | because we know people will want to vary it in the future | 09:03 |
| vila | yeah, right, whatever, in terms of implementations, it's still hook + registry + config var | 09:03 |
| spiv | Yes, that sounds like a good implementation to me. | 09:04 |
| spiv | Well, I'm not sure that it is actually literally a HookPoint | 09:04 |
| spiv | But registry-of-policies + config var, yes. | 09:05 |
| poolie | right | 09:05 |
| poolie | i agree if you also have a hook plus a registry the interactions seem complex | 09:06 |
| poolie | do people want a hook in particular, or just a chance to run their own code? | 09:06 |
| spiv | (ObComplexityIsFun: there's no reason why a specific policy couldn't provide hook points...) | 09:06 |
| vila | poolie: right, I don't say we shouldn't do that, I'm complaining about doing it as a tweak :) | 09:06 |
| spiv | (aside from reasons of taste ;) | 09:07 |
| vila | poolie: especially one whose scope could be quite different if junk files were out of the equation (since the most obvious hook otherwise will be a quick-and-dirty let's-just-delete-junk :) | 09:08 |
| vila | or said in yet another way: isn't it better to have ophans *now* as a good workaround for junk files coming in the way during pull/merges/ etc ? | 09:10 |
| vila | and knowing we have better solutions in the pipe | 09:10 |
| spiv | Well, I've joined late in the discussion... | 09:11 |
| vila | spiv: most of what you miss is in the mp comments | 09:11 |
| spiv | but I think poolie (or someone?) was asking how hard it would be to a) provide a config option that can provide the old behaviour for users that want that | 09:12 |
| spiv | and b) do so in a modular enough way that could allow other policies to be provided too | 09:12 |
| vila | and the answer is: perfectly doable with hook + registry + config but as a tweak ? | 09:12 |
| vila | b) answer is: all is defined in new_orphan so far | 09:13 |
| poolie | again i agree with spiv | 09:13 |
| vila | I know of one case that will require a bit more work by adding a cleanup | 09:13 |
| poolie | generally i really don't like asking people to do extra work as patr of a merge | 09:13 |
| poolie | but i'm concerned that this may seem like a step backwards for some people | 09:14 |
| poolie | so i want there to be an escape route, at least | 09:14 |
| poolie | it's hard to count on immediately going on to the fix you want to do next | 09:15 |
| poolie | interrupts tend to come up | 09:15 |
| spiv | vila: I'm not sure what you mean by "hook" in hook + registry + config. Do you mean something involving bzrlib.hooks? | 09:15 |
| poolie | basically what i'm suggesting is: put this policy behind some kind of object interface | 09:16 |
| vila | spiv: yes, a way to redefine new_orphan, and yes in the same spirit as your merge hook | 09:16 |
| poolie | register it plus the old one | 09:16 |
| poolie | make the new one the default | 09:16 |
| vila | poolie: oh, I perfectly understand :) | 09:16 |
| poolie | :) | 09:16 |
| spiv | As a strawman, why wouldn't it simply be registry-of-new_orphan implementations, and a config var that can be set to a key in that registry. | 09:16 |
| spiv | There's no "hook" in the bzrlib.hooks sense in that. | 09:17 |
| vila | spiv: haaaaaa, thanks, I knew it should be simpler :) | 09:18 |
| spiv | vila: well, I'm a bit baffled about where you thought the hook should have been ;) | 09:18 |
| poolie | indeed (maybe later) the concept of: 'config var chooses from the registry' should be generalizable | 09:18 |
| spiv | But I'm happy to remain ignorant on that point :) | 09:18 |
| spiv | poolie: +1 | 09:18 |
| spiv | poolie: (we already do a pretty good job of that for command line options) | 09:19 |
| spiv | poolie: (and I miss it when not writing bzrlib code :) | 09:19 |
| spiv | Speaking of not writing bzrlib code... it's time to log off for the night! | 09:19 |
| vila | spiv: well, you can imagine different policies applying to different files while the config route means a single policy for all files, but it's a matter of better defining what new_ophan can do (it's not allowed to *refuse* to orphan yet even if I made some comments about that in the tests), so I wasn't clear about it. Better now | 09:20 |
| poolie | vila, apparently you're the RM, according to the topic :) | 09:21 |
| poolie | good night spiv | 09:21 |
| vila | poolie: errr, who did that ? | 09:21 |
| poolie | :) not me i promise | 09:21 |
| poolie | you can still wriggle out of it | 09:21 |
| poolie | but if you wanted to do it thursday/friday, that might be nice | 09:22 |
| bialix | as football fans shouting: vila! vila! vila! | 09:22 |
| vila | meh, my topic line is fubared right now :-/ | 09:23 |
| vila | bbiab | 09:23 |
| vila | I don't think changing the RM randomly will help here especially when the said RM just learn it almost by accident.... :-/ | 09:25 |
| poolie | it actually wasn't me | 09:25 |
| poolie | perhaps it should go back to being john or me | 09:25 |
| poolie | i thought you must have signed up for it? | 09:25 |
| poolie | ah, i think i worked out what my problem with diff is | 09:26 |
| poolie | one of the plugins, maybe bzr-pager, masks the error codes | 09:27 |
| vila | I mean, I'd be happy to be RM (man, I should have been long ago and have helped on almost everything except building the installers), but I asked to be hand held on several occasions... | 09:27 |
| vila | poolie: No, I didn't, if it has been asked I may have though | 09:27 |
| vila | poolie: I'll keep it this way, expect some road bumps :) | 09:27 |
| poolie | we could do it together on my friday evening? | 09:28 |
| vila | poolie: perfect | 09:28 |
| vila | bialix: thanks for the support :) Here, take my shirt ! | 09:29 |
| bialix | :-) | 09:30 |
| fullermd | Ack, no! Put that back on! | 09:32 |
| * vila frowns, and thought the tattoo was fun... | 09:33 | |
| fullermd | That's a tattoo? I figured you were just mauled by a bear or something... | 09:33 |
| bialix | vila: at uds I've tried to to present the idea of multiple push/pull locations. you even listened to me then. I was not sure about the idea, and in many cases bookmarks plugin is already cover many use case. but I have one more. | 09:38 |
| vila | fullermd: Complaining about my tattooer ? | 09:38 |
| vila | bialix: shoot | 09:38 |
| === spike_ is now known as spikeWRK | ||
| vila | fullermd: he *is* a bear, so what ? | 09:39 |
| * poolie is going to merge up 2.0 -> 2.1 -> 2.2 | 09:40 | |
| bialix | my use case: automatically remember on push/pull non-defaul location. it could be some temporary location used say for quick testing, or something. usually I don't care enough to create bookmarks entry for it. but it will be nice to have it remembered behind the scene | 09:40 |
| bialix | vila: so I've been trying to present at uds the idea of :push:1 :pull:2 in addition to :push and :pull aliases | 09:41 |
| bialix | only one question is: user will need the way to get the list of those locations | 09:41 |
| Glenjamin | info -v perhaps | 09:41 |
| vila | bialix: the later is easy: 'bzr config' | 09:41 |
| bialix | maybe put them into `bzr info` output | 09:41 |
| bialix | bzr config meant to list the options as well? | 09:42 |
| bialix | makes sense | 09:42 |
| vila | bialix: yes, showing option origin (bazaar, locations, branch, whatever) | 09:42 |
| bialix | re bzr info: do we have a hhoks for it? ;-) | 09:42 |
| bialix | re bzr info: do we have hooks for it? ;-) | 09:43 |
| vila | dunno about that, but a 'see bzr config for more details' when 'bzr config' exists may be appropriate (or not) | 09:43 |
| bialix | vila: I wonder is it possible to extend/override :push aliases logic from plugin | 09:44 |
| vila | bialix: otherwise enhancing bookmarks so we can define aliases at branch level and then be able to say 'bzr pull :bm:test' sounds better than defining ':push:n' | 09:44 |
| bialix | vila: bookmarks can be defined at branch level | 09:45 |
| vila | bialix: this way they could be used for bind/pull/push/merge/ whatever | 09:45 |
| bialix | or do you mean adding post_push|pull hooks there> | 09:45 |
| bialix | or do you mean adding post_push|pull hooks there? | 09:45 |
| vila | no, just using the aliases from the command line | 09:45 |
| bialix | I don't follow | 09:45 |
| bialix | do you mean adding auto-bookmarks a-la bm:push:1 | 09:46 |
| vila | no, I mean defining them manually and then using them everywhere | 09:46 |
| vila | '1' doesn't mean anything to me | 09:47 |
| bialix | my point is that I'm very lazy person to define them manually | 09:47 |
| bialix | I'd like to get them recorded in post_push hook | 09:47 |
| Glenjamin | the idea was for :push:1 to be the last non-remembered push location? | 09:47 |
| luks | bzr push URL --remember=foo | 09:47 |
| bialix | '1' is just a number | 09:47 |
| luks | bzr push bm:foo | 09:47 |
| luks | ? | 09:47 |
| vila | bzr push URL --bookmark=foo | 09:48 |
| bialix | hey luks | 09:48 |
| luks | hi | 09:48 |
| vila | bzr push URL --bookmark=foo ? | 09:48 |
| luks | well, --remember is already there | 09:48 |
| luks | I think it would make sense to reuse it | 09:48 |
| vila | bzr push URL --remember=bm:foo ? | 09:48 |
| bialix | no, guys, I don't really know when I need to re-use that URL | 09:48 |
| vila | luks: yeah, thinking out loud | 09:48 |
| bialix | and will I reuse it | 09:48 |
| bialix | just auto-record in case of | 09:49 |
| bialix | my situation: I have testing machine | 09:49 |
| bialix | so I'm just pushing to it from time to time | 09:49 |
| bialix | it's easier for me | 09:49 |
| vila | bialix: but why only push ? submit and parent and master can be good candidates | 09:49 |
| vila | too | 09:49 |
| bialix | but the remembered push URL is URL to my central server | 09:49 |
| bialix | vila: right, but push is just the starting point for discussion | 09:50 |
| bialix | I've mentioned :pull:N too | 09:50 |
| bialix | :submit have no sense for me, I dislike it very much | 09:50 |
| vila | how to know what N means | 09:50 |
| bialix | you need to look | 09:51 |
| vila | bialix: that's where you merge from generally | 09:51 |
| bialix | vila: not in my workflow | 09:51 |
| vila | bialix: hehe, that's where I wanted to go :) | 09:51 |
| bialix | so, again idea behind :push:N | 09:51 |
| vila | bialix: what if you wanted to pull from the server instead ? | 09:52 |
| bialix | I push to non-default location, this location remembered as push:1 | 09:52 |
| bialix | next time I push to another non-default location, this location remembered as push:2 | 09:52 |
| vila | bialix: or rather, what is your workflow ? pushing then going to the server to do something else ? | 09:52 |
| bialix | say I have only 3-4 slots for this auto locations | 09:52 |
| bialix | I push to the another computer where I have hardware programmer and debug tools | 09:53 |
| bialix | vila: ^ | 09:53 |
| vila | do you make commits there ? | 09:53 |
| Glenjamin | but that computer doesn't move i assume, what's wrong with a bookmark? | 09:53 |
| bialix | almost, no | 09:54 |
| vila | Glenjamin: many branches | 09:54 |
| vila | bialix: so why not *pull* from this server instead ? | 09:54 |
| bialix | Glenjamin: because I have many branches | 09:54 |
| vila | (side note) I often use bzr push URL_prefix`bzr nick` as a good trick to | 09:55 |
| vila | avoid having to came with new names every time | 09:55 |
| bialix | vila: it's just a matter of habit, I guess. to pull from the server I need to launch the browser, figure out URL and then pull. With push I need one time navigate in FAR to desired location and use it for push | 09:55 |
| vila | bialix: on the serve you should only have to issue 'bzr pull URL' once and then 'bzr pull' | 09:56 |
| bialix | vila: believe me: I have *many* branches and *many* different devices I'm working from time to time | 09:56 |
| bialix | it's not just one project and one trunk | 09:57 |
| vila | bialix: I'm asking all of this because I'm working on a plugin that should help automate a lot of these workflows and I realized that we have different kind of branches, all of them needing to behave a little bit different | 09:57 |
| bialix | ok, if you think my use case is weird, I'm okj | 09:57 |
| bialix | I will look into hacking bookmarks, it's indeed good place to put my code in | 09:57 |
| vila | a mirror only needs to be pulled, no commits, no push, a bug fix needs to be pushed, ends up merged, may require merging from parent, etc | 09:57 |
| bialix | vila: I'm coding on one machine and testing on another; sometimes I made minor changes | 09:58 |
| vila | bialix: not weird at all, I'm trying to find whether you need such auto-recorded bookmarks when there is no automatic way to use them | 09:58 |
| vila | bialix: right, so the target branch is a mirror of your working on one | 09:58 |
| bialix | yep | 09:59 |
| vila | so you can either pull from it or bind it | 09:59 |
| bialix | no, I can't | 09:59 |
| vila | can't bind ? | 09:59 |
| vila | already bound ? | 09:59 |
| bialix | I'm usually don't push unfinished code to the central servewr | 09:59 |
| bialix | can't bind because of network configuration | 10:00 |
| vila | bind to test server while working, bind to central server when finished ? | 10:00 |
| bialix | can't pull either, only push | 10:00 |
| vila | aw | 10:00 |
| bialix | there is no test servr | 10:00 |
| vila | gee, poor bialix :( | 10:00 |
| bialix | I don't feel so | 10:00 |
| bialix | I'm pretty happy with push | 10:00 |
| vila | err, I thought the discussion was about a missing feature :) | 10:01 |
| vila | bialix: and a push template where the branch nick can be automatically inserted ? (Or using append_path may be) | 10:03 |
| bialix | no, there is no push templates | 10:04 |
| vila | bialix: I know, I'm proposing one :) | 10:04 |
| bialix | I've pushed to central server: this location is already remembered, that's right | 10:04 |
| vila | so you can say: bzr push bm:test_server and the url will caontains your `bzr nick` | 10:05 |
| bialix | I've pushed to test machine, the URL could be pretty arbitrary, sometimes even from one working branch I'm pushing to 2 or more locations to test different things | 10:05 |
| Glenjamin | can you get access to the branch object in a directory service lookup? | 10:06 |
| bialix | so that non-defautl URLs I want to be remembered somehow, hust in case I will need them later | 10:06 |
| bialix | s/hust/just/ | 10:06 |
| bialix | Glenjamin: I can open a branch in current directory if needed | 10:07 |
| Glenjamin | ah yes, thats how the AliasDirectory does it | 10:07 |
| vila | looking briefly at bookmarks, it seems to allow bazaar.conf and locations.conf but not branch.conf | 10:07 |
| vila | that would be a useful addition in all cases | 10:08 |
| bialix | vila: your proposals rely on the upfront action, that's what I want to avoid | 10:08 |
| bialix | vila: re bookmarks, config = self.branch.get_config() | 10:08 |
| bialix | I think the latter get the branch.conf first | 10:08 |
| vila | bialix: sure, but you won't avoid N nor looking at its meaning before using 'bzr push bm:push:1' | 10:09 |
| bialix | luks may know better | 10:09 |
| bialix | vila: so what? running the command `bzr bookmarks` before push:N is not so hard | 10:09 |
| bialix | and should be fast | 10:09 |
| vila | bialix: it's an upfront action | 10:10 |
| bialix | at least it will be faster than navigate to browser or FAR | 10:10 |
| bialix | vila: can't agree here, it's just info request, by action I mean: configure your bookmarks/push templates somehow before you can use them | 10:11 |
| bialix | in my proposal they will be recorded without any config | 10:11 |
| bialix | if you never know will you re-use them or not | 10:12 |
| Glenjamin | how about a plugin that records all recent URLs which aren't already remembered normally. and then accessed via recent:N and "bzr recents" lists them | 10:12 |
| bialix | something like that will work too | 10:12 |
| vila | cool man, we're just discussing and I'm proposing alternatives. I'm not saying your proposal is useless or bad or anything :) | 10:13 |
| bialix | vila: ack | 10:13 |
| vila | yeah, I like Glenjamin idea | 10:13 |
| * bialix have been trying to explain the same thing | 10:13 | |
| vila | see ? That's why discussing is good :) I can be very dense :) | 10:14 |
| vila | and 'bzr recents' can be 'bzr config recent*' | 10:14 |
| bialix | see, that's good | 10:14 |
| vila | or something | 10:14 |
| Glenjamin | is bzr config new? | 10:15 |
| vila | Glenjamin: so new it doesn't exist yet :) | 10:15 |
| Glenjamin | aha | 10:15 |
| bialix | it's imaginary atm | 10:15 |
| poolie | this is kind of weird, now i've sorted out my bzr-pager thing | 10:16 |
| bialix | btw, vila, will `bzr config` make the `bzr alias` command useless? | 10:16 |
| vila | there are several related bugs floating around that can be addressed by a 'bzr config' command that can display/filter/modify config files | 10:16 |
| vila | bialix: probably | 10:16 |
| poolie | i still get a strange scriptrunner failure | 10:16 |
| vila | bialix: note that 'bzr alias' handles deleting a config var... | 10:16 |
| poolie | where ... doesn't seem to match | 10:17 |
| poolie | and it doesn't happen locally | 10:17 |
| bialix | I've tought `config` should do it to | 10:17 |
| vila | bialix: indeed | 10:17 |
| vila | poolie: doctest changes since 2.4 ? | 10:17 |
| * bialix shakes vila's hand | 10:17 | |
| * vila feels warm | 10:18 | |
| bialix | Glenjamin: do you think recent:N should be global for all branches, or local for every branch? | 10:18 |
| Glenjamin | hrm | 10:18 |
| vila | bialix: local | 10:19 |
| vila | bialix: but you raise an interesting point as it means we can't have both. If you use a config var with a list value, it can't be an aggregation of branch.conf + bazaar.conf | 10:20 |
| bialix | hm hm | 10:20 |
| bialix | unless they have different names? | 10:20 |
| vila | and you will populate all of them ? | 10:21 |
| vila | the global one will soon become a mess unless you set a maximum size.. | 10:21 |
| bialix | if I'll put them in bazaar.conf in the dedicated section then they will be different from branch.conf | 10:21 |
| poolie | vila, that's my next guess | 10:21 |
| bialix | maximum size is mandatory | 10:21 |
| vila | bialix: locations.conf, but yes | 10:21 |
| vila | bialix: that's sounds like experimentation is needed but this could fly very well... | 10:22 |
| bialix | that's why I'd like to hack quick plugin to test the idea | 10:22 |
| bialix | and recent: prefix is really cool idea | 10:23 |
| vila | poolie: ellipsis handling being a recent addition ? ISTR that the flag is or'ed with others so if it's not implemented it will fail silently | 10:23 |
| poolie | i can't believe ellipsis is recent but maybe the behaviour changed | 10:23 |
| bialix | what's difference between branch format 6 and 7? | 10:31 |
| bialix | ah, stacked support | 10:32 |
| maxb | lifeless: Do you anticipate being able to do testtools 0.9.6 -> sid soon? If not, I might make the proposed PPA jump ahead of sid, so that testtools and subunit can be considered for proposed PPA promotion at the same time as 2.2.1 | 10:33 |
| lifeless | maxb: are you a dd ? | 10:34 |
| maxb | I am not | 10:34 |
| lifeless | ah | 10:34 |
| lifeless | should be able to do it tomorrow | 10:35 |
| maxb | Nor an Ubuntu anything, actually. I did read about the MOTU process but never quite got around to producing uploads for sponsorship at a sufficient rate to start on that process | 10:39 |
| jml | poolie, hello | 10:43 |
| poolie | hello jml | 10:43 |
| jml | poolie, we should talk some time! | 10:43 |
| poolie | mm | 10:44 |
| poolie | now could be good, i was just going to warp up | 10:44 |
| poolie | *wrap | 10:44 |
| === Meths_ is now known as Meths | ||
| mgz | <poolie> now could be good, i was just going to warp up <- poolie lives is a spaceship! | 15:40 |
| mgz | *in | 15:41 |
| mgz | karma... can't enjoy other people's tyops without making your own | 15:43 |
| bialix | mgz: haha | 15:56 |
| === deryck is now known as deryck[lunch] | ||
| kpettit | What is a good text editor or ide that has bzr support built in? | 16:23 |
| kpettit | Normally I use gedit, eric or similar linux ones. | 16:23 |
| jelmer | I think there is (some) support for gedit. | 16:24 |
| kpettit | ah, didn't see it before. I'll check... | 16:24 |
| kpettit | I'm new with bzr and really like it. So I'm trying to use it more and see if there are any native editor things to help | 16:25 |
| Glenjamin | komodo ide claims to have bzr support, haven't tried it though | 16:46 |
| servilio | hi all! when having B and C as branches of A, will there be a problem when I merge back changes into A if I had cherrypicked changes between either of the branches (from B to C or the other way)? | 16:48 |
| Glenjamin | servilio: mostly no, but you can sometimes get spurious conflicts | 16:54 |
| Glenjamin | using remerge --weave or remerge --lca can help | 16:54 |
| vila | servilio: no, you may encounter warning about criss-cross merges.. whatever Glenjamin is saying :) | 16:54 |
| === deryck[lunch] is now known as deryck | ||
| === frakturfreak_ is now known as frakturfreak | ||
| === Ursinha is now known as Ursinha-lunch | ||
| vila | jml: bzr branch lp:bzr-gardener , feedback highly welcome :) | 17:37 |
| jml | vila, thanks! | 17:37 |
| jml | vila, I can't wait to try it. | 17:37 |
| vila | jml: very basic feature-wise so far but the design should scale | 17:38 |
| Glenjamin | very zen function naming | 17:40 |
| vila | Glenjamin: pfew, thanks, that was the hardest part, took me... months. Coding was far easier from there ;) | 17:41 |
| jml | vila, neat. | 17:41 |
| Glenjamin | you know you call grd.status regardless of the value of cmd? | 17:42 |
| vila | Glenjamin: good catch ! Doesn't matter yet, but thanks ! | 17:42 |
| vila | Glenjamin: fix pushed | 17:44 |
| Glenjamin | oh i see, it doesn't just call bzr status - it tells you the working tree status | 17:44 |
| Glenjamin | seems pretty tidy | 17:44 |
| vila | Glenjamin: yup, see in action during the fix above: http://paste.ubuntu.com/494278/ | 17:45 |
| Glenjamin | will pullable be true if a checkout is out of sync with its bound location? | 17:46 |
| vila | Glenjamin: hehe, tricky question already ? | 17:47 |
| vila | I already encounter case where not all branch kinds want to behave the same, | 17:47 |
| Glenjamin | i almost exclusively work with checkouts, central repo at work :) | 17:47 |
| vila | Glenjamin: light or heavy ones ? | 17:49 |
| Glenjamin | heavy | 17:49 |
| vila | anyway, they will be supported but they will require more states | 17:49 |
| Glenjamin | i'd imagine the pullable check on bound_url would be correct? | 17:50 |
| Glenjamin | although there's more states if local commits are involved | 17:50 |
| Glenjamin | which we try and avoid :) | 17:50 |
| vila | and probably also require a type concept so different checks and different actions will apply to mirrors or feature branches | 17:50 |
| Glenjamin | it might be useful to mention the other_url in the output from "merged" as well | 17:51 |
| vila | Glenjamin: 'merged' for example doesn't make a lot of sense for a mirror | 17:51 |
| vila | Glenjamin: could be, with -v, don't hesitate to file bugs | 17:52 |
| vila | Glenjamin: or even better send patches ;) | 17:52 |
| Glenjamin | i may branch and have a play about :) | 17:52 |
| vila | Glenjamin: enjoy ! | 17:52 |
| vila | jml: I started with 'status' so that scripts can use it for... whatever | 17:54 |
| jml | vila, good plan. | 17:54 |
| Glenjamin | update would be pretty cool, not sure what else though | 17:54 |
| jml | vila, I've already got a stack of ideas | 17:54 |
| vila | jml: but ideally I'd like to do: 'bzr gardener --pull --filter mirror ~/.bazaar/plugins' to update all my plugins with respect to their respective trunk | 17:55 |
| vila | jml: 'mirror' in that case would be somehow defined in a config file | 17:56 |
| jml | vila, *nod* | 17:56 |
| Glenjamin | why not make your plugins checkouts? | 17:56 |
| vila | jml: and would exclude bug fixes or feature branches | 17:56 |
| Glenjamin | lightweight ones even | 17:56 |
| jml | vila, yeah. I'm thinking now that I want my Launchpad devel, stable etc branches ignored when I do status | 17:56 |
| jml | or treated differently at least | 17:57 |
| vila | jml: you got the idea | 17:57 |
| Glenjamin | then the action is just "update all the checkouts", and your dev ones wouldn't be bound | 17:57 |
| vila | jml: I don't think the branch type can be infered from the branch.conf urls, so I plan to rely on an explicit typing (which can be based on path: bzr/experimental, bzr/bugs, bzr/releases, etc) | 17:58 |
| vila | Glenjamin: yup, that could work | 17:58 |
| vila | Glenjamin: but I tend to use either plain branches or bound branches or looms | 17:59 |
| jml | vila, yeah. either types or something more capability-based | 17:59 |
| vila | jml: I haven't thought about looms yet | 17:59 |
| jml | vila, e.g. "for devel, *do* check pullability, *don't* check merging" etc. | 17:59 |
| Glenjamin | i don't think i've ever used looms | 17:59 |
| vila | jml: yeah | 17:59 |
| vila | jml: type and actions are the ones I want to put in config | 18:00 |
| Glenjamin | can you "tag" a branch in some way, then filter by those tags? (not revision tags) | 18:00 |
| vila | Glenjamin: via configuration, that's the plan | 18:00 |
| vila | Glenjamin: so most of the time you could use 'bzr gardener' when working from a root (a root in a garden, it all makes sense !!!!111@@) or specify action when needed : 'bzr gardener --update this-branch' | 18:02 |
| Glenjamin | bzr gardener --update this-branch is equivalent to cd this-branch && bzr update ? | 18:03 |
| vila | jml: oh, I tried to use transports everywhere so branches could be scanned remotely too, but I don't know if there is a simple way to scan for lp:~vila/bzr | 18:04 |
| vila | Glenjamin: yeah, silly example | 18:04 |
| Glenjamin | the filter stuff seems like a good approach | 18:04 |
| === Ursinha-lunch is now known as Ursinha | ||
| bfrog | why is launchpad so slow to clone from? | 18:39 |
| bfrog | it never fails to be like 5kbps | 18:39 |
| lifeless | bfrog: there is a bug open I think; we were looking at firewall issues | 19:45 |
| lifeless | elmo: has that firewall you suspected of being LFP-sensitive been upgraded to lucid yet? | 19:45 |
| maxb | LFP? | 20:04 |
| lifeless | long fat pipes | 20:08 |
| marienz | huh, I could've sworn there was a command that printed the path to your plugin dir, so you don't have to look it up in the documentation | 20:26 |
| james_w | it's in bzr version output isn't it? | 20:26 |
| lifeless | bzr --verison | 20:26 |
| marienz | so it is! thanks | 20:27 |
| james_w | ok, not exactly, but close enough | 20:27 |
| marienz | I forgot the "2.0" | 20:27 |
| * marienz is not normally on windows, and it shows | 20:27 | |
| maxb | Where might I discover whether InventoryLink.symlink_target is a bytestring or unicode string, other than by setting up a testcase to investigate? | 20:30 |
| mgz | jam: it appears launchpad still doesn't like you | 20:49 |
| jam | mgz: yeah.... no love on the emails | 20:49 |
| jam | I don't know why, vincent looked at my emails and they work on his end | 20:50 |
| mgz | they seems fine to me too, might just need to file a bug against launchpad | 20:51 |
| jelmer | maxb: just checking - if you're working on that bzr-svn bug, please assign the bug to yourself | 20:52 |
| maxb | jelmer: I was doing preliminary investigation.... which has turned into being about to propose a merge :-) | 20:53 |
| maxb | Is it really a sensible thing to do, to repack every 1000 revisions during a single 'bzr branch' (from svn) operation? | 20:55 |
| jelmer | maxb: it's what happens when you commit a write group | 20:58 |
| maxb | yes, but is it *sensible* | 21:04 |
| lifeless | maxb: yes | 21:04 |
| lifeless | maxb: each pack adds linear probing | 21:04 |
| lifeless | maxb: within a pack is log(200) or so | 21:04 |
| jelmer | maxb: any luck? | 21:22 |
| jam | vila: if you are still around, is PQM basically deadlocked without your fix? I've been trying to land some patches and I'm getting failures | 21:24 |
| mgz | the random failure jam? if you keep trying you may have luck, but it's certainly been easier to hit recently. | 21:25 |
| jam | mgz: Well, it takes a long time for t-bird to successfully finish reading the 7MB email, and then to pipe it through subprocess, etc | 21:26 |
| jam | faster to chat here :) | 21:26 |
| jam | but I'll check | 21:26 |
| mgz | ...I really think that's what needs fixing. PQM should be sending a nice, short, summary, not a machine readable dump. | 21:26 |
| mgz | Is that something I can poke, or is the code somewhere obscure? | 21:27 |
| jam | mgz: well if my patch is extended to also strip the logs from successful runs, I think we'll have it | 21:28 |
| mgz | did you see my last comment/ | 21:29 |
| mgz | it looks like there's a line that tries to do that already, but in a different way to yours. | 21:29 |
| jam | mgz: I saw a comment, I'm pretty sure that line doesn't work :) | 21:29 |
| jam | It may be a 'race' thing. | 21:29 |
| mgz | I can well believe it, the log code has been seriously changed several times. | 21:29 |
| jam | oh, and the failing test was something else. The submitter used "\t" in his code, rather than just " " | 21:30 |
| mgz | gah! :) | 21:30 |
| mgz | ...I hope it wasn't me. | 21:30 |
| jam | mgz: no, knittl probably just had his editor configured to use tabs when possible | 21:31 |
| mgz | phew. I juggle my editor, and don't always have the right project style either. | 21:32 |
| knittl | uh | 21:32 |
| knittl | maybe a tab slipped in when writing the test | 21:33 |
| knittl | i even made vim highlight mixed spaces and tabs | 21:33 |
| mgz | knittl: you can also use `./bzr selftest -s bt.test_source` | 21:34 |
| maxb | jelmer: Yes, I've convinced myself I do need to convert unicode to bytestring, and pushed a followup | 21:34 |
| knittl | mgz: ok, i know the next time | 21:35 |
| jelmer | maxb: That still can't be right though, you need a "link " prefix | 21:35 |
| jelmer | maxb: argh, nevermind | 21:35 |
| maxb | yes, it's in there | 21:35 |
| maxb | I gloried in the fact that it wants an iterable :-) | 21:36 |
| jelmer | maxb: hehe | 21:36 |
| jelmer | maxb: could I persuade you to add a test that shows this fixes the bug? | 21:37 |
| * maxb goes hunting for suitable test fixtures to crib from | 21:39 | |
| jelmer | there should be some in tests/test_fetch.py | 21:40 |
| mgz | ...I've been looking at bzrlib.tests for too long, can't keep in mind which bits need explaining | 21:46 |
| maxb | jelmer: Now I'm confused. test_fetch_special_unbecomes_symlink ought to cover this case :-/ | 21:48 |
| jam | knittl: :set et<enter> :retab<enter> | 21:49 |
| jam | et == expandtab | 21:50 |
| jelmer | maxb: nope, it doesn't remove the svn:special bit | 21:50 |
| knittl | jam: for future commits? | 21:50 |
| jelmer | maxb: although that shouldn't really matter in this case I guess | 21:50 |
| jam | knittl: that is just the easy way to clean up your current file. ":set et" is a good way to configure vim to always expand tabs into spaces | 21:50 |
| jam | This is my default setting, in ~/.vimrc: | 21:51 |
| jam | set tw=79 sw=4 sts=4 ts=4 et ai si | 21:51 |
| jelmer | maxb: it's probably the text cache that's saving us there | 21:51 |
| knittl | jam: well, i usually prefer using tabs | 21:51 |
| jam | defaults to wrapping at 79 chars, soft stops at 4 chars, but using spaces rather than tabs | 21:51 |
| jam | ts=8 is probably better | 21:51 |
| jam | knittl: sure. I think you can also put something in ~/.vim/filetype.vim | 21:51 |
| maxb | jelmer: hmmm. right. I shall attempt to figure out how to defeat the cache, then | 21:51 |
| jam | which uses a regex to match things under "*/bzr* | 21:52 |
| jam | i know I have this there: | 21:52 |
| jam | au BufNewFile,BufRead *.py match Error /\s\+$/ | 21:52 |
| jam | to watch out for trailing whitespace | 21:52 |
| knittl | jam: i also match trailing space. and space before tabs. | 21:54 |
| knittl | which doesn't match tabs only and vim used tabs when copying those two lines (the pydoc string uses spaces …) | 21:54 |
| jam | knittl: sure, so you see *mixed* content, but not one-or-the-other | 21:55 |
| jam | I thought there was a python 'mode' that checked if you used mixed-within-the-file | 21:55 |
| jam | The problem I had with the "mixed-within-a-line" was wrapped lines | 21:56 |
| jam | since I might indent them to a non-tab-multiple | 21:56 |
| jam | Though I've since switched to all spaces | 21:56 |
| maxb | jelmer: It is acceptable to just copypaste test_fetch_special_unbecomes_symlink, and replace the single call to self.copy_content(source, target) with two, the first with an additional revision id parameter to only copy the first revision? | 22:02 |
| knittl | jam: can i amend the old revision? | 22:05 |
| knittl | i've only seen the mail now | 22:05 |
| jam | knittl: you can, 'bzr uncommit; fix; bzr commit" | 22:05 |
| knittl | and then push without problems? | 22:05 |
| jam | but you might as well just do a new commit, and then push | 22:05 |
| jam | knittl: you would have to 'bzr push --overwrite' | 22:05 |
| knittl | can i reuse the commmit message? | 22:05 |
| knittl | jam: what is the recommended approach here? | 22:06 |
| jam | knittl: *I* would just create a new revision with "fixup whitespace issues" and push that | 22:06 |
| jam | some people like to collapse history, I'm not really one of those | 22:06 |
| jam | (collapsing happens by having a 'mainline' where the tests always pass, etc. Individual branches don't have to be clean) | 22:06 |
| knittl | ok, it's pushed | 22:07 |
| jelmer | maxb: sure | 22:11 |
| jam | knittl: submitted again | 22:12 |
| knittl | k, thanks | 22:12 |
| jelmer | maxb: These tests need some more rigurous refactoring at some point. Right now they're all basically blackbox tests (they set up some svn situation and run fetch). I'd like to do more testing of the individual classes. | 22:12 |
| maxb | pushed | 22:16 |
| jelmer | maxb: I don't see anything... | 22:30 |
| maxb | jelmer: erm, yes, that would be my fault. I also pushed 82000 revisions of kdebase and have cause "some" delay in branch scanning | 22:32 |
| jelmer | hehe | 22:32 |
| jelmer | Those revisions should already be in the revision table on launchpad though | 22:32 |
| jelmer | ah, kdebase.. sorry | 22:32 |
| maxb | Question for you, though - why do various layout methods take an optional project parameter - and why is it sometimes defaulted to None and sometimes to "" ? | 22:32 |
| jelmer | maxb: Depends on the methods implementation. | 22:39 |
| maxb | As in, it's None if someone was prepared to assert the parameter was genuinely unused? | 22:39 |
| maxb | btw, is https://code.launchpad.net/~maxb/bzr-svn/unused/+merge/32822 on your radar to look at at some point (it's just unused code removal) ? | 22:42 |
| jelmer | maxb: Sorry, I saw it earlier and had a brief look but not enough time to look at it in more detail. | 22:45 |
| jelmer | maxb: IIRC it removes get_rhs_ancestors(), which I'd like to keep around because I'd like to use it for optimization in the future. | 22:46 |
| maxb | ah, ok. I killed it because it was unused, and only had a fileprops-based implementation | 22:47 |
| jelmer | maxb: wrt project in the layout methods; some methods don't actually care about what project is specified for example, or their project value is a prefix | 22:48 |
| jelmer | maxb: it really should only have a fileprops-based implementation, but would allow us to see what revisions are present in a svn branch. | 22:49 |
| maxb | ok, I'll rewrite history of that branch to keep get_rhs_ancestors | 22:58 |
| === Ursinha is now known as Ursinha-afk | ||
| poolie | hi jam, maxb, jelmer | 23:06 |
| maxb | hello | 23:06 |
| jelmer | 'morning poolie | 23:06 |
| dlee | If I check out with Bzr from one svn branch, then check out separately from another svn branch of the same project, assuming the two svn branches share a lot of common revisions, will I profit by putting my two Bzr checkouts in a shared repo, or will Bzr connect the common svn revisions that way? | 23:13 |
| dlee | I read a lot about this problem a long time ago, but I'm not sure of current behavior. | 23:14 |
| maxb | Yes you will save time and diskspace by doing both within a shared repository | 23:14 |
| dlee | Cool! I wasn't sure if the bzr revids would map repeatably to the same svn revisions. | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!