| lifeless | poolie: it rang out, trying again | 00:07 |
|---|---|---|
| === mw is now known as mw|out | ||
| lifeless | 68 failing now | 00:57 |
| lifeless | 8 | 01:20 |
| === kiko is now known as kiko-zzz | ||
| poolie | heads down on ssh locking | 01:29 |
| lifeless | woo | 01:58 |
| lifeless | full test time, think its finally hammered into submission | 01:58 |
| lifeless | lunch time too | 02:01 |
| thatch | lifeless: when you get some free time, can I harass you about the get_parent_map/old-server reauthenticate-over-ssh issue again? | 02:02 |
| jml | why doesn't this work: $ bzr log -r date:2008-03-14.. | 02:05 |
| jml | bzr: ERROR: Requested revision: u'date:2008-03-14' does not exist in branch: BzrBranch6(...) | 02:05 |
| poolie | note it is the first one _after_ that date according to the source | 02:06 |
| jml | still, it seems a strange error | 02:06 |
| poolie | you'd rather "no revisions after xxx"? | 02:08 |
| poolie | anyhow is it in fact true there are no revisions on or after that date? | 02:08 |
| poolie | or did you expect it to just log nothing? | 02:08 |
| * Odd_Bloke would expect it to log nothing. | 02:28 | |
| jelmer | Logging nothing or saying "no revisions after xxx" both make sense to me | 02:29 |
| Odd_Bloke | Logging nothing is more consistent with what we do in an empty branch. | 02:29 |
| jelmer | printing the error message avoids the user wondering why there was nothing logged though | 02:31 |
| jelmer | similarly, I wouldn't be opposed to printing "Empty branch" when running bzr log in an empty branch | 02:31 |
| Odd_Bloke | Nor I, I was just commenting on current behaviour. | 02:33 |
| Odd_Bloke | I can't say I'm massively bothered either way. | 02:33 |
| jml | poolie: there are no revisions after that date | 02:34 |
| jml | what jelmer said is what I think (<jelmer> Logging nothing or saying "no revisions after xxx" both make sense to me) | 02:35 |
| awilkins | I also find the default silence of bzr to be a little eerie sometimes | 02:44 |
| jml | remind me how to do this: I've made some changes in a working tree, I haven't committed, and now I realise I want them in a new branch. | 02:52 |
| mwhudson | jml: make a new branch | 02:52 |
| mwhudson | cd into it | 02:52 |
| mwhudson | bzr merge --uncommitted ../old-branch | 02:52 |
| bob2 | bzr reconfigure --checkout ; bzr branch . wherever ; bzr switch ../wherver | 02:53 |
| jml | mwhudson: thanks. | 02:53 |
| lifeless | ok really the last time. fingers crossed | 03:38 |
| abentley | lifeless: why do you not want the inventory_validator_type in Revision objects? | 03:41 |
| lifeless | I think its making an abstraction violation worse | 03:42 |
| abentley | I would be quite happy to ditch the validator entirely, but if we're keeping it, I think we need to know what it means. | 03:43 |
| lifeless | I think it is happily hidden behind Repository/Revision themselves. | 03:43 |
| abentley | The validator? | 03:43 |
| lifeless | yes | 03:43 |
| lifeless | its exposed at the moment, and only well defined some of the time, but all the uses for it are things that should be methods on either Revision or (probably better given our current object use style) Repository | 03:44 |
| abentley | So if I were to introduce a new repo format whose revisions didn't have validators in their serialization, that would be fine with you? | 03:45 |
| lifeless | if we can somehow validate the revisions without that, in principle, yes. | 03:45 |
| abentley | You mean "validate the inventories"? | 03:45 |
| lifeless | no, I mean the revision - which is a transitive validation of all the stored data | 03:46 |
| abentley | The inventory_sha1 does not validate the revision. | 03:46 |
| lifeless | thats true | 03:46 |
| lifeless | I was making a more general statement. I really precise one would be 'if it is no less capable of validating the inventory for that revision', but thats much more awkward | 03:47 |
| abentley | lifeless: It sounds like you're significantly increasing the difficulty level. | 03:48 |
| abentley | Validating the inventory is one thing-- validating the whole revision is another. | 03:48 |
| lifeless | right now we get revision validation via the revision signature | 03:48 |
| lifeless | clearly if thats not there we only have validation of the data the revision references | 03:48 |
| lifeless | and I did not intend to raise the barrier higher than that | 03:49 |
| abentley | I don't really get your second statement. | 03:51 |
| lifeless | ok, well lets start over | 03:51 |
| lifeless | are you planning on removing inventory validation? | 03:51 |
| lifeless | (aka not reenabling it) | 03:52 |
| abentley | No. I was planning to ignore it until you started saying this was a blocker for rich-root-pack | 03:52 |
| lifeless | I think its a pretty severe defect in the current code | 03:53 |
| abentley | Now I want to do the minimum necessary to keep you happy and ensure we don't have this problem again. | 03:53 |
| lifeless | I will be happy if: pack-rich-root repositories validate their inventory | 03:54 |
| lifeless | during 'check' | 03:54 |
| abentley | If I simply introduce a new revision serialization just to indicate the inventory serialization, that's going to be wasteful. | 03:54 |
| lifeless | such that an edited inventory causes a check failure | 03:54 |
| abentley | Because I'll have to introduce at least two, and possibly many more as time goes on. | 03:54 |
| lifeless | I don't think you need to introduce a new serialisation, but you were adamant that you needed to | 03:54 |
| abentley | If we don't know what a validator is, we can't hope to use it correctly. | 03:55 |
| lifeless | erm | 03:55 |
| lifeless | clearly that statement is true, but we know what validators we have | 03:55 |
| lifeless | I wrote the code to fix things so that I would be happy | 03:56 |
| abentley | I think that sticking the validator in the revision is horrid. It's local data; it doesn't belong there. | 03:57 |
| lifeless | its very simple: change repository.get_inventory_sha to actually use the text, and change fetch to update the sha1 during rich root tree root addition | 03:57 |
| lifeless | those two changes, in total, made me happy. | 03:57 |
| abentley | At the cost of making me tremendously unhappy. | 03:57 |
| abentley | Because bazaar is a distributed system, and values should really be write-once. | 03:58 |
| lifeless | which is not an acceptable cost | 03:58 |
| lifeless | well given that the inventory is being rewritten *already* | 03:58 |
| lifeless | the inventory validator being updated is a consequence of the rewrite being done by the plain->rich root fetcher | 03:59 |
| abentley | lifeless: it is being rewritten, true, but in a deterministic way. The new values are implied by the existing values. | 04:00 |
| lifeless | the same holds for the inventory sha change | 04:00 |
| lifeless | in the format under discussion the new inventory serialisation is deterministic, as is the resulting sha | 04:00 |
| abentley | The problem with the inventory sha change is that it is tied to the inventory format, but affects the revision format. | 04:01 |
| abentley | If the revision format implied that validator, that would be acceptable to me. | 04:01 |
| lifeless | uhm, those two things are part of a repository format though; they can't be used in isolation or arbitrary combinations | 04:02 |
| lifeless | you can't use an original format revision serialiser today | 04:02 |
| abentley | You can shove anything in a bundle, and it will translate as necessary into the target serializers. | 04:02 |
| lifeless | directly? or via install_revisions? bundles should not be serialising, they should be using the object model | 04:03 |
| abentley | I would have to check. | 04:04 |
| lifeless | if they use serializers directly they are profoundly hostile to e.g. bzr-svn | 04:04 |
| lifeless | serialisers are private on a repository | 04:05 |
| abentley | Well, it looks like it only handles inventory, not revisions. | 04:06 |
| abentley | If the repository doesn't use the same inventory serializer as the bundle, then it converts it to an object and calls Repository.add_inventory | 04:07 |
| lifeless | so the basic thing here seems to be - we have individually versioned formats for code reuse and to catch some cases of bugs; There are dependencies between our formats such that changing anything about e.g. inventory changes the value of fields in e.g. revision | 04:09 |
| lifeless | so yes, I think you need a new revision format to be strictly correct; the new format needs no changes other than a version string bump IMO. | 04:09 |
| lifeless | and I think every inventory change will do that if you want to be able to analyse serialised revisions outside of the repository that owns them. (I think that being able to do that is of questionable value FWIW). | 04:10 |
| abentley | And as you can imagine, I don't want that kind of churn. | 04:11 |
| abentley | I'd rather specify what the validator means. | 04:12 |
| lifeless | maybe I don't understand what you mean | 04:13 |
| lifeless | but unless you define the validator as being an arbitrary datatype (and thus needing a format bump _anyway_ when it changes), I don't see it preventing any churn | 04:13 |
| j1mc | hello, i've kind of goofed up my bzr history on the bzr repository/server. i didn't do a bzr bind, and several other people committed changes that i just merged in, and then pushed up a few of my changes. the content is accurate, but the history is fscked. is there a way to fix/correct the history? | 04:14 |
| poolie | what do you want it to look like? | 04:15 |
| j1mc | i want the prior history to be shown. 108 revisions were removed from the branch, and replaced by my generic 'a bunch of updates' commit messages. | 04:15 |
| j1mc | :( | 04:16 |
| lifeless | j1mc: sure thing, what you need to do is do 'bzr branch -r revid:XXX trunk local; cd local; bzr merge -r revid:YYYY ../trunk; bzr commit; bzr push --overwrite ../trunk' | 04:16 |
| j1mc | lifeless, can you please explain to me what that will do? | 04:16 |
| lifeless | j1mc: where XXX is the revision id (not revision number) of the last commit that should have been on the mainline before you pushed | 04:16 |
| j1mc | (thanks, btw) | 04:16 |
| lifeless | j1mc: and YYY is the revision id of the tip of your branch (possibly even the current mainline tip) | 04:17 |
| lifeless | j1mc: what it will do is do the merge that bind would have done via 'bzr update' | 04:17 |
| lifeless | j1mc: you can get revision ids via bzr log --show-ids | 04:18 |
| j1mc | lifeless: this is on launchpad, will it cause 108 emails to be sent out with the updated revision history | 04:18 |
| j1mc | s/updated/corrected | 04:18 |
| lifeless | j1mc: presumably :(. thumper ^ | 04:18 |
| j1mc | haha | 04:18 |
| lifeless | after you ahve done this | 04:19 |
| lifeless | there is an option you can turn on in your branch to prevent this mistake | 04:19 |
| lifeless | its in the manual I believe | 04:19 |
| kgoetz | Kamping_Kaiser: look at that ^^ | 04:20 |
| j1mc | thanks... | 04:20 |
| abentley | lifeless: If we have different types of inventories, we can just specify the validator type, e.g. "inventory6sha1" | 04:20 |
| abentley | That means we don't need a different format for every inventory format. | 04:20 |
| lifeless | abentley: so the validator becomes a tuple essentially - (type, validator) | 04:20 |
| abentley | Sure. | 04:21 |
| lifeless | abentley: this seems redundant to me, because the repository already knows the type. Which is why I don't think we need a new revision format in the first place. | 04:21 |
| abentley | The bundle does not know the type. It is not in a repository format. | 04:22 |
| lifeless | abentley: but if you feel its essential in the disk format, go ahead I guess. I really think its wrong, but we seem to be at an impasse | 04:23 |
| lifeless | I think bundles are buggy then (grin-joke) | 04:24 |
| lifeless | well, play on words. I really do think that a bundle has the same duty of integrity as any other revision storage format | 04:24 |
| abentley | A few minutes ago, you said "I think you need a new revision format to be strictly correct" | 04:24 |
| lifeless | I can see the logic for why you want one; I don't think its needed because its conflating two different things | 04:25 |
| abentley | lifeless: Bundles have very good integrity checking. | 04:25 |
| lifeless | good; so they _must_ know whether they came from a rich root or non rich root repository | 04:26 |
| lifeless | and if they know that, they know whether the sha in their revision is for a rich root or plain inventory | 04:26 |
| lifeless | sha for the inventory in their revision | 04:26 |
| abentley | The one does not follow from the other. | 04:27 |
| lifeless | given our data model I think it does | 04:27 |
| abentley | They store a sha1 of the expected text output. | 04:27 |
| abentley | The sha1 of the fulltext. | 04:27 |
| abentley | But this is stored in private data-- the text of the revision is completely ignored. | 04:28 |
| lifeless | which clearly will differ if the source and target repository differ | 04:29 |
| abentley | If the source and target differ in format, it generates the fulltext of the source, verifies it, and then convert it into the target format. | 04:30 |
| lifeless | where you mean 'serialisation of a single object type' by format | 04:30 |
| lifeless | and when I talk formats I mean 'entire repository' | 04:30 |
| abentley | Right. | 04:30 |
| lifeless | if bundles had the repository format there would be no problem, you wouldn't try to use a fast path that doesn't fit | 04:31 |
| abentley | Or alternatively, if inventory format didn't affect revision contents, there would also be no problem-- we could mix and match. | 04:32 |
| lifeless | anyhow, we agreed on a compromise in London, which was a new revision format, so lets do that. I'm really unkeen on inventory_validator being (type, opaque_data), because you have to have a new bzr to read new types and validate them anyway | 04:32 |
| lifeless | so I don't see that we gain anything over just revving the revision serialiser itself; which is trivial and tiny amount of code | 04:32 |
| abentley | lifeless: Okay, fine. I'll implement two revision formats, one for each inventory format. | 04:35 |
| abentley | But *you* get to implement the new revision format when you do journalled inventories. | 04:36 |
| lifeless | surely its | 04:36 |
| lifeless | class SubX(parent): | 04:36 |
| lifeless | revision_version = 7 | 04:36 |
| lifeless | class SubY(parent): | 04:36 |
| lifeless | revision_version = 8 | 04:37 |
| abentley | I have no idea. | 04:38 |
| abentley | I suspect it's a bit more than that. | 04:38 |
| abentley | Once you've implemented the serializers, you've got to update the places they're used. | 04:38 |
| lifeless | assuming you ditch knit based rich root and subtrees | 04:39 |
| lifeless | which I recommend | 04:39 |
| lifeless | then its just a new subclass of the two Pack repo formats, with a single line override in the same manner | 04:39 |
| j1mc | lifeless: you responded pretty quickly to my "history" issue above. is that a common situation? | 04:42 |
| lifeless | j1mc: no | 04:42 |
| j1mc | you just know bzr well. and other people bind their branches.... so it doesn't happen to them? | 04:43 |
| abentley | lifeless: And registering the formats in xml_serializer.format_registry, and I'm pretty sure they pop up in some other places. | 04:43 |
| lifeless | abentley: ok, so 10 lines then ? :] | 04:44 |
| lifeless | j1mc: I'm one of the old hands yeah :) | 04:44 |
| lifeless | ok | 04:45 |
| j1mc | :) thanks so much for your help, lifeless | 04:45 |
| lifeless | I've nuked VersionedFile.get_parents, now to make the implementation within knit.py smooth. Then a patch we shall see. | 04:45 |
| j1mc | btw, i'm in the general vicinity of john meinel (sp?). i've met him once before... he's a good guy. | 04:45 |
| lifeless | j1mc: cool, yes he is | 04:46 |
| lifeless | abentley: btw, export-loom, am I expecting a new patch, or should I remove the default and commit myself? | 04:46 |
| abentley | Please go ahead. | 04:46 |
| lifeless | abentley: will do | 04:47 |
| abentley | I'm for bed. | 04:48 |
| lifeless | wow | 04:48 |
| lifeless | must be very late now | 04:48 |
| jelmer | hmm, I think I forgot something.. | 04:49 |
| abentley | Eh, not even 1:00am | 04:49 |
| lifeless | jelmer: hah! | 04:49 |
| Odd_Bloke | jelmer: Was it 'going to bed'? Because I've done exactly the same... | 04:49 |
| jelmer | Odd_Bloke: :-) | 04:51 |
| Symgeosis | I'm new to Bazaar and I'm having problems figuring out how to pull an older revision of a branch. Could somebody help me out with the command? | 04:54 |
| lifeless | Symgeosis: bzr pull -r revno --overwrite | 04:58 |
| Symgeosis | Thanks Lifeless. | 04:58 |
| j1mc | lifeless: i have an additional question about your prior suggestion. | 05:01 |
| thumper | lifeless: I lost the context, can you explain (launchpad emails)? | 05:01 |
| j1mc | you wrote, "and YYY is the revision id of the tip of your branch (possibly even the current mainline tip)" | 05:01 |
| j1mc | would that be a revid of one of the earlier revisions? | 05:02 |
| j1mc | i don't know what a branch "tip" is | 05:02 |
| j1mc | thumper: http://pastebin.ca/948485 (context) | 05:03 |
| Odd_Bloke | j1mc: The branch tip is the revision that the branch points to. The head, in git terminology (I think). | 05:03 |
| j1mc | Odd_Bloke: thanks, but i still don't quite understand. | 05:05 |
| thumper | j1mc: you could set you subscription level to "No email" for the change and then edit it back afterwards to avoid the email | 05:05 |
| poolie | hm, so should i do this locking change by passing a parameter down saying "don't wait", or by having the smartserver set a global option not to wait for locks? | 05:11 |
| poolie | relying on global state is undesirable, certainly | 05:12 |
| poolie | otoh it really should not normally be waiting | 05:12 |
| j1mc | lifeless: sorry to keep bugging you (if you are even still around), but i'm having a hard time knowing what i should be selecting as the second (XXX) revid. | 05:13 |
| j1mc | would it be a recent revid (from just before i goofed up the history)? or one of the ones from earlier in the history? | 05:14 |
| bob2 | do you mean second (YYY)? | 05:18 |
| j1mc | bob2: yes, the second YYY | 05:19 |
| poolie | j1mc: it's the last one that had what you consider "good" history | 05:19 |
| poolie | probably the one just before your merge | 05:19 |
| bob2 | YYY should be the revid of the top of your branch (second part of the output of bzr revision-info) | 05:20 |
| j1mc | maybe it would help if i posted the last good revision to pastebin | 05:21 |
| j1mc | http://pastebin.ca/948518 | 05:21 |
| j1mc | 3651.1.108 is the last good revno | 05:22 |
| j1mc | i think i would use that for the XXX part | 05:22 |
| bob2 | (that's a revision number, not a revision id) | 05:23 |
| j1mc | bob2: correct | 05:23 |
| j1mc | revision-id:asommer70... | 05:23 |
| j1mc | that's the revid | 05:23 |
| j1mc | i'm hesitant to use the "asommer70@gmail.com-20080318135647-hbbpj5bl819nu1oa" as both XXX and YYY, but that's what i think is being suggested. | 05:24 |
| bob2 | XXX is supposed to be the last revision id before things went wrong, YYY is the tip of your currently wrong branch (which, as lifeless said, might still be the tip of the lp trunk) | 05:25 |
| bob2 | afaict | 05:26 |
| j1mc | so in that example, my "incorrec" push has a revid of "jwcampbell@gmail.com-20080319032336-pyefchhxbdwyrsjp" that would be YYY | 05:27 |
| j1mc | (it is the most recent push to the branch" | 05:27 |
| j1mc | (sorry for the typos, it's late) | 05:27 |
| j1mc | bzr branch -r revid:asommer70@gmail.com-20080318135647-hbbpj5bl819nu1oa trunk local; cd local; bzr merge -r revid:jwcampbell@gmail.com-20080319032336-pyefchhxbdwyrsjp ../trunk; bzr commit; bzr push --overwrite ../trunk | 05:32 |
| bob2 | does "bzr log" in trunk show what you want it to show? | 05:33 |
| lifeless | hi soerry | 05:33 |
| lifeless | been on phone | 05:33 |
| j1mc | bob2: yes. | 05:33 |
| j1mc | on my local copy | 05:34 |
| j1mc | lifeless: np | 05:34 |
| lifeless | j1mc: so | 05:34 |
| lifeless | j1mc: to find XXX, run bzr log --show-ids | 05:34 |
| lifeless | j1mc: somewhere amongst your merged revisions will be a commit to the trunk that *should* be on the mainline (that is have a whole number revision number, with no dots), but that is shown nested | 05:35 |
| lifeless | j1mc: the first one of those, is the one you want as XXX | 05:35 |
| j1mc | http://pastebin.ca/948518 | 05:35 |
| j1mc | the first one listed is the most recent commit and push to the branch. it's the one that screwed everything up. the one after that is the last good one | 05:36 |
| j1mc | based on that, i think this is correct: | 05:36 |
| j1mc | bzr branch -r revid:asommer70@gmail.com-20080318135647-hbbpj5bl819nu1oa trunk local; cd local; bzr merge -r revid:jwcampbell@gmail.com-20080319032336-pyefchhxbdwyrsjp ../trunk; bzr commit; bzr push --overwrite ../trunk | 05:36 |
| j1mc | where "asomer..." is the last good one | 05:37 |
| lifeless | j1mc: ok, then use asommer70@gmail.com-20080318135647-hbbpj5bl819nu1oa as XXX | 05:37 |
| j1mc | and where "jwcampbell..." is the tip, or most recent commit | 05:37 |
| lifeless | and whatever revision id revno 3666 has for YYYY | 05:37 |
| j1mc | lifeless: in my log, there is no 3666 | 05:44 |
| lifeless | uhm | 05:45 |
| lifeless | 3667 and after a while 3666 and so on | 05:45 |
| lifeless | what command are ou running | 05:45 |
| lifeless | to get the log | 05:45 |
| lifeless | do you have an alias set overriding revision selection | 05:45 |
| j1mc | bzr log --show-ids > ~/Desktop/ids | 05:45 |
| j1mc | no | 05:45 |
| lifeless | then look further down the file :) | 05:46 |
| j1mc | :) got it | 05:46 |
| poolie | lifeless: i see the smart server locking tests specifically ask for knit repositories | 05:53 |
| poolie | do you suppose that is an accident, or because they want one that has more locking than packs? | 05:54 |
| poolie | hm | 05:54 |
| lifeless | the former I believe | 05:54 |
| poolie | i'll mail spiv | 05:55 |
| lifeless | annotate doesn't blame me ? | 05:56 |
| * poolie looks | 05:56 | |
| poolie | btw did you know gannotate supports Ctrl+F | 05:56 |
| lifeless | yes | 05:56 |
| poolie | ah yes, it is you | 05:57 |
| poolie | > Make test_smart use specific formats as needed to exercise locked and unlocked repositories. | 05:57 |
| poolie | so do you still want it? | 05:59 |
| lifeless | yes thanks | 05:59 |
| lifeless | running against packs may be interesting too, but running against knits is essential until we stop using them. | 06:00 |
| poolie | i'm confused | 06:00 |
| poolie | you said it was an accident | 06:00 |
| poolie | but you still want it? | 06:00 |
| lifeless | oh | 06:00 |
| lifeless | I meant deliberate;) | 06:00 |
| lifeless | gee look at the time, gotta go :P | 06:01 |
| lifeless | (seriously, I woke at 4am, I am rather shattered - getting former and latter confused is not good. I'm going to go have a cat nap) | 06:03 |
| kgoetz | hehehe | 06:06 |
| poolie | sure | 06:13 |
| lifeless | actually, going to call it a work-day | 06:29 |
| lifeless | I need to dig up the python C api and turn a list to a tuple to finish this patch | 06:31 |
| j1mc | lifeless: you rock. your command helped me to fix it. | 06:47 |
| kgoetz | \o/ | 06:48 |
| jml_ | hi ho | 07:01 |
| poolie | hi | 07:01 |
| === jml_ is now known as jml | ||
| Odd_Bloke | So many jmls! | 07:02 |
| j1mc | Odd_Bloke: ... I'm j1mc :) | 07:03 |
| j1mc | but yeah... kind of strange | 07:03 |
| jml | I'm on a crippled system atm. | 07:04 |
| Odd_Bloke | jml: :( | 07:06 |
| Odd_Bloke | Night! | 07:13 |
| siretart | is 'bzr selftest' supposed to work using the 1.3rc1 debian package? | 08:26 |
| james_w | siretart: are you seeing failures? | 09:03 |
| siretart | james_w: http://paste.debian.net/51435 | 09:35 |
| james_w | siretart: wow. you're not in a directory with a directory named "tests" or a "tests.py" are you? | 09:39 |
| siretart | james_w: no, I'm not | 09:42 |
| siretart | bzr & bzrtools seemed to work anyways, so I've decided to just upload bzrtools 1.3.0 to sid | 09:43 |
| james_w | I saw that, thanks. | 09:43 |
| siretart | is that perhaps because of python 2.4 instead of python 2.5? | 09:45 |
| siretart | no, doesn't seem so | 09:45 |
| james_w | is tests/* shipped in the binary package? | 09:47 |
| siretart | ha, it seems that builddeb is breaking selftest | 09:47 |
| siretart | after removing bzr-builddeb, the 'selftest' command works fine again | 09:47 |
| james_w | ah, you're not doing bzr --no-plugins selftest | 09:47 |
| siretart | well, I wanted to run the selftests on bzrtools | 09:47 |
| james_w | ok. I want to prepare a builddeb upload today, and it should fix all of this nonsense. | 09:47 |
| siretart | great! | 09:47 |
| james_w | sorry for breaking it. | 09:48 |
| siretart | just drop me a note, I'll sponsor it | 09:48 |
| siretart | no worries | 09:48 |
| james_w | great, thanks. | 09:48 |
| siretart | btw, are you DM or was that just jelmer? | 09:48 |
| james_w | that was just jelmer | 09:48 |
| siretart | ok | 09:48 |
| VSpike | I use cygwin on Windows. Am I generally better using the cygwin supplied bzr or the windows version? | 10:04 |
| luks | cygwin's python is usually slower | 10:05 |
| VSpike | I'm currently using the Windows version which mostly seems OK but I am having problems with the sftp protocol. | 10:05 |
| james_w | VSpike: would you like to describe the problems? | 10:05 |
| VSpike | I've found this https://lists.ubuntu.com/archives/bazaar/2008q1/036410.html | 10:05 |
| VSpike | commit to sftp repo freezes | 10:05 |
| VSpike | works from dos box, freezes in cygwin bash | 10:05 |
| james_w | so you have exported that variable? | 10:06 |
| VSpike | I tried export BZR_SSH="paramiko" and that makes it output an extra line "Connected (version 2.0, client OpenSSH_4.6p1)" before freezing | 10:07 |
| VSpike | I have not set up keys, so in DOS it prompts for password. I was basically wondering as next step, either try to set up keys or try out a full cygwin stack instead | 10:08 |
| VSpike | I can install Cygwin paramiko, but I think I will have to use cygwin bzr to take advantage of it? | 10:09 |
| VSpike | In the DOS box, it outputs exactly the same line and then prompts for a password | 10:10 |
| VSpike | I thought paramiko linked to putty/pageant not openssh? | 10:11 |
| VSpike | my windows bzr is 1.2 and the cygwin version is 1.1 ... will i have any problems if i downgrade? | 10:23 |
| awilkins | Due to the fuss from the emacs camp, does 1.3 have any speedups for trees with large file counts? | 10:30 |
| awilkins | cd .. | 10:31 |
| awilkins | oops | 10:31 |
| james_w | awilkins: I think it was all a bit late for much stuff to go in to 1.3 | 10:32 |
| james_w | and it's not the large file count that the operations they are discussing are having problems with, it's the depth of history | 10:32 |
| james_w | which is >87000 revisions | 10:32 |
| awilkins | Ah, ok then | 10:33 |
| awilkins | My problems are the opposite :-) - 8000-ish revisions, about 30,000 files | 10:33 |
| awilkins | But it's still worlds faster than SVN | 10:34 |
| awilkins | (except the branching-from-svn part :-) ) | 10:34 |
| james_w | awilkins: that should hopefully be sped up soon. (if you are using bzr-svn) | 10:37 |
| awilkins | awilkins: Yes, I hear those new pyrex bindings are the bees knees | 10:37 |
| james_w | awilkins: if you are having trouble with large trees posting to the list with the operations and profile data may help. | 10:37 |
| * awilkins is talking to himself again | 10:37 | |
| james_w | :-) | 10:37 |
| awilkins | james_w: I think my problems are less to do with bzr and more to do with filesystem performance on Win32 | 10:38 |
| james_w | it's more the "don't pack after every commit" that will make a difference, that's a separate issue to the bindings | 10:38 |
| awilkins | james_w: I'll consider it, but as I said, it kicks the pants off SVN | 10:38 |
| awilkins | james_w: Yes, that too | 10:38 |
| james_w | awilkins: ah, well you're on your own then :-) | 10:38 |
| james_w | seriously though, there may be ways to speed it up, so consider it | 10:39 |
| james_w | I can help you collect the profile data if you like. | 10:39 |
| awilkins | james_w: Yup, after thursday I'll have some time ; I want to have a crack at building those pyrex bindings on Win32 (I have MinGW AND the MS 2003 compiler sitting in the wings wiating) | 10:39 |
| james_w | that would be very valuable, thanks. | 10:40 |
| awilkins | Big Feature Push on at the moment (ie, meeting the consumers for an iteration meeting tomorrow :-) ) | 10:40 |
| awilkins | james_w: I had a try at building them last week ; it's a TOTAL pain in the arse | 10:40 |
| james_w | I can imagine. | 10:41 |
| awilkins | It's mostly SVNs fault ; APR is a breeze to build on Win32 | 10:41 |
| awilkins | "Load the Visual Studio project we provide and as long as you have the SDK it works" | 10:41 |
| * awilkins rolls on the drum for Vista SP1 | 10:42 | |
| awilkins | "Your computer will reboot several times during installation" (you could write that on Bill GAtes grave....) | 10:44 |
| awilkins | james_w: Are pack repos reverse-delta or forward-delta? | 10:48 |
| james_w | awilkins: they are based on knits | 10:48 |
| * awilkins is ignorant of what a knit is | 10:49 | |
| james_w | hang on, which way round is reverse-delta? | 10:49 |
| awilkins | You keep the current revision verbatim and store the deltas to get back to the previous revision | 10:49 |
| awilkins | (at least, that's what I mean when I say it) | 10:49 |
| awilkins | What RCS does | 10:49 |
| james_w | awilkins: no, it's forward-delta then I think. | 10:50 |
| awilkins | I was thinking maybe if you had checkpointed verbatim revisions in there it might make the emacs deep-history thing better | 10:50 |
| awilkins | But I am a novice :-) | 10:50 |
| luks | it's graph/index operations that are slow, not the delta decompression of actual files | 10:51 |
| === doko_ is now known as doko | ||
| james_w | oh, I think it does store full texts when the delta chain is too long or an individual delta is too large. | 10:51 |
| awilkins | Jolly good, I'm glad something so obvious as to occur to me wasn't overlooked :-) | 10:52 |
| james_w | but as luks says, operations like log etc. are what they are talking about, which doesn't access the texts | 10:52 |
| awilkins | Are per-file logs slow? | 10:52 |
| awilkins | (as opposed to whole-tree logs)? | 10:52 |
| luks | any log | 10:52 |
| * awilkins is surprised | 10:53 | |
| luks | log in bzr needs to sort the graph in many ways, in git just dumps the (almost) raw index | 10:53 |
| luks | which is one reason why it's slower | 10:53 |
| awilkins | Fair enough.... time to reboot for me, back in a mo | 10:54 |
| james_w | luks: git does need to sort the revisions, it just has less constraints on the sort. | 10:55 |
| james_w | in particular it needs to load all revisions with pointers to their parents, and then traverse the graph once before it can output any revisions. | 10:56 |
| james_w | it still takes bzr about 10s to do even that on the emacs repo | 10:56 |
| luks | james_w: if I'm not mistaken, git doesn't even topologically sort them by default | 10:57 |
| james_w | luks: true, sorry, it date sorts them. | 10:57 |
| james_w | However it can still topo sort them very quickly. | 10:57 |
| luks | but I was surpsised that with my toy repository format I was playing with a few months ago, I had log faster than in hg | 10:58 |
| luks | and hg does much less work on sorting there | 10:58 |
| james_w | git log --date-order > /dev/null 2.76s user 0.09s system 98% cpu 2.900 total | 10:58 |
| james_w | luks: that's good to hear. How did your repository format differ? | 10:58 |
| luks | getting rid of the xml revision format would also help bzr | 10:58 |
| james_w | --date-order is the strictest git log format, and the above is warm cache. | 10:59 |
| luks | different indexes, bulk reads, no xml, ... | 10:59 |
| james_w | luks: that sounds good. | 10:59 |
| fullermd | Well, you can say almost anything, and as long as you include "no XML" it sounds good :p | 11:06 |
| fullermd | "I like to eat babies with mustard, relish, and no XML." "Wow, really? That sounds great!" | 11:06 |
| Peng | luks: What became of your toy format? | 11:07 |
| luks | empty disk space, I think :) | 11:08 |
| luks | or maybe it's still somewhere on the laptop | 11:08 |
| Peng | It sounds like it was good work. | 11:09 |
| luks | well, in my experience with submitting patches to bzr, something like that would never be accepted | 11:10 |
| awilkins | SVN working copies used to use XML, they traded "down" to a KV format instead and got large perfomance increases | 11:11 |
| luks | I had a few more interesting private branches here, but almost never finished them because I realized I'm just wasting my time | 11:11 |
| awilkins | I'm surprised that BZA is using XML in any of it's disk formats, to be honest | 11:12 |
| luks | it's legacy thing, I guess | 11:12 |
| luks | XML is not a serious bottleneck and if it works, why replace it | 11:12 |
| james_w | luks: why do you think they wouldn't be accepted | 11:12 |
| awilkins | I mean, what, just loading those enormous libraries must account for a substantial fraction of startup time :-) | 11:12 |
| luks | james_w: because even trivial patches sit in BB for months | 11:13 |
| james_w | awilkins: it doesn't use the large libraries I don't think. | 11:13 |
| james_w | luks: but if it has benefits I'm sure it will be appreciated, and I think it would get people looking at it pretty quickly. | 11:13 |
| awilkins | james_w: Hmmph, I wrote a toy library for parsing XML in VB3 once ; I was amazed by the speed you can get when you just walk a pointer through a string buffer on it. | 11:14 |
| luks | james_w: as an example, see the ML discusion about the revno patch | 11:14 |
| james_w | luks: If you still have it at least I would like to have a look. | 11:14 |
| luks | james_w: I sent two mails to the mailing list, it improves performance significantly, and I got no responses | 11:14 |
| james_w | luks: true, that one has been overly long. | 11:14 |
| james_w | luks: with code? | 11:15 |
| luks | mails? yes with working code | 11:15 |
| james_w | awilkins: yeah, bzr uses a very basic XML, so it's not hard to parse. | 11:15 |
| james_w | luks: ok, let me dig them out. | 11:15 |
| luks | in my experience, patches by non-Canonical people are reviewed only if it touches somebody's favorite code | 11:15 |
| luks | james_w: no need, I'm not going to finish that patch :) | 11:16 |
| luks | and if it touches somebody's favorite code, they will nickpick on unimportant details | 11:16 |
| james_w | luks: I'd still like to look. | 11:17 |
| luks | I really see bzr development as "closed" and that's why I somehow stopped being interested in it | 11:17 |
| james_w | luks: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/35667 <- that one? | 11:17 |
| luks | no | 11:17 |
| luks | see jam's "[MERGE] lookup revno by iterating history" thread | 11:18 |
| james_w | luks: that's not the repository format one though? | 11:22 |
| luks | ah, no | 11:22 |
| james_w | luks: I agree that should have been looked at though. | 11:22 |
| james_w | hopefully jam will pick it up and work on it. | 11:22 |
| luks | the repository format was never really finished | 11:22 |
| james_w | yeah, but it would still be interesting to look at it to find the good ideas. | 11:22 |
| luks | http://bundlebuggy.aaronbentley.com/request/%3C64ab70ac0802041811u61752e66l3a04f025336390ae@mail.gmail.com%3E is another nice example | 11:25 |
| james_w | yeah, I was just looking at that one, it's a real shame there's been no real review. | 11:27 |
| luks | it's not really about real reviews, but at least telling the person that "the patch is completely wrong" or "it looks good but we don't have time right now" would help | 11:28 |
| luks | also I think there are people on the mailing list capable of reviewing patches like this, but their vote wouldn't count anyway, so they just don't | 11:29 |
| luks | anyway, enough ranting from me :) | 11:30 |
| VSpike | bah | 11:30 |
| james_w | luks: I agree. | 11:31 |
| VSpike | swapped to cygwin version and now bzr status shows everything as modified or conflicting | 11:31 |
| james_w | I realised the other day that apparently anyone can BB:comment, so at least that allows non-reviewer reviewers to have their comments given some status. | 11:32 |
| VSpike | even in a just committed tree | 11:32 |
| james_w | VSpike: that's not good. | 11:32 |
| james_w | luks: thanks for your comments. | 11:32 |
| VSpike | james_w: heh. nope | 11:32 |
| VSpike | what does it mean when a file has a * after it? not seen that before | 11:33 |
| james_w | VSpike: so you're using the same tree as you just were with the native version, but now with the cygwin version. | 11:33 |
| VSpike | yes | 11:33 |
| james_w | I've no idea actually. | 11:33 |
| luks | VSpike: executable bit change | 11:33 |
| james_w | were you using the native through cygwin before? | 11:33 |
| VSpike | james_w: i was executing it from a cygwin shell | 11:34 |
| VSpike | luks: that could be the problem | 11:34 |
| james_w | ok, so it might be the jump of going from windows->posix. | 11:34 |
| VSpike | how does the windows version comprehend executable bits? | 11:34 |
| james_w | I don't know if native via cygwin behaves as windows or posix. | 11:34 |
| james_w | VSpike: it doesn't | 11:34 |
| james_w | there's a plugin you can use to change the execute bit if you need to. | 11:35 |
| luks | VSpike: I think it's just that the dirstate is confused | 11:35 |
| james_w | could you pastebin the output of bzr status? | 11:35 |
| VSpike | james_w: it would be windows, would be my guess. Running a windows program from cygwin doesn't change it's environment afaik | 11:35 |
| luks | if you don't have any uncommitted changes, try branching it again off the existing one | 11:35 |
| james_w | ok, thanks. | 11:35 |
| james_w | VSpike: yes, try branching, or bzr remove-tree, bzr checkout may also work. | 11:36 |
| jelmer | hi Zindar | 11:38 |
| Zindar | hey Jelmer... how's things? | 11:39 |
| VSpike | pastebin.com/m7a81b1ef | 11:39 |
| jelmer | quite well.. fighting with pyrex | 11:39 |
| VSpike | that's bzr diff and bzr status | 11:39 |
| Zindar | jelmer: :) | 11:40 |
| Zindar | I'm enjoying the emacs bzr mailing threads :) | 11:40 |
| Zindar | jelmer: I'm writing support for apple Mail.app in bzr send btw... almost done... | 11:40 |
| james_w | VSpike: ah yeah, that's the problem, the windows version has made everything appear executable to cygwin. | 11:40 |
| james_w | VSpike: a branch should save you. Otherwise install the xbit plugin and remove the executable status of them all. | 11:41 |
| james_w | VSpike: or just chmod in cygwin should work and be less effort. | 11:41 |
| jelmer | Zindar: ah, nice | 11:41 |
| VSpike | james_w: I'm just trying to recall, but I think cygwin shows everything +x | 11:41 |
| VSpike | james_w: I don't think you can remove with chmod | 11:42 |
| Zindar | appletalk is not like other languages :) | 11:42 |
| jelmer | Zindar: the emacs thread is interesting indeed. It would be nice if we could get them onboard | 11:42 |
| jelmer | Zindar: their requirements would probably drive some more performance work, and would be good pr | 11:43 |
| VSpike | james_w: oh, ok i lied. you can | 11:43 |
| Zindar | yeah.. but I understand the performance problems... it's almost too slow for me.. and I'm working with a smaller project than emacs | 11:43 |
| james_w | Zindar: that would be cool, thanks. Especially when jelmer's child_submit_to patch lands bzr send will be great, so having it work everywhere will be cool. | 11:43 |
| Zindar | james_w: just scratching my own itch :) | 11:44 |
| * awilkins is infuriated that Branch.rename_one isn't implemented | 11:45 | |
| jelmer | james_w: it has already landed :-) | 11:45 |
| VSpike | ah, that's better. find -type f -exec chmod a-x "{}" \; | 11:46 |
| james_w | jelmer: ah, cool, I'll start setting it everywhere, thanks. | 11:46 |
| awilkins | Dammit, how do you move files from a python console | 11:52 |
| awilkins | (in bzr, not the plain os) | 11:52 |
| luks | WorkingTree.rename_something | 11:52 |
| james_w | awilkins: Tree.rename() I think | 11:52 |
| james_w | rename_one() maybe | 11:53 |
| awilkins | Branch.rename_on() isn't implemented.... can you gte a Tree from a branch? | 11:53 |
| james_w | There's also move() I think, but it has slightly different semantics. | 11:53 |
| luks | you can't, the other way around | 11:53 |
| luks | you get a branch from a tree | 11:53 |
| james_w | tree.bzrdir.open_workingtree() | 11:53 |
| luks | (that means, open the working tree, not the branch) | 11:53 |
| james_w | branch.bzrdir sorry | 11:54 |
| luks | oh | 11:54 |
| awilkins | I did "frombzrlib.workingtree import WorkingTree ; tree = WorkingTree.open('.') | 11:57 |
| james_w | awilkins: perfect. | 11:58 |
| awilkins | I'm walking my tree renaming all my .xml files to .pxml | 11:58 |
| awilkins | It was taking forever from a shell with all the process spawning | 11:58 |
| awilkins | It's taking a while from the console.... | 11:58 |
| fullermd | Just proves the earlier point about XML being bad for performance ;> | 12:00 |
| awilkins | Yeah, they'll be much faster when they are pxml files | 12:00 |
| awilkins | :-P | 12:00 |
| awilkins | It's just so my diff tool can use a custom rule on the without applying it to other xml files | 12:01 |
| dato | siretart: are you going to fix your bzrtools upload? it is uninstallable against 1.3. (hint: `bzr diff -c -1` vs `bzr diff -c -2`) | 12:02 |
| Peng | Someone should set child_submit_to on bzr.dev (and all the other branches too) | 12:03 |
| awilkins | Damn, this rename is still going | 12:04 |
| awilkins | 'tis only 3500 files | 12:05 |
| awilkins | http://pastebin.ca/948729 << anyone see anything wrong with this in terms of performance ? | 12:06 |
| awilkins | Is it rewriting my 6 MB dirstate file after each call, for example? | 12:10 |
| james_w | awilkins: nothing specifically. | 12:11 |
| james_w | I may be missing something though | 12:11 |
| awilkins | I have a feeling it's because I'm using rename_one and the tree has 18,000 files in it | 12:11 |
| luks | seems so | 12:11 |
| awilkins | It's only done 1300 / 3500 files | 12:11 |
| luks | there is a flush call, which seems to save the dirstate | 12:12 |
| awilkins | The dirstate is definitely increasing | 12:12 |
| awilkins | I'll have a crack with .move() | 12:13 |
| Peng | jelmer: bzr-svn (latest 0.4 branch and bzr.dev) fails at branching http://codespeak.net/svn/pypy/dist/: Failed PROPFIND on /svn/!svn/bc/45181/pypy/dist | 12:15 |
| jelmer | Peng: One sec, I'll see if I can reproduce it here | 12:16 |
| Peng | Thanks. | 12:16 |
| awilkins | Bah, I don't think move() can rename the file, just moves the folder it's in | 12:19 |
| awilkins | (from reading code) | 12:19 |
| fullermd | Brings back memories of when 'mv' and 'move' and 'rename' were separate commands. | 12:20 |
| awilkins | I don't think theres an API call that can do bulk renames :-( *sulk* | 12:20 |
| awilkins | Well, not a "public" one, I think | 12:21 |
| jelmer | Peng: this is a server side issue | 12:33 |
| jelmer | svn ls -r45181 http://codespeak.net/svn/pypy/dist fails as well | 12:33 |
| jelmer | (or a svn client library issue, depending on how you want to look at it) | 12:34 |
| Peng | jelmer: Ok. That sucks. | 12:38 |
| Peng | "trivial commit to test pushing from bzr" | 12:39 |
| === mrevell is now known as mrevell-lunch | ||
| jelmer | wow, ok | 12:43 |
| jelmer | that's either a very big coincidence or there's something funky happening here | 12:43 |
| jelmer | ah, 45182 fails too | 12:43 |
| Peng | (45181 is probably related to https://code.launchpad.net/~mwhudson/pypy/bzr-svn) | 12:45 |
| Peng | s/probably// | 12:45 |
| dato | siretart: ok, I'll fix | 12:49 |
| awilkins | Oh you have to be frickin' kidding me | 12:53 |
| awilkins | Seems the new Vista SP1 has some "security" fixes in it | 12:53 |
| awilkins | I can no longer change the permissions on "notepad.exe" so that I can overrwrite it with something non-crap | 12:54 |
| fullermd | Friend of mine once had a Win2k machine that did something like that. It would reappear every time it was deleted. | 12:54 |
| awilkins | Oh, that's not too hard to get around. | 12:54 |
| awilkins | No, this is different ; I'm an admin user but I can't change the file permissions | 12:55 |
| awilkins | I could before | 12:55 |
| fullermd | Obviously, anybody trying to harm notepad is a hax0r and must be stopped. | 12:55 |
| awilkins | I wonder if I reboot in Ubuntu and copy over it it will notice / moan ? | 12:56 |
| awilkins | Bah | 12:56 |
| siretart | dato: BAH, sorry, I was in the wrong branch :( | 13:13 |
| dato | siretart: no worries, fixed now. | 13:13 |
| siretart | dato: thanks! | 13:13 |
| dato | np | 13:13 |
| siretart | I experimented in a private branch for the snapshotting, and botched the merge for the 'offical' branch | 13:13 |
| siretart | :/ | 13:14 |
| * awilkins has remembered the fix for his "notepad nazi-ism" problem | 13:15 | |
| === mrevell-lunch is now known as mrevell | ||
| === kiko-zzz is now known as kiko | ||
| jelmer | dato,siretart: hi | 14:04 |
| jelmer | Would either of you be able to sponsor the first upload of bzr-dbus these days? | 14:04 |
| jelmer | *one of | 14:04 |
| siretart | jelmer: There is no debian/watch file, so can't use that to retrieve upstream tarball | 14:08 |
| siretart | (message from bzr bd) :) | 14:09 |
| siretart | jelmer: any reason to not use debhelper 5? | 14:12 |
| jelmer | siretart: it should get a snapshot from launchpad | 14:23 |
| jelmer | siretart: No, that's a mistake on my part | 14:23 |
| === bigdo1 is now known as bigdog | ||
| jelmer | siretart: should be fixed now | 14:26 |
| siretart | would you care to commit a watchfile? | 14:27 |
| siretart | see the bzrtools package for an example | 14:27 |
| dato | well, I don't think bzr-dbus has released tarballs? | 14:28 |
| jelmer | yeah, that's the problem at the moment | 14:28 |
| siretart | oh, I see. bzr-builddeb is in export-upstream mode | 14:29 |
| siretart | bzr: ERROR: No such tag: bzr-dbus-0.1~bzr34 | 14:29 |
| jelmer | siretart: what version of bzr-builddeb are you running? | 14:29 |
| siretart | ii bzr-builddeb 0.92 bzr plugin for Debian package management | 14:30 |
| siretart | perhaps http://bzr.debian.org/pkg-bazaar/bzr-dbus/unstable/ doesn't have the necessary tags? | 14:31 |
| jelmer | newer versions will interpret ~bzr34 and export revision 34 | 14:31 |
| siretart | aah, I see | 14:31 |
| jelmer | you can also override it manually by specifying --export-revision=34 (IIRC) | 14:31 |
| jelmer | looks like it's actually --export-upstream-revision=34 | 14:32 |
| siretart | yes, that seems to do the trick | 14:32 |
| james_w | I'm going to get all those fixes together later. | 14:33 |
| siretart | jelmer: the selftests are failing | 14:40 |
| siretart | Ran 37 tests in 1.039s | 14:40 |
| siretart | FAILED (failures=2, errors=1) | 14:40 |
| siretart | are you aware of that? | 14:40 |
| jelmer | siretart: ouch, no | 14:43 |
| * jelmer fix0rs | 14:43 | |
| jelmer | siretart: fixed | 14:44 |
| === mw|out is now known as mw | ||
| siretart | did you push to http://bzr.debian.org/pkg-bazaar/bzr-dbus/unstable/? | 14:45 |
| jelmer | argh, wrong remembered push location | 14:46 |
| jelmer | should be fixed now | 14:47 |
| siretart | jelmer: the testsuite seems to assume a running and working dbus, right? | 14:49 |
| siretart | http://paste.ubuntu.com/5872/ | 14:50 |
| jelmer | siretart: yes | 14:52 |
| jelmer | siretart: the plugin should however cause no trouble if dbus is not available | 14:53 |
| jetsaredim | is there a "proper" way to do a merge on a file that has conflicts? | 15:13 |
| james_w | jetsaredim: sorry, can you explain please? | 15:15 |
| jetsaredim | lets say I have two completely different versions of a file | 15:15 |
| abentley | awilkins: A public API that can do bulk renames is TreeTransform. | 15:16 |
| jetsaredim | I know I want all of one and none of the other | 15:16 |
| jetsaredim | if I just plaster the one I want over the one that's there - is that going to screw up any sort of vcs tracking? | 15:16 |
| awilkins | abentley: Thanks for the pointer | 15:18 |
| abentley | It can do anything to a working tree, which is why its API is rather ugly. | 15:18 |
| abentley | There should probably be a "renames" method on WorkingTree. | 15:19 |
| * awilkins thought the same ; was thinking about refactoring "rename_one" into "rename_many" and getting "rename_one" to call it | 15:20 | |
| abentley | I'd implement rename_many on TreeTransform, not refactor rename_one. | 15:21 |
| abentley | Because TT will always do what you ask it to. | 15:21 |
| jetsaredim | so - is that a "it doesn't matter"? | 15:21 |
| abentley | A naïve implementation of rename_many will rename files on top of one another. | 15:21 |
| fullermd | jetsaredim: Overwriting a file with 'cp' isn't any different from the VCS's POV than editing it to remove the conflicts, so I can't think how it would. | 15:22 |
| jetsaredim | ok cool | 15:23 |
| abadger1999 | jelmer: ping | 15:27 |
| jetsaredim | thanks all | 15:28 |
| abadger1999 | Hey guys, brandon_rhodes has some questions about bzr-svn. | 15:28 |
| abadger1999 | Can anyone here comment on a few end user questions? | 15:28 |
| jelmer | abadger1999: pong | 15:29 |
| jelmer | abadger1999: sure | 15:29 |
| jelmer | brandon_rhodes: hi | 15:29 |
| brandon_rhodes | jelmer: Hey! | 15:29 |
| brandon_rhodes | If I use bzr locally and then commit back to svn, then it can't of course do the merge back to svn with the separate changes I've made listed under the merge change. | 15:30 |
| brandon_rhodes | But ... does it at least make a cool commit comment or something that lists the local changes that were included in the merge? | 15:30 |
| siretart | jelmer: uploaded | 15:31 |
| jelmer | brandon_rhodes: Not sure I understand what you mean. bzr merges are tracked in svn | 15:32 |
| jelmer | siretart: tahnks! | 15:32 |
| brandon_rhodes | jelmer: In subversion, if I make 10 changes on a branch then merge to trunk, subversion just says "here's brandon's Big Change To Trunk", and it looses the info that the merge is of ten separate little changes. Linus complains about this. | 15:33 |
| jelmer | brandon_rhodes: So, bzr-svn stores information about the merge in svn properties | 15:33 |
| jelmer | so bzr will be able to see where the changes were merged from | 15:34 |
| brandon_rhodes | jelmer: I'd heard a rumor that, in bzr, the "4031 Brandon merges his stuff" change to trunk has, listed underneath it / inside it, the 10 changes I made that then got put together in the merge... | 15:34 |
| brandon_rhodes | Whoa! | 15:34 |
| brandon_rhodes | It uses svn properties? | 15:34 |
| brandon_rhodes | That's heavy! | 15:34 |
| jelmer | brandon_rhodes: However, you won't be able to see what was merged from svn | 15:34 |
| jelmer | there is no way to adjust the commit message - it would break referential integrity in bzr | 15:35 |
| jelmer | at least until we do a format upgrade | 15:35 |
| brandon_rhodes | Oh ... huh. | 15:35 |
| jelmer | brandon_rhodes: You can include information about the merges in the commit message yourself though | 15:36 |
| brandon_rhodes | So you couldn't have the message, beneath my own comment, auto-include a bit of text that says "this merge included 9 separate changes: ..." and maybe list one-line summaries of them or something? | 15:36 |
| brandon_rhodes | It would just be cool to see that info when other developers were browsing svn normally | 15:37 |
| jelmer | brandon_rhodes: bzr push to svn does the same thing as bzr push to any other bzr branch - it preserves the exact revision | 15:38 |
| jelmer | one of the core ideas behind most dvcses is that a specific revision id can only refer to exactly one unique revision | 15:39 |
| jelmer | (referential integrity) | 15:39 |
| jelmer | changing the commit message would violate that basic rule | 15:40 |
| jelmer | there are two possible ways around this: | 15:41 |
| jelmer | - we could set two revision properties in svn: one that svn sees and one that bzr sees. This however can't happen until the next mapping upgrade of bzr-svn | 15:42 |
| jelmer | - it should be fairly easy to write a plugin that edits the bzr commit message and inserts the merge info there | 15:42 |
| jelmer | brandon_rhodes: still there? | 15:43 |
| brandon_rhodes | Yes. | 15:52 |
| brandon_rhodes | Sorry, writing up 2nd day sprint report :-) | 15:52 |
| brandon_rhodes | jelmer: I think I'd better play with bzr and subversion some myself, and then I'll understand what's going on with merging. :-) | 15:53 |
| brandon_rhodes | All I know right now is what someone drew for me while talking | 15:53 |
| jelmer | brandon_rhodes: ah :-) | 15:54 |
| jelmer | brandon_rhodes: A better way of describing it is probably to consider what "bzr push" should do | 15:55 |
| jelmer | brandon_rhodes: you would expect it to make sure that the branch on the remote side contains the exact same contents as your local branch | 15:55 |
| brandon_rhodes | jelmer: Um. | 15:56 |
| brandon_rhodes | jelmer: Oh. You're talking about a situation where the branch actually exists in Subversion? | 15:56 |
| jelmer | brandon_rhodes: Not necessarily - it is also push to push a new branch into subversion | 15:56 |
| brandon_rhodes | jelmer: I thought I'd heard a guy talking about just copying svn /trunk into a bzr of his own, then merging right back into svn /trunk. I'd missed the fact bzr was creating a branch in svn. | 15:57 |
| brandon_rhodes | Then it makes sense that you'd copy the changes 1-for-1. | 15:57 |
| brandon_rhodes | But it still seems subversion couldn't "see" what the merge included like bzr can "see" that the merge to /trunk is the sum of lots of little changes in the branch ... is that true? | 15:58 |
| jelmer | brandon_rhodes: well, if you use "bzr push svn://.../trunk" you're telling bzr to add the extra revisions you have locally to /trunk | 15:58 |
| jelmer | brandon_rhodes: yes, that's correct | 15:58 |
| brandon_rhodes | jelmer: As separate revisions? Gotchya. | 15:59 |
| jelmer | brandon_rhodes: Only the mainline revisions | 15:59 |
| brandon_rhodes | Roger. | 15:59 |
| jelmer | brandon_rhodes: Since subversion doesn't support merge tracking | 15:59 |
| brandon_rhodes | Right. | 15:59 |
| brandon_rhodes | It just mushes them all together. | 15:59 |
| jelmer | right | 15:59 |
| ubotu | New bug: #203941 in bzr "Bzr -r ancestor:badbranch signals errors too late" [Undecided,New] https://launchpad.net/bugs/203941 | 16:17 |
| === kiko is now known as kiko-fud | ||
| jelmer | Peng: any chance you can file a bug about that bug in bzr-svn you hit with codespeak? | 16:59 |
| Peng | jelmer: Ok. | 17:08 |
| Verterok | moin | 17:10 |
| intellectronica | hya, i'm getting the following error when trying to push to a server: ShortReadvError: readv() read 3451 bytes rather than 3640 bytes at 1997614 for ... | 17:12 |
| intellectronica | any ideas what could that be? bzr 1.2 both locally and on the sever | 17:13 |
| brandon_rhodes | Can bazaar do svn:externals-like stuff? | 17:14 |
| brandon_rhodes | And can it do it on files instead of svn which can only do directories (eww!) | 17:15 |
| Peng | brandon_rhodes: Not yet. | 17:16 |
| brandon_rhodes | It would be cool to have a VC that could easily version control something like /etc/ or my homedir, where some stuff needs to be checked out from a common repo (so my .bashrc might look the same on all my systems), but pull other stuff from a per-homedir or per-system repo | 17:17 |
| brandon_rhodes | So that /etc/sysctl.conf could pull from a "debian-common" repo and be the same on my machines, but "/etc/hostname" be per-machine | 17:19 |
| fullermd | I doubt nested-files will ever be around. | 17:20 |
| fullermd | That calls more for symlinks, or maybe just merges. | 17:20 |
| brandon_rhodes | Drat. :-) | 17:21 |
| brandon_rhodes | And it would be neat if the first part of /etc/sysctl.conf could pull from "debian-common" but then have the file end with stuff from a machine-specific repository :-) | 17:21 |
| * fullermd will hold out for a pony instead. | 17:21 | |
| * brandon_rhodes grins :-) | 17:23 | |
| LarstiQ | fullermd: what do you mean with nested-files? | 17:25 |
| LarstiQ | oh eek | 17:25 |
| ubotu | New bug: #203975 in bzr-svn "PROPFIND failed branching http://codespeak.net/svn/pypy/dist/" [Undecided,New] https://launchpad.net/bugs/203975 | 17:25 |
| fullermd | LarstiQ: Egads! Don't look; you'll go blind. | 17:25 |
| jelmer | Peng: thanks | 17:29 |
| jelmer | curl is the http library that is going away, no? | 17:30 |
| Peng | I'm using curl, aren't I? | 17:34 |
| Peng | Well, I am, but how would you know? | 17:34 |
| Peng | Yes, it is. | 17:34 |
| ubotu | New bug: #203979 in bzr "ShortReadvError trying to push to a server" [Undecided,New] https://launchpad.net/bugs/203979 | 17:40 |
| === kiko-fud is now known as kiko | ||
| === kiko is now known as kiko-phone | ||
| === kiko-phone is now known as kiko | ||
| LeoNerd | Has anyone here ever played with the Python CPAN module..? Module for constructing/interacting with Python objects from Perl code... | 18:59 |
| LeoNerd | I'd like to instantiate a 'bzrlib' object from Python, so as to call various methods on it | 18:59 |
| fullermd | Funny, I've thought passingly about that very thing... | 18:59 |
| dato | *g* | 19:00 |
| barry | hi folks, quick question: we're setting up bzr serve via ssh in an authorized_keys file command="" section. having some problems and we're wondering if bzr serve logs anywhere? | 19:15 |
| LeoNerd | So.. Not being a python programmer, could someone suggest me a nice simple line to demonstrate that bzrlib is working..? I now have a shiney Inline::Python perl module here ;) | 19:15 |
| barry | we're using: command="/usr/bin/bzr serve --allow-writes --inet --directory=/foo" | 19:16 |
| barry | and we're getting an error -1 when we try to bzr push bzr+ssh:// | 19:16 |
| LeoNerd | Are you sure you need that --inet there? | 19:16 |
| dato | no idea, but I guess you checked ~/.bzr.log already? | 19:17 |
| LeoNerd | Oh.. heh. so you do. Never mind :) | 19:17 |
| barry | dato: we're not getting a .bzr.log file | 19:17 |
| barry | LeoNerd: yeah ;) | 19:17 |
| dato | ok | 19:18 |
| barry | btw, we're using bzr 1.1rc1 on the server | 19:18 |
| barry | we figured it out | 19:24 |
| luks | LeoNerd: I think it would be easiest to write most of what you need in python and use only simple functions from perl | 19:25 |
| LeoNerd | Hrm... Technically I guess it would work either way around | 19:26 |
| luks | because the bzrlib API is full of classes and I'm not sure how well does Inline::Python handles that | 19:26 |
| LeoNerd | Inline::Python does classes | 19:26 |
| LeoNerd | It wraps them in a trampoline object, that supports the same methods | 19:26 |
| luks | yeah, but to what extent | 19:26 |
| luks | http://bazaar-vcs.org/Integrating_with_Bazaar has some examples of simple bzrlib usage | 19:27 |
| LeoNerd | .oO( How annoying.. vim can't highlight python in heredocs in perl code.. booo ) | 19:28 |
| LeoNerd | Hmm.... repo = branch.repository <== that's an attribute rather than a method call, yes? | 19:35 |
| luks | yes | 19:35 |
| luks | method calls have (), this is not perl :) | 19:35 |
| LeoNerd | Hm... OK | 19:35 |
| dato | luks: well, it could be a property | 19:36 |
| dato | (no idea if that'd be relevant for what LeoNerd is doing) | 19:36 |
| luks | right | 19:36 |
| luks | but that's the same for Inline::Python, I think | 19:36 |
| luks | since the method call is handled by python automatically | 19:36 |
| scode | Hmm. I was under the impression 'bzr serve' would produce a browseable web interface, in addition to the optimize bzr synch protocol. What is the idiomatic way to provide a web browsable copy of a repository? | 19:37 |
| scode | (bzr serve does not seem to speak HTTP when I try it) | 19:37 |
| radix | scode: loggerhead I think | 19:39 |
| dato | scode: there is no built-in capability in bzr for that | 19:39 |
| LeoNerd | Hrm.... It seems Inline::Python only supports method calls on wrapped objects, not attribute access | 19:40 |
| luks | that's why I mentioned implementing "wrappers" in python | 19:40 |
| scode | radix/dato: Ok - thanks. | 19:40 |
| LeoNerd | Can I add new methods to an existing class.? Are all classes open? | 19:41 |
| luks | yes | 19:41 |
| LeoNerd | Woo :) I've just opened a branch, queried top revision, and printed its log summary. From perl ;) | 19:45 |
| james_w | scode: there's bzr-webserve as well that provides a "webserve" command to give a HTTP interface | 19:47 |
| dato | and there is even a third one nobody ever remembers | 19:50 |
| ubotu | New bug: #204025 in bzr "Concurrent updates of separate threads in a shared repository fails" [Undecided,New] https://launchpad.net/bugs/204025 | 19:51 |
| LeoNerd | Hm.. So.. how much of the core simple stuff in bzrlib is going to use attrs rather than methods? | 19:51 |
| LeoNerd | .oO( Also I can't see documentation on these attrs on the docs pages - do they not come out? ) | 19:52 |
| LarstiQ | LeoNerd: in what sense? | 19:54 |
| LeoNerd | LarstiQ: Well.. the examples use branch.repository to get the repo. for a branch... I couldn't see that on the branch docs page | 19:54 |
| LarstiQ | LeoNerd: there are lots of non-methods like that, yes | 19:55 |
| LeoNerd | Hmm.. :/ | 19:55 |
| LarstiQ | LeoNerd: a method wouldn't really make sense | 19:55 |
| * LeoNerd ponders improving Inline::Python so it can do that | 19:55 | |
| LarstiQ | ? | 19:55 |
| LarstiQ | LeoNerd: yay :) | 19:55 |
| LeoNerd | Simply implementing hash lookup ought to be sufficient | 19:56 |
| LeoNerd | Hmm.. though.. dunno what Python's API might make it look like | 19:56 |
| LeoNerd | I could tie STOREHASH and RETRIEVEHASH so that $branch->{repository} is rvalue and lvalue | 19:56 |
| LeoNerd | But.. more interesting things like enumerating all the keys... keys %$branch ... would python allow that? | 19:57 |
| luks | keys %$branch would be similar to dir(branch) | 19:57 |
| LarstiQ | LeoNerd: there is no iteration on the object itself for it's members, but you can do that on object.__dict__ (which is a dictionary) | 19:57 |
| LarstiQ | luks: thanks, now I know what keys does ;) | 19:58 |
| LeoNerd | Hmm.. Is every object backed by just a dictionary? | 19:58 |
| luks | LarstiQ: d.keys() | 19:58 |
| LarstiQ | LeoNerd: not in theory, though most won't play funny games on you | 19:58 |
| scode | james_w: thanks! | 19:59 |
| LeoNerd | Hm.. OK.. So would it be reasonable to represent an object as a hashref, to allow the usual sorts of things with its keys? | 19:59 |
| LarstiQ | LeoNerd: if properties are used, or __getatrr__ is overriden, the answer would be no | 19:59 |
| LarstiQ | LeoNerd: I don't know perl nor it's idioms | 19:59 |
| luks | LarstiQ: not really | 19:59 |
| luks | properties don't really translate well to that | 20:00 |
| luks | because the value can change in any "call" | 20:00 |
| * LarstiQ thought he just said that? | 20:00 | |
| LarstiQ | though I confess in a roundabout way | 20:00 |
| luks | yeah :) | 20:00 |
| luks | I think best would be to treat them all as functions | 20:01 |
| LeoNerd | Well.. a real native hash allows getting/setting of arbitrary named elements, and enumeration of the keys | 20:01 |
| luks | but then you can't easily assign to them, so you would have to use e.g. branch->repository($new_repo) | 20:01 |
| LeoNerd | Would it be sensible to make a python object look like that? | 20:01 |
| LeoNerd | Yah.. plus.. I wasn't sure if they live in different namespaces | 20:02 |
| LeoNerd | object.foo() vs. object.foo | 20:02 |
| luks | no, they are in the same namespace | 20:02 |
| luks | object.foo() just takes object.foo and calls it | 20:02 |
| LeoNerd | Ah OK.. Though.. Looking at how the Inline::Python works, it just throws (pl) method calls into (py) method calls. If I did the attrs. like that as well, it would have to know which one to do | 20:03 |
| LeoNerd | Plus, your point about assignment... I suspect a hash is the way to go here | 20:04 |
| luks | maybe implement something like getattr, setattr? | 20:04 |
| luks | (that is, separate functions) | 20:04 |
| LarstiQ | LeoNerd: everything on an object is an attribute lookup first | 20:04 |
| LarstiQ | wow, that's sloppily worded | 20:05 |
| luks | actually, it probably allows you to use the native ones from python | 20:05 |
| LeoNerd | branch.getattr("repository") or something? | 20:05 |
| luks | gettattr($branch, "repository") | 20:06 |
| LeoNerd | Hrm... That seems not to be exported to perl :/ | 20:07 |
| LeoNerd | I suspect this probably requires more poking at Inline::Python's internals... | 20:08 |
| LeoNerd | Ooh.. but methods are just code refs as attributes, yes? I wonder if breakage would happen if you try to pull one of those out directly | 20:13 |
| === mw is now known as mw|food | ||
| mxpxpod | besides bzr-hg (which doesn't work with bzr 1.2), is there a hg->bzr converter? | 20:54 |
| Odd_Bloke | mxpxpod: There's fast-export/import which might work. | 20:55 |
| mxpxpod | oh, cool | 20:57 |
| mxpxpod | I didn't realize that fastimport came with exporters | 20:57 |
| dato | mxpxpod: well, you'll need an exporter for hg | 20:58 |
| dato | mxpxpod: I think there is one in... sec | 20:58 |
| mxpxpod | dato: fast-import comes with one in the exporters directory | 20:58 |
| === mw|food is now known as mw | ||
| dato | oh | 20:59 |
| dato | well, they've made a copy from the canonical location then | 20:59 |
| mxpxpod | dato: from where? | 21:00 |
| dato | http://repo.or.cz/w/fast-export.git | 21:01 |
| mxpxpod | no no, I was talking about the fast-import bzr plugin coming with exporters | 21:01 |
| dato | mxpxpod: though maybe bzr-fastimport is its new home, not sure | 21:01 |
| dato | yes | 21:02 |
| dato | I said they made a copy | 21:02 |
| dato | you said from where | 21:02 |
| mxpxpod | oh, gotcha | 21:02 |
| dato | I gave you the "from" | 21:02 |
| dato | :) | 21:02 |
| mxpxpod | ;) | 21:02 |
| weigon | what to do when I get: | 21:04 |
| weigon | bzr: ERROR: Pack '2765b027c9b99141c06eeabd2ca628ac' already exists in <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x0151EF90> | 21:04 |
| weigon | ... on a push | 21:08 |
| weigon | if it already has it, why does it try to apply it ? | 21:08 |
| james_w | dato: yeah, I think we've taken over fast-export.git | 21:16 |
| james_w | or rather incorporated it. | 21:16 |
| weigon | ... and why does it work at a second try ? locking ? | 21:17 |
| james_w | weigon: it probably pushes a different pack, or doesn't bother as it already exists. I don't know why you would have got the first one. | 21:18 |
| dato | james_w: oh, I see :) | 21:19 |
| fullermd | It's not the first time the error has come up. Nobody's made it reproducible yet, though. | 21:20 |
| fullermd | I think it's considered to be a manifestation of some weird bug. | 21:20 |
| === jml` is now known as jml | ||
| james_w | weigon: a bug filed with the relevant chunk of your ~/.bzr.log may start the ball rolling. | 21:30 |
| === mwhudson_ is now known as mwhudson | ||
| james_w | siretart: hi. I realise it's late, so it's fine if you're not able to do it today. I have pushed what I think is a working package to the launchpad branch. If you could check it and upload that would be great, thanks. | 21:37 |
| siretart | james_w: not alioth? | 21:37 |
| james_w | siretart: http://bazaar.launchpad.net/~james-w/bzr-builddeb/trunk in case you lost the URL. | 21:37 |
| james_w | siretart: no, launchpad, I can push to alioth if you would like. | 21:37 |
| james_w | in fact I'll do that anyway. | 21:38 |
| siretart | ok | 21:38 |
| siretart | I just wouldn't expect a branch named 'trunk' to be suitable for publishing in a distribution :) | 21:38 |
| siretart | at least not without further comments about that | 21:38 |
| james_w | ah, ok. | 21:39 |
| siretart | ok, I've updated the branch info, so lp:bzr-builddeb *should* point to the up-to-date branch | 21:40 |
| james_w | thanks | 21:41 |
| siretart | seems to work | 21:42 |
| james_w | do you know if they run denyhosts on alioth? | 21:42 |
| dato | denyhosts? | 21:44 |
| siretart | the package does not seem to be installed | 21:44 |
| siretart | so I'd assume no | 21:44 |
| james_w | one of the "block ip addresses that guess passwords on ssh" scripts | 21:44 |
| dato | oh | 21:44 |
| dato | they use fail2ban afaik | 21:45 |
| james_w | I guess there are many, I don't even know if denyhosts is the right name | 21:45 |
| james_w | ah, that's it then. That's why I always have trouble connecting to alioth. | 21:45 |
| dato | really? what do you do for it to hate you? :) | 21:46 |
| mxpxpod | has there been any recent work to get svn:externals working in bzr-svn? | 21:46 |
| james_w | I forgot to set a user in ~/.ssh/config, so I always try and log in first with my local username, and then obviously get blocked about the same time that I realise. | 21:46 |
| dato | ah, heh | 21:47 |
| james_w | I've rectified that now, so I should be able to do it properly next time. | 21:47 |
| dato | james_w: that has an easy solution | 21:47 |
| dato | james_w: become a DD | 21:47 |
| james_w | mxpxpod: I haven't heard of any. | 21:47 |
| dato | :-P | 21:47 |
| james_w | dato: or that... | 21:47 |
| james_w | :) | 21:47 |
| mxpxpod | james_w: are nested bzr trees supported? | 21:47 |
| james_w | though I don't use my local username anywhere else. | 21:48 |
| james_w | mxpxpod: sort of. | 21:48 |
| james_w | mxpxpod: vague answer I know | 21:48 |
| mxpxpod | :D | 21:48 |
| james_w | mxpxpod: there is some support for storing the necessary data, but actually using them will typically fail as there are plenty of bugs to shake out. | 21:48 |
| mxpxpod | for instance: https://bugs.launchpad.net/bzr-svn/+bug/82863 mentions that development is blocked by support for by-reference nested trees | 21:48 |
| ubotu | Launchpad bug 82863 in bzr-svn "svn:externals is not supported" [Wishlist,In progress] | 21:48 |
| siretart | james_w: http://paste.ubuntu-nl.org/60220/ :( | 21:48 |
| james_w | siretart: is there a line missing from the end of that? | 21:49 |
| siretart | ImportError: cannot import name tests | 21:49 |
| siretart | make: *** [build-python2.5] Error 1 | 21:49 |
| siretart | these were missing | 21:50 |
| james_w | ah, stupid stupid me. | 21:50 |
| siretart | hey, I even did a stupid upload today ;) | 21:51 |
| james_w | I can't seem to find a reliable way to run the tests during the build | 22:05 |
| james_w | siretart: I'm too tired to really think about this any more tonight. Do you want to wait until another day, or just upload with the tests disabled? | 22:09 |
| siretart | james_w: I've just tried to do that. package builds fine, but `bzr selftest builddeb` still fails. are you aware of that? | 22:09 |
| james_w | siretart: can I see the errors please? | 22:10 |
| james_w | it works fine for me. | 22:10 |
| james_w | though I'm python2.5 based, are you on a 2.4 machine? | 22:11 |
| siretart | http://paste.ubuntu-nl.org/60224/ | 22:12 |
| siretart | I'm on a pretty freshly installed debian/sid system | 22:12 |
| siretart | which has /usr/bin/python still pointing to python2.4 | 22:12 |
| james_w | oh, what? Why does that not work for you? | 22:12 |
| james_w | it's not a python2.4 issue. | 22:13 |
| siretart | there doesn't seem to be any tests installed into the package.. hmm | 22:13 |
| james_w | that might be it :) | 22:13 |
| james_w | siretart: thanks :) We should be able to enable the tests now. | 22:15 |
| james_w | packages=['bzrlib.plugins.builddeb'], | 22:15 |
| james_w | package_dir={'bzrlib.plugins.builddeb': '.'}, | 22:15 |
| james_w | that doesn't seem to be enough in setup.py to build and install the tests. | 22:16 |
| hacklberry | is it possible to make bzr work with mingw ssh on windoze (or does bzr work only with putty)? | 22:17 |
| james_w | hacklberry: as I understand it there are several options for ssh on windows. | 22:19 |
| james_w | e.g. plinj | 22:19 |
| james_w | plink sorry | 22:19 |
| james_w | and it can/does use paramiko, so anything that can use is ok. | 22:20 |
| james_w | I don't know if it can use the mingw one though, sorry. | 22:20 |
| siretart | I think I fixed it now | 22:20 |
| siretart | james_w: are you okay with this patch: http://paste.ubuntu-nl.org/60226/ | 22:21 |
| james_w | siretart: that would be fine. If you have a couple of minutes I think I may have a better one. | 22:22 |
| siretart | ah, sure | 22:22 |
| hacklberry | james_w: it looks like it does not work with mingw ssh, i just tried a little test, first on my slackware laptop: | 22:27 |
| hacklberry | martin@yobbo:~/test_bzr$ bzr branch sftp://martin@192.168.130.143/home/martin/bzr/rlm_ftress | 22:27 |
| hacklberry | Branched 109 revision(s). | 22:27 |
| hacklberry | and here is the result from my windoze workstation (when trying to do the same from a mingw/msys terminal): | 22:27 |
| hacklberry | $ bzr branch sftp://martin@192.168.130.143/home/martin/bzr/rlm_ftress | 22:27 |
| hacklberry | command-line: line 0: Bad configuration option: ClearAllForwardings | 22:27 |
| hacklberry | bzr: ERROR: Unable to connect to SSH host 192.168.130.143; EOF during negotiation | 22:27 |
| james_w | siretart: if you pull I think that should work. | 22:28 |
| james_w | siretart: if not, please upload your change. | 22:28 |
| james_w | hmm, I wonder where that "ClearAllForwardings" comes from. | 22:29 |
| james_w | hacklberry: it looks like it is could work, if you can work out what that means then you may be able to fix it, or work out how bzr can support it. | 22:29 |
| siretart | well, you incorporated my change to setup.py :) | 22:30 |
| hacklberry | has something to do with how bzr uses the mingw ssh i guess, the ssh on its own works fine, ie. i can do slogin martin@192.168.130.143 without any problems | 22:30 |
| lifeless | yawn link, good morning | 22:31 |
| mwhudson | hello lifeless | 22:31 |
| james_w | hi lifeless | 22:32 |
| james_w | hacklberry: ok, so it would be great if you could find out what bzr is doing wrong and file a bug. | 22:32 |
| hacklberry | james_w: i m playing with it now | 22:33 |
| james_w | hacklberry: great, thanks. | 22:34 |
| siretart | james_w: the test-builddeb command seems to run all tests just fine, but reports exit code 1 instead of 0, which fails the build. huh? | 22:34 |
| james_w | siretart: sorry, stupidity again. | 22:35 |
| james_w | siretart: it returns result.wasSuccessful() | 22:35 |
| james_w | so it wants a return not result in __init__.py | 22:35 |
| james_w | siretart: fix pushed, sorry. | 22:36 |
| siretart | heh. I'm learning more and more about bzr :) | 22:37 |
| siretart | 'not result'? | 22:38 |
| siretart | that looks weird.. | 22:38 |
| james_w | siretart: true, I'll fix it. | 22:39 |
| siretart | but works! :) | 22:39 |
| james_w | correction pushed if you care, otherwise it can wait. | 22:40 |
| james_w | readable good. working better. | 22:40 |
| poolie | hi | 22:41 |
| james_w | hi poolie | 22:41 |
| siretart | james_w: ah, thanks for clarifying that. I'll upload in a sek | 22:41 |
| james_w | siretart: brilliant, thanks. | 22:42 |
| james_w | thanks siretart | 22:58 |
| siretart | you're welcome! | 22:58 |
| hacklberry | excuse my naivite, but i think the following message is (perhaps) incorrect (as i do not run a bzr server): | 23:01 |
| hacklberry | C:\test>bzr branch bzr+ssh://martin@192.168.130.143/home/martin/bzr/rlm_ftress | 23:01 |
| hacklberry | Connected (version 2.0, client OpenSSH_4.3p2) | 23:01 |
| hacklberry | Adding ssh-rsa host key for 192.168.130.143: 07AA7C20C76E8D87F84EBB7E1FCD07F6 | 23:01 |
| hacklberry | Authentication (publickey) successful! | 23:01 |
| hacklberry | Secsh channel 1 opened. | 23:01 |
| hacklberry | Server is too old for fast get_parent_map, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this) | 23:01 |
| hacklberry | Connected (version 2.0, client OpenSSH_4.3p2) | 23:01 |
| hacklberry | Authentication (publickey) successful! | 23:01 |
| hacklberry | Secsh channel 1 opened. | 23:01 |
| hacklberry | Branched 109 revision(s). | 23:01 |
| siretart | hacklberry: bzr+ssh:// uses the smart server on the remote side, starting it on demand | 23:01 |
| hacklberry | siretart: thanks | 23:02 |
| hacklberry | siretart: just out of interest - does bzr need to be installed on the remote box where i store my branches? (it didn't use to) | 23:11 |
| asabil | hacklberry: no, but if you have it it is better | 23:16 |
| asabil | it allows you to use the bzr:// transport (actually bzr+ssh://) | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!