| spiv | jisakiel: it's basically a very very simple alternative to bzr_access :) | 00:00 |
|---|---|---|
| jisakiel | hmm, I see | 00:00 |
| jisakiel | like *very very very* simple | 00:01 |
| jisakiel | I kinda like more the original, as it allows for several repos | 00:01 |
| jisakiel | http://www.selenic.com/repo/index.cgi/hg-stable/file/tip/contrib/hg-ssh | 00:01 |
| === Verterok is now known as Verterok|afk | ||
| jisakiel | but seems easy enough to extend | 00:02 |
| jisakiel | won't make any troubles because of the "bzr log" problem? | 00:03 |
| jisakiel | I mean: right now, I'd just have "bzr init ~bzr/repo" and then push over the different projects there, but... | 00:03 |
| spiv | So long as you don't restrict the client from seeing directories they need. | 00:03 |
| jisakiel | and you wouldn't have anything needed "up" unless...? | 00:04 |
| spiv | e.g. if you do bzr init-repo /bzr/proj && bzr init /bzr/proj/branch, then it's ok to limit the client to /bzr rather than / | 00:04 |
| spiv | Or even /bzr/proj | 00:04 |
| spiv | But if you limit to /bzr/proj/branch, then the client won't be able to access the shared repository at /bzr/proj, and it will need to access it. | 00:05 |
| jisakiel | ncht | 00:06 |
| jisakiel | and btw | 00:06 |
| jisakiel | is there a way of checking out (like in svn again, it's just that I used to use it a bit before) the whole repo? IIRC checking out /bzr/proj would not work | 00:07 |
| jisakiel | could be wrong though | 00:07 |
| spiv | Not really, no. | 00:07 |
| spiv | You could just "cp -a" it ;) | 00:08 |
| jisakiel | consider that as a suggestion as well ;) | 00:08 |
| jisakiel | that way you would be able to checkout not just "trunk", but all development branches as well | 00:08 |
| spiv | Yeah, we would like to have better ways to manipulate groups of branches. | 00:08 |
| jisakiel | *if* you use a shared repo to hold them (which seems logical) | 00:09 |
| spiv | At the moment shared repos are just a storage optimisation, rather than implying any semantic like "these branches are part of a group of related branches" | 00:10 |
| jisakiel | aham | 00:10 |
| jisakiel | well, semantic seems implied from the storage optimization (if there are shared files between the branches as to make it worth it... they are definitely related) | 00:11 |
| spiv | But in practice, they usually are related. So it is tempting to use shared repositories like that... but it's not part of our design yet, and we're wary of making design mistakes that will be hard to undo. | 00:12 |
| jisakiel | last year I didn't know of shared repos and end up with hundreds of megs of slightly different big branches | 00:12 |
| * spiv nods | 00:12 | |
| jisakiel | yeah, I guess it could be considered independent enough | 00:12 |
| jisakiel | as in "you could want to have a group of related branches without having them under the same folder" | 00:13 |
| spiv | The other thing in favour of using shared repos for a "group of related branches" concept rather than creating a new concept is it would be less concepts for users to learn about. | 00:13 |
| jisakiel | it's kind of easy, yep | 00:13 |
| jisakiel | I guess it brings new problems... I lost track a bit of launchpad enhancements, but I don't know if shared repos are compatible with development branches | 00:14 |
| jisakiel | I seem to recall something from the rss related | 00:14 |
| spiv | You can use shared repos with any format except the really ancient ones. | 00:14 |
| jisakiel | as to avoid having huge branches to checkout from the servers | 00:14 |
| jisakiel | ah, so I can just bzr init-repo shared, then checkout inside from lp? | 00:15 |
| jisakiel | and if there is storage to be won it will? | 00:15 |
| jisakiel | (cooool) | 00:15 |
| spiv | Ah, you can, but that won't help you avoid downloading all of history ;) | 00:15 |
| jisakiel | I guess I should have just branched from my existing branches, then pulling from the repo, but that was a merge-fest waiting to happen | 00:15 |
| spiv | You can do "bzr checkout --lightweight" and since 1.6.1 "bzr branch --stacked", though. | 00:16 |
| jisakiel | we used branches and not checkouts nevertheless | 00:16 |
| spiv | Basically, if you already have the history locally, then a shared repo can help you. | 00:16 |
| jisakiel | heh, --stacked functionality seems to overlap a bit with shared repos, doesn't it | 00:17 |
| spiv | An new (and thus empty) shared repo doesn't perform any differently to a standalone branch+repo. | 00:17 |
| spiv | Hmm, not really :) | 00:17 |
| spiv | But maybe I'm too close the implementation to see what you mean ;) | 00:18 |
| jisakiel | sure you are! :D | 00:18 |
| fullermd | --stacked can give a result that superficially looks like the a result of shared repos in the short term. How's what? :p | 00:19 |
| jisakiel | as in "--stacked saves storage? by reusing the common history? from the pointed branch" vs "shared-repo reuses whatever" | 00:19 |
| fullermd | Really, in much the same way and for the same reasons as hardlinking the repo. | 00:19 |
| jisakiel | so, summing up (gotta go!), a plugin -and, possibly, modificating bzr+ssh behaviour?- would be needed to replicate svnserve functionality... | 00:22 |
| jisakiel | oh, btw can't I use bzr over https (even if unefficient?) that's another way of authenticating (weaker, though) and having fine-grained permissions... | 00:23 |
| spiv | That is an option, and it should work. | 00:25 |
| jisakiel | I might try that then as a first approach | 00:25 |
| jisakiel | and afterwards try to bang the limit_path script until I get it to work as I'd like :) | 00:25 |
| spiv | Although, hmm. | 00:26 |
| spiv | It might be a bit fiddly to set up. | 00:26 |
| spiv | Let us know how you go :) | 00:26 |
| jisakiel | webdav shared folder, and .htaccess I guess | 00:26 |
| spiv | Oh, webdav. | 00:26 |
| spiv | That's probably not so bad, although I'm not familiar with the state of the webdav code. | 00:27 |
| jisakiel | heh, that's easier | 00:27 |
| spiv | (Is that still provided by a plugin?) | 00:27 |
| jisakiel | yep | 00:27 |
| * spiv nods | 00:27 | |
| jisakiel | mod_dav irc | 00:27 |
| jisakiel | iirc | 00:27 |
| spiv | Oh, I meant, on the bzr side :) | 00:27 |
| jisakiel | lol | 00:27 |
| fullermd | Well, no matter how you slice it, you can't set authority boundaries other than at repository boundaries. | 00:27 |
| spiv | If you have trouble with webdav, vila is a good person to chat to for help -- depending on timezones :) | 00:28 |
| jisakiel | just saw something related to https in the configuration section of the docs, so I guess it should more-or-less work | 00:28 |
| jisakiel | heh, ok, txs for the info | 00:28 |
| fullermd | I'm not sure the webdav stuff still works. It was broken at one time, and I didn't think vila had touched it in a good long while. | 00:28 |
| jisakiel | ough | 00:29 |
| jisakiel | I'll try just for the record then | 00:29 |
| * fullermd nod. | 00:29 | |
| fullermd | 's the only way to be sure. | 00:29 |
| jisakiel | as I think I had the webdav shared folders still working | 00:29 |
| jisakiel | in fact | 00:29 |
| === spm_ is now known as spm | ||
| spiv | jisakiel: or if the users are using linux, you could get them to use http://dav.sourceforge.net/ to make webdav look like an ordinary filesystem ;) | 00:30 |
| jisakiel | what I can't is trick bzr to push over webdav into plain http, can I | 00:31 |
| jisakiel | as I was trying the webdav thing but I have it over http (yeah, I know, insecure etc ;)) | 00:32 |
| spiv | I don't know enough about the webdav plugin, sorry. | 00:32 |
| jisakiel | ncht | 00:32 |
| spiv | (I would have thought it would work, but I really have no idea :) | 00:32 |
| jisakiel | bzr: ERROR: Invalid http response for http://jisakiel.dyndns.org/privado/.bzr/branch-format: Unable to handle http code 401: expected 200 or 404 for full response. | 00:33 |
| jisakiel | (whatever) | 00:33 |
| spiv | I think you need to use http+webdav:// to use the plugin? | 00:33 |
| jisakiel | that's what I meant | 00:34 |
| jisakiel | I'll try in other time, as I gotta go now | 00:36 |
| jisakiel | quick last one: any *simple* (as in "grep") way of knowing which folders would a branch need to be accessible for it to work | 00:37 |
| jisakiel | (as the limit_path would perhaps be able to share from the upmost needed folder that way) | 00:37 |
| jisakiel | well, I'll have a look myself. Thanks so very much for the insights! | 00:39 |
| jisakiel | goodbye all... ^^ | 00:40 |
| === Verterok|afk is now known as Verterok | ||
| === arjenAU2 is now known as arjenAU | ||
| poolie_ | spiv: i presume you did test the autopack rpc? how did it go? | 03:15 |
| spiv | poolie_: it seems to work, although it's a bit of a hassle to test by hand. I guess I could script "for i in seq 10 ; do bzr ci --unchanged -m 'foo'; bzr push bzr://... ; done" | 03:18 |
| poolie_ | i think it would be wise to at least try that against both servers that do and don't supporti t | 03:21 |
| * spiv nods | 03:22 | |
| spiv | I'll give it a work out, see what breaks. | 03:22 |
| spiv | And look at that, it broke! | 03:22 |
| spiv | D'oh. | 03:22 |
| poolie_ | :/ | 03:22 |
| * spiv fixes | 03:22 | |
| spiv | Ah, but the full test suite does notice, I mustn't have run that as recently as I thought I had. Hmm. | 03:23 |
| spiv | Looks shallow, anyway. | 03:23 |
| === TheMuso_ is now known as TheMuso | ||
| spiv | Yeah, just a last-minute snafu in the final quick-cleanup-before-hitting-submit revision. I'm checking for other gotchas. | 03:33 |
| poolie_ | spiv, i'm sending a partial review | 03:33 |
| poolie_ | will be back on it in a bit | 03:33 |
| spiv | poolie_: thanks | 03:38 |
| lifeless | poolie_: I'm going to catch a train before 5, to skip transit crowds going to a friends birthday | 04:32 |
| lifeless | poolie_: I'll hack on the train | 04:32 |
| poolie_ | sure, have a good trip | 04:32 |
| === RAOF_ is now known as RAOF | ||
| spiv | poolie_: FWIW, working autopack rpc cuts the number of RPCs for the 10th push of 1 revision from 179 to 44. | 05:52 |
| poolie_ | nice | 05:53 |
| poolie_ | still a bit high but nice | 05:53 |
| spiv | Yeah. | 05:53 |
| spiv | The change to -Dhpss to make it dump call counts to stderr makes this sort of measurement much more convenient. | 05:55 |
| vila | hi all | 07:02 |
| vila | fullermd: I've got news for you :) webdav wasn't updated for a while but was finally updated and is now passing the test suite for some months (both against our internal test server and against a real apache2 server) | 07:08 |
| vila | fullermd: And since the bzr transport API is one of the most stable we have, the plugin doesn't need updates and I changed the requirement to be a simple bzr >= 1.6 | 07:10 |
| vila | Too bad jsakiel seems already gone, but if he got a 401, he has to provide a user for authentication | 07:13 |
| poolie_ | spiv, did you send the update to that patch? | 07:22 |
| === poolie_ is now known as poolie | ||
| poolie | hi vila | 07:23 |
| === thekorn_ is now known as thekorn | ||
| Odd_Bloke | jelmer: Belated pong. | 08:53 |
| thumper | poolie: ping | 09:33 |
| * thumper hopes poolie is still around and lookng at his computer | 09:33 | |
| poolie | hi | 09:33 |
| poolie | on phone still | 09:33 |
| thumper | poolie: ok | 09:41 |
| poolie | hi, i'm free | 09:41 |
| thumper | poolie: I was going to ask about the auto pack bug with stacked branches | 09:42 |
| thumper | I hadn't realised exactly what the problem was | 09:42 |
| thumper | but if it fails on all autopacks, that is very bad for LP | 09:42 |
| poolie | thumper: that would be bad | 09:43 |
| poolie | is there a bug # for this? | 09:43 |
| * thumper pokes jml | 09:43 | |
| jml | this is the check reference one, iirc | 09:44 |
| * jml looks | 09:44 | |
| jml | this one is related but not it, I think, https://bugs.edge.launchpad.net/bzr/+bug/280608 | 09:45 |
| ubottu | Launchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Undecided,New] | 09:45 |
| jml | poolie, thumper: https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/280595 | 09:46 |
| ubottu | Launchpad bug 280595 in launchpad-bazaar "RevisionNotPresent error when mirroring stacked branches" [High,New] | 09:46 |
| poolie | are you saying this is a knock-on effect from autopack not dtrt? | 09:49 |
| thumper | I think so | 09:49 |
| thumper | but I don't have enough info just yet | 09:49 |
| thumper | I was only just told that it was related to autopack | 09:49 |
| poolie | launchpad whitespace breakage ftw :/ | 09:51 |
| beuno | poolie, in comments? | 09:52 |
| poolie | yeah | 09:58 |
| jml | as you can tell from the comments, there are a lot of related, confusing bugs with serious sounding error messages | 10:00 |
| jml | and these are happening regularly among the Launchpad team, making the system seem flaky | 10:01 |
| beuno | poolie, I have a branch that may fix that, just need to do some further testing on it to make sure it doesn't break in other browsers | 10:04 |
| poolie | yay | 10:13 |
| beuno | mwhudson, I'm working on getting "head:" to be used by default in the URL if you're looking at the tip in LH | 10:23 |
| beuno | so people don't have top URL hack anymore | 10:23 |
| poolie | presumably bug 280608 is just cosmetic, as losing the lock at that point should have no visible effect | 10:24 |
| ubottu | Launchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Medium,Confirmed] https://launchpad.net/bugs/280608 | 10:24 |
| poolie | it's not physically held afaics | 10:24 |
| beuno | mwhudson, not sure if this is fiddling too far down: http://paste.ubuntu.com/64537/ | 10:24 |
| poolie | i'll merge that patch anyhow | 10:24 |
| mwhudson | beuno: is that in fix_revid? | 10:26 |
| beuno | mwhudson, no, get_revno | 10:26 |
| beuno | we don't run revnos past fix_revid in many places | 10:26 |
| mwhudson | oh right | 10:27 |
| mwhudson | beuno: basically, i don't know what a good ui is here | 10:27 |
| beuno | so, this would, in a way, make it impossible to get the actual revno, so it kinda sucks | 10:27 |
| beuno | hm | 10:27 |
| beuno | I could start slapping fix_revid or something on URLs | 10:28 |
| * beuno revertrs | 10:28 | |
| mwhudson | when someone clicks on the first revision on the changes pages, are they clicking on it because they're interested in the head revision, or because they're interested in that particular revision | 10:28 |
| mwhudson | beuno: certainly, i think when people click the 'files' tab, 'head:' is appropriate in urls | 10:29 |
| mwhudson | but this probably means we need to carry a bit more state around | 10:29 |
| LarstiQ | jelmer: a branch got renamed in svn, and now bzr-svn thinks it's an entirely new branch. Can I just tell it 'no, it is actually _this_ branch'? | 11:32 |
| jelmer | LarstiQ, does it still use the same branching scheme? | 11:35 |
| LarstiQ | the new dir is a sibling of the old one, but let me check | 11:38 |
| LarstiQ | jelmer: Guessed branching scheme: TrunkBranchingScheme(0), guess scheme to use: SingleBranchingScheme(foo) | 11:41 |
| LarstiQ | jelmer: where foo is the path in the svn repository under trunk/, so that differs between pre and post move | 11:42 |
| jelmer | LarstiQ: if the branching scheme is different, there's no way to let it recognize the old history | 11:42 |
| LarstiQ | and the SingleBranchingScheme is always tied to the exact location in svn repository, so moves will always impose a cut between bzr branches? | 11:46 |
| jelmer | LarstiQ, yes | 11:50 |
| * LarstiQ grumbles | 11:53 | |
| jelmer | LarstiQ, branching schemes suck, deal with it :-) | 11:54 |
| * mwhudson waves https://bugs.launchpad.net/bugs/291046 around | 11:54 | |
| ubottu | Launchpad bug 291046 in bzr "pushing branch6/packs5 to location with default stacking policy creates broken branch" [Undecided,New] | 11:54 |
| LarstiQ | jelmer: I don't know how I'm going to deal with it yet, it seems to me there is enough information available to not break so horribly. | 11:56 |
| jelmer | LarstiQ, 0.5 no longer has branching schemes and deals with this properly | 11:57 |
| * LarstiQ glomps jelmer | 12:03 | |
| LarstiQ | jelmer: is there an ETA? | 12:03 |
| * LarstiQ lunches | 12:04 | |
| * Jc2k must know how this magic works... =) | 12:04 | |
| gour | is '--1.6.1-rich-root' safe format to use? | 12:10 |
| * gour also wonders when we'll see some reduction in format number | 12:11 | |
| lifeless | gour: if you're using rich roots at all, 1.6.1-rich-root is fine to use | 12:20 |
| lifeless | gour: its listed as supported after all | 12:20 |
| abentley | jelmer: :pull is actually :parent, so "I'll consider changing the default ... to :pull, :parent" is a bit wrong. | 12:23 |
| jelmer | abentley, ah, ok | 12:24 |
| jelmer | LarstiQ, "when I have time" | 12:24 |
| LarstiQ | jelmer: right :) | 12:39 |
| LarstiQ | gour: but be warned that non-rich-root doesn't mix well with rich-root | 12:40 |
| * jelmer wonders if rich root is ever to become the default.. | 12:42 | |
| LarstiQ | jam: did you need any more information on bug 50568 ? | 12:43 |
| ubottu | Launchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed] https://launchpad.net/bugs/50568 | 12:43 |
| gour | jelmer: why not? | 12:47 |
| gour | some format(s) perform better? | 12:47 |
| unenough | i want to backup my repo. what's the easiest way to store the smallest archive with the whole repo in it? | 12:57 |
| === cprov is now known as cprov-afk | ||
| jam | LarstiQ: good morning. I haven't followed up on it, but I'll look at your script | 13:51 |
| LarstiQ | jam: thanks | 13:52 |
| LarstiQ | jam: for my immediate situation I've just setfacled | 13:53 |
| LarstiQ | which works fine | 13:53 |
| jam | LarstiQ: well, for that particular one, I think you are creating a new branch, which is a bit different than pushing existing code into the repo | 13:56 |
| jam | but I'll admit that is probably broken | 13:56 |
| jelmer | gour: it's not been happening for quite a while | 13:57 |
| jam | so I'm thinking we should open a new bug for what you are encountering | 13:57 |
| jam | because it is probably a different fix than bug #50568 | 13:57 |
| ubottu | Launchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed] https://launchpad.net/bugs/50568 | 13:57 |
| unenough | is there a way to create an archive of my repo? | 14:00 |
| unenough | easy way | 14:01 |
| jam | unenough: rsync my-repo copy-of-my-repo ? | 14:04 |
| unenough | doesn't that include a lot of redundant data? | 14:04 |
| jam | unenough: redundant in what sense? | 14:04 |
| unenough | copies of complete files (the current working copy) | 14:05 |
| unenough | that happen to exist under the repo dir | 14:05 |
| unenough | branches | 14:05 |
| unenough | i don't know what to call them | 14:05 |
| unenough | besides, sometimes it's much more convenient to just have a .gz file of the repo | 14:06 |
| jam | unenough: well you can do "tar cvzf repo.tar.gz .bzr/repository" however that won't keep the branch pointers | 14:06 |
| jam | as they are kept in their individual directories | 14:06 |
| unenough | that's why i want a single command to do it | 14:07 |
| unenough | like, "bzr archive" :) | 14:07 |
| jam | I could help you write a plugin for it, but no there isn't something trivial that already exists | 14:08 |
| Odd_Bloke | Something with 'find' would probably work. | 14:08 |
| Odd_Bloke | jam: I think this was discussed in London, but I don't remember what the conclusion was. | 14:08 |
| Odd_Bloke | Or if, indeed, there was one. | 14:08 |
| jam | I think I need to alias ":e" to vi in my shell :) | 14:12 |
| unenough | jam, Odd_Bloke there is this https://launchpad.net/bzr-gzipped-bundle | 14:15 |
| unenough | but it seems dead | 14:15 |
| jam | unenough: that is a really old plugin that has been replaced by builtin-code | 14:15 |
| jam | and it wouldn't do multiple branches | 14:15 |
| jam | (The current "bundle" format is bzipped anyway) | 14:15 |
| jelmer | Odd_Bloke, nevermind | 14:19 |
| jelmer | Odd_Bloke, I was going to mention there was another ITP open about bzr-xmloutput | 14:19 |
| jelmer | Odd_Bloke, but that seems to be assigned to you now | 14:19 |
| jam | markh: ping | 14:39 |
| === NfNit|oop is now known as NfNitLoop | ||
| spiv | jam: I just sent an update to the autopack patch | 15:53 |
| spiv | jam: now I'm off to try sleep despite the hot weather | 15:54 |
| jam | spiv: I thought it was cold there | 15:54 |
| jam | did it suddenly switch? | 15:54 |
| jam | (again) | 15:54 |
| spiv | jam: It's been very variable the last two weeks. | 15:54 |
| jam | spiv: I also sent an update to your Graph change | 15:54 |
| jam | though you are probably too tired to look over it now | 15:54 |
| spiv | Tomorrow is forcast to be 36 celsius. | 15:55 |
| spiv | jam: I've taken a quick sleepy glance, and I like the look of it. | 15:58 |
| spiv | jam: thanks very much for making a complete patch, rather than just comments. That's very helpful at this point in the release cycle :) | 15:59 |
| jam | yeah, I thought it would be | 15:59 |
| jam | you're certainly welcome | 15:59 |
| * spiv -> zzzz | 16:00 | |
| jszakmeister | jelmer: you there? | 16:59 |
| jelmer | jszakmeister, yep | 16:59 |
| jszakmeister | Ran into a bzr-svn bug (I think) | 16:59 |
| jszakmeister | Ever see the error: | 17:00 |
| jszakmeister | ReadOnlyError: A write attempt was made in a read only transaction on KnitPackRepository | 17:00 |
| jelmer | jszakmeister, what version of bzr-svn? | 17:00 |
| jszakmeister | I branched from an svn repo, made some changes, pushed into a shared repo, and then treied to push from the shared repo into a new branch of subversion | 17:01 |
| jszakmeister | The latest (0.4.13, I believe) | 17:01 |
| jszakmeister | Wait... I'm not so sure about that... hold on. | 17:01 |
| jszakmeister | Crap. 0.4.11 | 17:02 |
| jszakmeister | Let me update and try again | 17:02 |
| jszakmeister | I though I had installed the latest on this machine... but it was probably my desktop at home. | 17:02 |
| jelmer | please try to reproduce with 0.4.13 first | 17:07 |
| jszakmeister | Yeah, I'm trying that now... | 17:15 |
| jszakmeister | Sorry, I thought I was at 0.4.13 already. :-( | 17:15 |
| jszakmeister | jelmer: The error went away. | 17:35 |
| jszakmeister | Sorry for the noise. | 17:35 |
| jelmer | another bug well fixed :-) | 17:37 |
| jam | jelmer: ping | 18:07 |
| jelmer | jam, pong | 18:08 |
| jam | I'm trying to build bzr-svn 0.4.13 so that we can have the windows installer | 18:08 |
| jam | and I'm running into problems at compile time | 18:08 |
| jam | specifically: | 18:08 |
| jam | subvertpy\subvertpy\editor.c:140: error: initializer element is not constant | 18:08 |
| jam | subvertpy\subvertpy\editor.c:140: error: (near initialization for `TxDeltaWindowHandler_Type.tp_deal | 18:08 |
| jam | loc') | 18:08 |
| jam | I believe this happens when you set a static structure | 18:08 |
| jam | to point to a function | 18:09 |
| jam | which only exists in a dll | 18:09 |
| jam | which isn't legal on Win32 | 18:09 |
| jam | because the address isn't known until load time | 18:09 |
| jam | (This happens for trunk/0.4.10,11,12,13) | 18:10 |
| jam | Do you know if markh did some customization of bzr-svn that didn't make it back into trunk for it to build on win32? | 18:10 |
| jam | I also get a bunch of errors about: util.h:28: warning: ignoring #pragma GCC visibility | 18:14 |
| jam | jelmer: ? | 18:24 |
| jelmer | jam, sorry | 18:25 |
| jam | np, we all get busy, I just didn't know if you read any of what I said or not | 18:25 |
| jelmer | blegh | 18:26 |
| jelmer | yeah, I suspect Mark has a patch for that | 18:26 |
| jelmer | it should probably be upstream | 18:26 |
| jelmer | the fix would probably be to add a (yuck) wrapper function | 18:27 |
| jam | jelmer: the standard python way is to leave the entry as a NULL pointer and then during the __init__ function | 18:30 |
| jam | you populate it | 18:30 |
| jam | well INIT_MODULE or whatever the specific function is | 18:30 |
| jam | I've done the hack for other stuff | 18:30 |
| jam | I just didn't know how he managed to compile it | 18:30 |
| jam | and thought maybe he mentioned it to you | 18:31 |
| jam | well, I guess I was hoping he sent you a patch that you just forgot about until now | 18:32 |
| jam | :) | 18:32 |
| === fta_ is now known as fta | ||
| jelmer | jam, not that I remember :-) | 18:42 |
| jam | jelmer: so if I was to try to make a fix to get a stable released bzr-svn packaged into a win32 installer, what branch should I use? | 18:54 |
| jam | just do it off of the tag:bzr-svn-0.4.13 ? | 18:54 |
| jelmer | jam, yep | 18:55 |
| === Verterok_ is now known as Verterok | ||
| jam | ok, it wasn't ever clear to me what the 0.4 branch was versus trunk versus 0.5, etc | 18:55 |
| jelmer | jam, 0.5 (aka trunk) is not ready for use yet | 18:59 |
| jelmer | jam, the 0.4 branch is the stable branch from which all the 0.4.x releases are made | 18:59 |
| jam | jelmer: I think I have a patch | 19:15 |
| jam | it was actually a lot simpler than I was worried it would be | 19:15 |
| jam | just 3 'dealloc' functions that need to be set at runtime instead of startup | 19:16 |
| jam | however, I don't actually have it running yet, because of dll load failures | 19:16 |
| jam | but I think that is just PATH issues | 19:16 |
| jam | the build succeeded | 19:16 |
| === gotgenes is now known as gotgenes_away | ||
| jelmer | any chance you can send me the patch? | 19:17 |
| jam | well, I'm trying to see if I can actually get it to work | 19:31 |
| jam | but yeah, I'll send it to you | 19:31 |
| jam | I'm pushing it to lp right now | 19:31 |
| jam | lp:~jameinel/bzr-svn/0.4.13-win32 | 19:31 |
| jam | jelmer: pushed, would you rather I sent you a patch? | 19:35 |
| jelmer | jam, no, thanks, I think know how to use bzr merge :-) | 19:35 |
| jam | jelmer: so... I am able to build it, but now I get a lot of: | 19:48 |
| jam | DLL load failed: The specified module could not be found. | 19:48 |
| jam | whenever I try to use it | 19:48 |
| jam | (during import client) | 19:48 |
| jam | so no joy yet | 19:48 |
| === mw is now known as mw|food | ||
| jam | jelmer: If I run from 'cmd.exe' instead of running under cygwin, I at least get the popup describing the dll that couldn't be loaded. Which seems to be "libapr.dll". | 19:57 |
| jam | And I can say that 'libapr-1.dll' is in the Subversion directory, but "libapr.dll" is not. Why would that be? | 19:57 |
| jelmer | jam, Not sure what's the problem there.. | 19:59 |
| jam | maybe markh is a better person to ask | 19:59 |
| jelmer | jam, the windows specific bits in setup.py are beyond me.. | 20:00 |
| jam | though I haven't seen him around :) | 20:00 |
| jam | jelmer: what is weird is that the subversion-dev .zip file does indeed have a 'libapr.lib' | 20:00 |
| jam | so you have to supply "-llibapr" as you would expect | 20:00 |
| jam | however, it seems to correspond with a 'libapr-1.dll' but someone didn't tell it that | 20:00 |
| jelmer | jam, are you using setup.py ? | 20:00 |
| jam | jelmer: yeah, I'm using setup.py to build it | 20:00 |
| jam | on my home machine if I don't manually set the path, it dies because of a missing libsvn_client-1.dl | 20:03 |
| jam | if I put the Subversion dir first, it dies because of a missing libapr.dll | 20:03 |
| jam | it seems when someone was building subversion they got confused as to what dlls they were supposed to use | 20:04 |
| awilkins | It is rather tricksy, I'll have to say | 20:06 |
| jelmer | jam: lp:~jameinel/bzr-svn/0.4.13-win32, right? | 20:09 |
| lifeless | hi | 20:23 |
| jelmer | 'morning Robert | 20:24 |
| jelmer | jam: my bzr and launchapd don't seem to recognize it | 20:26 |
| jam | jelmer: yeah, I'm using stacking and it didn't seem to propagate to the http:// side, though it worked for we to branch via bzr+ssh | 20:35 |
| jam | morning lifeless | 20:36 |
| jam | lp:~jameinel/bzr-svn/0.4.13-win32 should be correct | 20:36 |
| jelmer | jam, even fetching over ssh doesn't seem to work | 20:37 |
| jam | jelmer: weird | 20:40 |
| jam | I'm sure it worked here, because I had to install it on the shared windows host | 20:40 |
| jam | I'll just send you a bundle for now | 20:40 |
| jelmer | jam, thanks | 20:41 |
| jam | sent | 20:41 |
| jam | jelmer: so when I look at the dev files that that Subversion supplies, the libapr.lib seems to be claiming it will be building a libapr.dll even though there is only libapr-1.dll | 20:43 |
| jam | so probably someone built it incorrectly | 20:43 |
| lifeless | vila: awake? | 20:44 |
| vila | no :) | 20:44 |
| lifeless | vila: oh good | 20:44 |
| lifeless | vila: so the answer to why the chk of a file is not the sha of its contents is not related to the tests ;) | 20:45 |
| lifeless | vila: it is - the CHK for an object is the hash of bytes resulting from encoding it - there is a type header prefixed - not the hash of the thing itself | 20:45 |
| vila | oh, so that the chk map can be used for anything | 20:47 |
| lifeless | s/chk map/chk store/ | 20:47 |
| lifeless | but yes | 20:47 |
| lifeless | we should be able to scan it and determine the object type to call back to to parse and process data | 20:48 |
| lifeless | so for a files content the type is probably something like 'bytes:\n' | 20:48 |
| lifeless | but it means what is hashed is still != the files content itself | 20:48 |
| lifeless | (not that we use CHK stores for file content today, or in my branch's planned scope at all) | 20:49 |
| vila | right, the focus is on inventories right ? | 20:49 |
| lifeless | yes | 20:49 |
| jam | jelmer: I think I've sorted it out.... but it makes me sad | 20:50 |
| jam | It seems that whoever is building the .zip files is doing it differently than the person building the Setup-Subversion.exe installer | 20:51 |
| jam | all of the _dev.zip files point to "foo.dll" | 20:51 |
| jam | while the installer points to "foo-1.dll" | 20:51 |
| jelmer | jam, Thanks, patch merged | 20:51 |
| jelmer | jam, Ahhhh | 20:51 |
| jelmer | jam, Yeah, there's different people providing patches | 20:51 |
| jam | ebswift versus djh | 20:51 |
| jam | jelmer: any idea who I should poke with a stick? | 20:52 |
| jelmer | jam, saywha? | 20:52 |
| jam | jelmer: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91 | 20:52 |
| jam | ebswift is the one making the .msi installers | 20:52 |
| jelmer | ahh | 20:52 |
| jam | djh is the one making the .zip flies | 20:52 |
| jam | and they don't talk to eachother I guess | 20:52 |
| === mw|food is now known as mw | ||
| lifeless | jam: in case you didn't knw, cygwin's mingw is subtly different to mingw's mingw | 21:08 |
| lifeless | the -1 different looks like libtool to me | 21:09 |
| jam | lifeless: well it works fine here, which is enough for me | 21:09 |
| jam | I'll see if that is the problem, though | 21:09 |
| lifeless | cygwin's mignw is a gcc cross compiler | 21:09 |
| lifeless | mingw's is a native compiler. IIRC | 21:09 |
| === thekorn__ is now known as thekorn_ | ||
| jam | lifeless: well, compiling against the 1.5.4_dev.zip and making sure the 1.5.4.zip dlls are first in my path means that everything succeeds | 21:13 |
| jam | so it is a _dev.zip + .zip having different pointers than the Setup program ... | 21:13 |
| lifeless | jam: sure | 21:18 |
| lifeless | jam: so I'm thinking they are using a different libtool | 21:18 |
| jam | could be | 21:18 |
| === gotgenes_away is now known as gotgenes | ||
| jam | jelmer: do you have a bzr-svn that doesn't cause every branch probe to completely abort when running bzr.dev? | 21:59 |
| jam | 0.4.13 claims it is completely incompatible with bzr.dev and aborts the process | 21:59 |
| poolie | hello jam | 21:59 |
| jam | hi poolie | 21:59 |
| poolie | jam, spiv, lifeless, call in 1m if you like | 21:59 |
| jelmer | jam: the 0.4 branch works with bzr.dev | 21:59 |
| jam | jelmer: so just update? | 21:59 |
| jelmer | jam, yep | 22:00 |
| jam | I should say it only occasionally aborts, like when I'm checking out a new branch | 22:00 |
| jelmer | jam, only when bzr-svn comes into play | 22:06 |
| jam | well, only when it *thinks* it needs to come into play :) | 22:06 |
| jelmer | only when *bzr* asks it to probe a location for a bzr-svn branch (-: | 22:06 |
| jam | what happened to only issuing a warning? | 22:06 |
| jelmer | it only issues a warning when it's one version out of sync | 22:07 |
| jelmer | but 0.4.13 is two versions out of sync | 22:07 |
| spiv | poolie: hi, I slept in. | 22:20 |
| poolie | hi, np | 22:20 |
| poolie | want to join us now? | 22:20 |
| lifeless | poolie: did you try me? | 22:20 |
| poolie | tried it, didn't like it :-P | 22:21 |
| lifeless | .oO | 22:21 |
| lifeless | now why don't I remember tat | 22:21 |
| fullermd | Hey, who used all my ether? | 22:22 |
| lifeless | dunno, you should check on ethertube.com | 22:22 |
| lifeless | poolie: so, call then? | 22:22 |
| lifeless | spiv: you failed | 22:23 |
| spiv | poolie: starting skype now | 22:24 |
| disturbedsaint | hi | 22:30 |
| disturbedsaint | Is there somebody with tortoisebzr experience around? | 22:30 |
| poolie | mhammond may be around in a bit | 22:31 |
| poolie | or you can just ask | 22:31 |
| * markh is here! | 22:31 | |
| poolie | oh hi | 22:31 |
| poolie | :) | 22:31 |
| markh | hi :) | 22:31 |
| markh | disturbedsaint: what's up? | 22:32 |
| disturbedsaint | just triend tbzr but it doesnt seem to display anything | 22:32 |
| disturbedsaint | since the included .txt's and wiki don't provide too much info I guess im kinda stuck | 22:33 |
| disturbedsaint | Not getting the nice context menu's a shown in the screenshots | 22:33 |
| markh | hrmph | 22:33 |
| markh | you aren't using a 64bit windows? | 22:34 |
| disturbedsaint | nope | 22:34 |
| disturbedsaint | 32bit xp | 22:34 |
| markh | there is optionally a diagnostic tool installed - 'tbzrtrace.exe' I think. It's not installed by default though - you need to click the "diagnostic tools" option at install time. Can you recall if you selected that? | 22:35 |
| markh | if not, would it be possible to re-execute the installer and select that? | 22:35 |
| markh | (oh - you aren't using bzr 1.8-lite are you?) | 22:35 |
| disturbedsaint | I branched | 22:36 |
| disturbedsaint | which might be the reason | 22:36 |
| markh | branched? | 22:36 |
| markh | running from sources? | 22:36 |
| disturbedsaint | kinda doing 10things at the same time, sorry for unclear reaply | 22:37 |
| disturbedsaint | running from sources indeed | 22:37 |
| markh | ah | 22:37 |
| markh | so you have pywin32-212 and have registered the shell execution by executing "mtbzr/scripts/tbzr.py"? | 22:37 |
| disturbedsaint | pywin32-212.win32-py2.5.exe | 22:38 |
| disturbedsaint | and I ran the script | 22:38 |
| disturbedsaint | with debug | 22:38 |
| disturbedsaint | but the output in PythonWin/Trace Collector isn't all that helpfull | 22:39 |
| markh | so no tracebacks or anything? | 22:39 |
| markh | you probably need to restart explorer too. | 22:40 |
| markh | (inno sends a shell notification that we don't when run manually - we should!) | 22:40 |
| markh | if you tell explorer to use a new process for each window, you can often avoid restarting - I tend to restart from the same command-prompt I registered with, which makes sure the env is setup correctly | 22:41 |
| disturbedsaint | ah, got a traceback | 22:42 |
| disturbedsaint | <type 'exceptions.ImportError'>: No module named win32pipe | 22:42 |
| markh | strange | 22:42 |
| markh | ah - python from sources too? | 22:42 |
| disturbedsaint | afaik not | 22:43 |
| disturbedsaint | but is a long time ago I installed it | 22:43 |
| disturbedsaint | C:\Python25\Lib\site-packages\win32\win32pipe.pyd exists, dont know if its the right one | 22:43 |
| markh | "python -c import win32pipe" works? | 22:43 |
| markh | yeah, it will be | 22:43 |
| markh | so pythonpath is messed up in com which implies the registry. Do you have the key HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.5\PythonPath? | 22:44 |
| disturbedsaint | importing win32pipe in python shell works | 22:44 |
| disturbedsaint | yes,HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.5\PythonPath is there | 22:45 |
| markh | it should have the default value of the default pythonpath - c:\python25\lib should be right | 22:45 |
| markh | it might have a couple with ';' seps | 22:46 |
| disturbedsaint | C:\Python25\Lib;C:\Python25\DLLs;C:\Python25\Lib\lib-tk | 22:46 |
| disturbedsaint | should be fine | 22:46 |
| markh | yeah | 22:47 |
| markh | so - maybe check that is the *first* traceback you see. Otherwise I'd be inclined to add a 'print' somewhere to see what PYTHONPATH is | 22:48 |
| markh | also, seeing if the scripts in shellext\tests work would be interesting. I suspect they will | 22:49 |
| disturbedsaint | ill rerun python tbzr.py --debug and see if I get a traceback | 22:51 |
| markh | I expect that to work. I'm guessing somehow the PYTHONPATH isn't correct when python is loaded a a COM object - it seems to work when Python is loaded normally | 22:52 |
| markh | those tests also use COM objects - but I expect them to work as it is Python loading the Python COM objects, so the pythonpath is likely to be correct still. | 22:52 |
| disturbedsaint | k | 22:53 |
| disturbedsaint | kind of complicated :P | 22:53 |
| markh | yeah | 22:53 |
| disturbedsaint | yeah first traceback is missing win32pipe | 22:54 |
| markh | and that is only when trying to use the shell ext, or at registration time? | 22:54 |
| markh | bizare though - win32pipe isn't the first win32 module loaded. | 22:54 |
| disturbedsaint | after registration when I browse a folder | 22:54 |
| disturbedsaint | by using notepad, open | 22:54 |
| markh | what are the last few lines in the traceback? | 22:55 |
| markh | hrnmph - that is insane. The traceback must point at client.py | 22:56 |
| disturbedsaint | http://nopaste.info/702238f887.html | 22:56 |
| markh | ahh - hg :) | 22:57 |
| markh | so that is very strange. win32pipe is imported in those modules *after* pywintypes, win32api and win32event | 22:58 |
| markh | so its not a simple path issue | 22:58 |
| disturbedsaint | there is no win32pipe.py | 23:01 |
| markh | but it looks like a simple "python can't find module" error, rather than "found the module but failed to load it" | 23:01 |
| markh | win32pipe.pyd is the correct file | 23:01 |
| igc | morning all | 23:02 |
| disturbedsaint | but there is a win32api.py and win32event.py file | 23:02 |
| markh | it is right next to win32event.pyd, which is imported directly before win32pipe! | 23:02 |
| markh | igc: good morning! | 23:02 |
| disturbedsaint | its middle of the night here :P | 23:02 |
| igc | hi markh! | 23:02 |
| markh | disturbedsaint: oh - you have something strange going on then :)( | 23:02 |
| disturbedsaint | ill redownload pywin32 | 23:03 |
| markh | I think py2exe might create stub .py files for .pyd files. I can't imagine how they got there for you though. | 23:03 |
| markh | disturbedsaint: you might need to uninstall and nuke the dirs too | 23:03 |
| markh | what dir is win32api.py in? | 23:03 |
| markh | igc: how are things? | 23:04 |
| disturbedsaint | in some shady temp-dir | 23:04 |
| markh | heh - nuke that :) | 23:04 |
| disturbedsaint | C:\Python25\Lib\site-packages\isapi\test\build\bdist.win32\winexe\temp | 23:04 |
| markh | hrmph | 23:04 |
| markh | oh | 23:04 |
| markh | you tried to py2exe an isapi extension? | 23:05 |
| igc | markh: surgery was successful ... recovering slowly | 23:05 |
| disturbedsaint | not that I know | 23:05 |
| markh | igc: awesome!! :) | 23:05 |
| disturbedsaint | could have been part of something else though | 23:05 |
| igc | markh: more in 3 weeks time though | 23:05 |
| markh | igc: what is recovery prognosis? | 23:05 |
| markh | ouch | 23:05 |
| markh | so one more in 3 weeks, then hopefully just recovery? | 23:05 |
| igc | markh: kind of - another 4 hr operation in 3 weeks, then recover from that, then a few months of chemo to wrap up | 23:07 |
| markh | bugger | 23:07 |
| igc | markh: so a long journey | 23:07 |
| igc | markh: nice to be back online though! | 23:07 |
| markh | yeah :( and yeah :) | 23:08 |
| markh | i expect its nice to know the first hit was a success | 23:08 |
| markh | must be a weight from your mind | 23:08 |
| igc | yup | 23:08 |
| igc | markh: and how are you? | 23:09 |
| markh | I'm very well! | 23:09 |
| igc | excellent! | 23:09 |
| markh | had about 10 days in china for my brother's wedding - was quite amazing! | 23:09 |
| igc | wow | 23:09 |
| markh | absolutely fascinating place | 23:09 |
| markh | disturbedsaint: this is one of the reasons that redoing the COM part in C++ is on the list of things to do... | 23:11 |
| disturbedsaint | markh: is it that much harder in python? | 23:11 |
| disturbedsaint | btw test_iconoverlay.py is OK, test_contextmenu.py fails | 23:11 |
| markh | its probably just stale. | 23:12 |
| markh | disturbedsaint: its much easier in python - python's more of a pain from a deployment and 'embedding in other random processes' POVs. | 23:13 |
| disturbedsaint | I see | 23:13 |
| disturbedsaint | well I'm off to bed | 23:13 |
| disturbedsaint | if there's anything I can test or try I'll be here on the irc this weekend | 23:14 |
| markh | disturbedsaint: sorry I couldn't get you going, but something very strange is going on with those imports - and we haven't yet got to anything tbzr related! | 23:14 |
| markh | I'll be on and off here too - just ping me | 23:14 |
| disturbedsaint | Well Ill do a clean python install to start with | 23:14 |
| disturbedsaint | prolly till tomorrow | 23:15 |
| markh | check there are no other dupes of 'wn32api' in your tree or on your PYTHONPATH | 23:15 |
| disturbedsaint | Will do! | 23:15 |
| disturbedsaint | have a nice day! (or night?) | 23:15 |
| markh | I'd try adjusting client.py and printing win32event.__file__ just before the win32pipe import | 23:15 |
| markh | it should print the file right next to win32pipe.pyd! | 23:15 |
| markh | 10:15 am for me - about to make coffee no 2 :) | 23:16 |
| markh | good night! | 23:16 |
| disturbedsaint | will try that | 23:16 |
| disturbedsaint | thx! | 23:16 |
| disturbedsaint | gb | 23:16 |
| === mlh is now known as mlh_zombie | ||
| chx | after bzr init I get Standalone tree (format: pack-0.92) I have bzr 1.8 installed is there something I need to do? bzr init --1.6 maybe? 0.92 seems very old. | 23:31 |
| lifeless | chx: thats fine | 23:33 |
| lifeless | chx: that just says that the default format was created in bzr 0.92 | 23:33 |
| lifeless | chx: so you can use the repository / branch with bzr clients back to 0.92 | 23:33 |
| chx | oh ok. | 23:34 |
| === spm_ is now known as spm | ||
| ccxCZ | how do I convert relative path to file id? | 23:45 |
| lifeless | poolie: do we do announcements on lp about bzr releases | 23:46 |
| ronny | yo | 23:46 |
| lifeless | ccxCZ: in python? | 23:46 |
| ronny | is there any documentation about the metadata i can put into a bzr repo and how it worksß | 23:46 |
| ccxCZ | lifeless: yup | 23:46 |
| lifeless | ccxCZ: tree.path2id(relpath) | 23:46 |
| poolie | lifeless: yes, we do | 23:46 |
| lifeless | hno has observed that there isn't a 1.8 announcement | 23:46 |
| lifeless | I haven't verified this | 23:46 |
| ccxCZ | lifeless: I haven't noticed that, thanks | 23:47 |
| poolie | that may be true | 23:48 |
| ronny | lifeless: what kinds of additional metadata about history is possible in bzr? | 23:54 |
| lifeless | ronny: I'm not sure what you mean | 23:54 |
| ronny | lifeless: i mean extra information i can assign to revisions | 23:54 |
| lifeless | ronny: at commit time bzr can record arbitrary key:value properties | 23:55 |
| ronny | (afair rich root + bzr svn do use stuff like that to keep clones able to communicate with the svn upstreams) | 23:55 |
| ronny | lifeless: and after commit? | 23:55 |
| lifeless | ronny: there is no facility for editing a revision after its committed | 23:55 |
| ronny | lifeless: i dont want to edit, i just want to add stuff | 23:55 |
| lifeless | ronny: that would count as editing :) | 23:56 |
| ronny | sad | 23:56 |
| lifeless | ronny: you could build a lookaside system on top of bzr's core I guess; what you're asking it pretty vague to me, I don't really understand your use case | 23:56 |
| lifeless | ronny: the very very very deep level of bzr is a write-once key:value database | 23:56 |
| lifeless | ronny: everything is built on the write-once aspect, because that makes distribution and transfer of data and integrity _much_ simpler than if we didn't have that | 23:57 |
| ronny | lifeless: i just want append-only metadata thats added after the actual commit | 23:57 |
| Odd_Bloke | ronny: A text file? | 23:58 |
| lifeless | ronny: so, we don't have a pre-canned mechanism for that today; you could write one using bzr's primitives, or even as odd_bloke says just use a text file | 23:59 |
| ronny | no NOT files | 23:59 |
| Odd_Bloke | ronny: Why not? | 23:59 |
| ronny | its metadata about the history, not part of the actual history of the data im managing in the scm | 23:59 |
| lifeless | ronny: I understand that | 23:59 |
| ronny | think of it as rich tags | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!