| lifeless | dato: ^ | 00:00 |
|---|---|---|
| dato | yeah, I was thinking | 00:00 |
| lifeless | :P | 00:01 |
| lifeless | james w mentioned the index's support for review etc as being very useful | 00:01 |
| dato | yeah, the index is actually very useful for that | 00:02 |
| dato | I tend to review my stuff before committing a lot | 00:02 |
| lifeless | I wrote a proposal for review support in bzr | 00:02 |
| dato | so it's very useful to say, "ok this part is definitely ok, don't show to me in `diff` again please" | 00:03 |
| lifeless | have you seen that? | 00:03 |
| dato | no, subj? | 00:03 |
| dato | ah | 00:03 |
| dato | probably RFC: supporting code review and partial commits better | 00:03 |
| lifeless | yes I was just digging it up :) | 00:03 |
| lifeless | if you have the time I would love your feedback on that as someone that used bzr for ages, knows the feel we aim for etc, but also is fluent with sophisticated use of git's index | 00:04 |
| lifeless | It is not written as a comparison to the index; we wanted to derive something useful from first principles | 00:05 |
| dato | right | 00:05 |
| dato | ok, I can read the thread | 00:05 |
| lifeless | but git's index is clear prior art :) | 00:05 |
| lifeless | that would be lovely; thanks | 00:06 |
| jelmer | ok, bzr push --overwrite and bzr uncommit work on svn repositories now >-) | 00:20 |
| lifeless | holy cow | 00:20 |
| lifeless | that is full of awesome | 00:20 |
| jelmer | So (other than proper integration in push) that means full coverage I think | 00:21 |
| lifeless | well that lhs parent bug thing | 00:22 |
| jelmer | I've got most of that covered, working on tests atm | 00:23 |
| lifeless | sweeet | 00:23 |
| james_w | nice work jelmer, that's pretty cool | 00:25 |
| lifeless | I shudder to think how it works | 00:37 |
| lifeless | jelmer: planning merge support for svn trees now ? :) | 00:37 |
| james_w | you could just edit the files in the svnroot | 00:37 |
| jelmer | lifeless, probably at some point :-) There's some other things I'd like to work on first though, such as integrating the svn-push command | 00:49 |
| james_w | jelmer: do you have the rebase based mode for bzr-svn now? | 00:50 |
| jelmer | james_w, not sure I follow - what sort of mode of mode? | 00:51 |
| james_w | it was discussed a little while back, more like git-svn I think | 00:52 |
| james_w | for those that didn't want the properties tracking etc., and could put up with having one hand tied behind their back | 00:52 |
| jelmer | ahh | 00:54 |
| jelmer | yep, that's in now, under the command dpush | 00:54 |
| james_w | cool | 00:54 |
| james_w | I'll have to play sometime in case anyone asks me about it | 00:54 |
| DBO | i can't seem to upgrade my bzr repo | 01:30 |
| lifeless | are you getting an error? | 01:30 |
| DBO | ok so it went like this | 01:30 |
| DBO | my main trunk got a bzr upgrade | 01:30 |
| DBO | so when i went to merge it into my branch | 01:31 |
| DBO | it said to upgrade, so I did and it all worked | 01:31 |
| DBO | I then did the merge | 01:31 |
| DBO | that worked | 01:31 |
| DBO | then when I do bzr push | 01:31 |
| DBO | it tells me to upgrade | 01:31 |
| DBO | which i already did | 01:31 |
| lifeless | what is the exact message it giveS? | 01:32 |
| DBO | Using saved location: bzr+ssh://jassmith@bazaar.launchpad.net/~jassmith/do/Optimizer/ | 01:32 |
| DBO | bzr: ERROR: Tags not supported by BzrBranch5('bzr+ssh://jassmith@bazaar.launchpad.net/%7Ejassmith/do/Optimizer/'); you may be able to use bzr upgrade --dirstate-tags. | 01:32 |
| DBO | i ran the command it suggested and it says its already up to date | 01:32 |
| Peng_ | bzr upgrade sftp://jassmith@bazaar.launchpad.net/~jassmith/do/Optimizer/ | 01:32 |
| DBO | oooo | 01:33 |
| jelmer | we really should stop recommending people to upgrade to --dirstate-tags.. | 01:33 |
| lifeless | that error is a bad one | 01:33 |
| lifeless | jelmer: care to submit the obvious patch? | 01:33 |
| DBO | what does it do? | 01:33 |
| meteoroid | is sftp faster than bzr+ssh, or just shorter to type? | 01:33 |
| lifeless | (just remove the --dirstate-tags) | 01:33 |
| lifeless | meteoroid: sftp works ;P | 01:34 |
| jelmer | I thought James had one which improved some of the upgrade error messages | 01:34 |
| jelmer | james_w, Whatever happened to that? | 01:34 |
| lifeless | jelmer: not this one | 01:34 |
| Peng_ | meteoroid: upgrade doesn't work over bzr+ssh. (I think that might've been fixed in bzr.dev last week though.) | 01:34 |
| meteoroid | ah ok | 01:34 |
| DBO | so erm, how long is this command supposed to take Peng_? | 01:34 |
| james_w | I thought that was Andrew that wrote that patch | 01:34 |
| lifeless | DBO: dirstate-tags is an older format that should be avoided generally; that error message is one we missed - it should just say 'bzr upgrade' there. | 01:34 |
| Peng_ | DBO: Well, it has to download everything and upload it again. | 01:35 |
| DBO | Peng_, ok, long time, I'll go make a sammich | 01:35 |
| Peng_ | Hm, all you'd really have to do for tag support is upgrade the branch, though. | 01:35 |
| Peng_ | DBO: That branch isn't ver large, only ~4.5 MB. Unless you're on dial-up, it shouldn't take forever. | 01:35 |
| lifeless | Peng_: a branch5 branch is knit based already | 01:35 |
| lifeless | Peng_: so upgrading to packs is a good thing anyhow | 01:36 |
| DBO | Peng_, im on something that averages around 100kbps down and slightly better than dialup up =P | 01:36 |
| Peng_ | lifeless: True. | 01:36 |
| Peng_ | DBO: Oh. | 01:36 |
| DBO | anyhow, thanks for the wizardry that is bazaar, its the best tool we use =) | 01:36 |
| RAOF | DBO: I've filed a bug against launchpad asking for a "upgrade this branch" button, since launchpad could do it locally much, much faster. | 01:37 |
| DBO | RAOF, sweet | 01:38 |
| jelmer | bzr+ssh should support upgrades properly without involving the VFS code | 01:38 |
| jelmer | lifeless, submitted to the list | 01:42 |
| jelmer | james_w, yeah, it was spiv indeed. sorry | 01:42 |
| james_w | hey, I don't mind being credited with more than I've done | 01:43 |
| jelmer | :-) | 01:45 |
| * meteoroid wonder if it is always necessary to type the full upstream svn url when interacting with a bzr branch of an svn repo, and pushing / pulling changes. | 01:51 | |
| james_w | meteoroid: it shouldn't be | 01:52 |
| james_w | plain "bzr pull" should use the remembered URL | 01:52 |
| meteoroid | hm. | 01:52 |
| meteoroid | bzr: ERROR: No pull location known or specified. | 01:52 |
| james_w | interesting | 01:52 |
| meteoroid | i'm a little bit old, using ubuntu package, looks like 1.3.1 | 01:52 |
| james_w | it should remember it when that happens | 01:53 |
| james_w | that shouldn't matter for this | 01:53 |
| meteoroid | hm. | 01:53 |
| Peng_ | In my experience, bzr-svn has a habit of forgetitng the URL. I've never tried to track down what exactly happens. | 01:53 |
| Peng_ | A pull --remember fixes it. | 01:53 |
| jelmer | It's a known bug in older versions | 01:53 |
| jelmer | 0.4.11 will have it fixed | 01:53 |
| Peng_ | Oh, good. | 01:53 |
| Peng_ | jelmer: Has it already been fixed in the 0.4 branch? What exactly happened? | 01:53 |
| meteoroid | nice. are there beta debs for bzr-svn to go with the bzr beta debs? | 01:54 |
| Peng_ | There haven't been any beta releases of the next version of bzr-svn. | 01:55 |
| jelmer | Peng_, yes, it's fixed in the 0.4 branch | 01:56 |
| jelmer | Peng_, Missing set_parent() call, as simple as that :-) | 01:56 |
| Peng_ | jelmer: What was it missing from? Branching? | 01:57 |
| jelmer | Peng_, yes | 01:57 |
| Peng_ | Oh. | 01:57 |
| Peng_ | That's simple enough. Thanks for fixing it. :) | 01:58 |
| Peng_ | Did it affect svn-import too? | 01:58 |
| jelmer | that's also doing the set_parent() call at the moment | 01:59 |
| jelmer | I'm not sure when that was added though | 01:59 |
| Peng_ | Well, I'm gonna go. Bye. :) | 02:00 |
| meteoroid | Peng_: --remember did the trick, thanks | 02:03 |
| * meteoroid looks forward to a new release | 02:03 | |
| DBO | wooo, phase 3 of 4 | 02:15 |
| * DBO sighs | 02:15 | |
| RAOF | Ya. It's not speedy. | 02:15 |
| DBO | the best part of that last commit? it will drop a whole 1, you heard that, 1, machine (as in assembly level) instruction from our code | 02:17 |
| DBO | yep =) | 02:17 |
| DBO | its an AWESOME optimization | 02:17 |
| DBO | it also fixes a bug... | 02:17 |
| lifeless | inner loop ? | 02:17 |
| DBO | its inside a loop that gets run upwards of 100 million times a minute if you are a heavy user | 02:18 |
| DBO | it can be run never also... all depends on how much you use the program =P | 02:18 |
| lifeless | DBO: how do you make sure someone doesn't add an instruction back to the loop ? | 02:37 |
| DBO | lifeless, i have ninjas | 02:43 |
| lifeless | :P | 02:44 |
| lifeless | so its GnomeDO right ? | 02:44 |
| RAOF | GNOME Do, yes. | 02:45 |
| lifeless | meh caps schmaps | 02:47 |
| lifeless | anyhow | 02:48 |
| lifeless | what search engine(s) are involved there? | 02:48 |
| RAOF | This depends on what you mean. Do has its own search on its item collection. There are plugins which use locate, google, an arbitrary Firefox search provider, xesam, and others. | 02:49 |
| james_w | hey RAOF, are you on Intrepid yet? | 02:50 |
| RAOF | Yup. | 02:50 |
| lifeless | so it calls into each per-keystroke I guess (for completion?) | 02:50 |
| james_w | metacity? | 02:50 |
| * RAOF moves stupidly early in the cycle. | 02:50 | |
| RAOF | james_w: Indeed. | 02:50 |
| james_w | is your do window off to one side? | 02:50 |
| james_w | mine's not central on the screen | 02:50 |
| RAOF | james_w: Mine seems to be pretty much in the middle. | 02:51 |
| james_w | hmm, I'll try and work out what's going on then | 02:51 |
| RAOF | lifeless: This is currently in a bit of flux. Currently all items are known by Do before any searching occurs, and the keypresses search through this internal list. | 02:51 |
| lifeless | wheee memory use | 02:52 |
| lifeless | RAOF: I'm asking because I'm doing some IR stuff at the moment | 02:52 |
| RAOF | IR? | 02:52 |
| lifeless | information retrieval | 02:52 |
| RAOF | Ah. The memory use isn't bad; Do is currently at ~30MiB. | 02:53 |
| lifeless | RAOF: thats 50% of my free memory :) | 02:54 |
| james_w | RAOF: I restarted it and it it's now central, but a little high, I suspect X wackiness. | 02:54 |
| RAOF | james_w: It's intended to be a little bit above the middle. | 02:54 |
| RAOF | lifeless: Here's 50 cents, go buy yourself another gig of ram :) | 02:55 |
| james_w | RAOF: ah, that will be it then :-) | 02:55 |
| lifeless | RAOF: laptop slots are full kthx | 02:55 |
| RAOF | How much ram is _in_ that laptop? | 02:56 |
| lifeless | well there is 300MB back by killing flash | 02:56 |
| lifeless | 2G | 02:56 |
| RAOF | Same here. What's eating your ram? | 02:57 |
| lifeless | ff hs 570M res, evo is 390M res, npviewer *was* 330M or so res (but I just killed the bugger) | 02:57 |
| lifeless | next is xorg at 30M and a bug around that size | 02:58 |
| RAOF | ff at 200, evo at 156, banshee-1 at 150 resident. Everything else is below 100. | 02:59 |
| lifeless | so do you ask xesam for a concordance before you do any search? | 03:01 |
| lifeless | I'd have thought something like that that could be indexing gb's of data would be slow used that way | 03:01 |
| RAOF | The xesam plugin is sitting somewhere on launchpad; it's not a default plugin. | 03:04 |
| lifeless | ah | 03:04 |
| RAOF | I'm not sure how it does its think. | 03:04 |
| RAOF | s/k/g/ | 03:04 |
| lifeless | k | 03:04 |
| meteoroid | oh, bollocks | 04:12 |
| meteoroid | so, i want to use bzr and bzr-svn as a passthrough for a project where i am forking upstream code in one svn repo, and wish to provide an svn repo for the team working on the fork, merging perhaps in some cases bidirectionally through a bzr repo on my svn server. | 04:30 |
| meteoroid | i get an error trying to push code to my svn which is pulled from another, is this perhaps a limitation of bzr-svn? | 04:31 |
| jelmer | meteoroid, what error message? | 04:31 |
| meteoroid | one sec | 04:31 |
| jelmer | if this is a new branch you're pushing into subversion, use svn-push rather than push | 04:31 |
| meteoroid | ah | 04:32 |
| meteoroid | http://paste.plone.org/22937 fyi | 04:32 |
| meteoroid | will try that RW | 04:32 |
| meteoroid | RQ | 04:32 |
| meteoroid | svn-push did the trick | 04:33 |
| meteoroid | awesome! full speed ahead! :) | 04:33 |
| meteoroid | thanks jelmer | 04:33 |
| pickscrape | Is there a clever way to get a boolean value from bazaar.conf without having to parse it myself? | 04:51 |
| pickscrape | get_user_option just returns a string | 04:52 |
| meteoroid | hm, where does bzr-smart.py come from? | 05:04 |
| meteoroid | (to run smart server in apache httpd mod_python) | 05:05 |
| lifeless | I think the content of it is just whats in teh docs | 05:12 |
| meteoroid | ah, just wsgi config, any idea if the smart server works with mod_wsgi? | 05:14 |
| lifeless | I think it does | 05:20 |
| meteoroid | that would be much simpler, i bet i can figure it out | 05:20 |
| pickscrape | As a general rule should plugins not be using print for output? | 06:02 |
| pickscrape | I see that builtin commands tend to use self.outf.write() | 06:03 |
| pickscrape | Though some do use print | 06:03 |
| lifeless | command objects should always use self.outf | 06:09 |
| lifeless | and mutter etc | 06:09 |
| pickscrape | Is mutter for debug info rather than general user output? | 06:09 |
| pickscrape | OIC, the --quiet and --verbose options work by determining what mutter levels get shown to the user... | 06:14 |
| beuno | [OT] http://adweek.blogs.com/adfreak/2008/07/then-well-grab.html | 06:15 |
| beuno | ROFL | 06:15 |
| === mtaylor_ is now known as mtaylor | ||
| ToyKeeper | Oops. Must remember not to bzr upgrade until at least a month after bzr starts telling me to do so. | 07:44 |
| ToyKeeper | Launchpad doesn't like the new format. | 07:45 |
| RAOF | Which one? bzr is only likely to ask you to upgrade to pack-0.92, I think, and that's hardly new. | 07:48 |
| ToyKeeper | I was using pack-0.92 | 07:50 |
| ToyKeeper | Oddly enough, after updating bzr.dev (it was about a week old), it no longer tells me I'm using a deprecated format. | 07:51 |
| ToyKeeper | Whatever was broken in the old bzr.dev seems to be fixed now. | 07:51 |
| ToyKeeper | It complained that pack-0.92 was deprecated, and listed a '--1.6' option for upgrade which didn't work. Both are fixed now. :) | 07:52 |
| kiorky | uhm, i get problems configuring loggerhead, if i have /top/a/c and /top/b/c, the second "c" wont appear :( | 08:17 |
| kiorky | (in "auto_publish" mode) | 08:17 |
| * meteoroid whistles innocently while branching around 600 revisions of a public subversion | 08:52 | |
| RAOF | meteoroid: How many prebuilt dlls does it contain? :) | 08:53 |
| meteoroid | not a one, just python code. | 08:53 |
| meteoroid | i'm just worried i'll crash mod_dav_svn and wake some poor fool up ;d | 08:54 |
| RAOF | Soft. I've been trying to branch google-gdata, and that contains ~15Mb worth of prebuilt code. | 08:55 |
| meteoroid | lots of revisions of each prebuilt file? | 08:58 |
| RAOF | Quite a number, yes. | 08:58 |
| meteoroid | fun | 08:58 |
| meteoroid | why prebuilt code in svn? | 08:58 |
| RAOF | I have _no_ idea. | 08:59 |
| meteoroid | heh | 08:59 |
| RAOF | They have a Makefile and Visual Studio project which builds them. | 08:59 |
| meteoroid | someone teach them about svn:ignore ;d | 08:59 |
| RAOF | They're deliberately there. Oh, and there's an x86 and arm build of zlib in there, too. | 09:00 |
| meteoroid | hm. | 09:00 |
| * awilkins is branching the SVN of JTidy | 09:06 | |
| awilkins | It's taking a looong time | 09:06 |
| awilkins | Some things are a total sod to build on windows ; maybe those pre-built files are there for that reason | 09:10 |
| RAOF | These things are built from the source in this very svn repo, and have no dependencies outside of the .NET corelib stack. | 09:11 |
| awilkins | Ok then, they are daft | 09:11 |
| RAOF | Well, the zlib dlls aren't, true. | 09:11 |
| awilkins | With VB6, you at least have the excuse you need to preserve the GUIDS for binary compatibility | 09:12 |
| RAOF | What, really? | 09:12 |
| RAOF | A _rebuild_ breaks VB6? That's awesome. | 09:12 |
| awilkins | Yeah, VB6 uses an existing compiled binary to refer to for interface IDs and type IDs | 09:12 |
| awilkins | Because of COM | 09:13 |
| awilkins | And how it abstracts it all away from the developer | 09:13 |
| awilkins | I always make a copy in a "compat" subfolder | 09:13 |
| RAOF | That is made of pure win. | 09:13 |
| awilkins | It's the source of endless swearing in many codebases | 09:14 |
| RAOF | I can't possibly imagine why ;) | 09:14 |
| awilkins | I've written build tools arranged around determining VB6 dep trees and fixing the compatibility settings | 09:15 |
| meteoroid | and now i will find out how long it takes to branch ~10k revisions ;d | 09:18 |
| gour | i just found out that one project us using git on savannah. is bzr also supported there? | 09:27 |
| gour | *is | 09:28 |
| RAOF | Yes. | 09:29 |
| gour | really? then i can suggest to devs to move to bzr instead of CVS | 09:30 |
| RAOF | gnash is hosted on savannah, and uses bzr. I would be amazed if anyone was suggesting that something be moved _to_ cvs, though :) | 09:32 |
| gour | well, they already use CVS :-) | 09:34 |
| === AnMaster_ is now known as AnMaster | ||
| kiorky | pmezard: hello | 10:15 |
| kiorky | pmezard: do you have some kind of status for the forest extension? | 10:15 |
| kiorky | pmezard: oups, wrong chan : | 10:16 |
| kiorky | :) | 10:16 |
| gour | any handy url to answer question in http://article.gmane.org/gmane.comp.gnu.medical.devel/12670 ? | 10:40 |
| gour | (how switching from CVS to bzr might help to get more contribution to the project) | 10:43 |
| awilkins | Using Bazaar means that everyone gets the benefit of using a VCS ; using CVS limits that to a select few with commit access | 10:51 |
| ToyKeeper | gour: No particular URL comes to mind, but it'd be easy to make an argument based on user interface and benefits of DVCS over a single central repository. | 10:51 |
| ToyKeeper | The launchpad tour is full of good reasons too, though only some of that is bzr-related. https://edge.launchpad.net/+tour/index | 10:52 |
| gour | ToyKeeper: how about http://ianclatworthy.wordpress.com/2007/10/11/why-distributed-version-control-matters/ | 10:53 |
| * ToyKeeper wonders why that document is PDF instead of HTML | 10:55 | |
| ToyKeeper | gour: There's also the social aspect... cvs these days is about as hip as having toilet paper stuck to one's shoe. It can deter potential contributors just because it doesn't have a good "smell", so to speak. | 10:57 |
| ToyKeeper | Even if it's used correctly, people may assume it's a bad sign. | 10:58 |
| gour | rotfl | 10:58 |
| * gour sent url for ian's paper | 11:00 | |
| ToyKeeper | I'm in the middle of reading his manifesto for community-agile software guidance. He has some good texts. | 11:01 |
| gour | that's good one too | 11:01 |
| === pbor|afk is now known as pbor | ||
| LarstiQ | jelmer: pong | 12:17 |
| gnomefreak | for some reason bzr builddeb during a build using bzr bd --merge --dont-purge --builder='dpkg-buildpackage -rfakeroot -kA5C42601 -i.bzr' . wont allow me to sign it but with -S -sa it lets me sign it | 13:14 |
| gnomefreak | this has been happening for a while maybe a month or so now | 13:14 |
| gnomefreak | it results in a failed build but it built fine jsut failed to sign so maybe the error message can be tweeked as well? | 13:15 |
| LarstiQ | gnomefreak: sounds like filing a bug might be appropriate? | 13:18 |
| LarstiQ | gnomefreak: are you sure you want -i.bzr btw? | 13:18 |
| gnomefreak | LarstiQ: i might have already ill check since i cant remember | 13:18 |
| gnomefreak | LarstiQ: yes im sure | 13:18 |
| gnomefreak | we dont want .bzr being uploaded with package | 13:19 |
| LarstiQ | gnomefreak: maybe it's specific to building bzr packages, but .bzr also ignores 'files.bzr' and such | 13:19 |
| gnomefreak | or built for that matter | 13:19 |
| LarstiQ | gnomefreak: right right, but that ignore pattern is ignoring more than just /.bzr/ :) | 13:19 |
| gnomefreak | LarstiQ: shouldnt it only ignore .bzr since that is what i told it to ignore, with everything inside .bzr of course | 13:20 |
| LarstiQ | gnomefreak: it's a regex pattern, not a shell glob. | 13:23 |
| LarstiQ | gnomefreak: I guess if you don't have any files with 'bzr' in their name you are fine. | 13:23 |
| gnomefreak | i dont outside of .bzr | 13:23 |
| LarstiQ | ok, no problem then | 13:23 |
| gnomefreak | does bzr use LP for bug tracking? | 13:25 |
| LarstiQ | gnomefreak: yes, but you want bzr-builddeb I think? | 13:27 |
| gnomefreak | yeah i just relized it is needed instead of bzr i was thinking it was a plugin but i remember installing it as a package | 13:28 |
| james_w | gnomefreak: you don't need -i.bzr | 13:29 |
| gnomefreak | james_w: when was it changed? | 13:33 |
| gnomefreak | ok bug is filed | 13:33 |
| gnomefreak | james_w: ive been using -i.bzr for a long time since i was told to leave .bzr out of it | 13:34 |
| james_w | bzr-builddeb takes care of that | 13:35 |
| james_w | if it doesn't please file a bug explaining your setup | 13:35 |
| gnomefreak | it didnt used to so ive just been using same command not knowing it had changed | 13:38 |
| gnomefreak | well important problem has been reported https://bugs.launchpad.net/bzr-builddeb/+bug/254400 | 13:38 |
| ubottu | Launchpad bug 254400 in bzr-builddeb "when building a package with bzr-builddep it fails to promt me for a password to sign package" [Undecided,New] | 13:38 |
| gnomefreak | thanks for the input im gone again for store | 13:39 |
| LarstiQ | james_w: I also needed to use -i ('^/.bzr/'?) in the past. | 13:39 |
| james_w | interesting | 13:39 |
| james_w | do you know why? | 13:39 |
| gnomefreak | it was just the way it was | 13:40 |
| gnomefreak | afaik | 13:40 |
| gnomefreak | but i dont know the code for bzr | 13:40 |
| gnomefreak | thanks guys ill see you later | 13:40 |
| LarstiQ | gnomefreak: bzr-builddeb, not bzr | 13:42 |
| LarstiQ | james_w: iirc your initial decision was to mirror svn-buildpackage? | 13:42 |
| james_w | yeah | 13:42 |
| LarstiQ | it's all a bit hazy in my mind, but I thought without it I'd end up with .bzr/ in my packages. I admit my memory is fallible. | 13:43 |
| james_w | it does and "export" so it shouldn't | 13:45 |
| james_w | maybe there's a case that I missed though | 13:45 |
| kiorky | What will be the good place to propose a patch for loggerhead? | 13:49 |
| james_w | the bazaar mailing list, or a bug against loggerhead probably | 13:51 |
| james_w | you could put a branch on launchpad and propose it for merging | 13:51 |
| kiorky | ok | 13:54 |
| james_w | lifeless: http://repo.or.cz/w/topgit.git?a=blob;f=README | 15:04 |
| === prateeksaxena is now known as prTk | ||
| james_w | lifeless: the announcement: http://article.gmane.org/gmane.comp.version-control.git/91197 | 15:06 |
| maploin | hi, i'm trying to do a merge, but i get a Content conflict in a file that i deleted, which also appears in the removed list. How do I solve this? | 15:19 |
| kiorky | /B 2 | 15:50 |
| rocky | jelmer: have a minute for more information about my mysterious can-keep-committing-same-revisions problem? | 17:24 |
| rocky | is there any way for me to tell where a branch came from? like see that it was branched from branch1 which was branched from branch2 which was branched from trunk ? | 17:26 |
| jelmer | rocky, hi | 18:11 |
| meteoroid | hey rocky, didn't know you were a bzr user :) | 18:11 |
| jelmer | rocky, still there? | 18:11 |
| rocky | jelmer: yep | 18:11 |
| rocky | meteoroid: yep ;) | 18:11 |
| jelmer | rocky, is there svn repo where you're experiencing this problem public? | 18:12 |
| rocky | jelmer: couple questions first... i should always be using svn-push when pushing a local branch changes back to svn right? | 18:12 |
| jelmer | rocky, You can, but there's no reason to | 18:12 |
| rocky | jelmer: i should use bzr push ? | 18:13 |
| meteoroid | rocky; i think only if you are creating the branch, e.g. if the parent dir doesn't exist upstream. | 18:13 |
| jelmer | rocky, the only situation where you have to use svn-push and nothing else is when nothing exists yet in svn | 18:13 |
| jelmer | rocky, in all other situations bound branches or regular push should work as well | 18:13 |
| rocky | gotcha | 18:15 |
| rocky | and regular pull should work fine too right? | 18:15 |
| jelmer | yeah | 18:16 |
| jelmer | back in ~30 min | 18:16 |
| meteoroid | rocky: in current release, though i believe fixed in 0.4.11 or whatever the next is, there is a wierd issue where sometimes the repo is forgotten. if 'bzr pull' doesn't work, give it a url and --remember, e.g. 'bzr pull --remember https://svn.rocky.org/svn/rocky/rockys-stuff' | 18:17 |
| rocky | jelmer: btw, the public svn repo for my work is at: https://dev.serverzen.com/svn/cluemapper/ClueMapper/ but i've been fiddling with this all morning so i could have everything messed up | 18:17 |
| meteoroid | ClueMapper looks interesting.. | 18:19 |
| rocky | www.cluemapper.org | 18:22 |
| === thekorn_ is now known as thekorn | ||
| meteoroid | jelmer: does the svn cache have to be per-user, can i set it up to be owned by a group that handles merges on the svn server? | 18:50 |
| meteoroid | well owned by is easy, but i mean, not in some location like ~/foozle/ | 18:50 |
| jelmer | rocky, Thanks, I'll have a look at that in a sec | 18:50 |
| jelmer | meteoroid, no, the location is pretty much hardcoded atm | 18:51 |
| * meteoroid nods head | 18:51 | |
| rocky | jelmer: just an fyi, i figured out kinda what the problem was ... everytime i checked out ClueMapper/trunk with bzr it somehow got remembered (with the bzr svn props) that it was ClueMapper/branches/rocky so when i would do a commit, it committed to ClueMapper/branches/rocky instead of trunk ... after i removed all of the bzr svn props from the svn repo, things started working predictably again | 18:52 |
| jelmer | rocky, that doesnt sound right | 18:52 |
| rocky | yeah i assume i triggered a corruption bug somewhere | 18:52 |
| jelmer | rocky, the props don't contain information about locations | 18:53 |
| rocky | oh? well i tried blowing away all my local checkouts/branches then checking out trunk again, adding a change, committing, and voila, it went back to the rocky branch (incorrect) ... it was only after i deleted those bzr svn branches that it finally started working | 18:53 |
| jelmer | hmm, I'll see if I can find out what was going wrong then | 18:54 |
| jelmer | corruption is not nice :-( | 18:55 |
| jelmer | rocky, you're running 0.4.10? | 18:55 |
| rocky | yes i am | 18:56 |
| rocky | atm, i'm running bzr 1.5, bzr-svn 0.4.10, svn 1.5 | 18:56 |
| rocky | ubuntu hardy heron | 18:56 |
| rocky | jelmer: fyi, i'm writing up a blog post on my experiments with bzr-svn as in how to get started ... i'd love to have you proof-read it to ensure i'm not making gross mistakes | 18:58 |
| meteoroid | hm, i will hang back on bzr 1.3.1, bzr-svn 0.4.9-1, and svn 1.4.6 on hardy for now. did you build from source? afaict these are the latest debs. | 18:58 |
| jelmer | rocky, sure, no problem | 18:59 |
| rocky | meteoroid: i used intreprid debs for all of those on hardy | 18:59 |
| rocky | k, i'm not done with the post yet | 18:59 |
| meteoroid | rocky: i wonder what sort of workflow you are describing, i also was going to write a guide on using bzr-svn to fork upstream projects while retaining the ability to push changes back into them, though i haven't quite figured out how to select only some changes for acceptance upstream. | 19:01 |
| meteoroid | "fork, n.: a branch with a middle finger logo." :-P | 19:01 |
| rocky | meteoroid: this is *very* basic | 19:01 |
| meteoroid | right on, perhaps i can build on yours when i write mine so i don't have to cover all that ground | 19:01 |
| rocky | sure | 19:03 |
| meteoroid | hey rocky you should open up non-https svn as well read-only, will lessen the load on your server when other people follow you in svn.. | 19:37 |
| rocky | meteoroid: http://www.cluemapper.org/svn | 19:39 |
| meteoroid | ah ok | 19:39 |
| meteoroid | i just tried as same url | 19:39 |
| rocky | i'm still trying to figure out the whole push/pull thing ... this is supposed to work on mirrored branches right? and won't work if the branches "diverge" ? could someone explain the simplest case of the branches "diverging" ? | 20:06 |
| meteoroid | i have more experience with that level of usage from bk, i'm not sure how similar bzr is, but generally in DSM there is some auto-conflict-resolution, and in some cases you need to hand-merge a conflict | 20:07 |
| meteoroid | er DSCM | 20:07 |
| meteoroid | other than the repo itself one of bk's strengths was, in the past, the conflict resolution code - in our team at rackspace we often had more than 20 branches a piece going between 12 or more people, the web / marketing team branched our code for the customer portal, networking had branches, etc.. | 20:08 |
| meteoroid | it was pretty nice except the not having source code and the paying lots of money | 20:08 |
| meteoroid | ;d | 20:08 |
| meteoroid | there were only a few of us who knew how to manage merges, but we handled that by having master branches for each team, so that if two entirely unrelated projects modified the same code, they'd have to sit down at some point and talk out what each of them did, or someone who knows the code and understand both projects use a 3-way merge tool like meld | 20:09 |
| meteoroid | i haven't tried meld with bzr yet but it's a pretty standard tool, works with svn | 20:10 |
| meteoroid | i suggest doing some experiments, i have been testing a lot of stuff over the past couple days and learned a good bit.. | 20:10 |
| meteoroid | the simplest case, i guess, let's say you modify one file in one branch, and another file in another branch, it should be straightforward | 20:14 |
| james_w | rocky: divergence happens if there are commits on two branches, so if I branch from you, and then we both commit on our own branch they will have diverged. | 20:16 |
| james_w | that then means we can't push/pull between us, one of us needs to merge | 20:16 |
| meteoroid | james_w: with non-overlapping changes, it should be straightforward though, yes? | 20:18 |
| james_w | meteoroid: yeah, it might be, but in bzr terms you *must* "bzr merge", you can't "bzr pull" | 20:18 |
| rocky | got it | 20:19 |
| rocky | commits on both branches invalidates pulling/pushing until one branch does merge from another -- that pretty much covers it right? | 20:19 |
| james_w | yeah, that's the essence | 20:19 |
| meteoroid | james_w: ah, ok, good to know.. | 20:22 |
| meteoroid | is there an intentional reason that bzr push / pull doesn't imply a merge if required? | 20:24 |
| james_w | so that it is an explicit step | 20:25 |
| meteoroid | okey doke. :) | 20:25 |
| james_w | it would be really hard to make push merge | 20:25 |
| james_w | you can make pull merge, but bzr doesn't, for a few reasons | 20:26 |
| meteoroid | i'm sure i'll learn more over time how bzr is different from bk, the only dscm i've used. hg seems more like bk in ways that i don't entirely appreciate. | 20:27 |
| meteoroid | the svn support in hg is esp wierd and sort of analogous to just doing an svn export on top of the hg branch ;g | 20:27 |
| meteoroid | well, it's a little better than that but still awkward imo. | 20:28 |
| meteoroid | anyway, i recall that in bk, push and pull were sort of analogous, only indicating direction, and that you could either pull changes from a developer workstation over ssh to merge them into a team branch, or push them up from the workstation, and pretty much the same stuff happened. if the merge failed or had conflicts or whatever the terminology is, a 3-way merge tool popped up, or a message was printed saying, like, "hey, you have to | 20:35 |
| meteoroid | i can see advantages to making it a conscious step, but it's also something else to teach users which may just fall upon more senior members of a team, creating bottlenecks. | 20:36 |
| jelmer | rocky, looks like the bug you hit earlier was 250480 | 20:37 |
| jelmer | (bug 250480) | 20:37 |
| ubottu | Launchpad bug 250480 in bzr-svn "Doesn't preserve non-lhs parents for file texts" [Critical,Triaged] https://launchpad.net/bugs/250480 | 20:37 |
| rocky | jelmer: ahh... great ;) | 20:37 |
| mathrick | hiya | 20:44 |
| mathrick | what's the status of cherrypicking support and how much of what it depends on is done? | 20:45 |
| jelmer | mathrick, cherrypicking itself is supported (has been for a long time); I'm not sure what the plans are for tracking cherrypicks | 20:45 |
| mathrick | that's exactly what I mean | 20:46 |
| mathrick | non-tracking cherrypicks are rather useless/harmful | 20:46 |
| james_w | why? | 20:46 |
| mathrick | because it causes conflicts later on | 20:46 |
| mathrick | and because by the time conflicts arise they will be buried deep in history, you won't even be able to uncommit them easily | 20:47 |
| uws | mathrick: Applying cherrypicks twice will be a no-op | 20:47 |
| uws | mathrick: uses the base revision anyway, so I don't see what conflicts it could cause | 20:48 |
| mathrick | uws: but if they're non-tracked, bzr won't notice and will try to apply, causing text conflicts, no? | 20:48 |
| LarstiQ | mathrick: no | 20:48 |
| uws | NO | 20:48 |
| uws | it will apply to the base | 20:48 |
| uws | and end up with the same results as it already had | 20:48 |
| mathrick | oh | 20:48 |
| uws | i.e. bzr status won't notice | 20:48 |
| LarstiQ | mathrick: what you describe is what svn does/used to do. | 20:48 |
| mathrick | so what exactly would tracking do that it doesn't already? | 20:49 |
| uws | mathrick: overview of missing patches/revisions | 20:49 |
| uws | mathrick: I have this issue with 2 diverged branches | 20:49 |
| uws | which I can not/do not want to merge | 20:49 |
| uws | But some revisions needs to be applied to both | 20:49 |
| uws | "bzr missing --line" helps listing them | 20:49 |
| uws | but I can't see which ones have been applied, and which ones not. | 20:50 |
| uws | (I had this issue this week, and discussed that here, so that's why I know) | 20:50 |
| mathrick | oh, I see now | 20:50 |
| mathrick | so they are true revisions, not just a fancy way to say patch -p0 < patch.diff? | 20:50 |
| uws | so I constantly end up reapplying hand-picked revisions from the ‘other’ branch | 20:50 |
| uws | only to notice that nothing happened :s | 20:50 |
| uws | mathrick: afaik (but not sure) it does just a patch | 20:51 |
| uws | mathrick: but it handles conflicts better. | 20:51 |
| uws | since it takes the base revision into account | 20:51 |
| mathrick | hmm, so are the revisions visible in the history? | 20:51 |
| uws | and if you end up with the same text result it will not bail out. | 20:51 |
| mathrick | if so, how is it possible that bzr missing fails to notice them? | 20:51 |
| uws | mathrick: no. that's what merge _tracking- would be. | 20:51 |
| uws | (which bzr does not) | 20:52 |
| mathrick | uws: no, as in no, they aren't visible in the history? | 20:52 |
| uws | i'm not sure what you mean. | 20:52 |
| uws | let me give an example | 20:52 |
| uws | initial branch has revisions a1 a2 a3 | 20:53 |
| uws | now I branch and create b4 b5 | 20:53 |
| uws | while development on the original branch continues as well: a4 a5 | 20:53 |
| uws | ok so far? | 20:53 |
| mathrick | yeah | 20:53 |
| uws | now, let's say I'm using the second branch | 20:53 |
| uws | so I have a1 a2 a3 b4 b5 | 20:53 |
| uws | But I want the revision "a5" as well | 20:53 |
| uws | but not a4 | 20:54 |
| mathrick | yep | 20:54 |
| uws | then I can 'cd branch2 && bzr merge -c5 ../branch1' | 20:54 |
| uws | that'll work. | 20:54 |
| uws | bzr status will list the changes | 20:54 |
| mathrick | yep | 20:54 |
| uws | so I commit them with "bzr commit -m 'cherry picked fix FOO' | 20:54 |
| uws | now I have a1 a2 a3 b4 b5 b6 | 20:55 |
| mathrick | yep, with b6 == a5 | 20:55 |
| uws | where revision b6 is the same patch as a5 | 20:55 |
| uws | but bzr does not remember those are the same | 20:55 |
| mathrick | mhm, so that's why I thought it'd cause conflicts | 20:55 |
| uws | so if you now do cd branch2; bzr missing ../branch1 | 20:56 |
| uws | it will list a4 and a5 as "missing" in branch2 | 20:56 |
| uws | and it will list "b4 b5 b6" as missing in branch1 | 20:56 |
| uws | mathrick: So that's annoying | 20:56 |
| uws | what happens to me in this case that I try to reapply a5 again | 20:57 |
| uws | because I forgot I already did it | 20:57 |
| uws | ...which will not give any conflicts, but it won't do change either. | 20:57 |
| uws | tracking cherry picks would help here, so that I can see I don't need to try merging a5 again. | 20:58 |
| uws | mathrick: hopefully this answers your question | 20:58 |
| mathrick | yes, except for "why aren't there any conflicts" | 20:59 |
| mathrick | uws: I understood it exactly as you explained it previously, but that led me to thinking it'd cause conflicts | 20:59 |
| mathrick | since it'd try to apply the same changes twice, which usually doesn't work too well | 20:59 |
| james_w | mathrick: it does exactly what you would want it to do | 21:00 |
| mathrick | but why? | 21:00 |
| james_w | if both end up with exactly the same text then it won't conflict | 21:00 |
| james_w | if one of them tweaks it slightly then it will give a conflict for that area | 21:00 |
| james_w | and you do want that, as the cherry pick didn't preserve the identical change, so you want to get a chance to resolve them. | 21:01 |
| pickscrape | Does the bzrlib test suite have any coverage reporting features? | 21:34 |
| meteoroid | hm, now i am having a wierd merge issue, but i wonder if it has more to do with bzr-svn than bzr | 22:02 |
| meteoroid | i created a bzr branch of one svn repo, made some modifications, in hopes of pushing them to a new branch in an entirely different svn repo. i was able to push once, but the latest code is not in svn. | 22:03 |
| meteoroid | now, when i try to push or pull from svn, it says that the branches have diverged. bzr merge says all changes applied successfully | 22:04 |
| meteoroid | oh, i know what changed, i applied svn properties (svn:externals) using an svn checkout | 22:05 |
| meteoroid | but, still, seems i should be able to merge to my bzr repo, then push my bzr changes up | 22:05 |
| jelmer | re | 22:06 |
| jelmer | meteoroid: You need to commit your merges in bzr | 22:06 |
| meteoroid | ah-ho | 22:07 |
| meteoroid | yeouch segfault | 22:07 |
| meteoroid | hm 'bzr push' rememberd the url, but segfaulted. bzr push url worked ok | 22:08 |
| meteoroid | well, whatever, i'm in business :) | 22:10 |
| meteoroid | thanks jelmer! | 22:10 |
| meteoroid | hey jelmer, i was trying to branch ~10k revisions last night, and around 5500 bzr seems to have hung, and i got an email from my web host about excessive swap usage. does bzr-svn depend on the ability to load the entire svn repo into memory the first time around? | 22:19 |
| bob2 | if the machine ou are running it on has old subversion libs, it will leak | 22:20 |
| meteoroid | 1.4.6 old? | 22:21 |
| meteoroid | on ubuntu, patched | 22:21 |
| meteoroid | so .. maybe? heh. | 22:21 |
| meteoroid | do i still need a source compile for subversion 1.5? always seems to drain a whole weekend outta me | 22:21 |
| * meteoroid tries to determine if it is actually faster to branch against local svn using http because apache gets its' own cpu core | 22:22 | |
| meteoroid | was seeing like 66% cpu for apache and 88% for bzr, seeing about 66-88% for bzr only using svn+file:// uri | 22:23 |
| lifeless | I thought the leak was in the python client libs | 22:25 |
| meteoroid | hm | 22:25 |
| lifeless | and that current bzr-svn with its own bindings shouldn't leak | 22:25 |
| meteoroid | maybe i should try to pull like 1000 rev at a time manually? | 22:25 |
| meteoroid | i am at 0.4.9 right now, which is slightly older than the current stable.. | 22:25 |
| meteoroid | hm, i branched a 300M svn repo and the bzr checkout is 1.4G. is this possibly because it contains a workingcopy that i should get rid of? | 22:36 |
| meteoroid | still seems a bit heavy. | 22:36 |
| bob2 | du -s .bzr/repository/obsol* | 22:37 |
| meteoroid | 3.1M | 22:38 |
| meteoroid | i have branches, tags, trunk, and .bzr, branches and tags are around 400M each, .bzr is almost 600M | 22:39 |
| meteoroid | so probably branches, tags, and trunk are workingcopy | 22:39 |
| lifeless | you did svn-import ? | 22:39 |
| meteoroid | no | 22:39 |
| lifeless | oh, thats interesting | 22:39 |
| meteoroid | just bzr branch svn+http://foozle/ | 22:39 |
| meteoroid | should i? | 22:39 |
| bob2 | into a shared repository? | 22:40 |
| lifeless | sounds like bzr-svn failed to determine your branching structure | 22:40 |
| lifeless | you should have gotten a NotBranch error trying to branch the root of the repository | 22:40 |
| meteoroid | well, it's a client's repo and that is very possible. | 22:40 |
| meteoroid | really? | 22:40 |
| lifeless | really | 22:40 |
| meteoroid | well. i didn't. | 22:40 |
| lifeless | because teh root is a container | 22:40 |
| meteoroid | ok | 22:40 |
| meteoroid | so i should use svn-import? | 22:40 |
| lifeless | its rarely the right thing to do to turn it into a brnach | 22:40 |
| lifeless | svn-import will probably do the same thing | 22:41 |
| lifeless | jelmer: are there tools to diagnos the above? | 22:41 |
| meteoroid | whether root of repo or no, is it possible to make a branch without a working copy? i know that some type of pushes or pulls default to this, but don't know if it can be specified. | 22:46 |
| lifeless | if you have a shared repo you can create it with --no-trees | 22:46 |
| lifeless | or you can do bzr remove-tree to remove a working copy | 22:47 |
| meteoroid | right on | 22:50 |
| meteoroid | wealp, it's still about twice the size of the server's master for svn, but at least it's not nine times ;d | 22:51 |
| meteoroid | speaking of shared repo, how do i set that up? | 22:55 |
| lifeless | bzr init-repo --no-trees PATH | 22:58 |
| lifeless | oh for bzr-svn | 22:59 |
| lifeless | you want init-repo --no-trees --rich-root-pack PATH | 22:59 |
| meteoroid | should i use different shared repo for svn and for general bzr work? | 23:00 |
| lifeless | at this point yes | 23:01 |
| meteoroid | ok | 23:01 |
| meteoroid | what's no-trees ? | 23:01 |
| lifeless | we are working on unifying things | 23:01 |
| meteoroid | i'll read the docs ;d | 23:01 |
| lifeless | it means that branches made by 'branch' will not get working copies by default | 23:01 |
| lifeless | you can make a copy with bzr checkout . in a branch | 23:01 |
| meteoroid | ah ok | 23:02 |
| meteoroid | and rich-root-pack ? | 23:03 |
| lifeless | thats the format bzr-svn uses | 23:04 |
| meteoroid | ah ok | 23:05 |
| meteoroid | so, if i create a new shared repo, and i have existing bzr branches of svn repo, can i branch into the shared repo without pulling from svn again? | 23:06 |
| bob2 | yes | 23:06 |
| meteoroid | just bzr branch from the existing copies into the new repo? | 23:06 |
| bob2 | existing branches, yes | 23:07 |
| * meteoroid grows increasingly impressed every day | 23:08 | |
| meteoroid | nice, thanks guys, i've saved a few hundred meg and if i need more than one bzr branch of any of these, it should be fine. | 23:10 |
| meteoroid | any quick way to reparent them to their svn urls easily? | 23:10 |
| lifeless | bzr pull --remember | 23:11 |
| meteoroid | sure, that's what i figured | 23:11 |
| lifeless | you could script it with a little python if you have more than a few to update | 23:11 |
| meteoroid | now, for a non-svn-related shared repo, if i want my repos accessible via http, i should have a working copy? | 23:11 |
| lifeless | newbranch.set_parnet_branch(oldbranch.get_parent_branch()) | 23:12 |
| lifeless | you don't need a working copy for bzr to access things over http | 23:12 |
| meteoroid | ok | 23:12 |
| * meteoroid still hasn't figured out http write yet | 23:12 | |
| lifeless | you might want one if you can't run loggerhead for people to be able to browse the source code in their browser | 23:12 |
| meteoroid | yah | 23:12 |
| meteoroid | how's trac compare to loggerhead? | 23:12 |
| lifeless | if you do you may want to look into bzr-push-and-update | 23:13 |
| lifeless | totally different things | 23:13 |
| meteoroid | well, trac has a browser | 23:13 |
| lifeless | loggerhead is a history viewer; trac is a wiki/bugtracker/coffee-maker | 23:13 |
| meteoroid | well, primarily it's a history browser with integrated bug tracker, designed to require and/or facilitate referencing issues on commit, and revisions in issues. | 23:14 |
| meteoroid | i'll just .. see .. for myself .. how they are different in the history browsing department. :) | 23:14 |
| lifeless | tis is loggerhead | 23:14 |
| lifeless | http://bzr-playground.gnome.org/cheese/trunk/ | 23:15 |
| meteoroid | does it run in mod_wsgi or mod_py? | 23:16 |
| meteoroid | atom feed is a nice touch :) | 23:17 |
| meteoroid | if it runs in wsgi, actually, i could possibly run it in zope alongside our plone-based issue tracker... | 23:17 |
| jelmer | lifeless, meteoroid: If you use bzr branch on the repository root it will consider that root a branch | 23:25 |
| jelmer | lifeless, even if the repository contains a trunk/branches/tags structure | 23:26 |
| jelmer | lifeless, meteoroid: bzr svn-import will do the right thing | 23:26 |
| meteoroid | ok | 23:26 |
| jelmer | and "bzr branch" on the repository root in bzr-svn 0.4.11 will warn you that you probably want svn-import | 23:26 |
| Necoro | I'm trying to push a branch to my usb-stick (having fat32 as a filesystem) | 23:27 |
| Necoro | but I always get: /usr/lib/python2.5/site-packages/bzrlib/atomicfile.py:125: UserWarning: AtomicFile(u'/mnt/usb/thesis/.bzr/README') leaked | 23:27 |
| Necoro | googling showed no real results | 23:27 |
| Necoro | so ... what's going wrong? =) | 23:27 |
| Necoro | I'm using bzr1.5 | 23:28 |
| Necoro | (and running Gentoo Linux) | 23:28 |
| meteoroid | hm | 23:28 |
| meteoroid | now it says "ERROR: not a branch: "[svn url]"" | 23:28 |
| meteoroid | jelmer? | 23:29 |
| jelmer | meteoroid, when does it do that? | 23:29 |
| meteoroid | bzr svn-import svn+https://dev.pushtotest.com/svn/tm5 tm5 | 23:29 |
| meteoroid | oh, um, hm, maybe it just doesn't like my https.. http is at least paused | 23:30 |
| jelmer | tm5 is probably not the repository root | 23:30 |
| meteoroid | it is, i run the svn server. :) | 23:30 |
| meteoroid | i think https fails because it has a placeholder ssl cert | 23:31 |
| jelmer | meteoroid: ah, that would make sense | 23:31 |
| meteoroid | need to fix that with client's cacert but he's on vacation and not sweating it himself ;d | 23:31 |
| jelmer | meteoroid, please try running 'svn ls" against that https url | 23:31 |
| meteoroid | ah ok just accept the cert in svn, duh | 23:32 |
| * meteoroid has never had so much fun spending all day with SCM before ;d | 23:35 | |
| Necoro | hmm ... the real error seems to be: bzr: ERROR: Transport error: [Errno 1] Operation not permitted: '/mnt/usb/t/.bzr/README.31770.Zakarumiy.tmp' | 23:35 |
| Necoro | but it doesn't show _what_ operation fails | 23:36 |
| Necoro | only THAT it fails :/ | 23:36 |
| meteoroid | jelmer: the size of the bzr repo, sans tree, is still ~600M, same as before, and about twice the size of the fsfs svn repo on the server. | 23:38 |
| LarstiQ | Necoro: there should be a traceback | 23:38 |
| LarstiQ | Necoro: if not on the console, then in ~/.bzr.log. Or you could supply -Derror | 23:38 |
| jelmer | meteoroid: with svn-import ? | 23:39 |
| meteoroid | yep | 23:39 |
| jelmer | meteoroid, Did it recognize the branch structure correctly? I.e. did it create trunk/, branches/foo directories? | 23:40 |
| meteoroid | there is basically an import of ~300, maybe 400M of stuff, and a single tag, trunk is currently empty. | 23:40 |
| meteoroid | well, i imported with -no-tree (that makes it like 1.4G) | 23:40 |
| meteoroid | er, the tree makes it like 1.4G total, not no-tree | 23:40 |
| jelmer | ? svn-import doesn't have a --no-trees option | 23:40 |
| Necoro | LarstiQ: http://rafb.net/p/BCAK0b42.html | 23:41 |
| meteoroid | sorry, i was following someone's advice earlier to have a shared repo and did init-repo with --no-trees | 23:41 |
| jelmer | meteoroid: ah, ok | 23:41 |
| meteoroid | so, how do i check if there is trunk, branches, etc.. ? | 23:41 |
| jelmer | meteoroid, svn-import will create that shared repo for you as well | 23:41 |
| meteoroid | ah ok | 23:42 |
| jelmer | meteoroid, The repo that was created, does it contain a trunk directory and a branches directory similar to your svn repo? | 23:42 |
| meteoroid | well, there's nothing but .bzr | 23:42 |
| meteoroid | i can checkout . RQ | 23:42 |
| jelmer | meteoroid, also, (just checking) the repository you imported into was empty before you ran svn-import? | 23:42 |
| meteoroid | yep | 23:42 |
| meteoroid | brand new fresh | 23:43 |
| jelmer | meteoroid, Ah, so it must not be recognizing the branching scheme correctly | 23:43 |
| meteoroid | okey doke | 23:43 |
| jelmer | meteoroid, It's using a standard scheme, e.g. the repo has a "trunk" directory and other directories under "branches" derived from that? | 23:43 |
| LarstiQ | Necoro: that is probably the chmod failing I guess. | 23:43 |
| LarstiQ | Necoro: might want to lookup what errno 1 is in that case. | 23:43 |
| Necoro | oh - ok | 23:43 |
| meteoroid | well, pretty close.. it was recently imported by the client and trunk is empty. it probably shouldn't exist at all. | 23:43 |
| meteoroid | but we do have tags/ and branches | 23:44 |
| LarstiQ | Necoro: but knowing fat32 where it errors if you try to chmod, that would be my guess. | 23:44 |
| Necoro | LarstiQ: where is this defined? - is it the global errno? | 23:44 |
| jelmer | meteoroid, You probably want to use --scheme=trunk0 as option to svn-import | 23:44 |
| meteoroid | tags/tm52CVS, branches/tm52b6, branches/ being worked on | 23:44 |
| meteoroid | right on | 23:44 |
| meteoroid | i'll give it a shot | 23:44 |
| LarstiQ | Necoro: it's just the system errno | 23:44 |
| meteoroid | should it have to contact svn each time, or should my user's cache speed this up? | 23:45 |
| LarstiQ | Necoro: this is reproducible for you, yes? | 23:45 |
| meteoroid | hm, nope, looks like apache2 is pegged again :) | 23:46 |
| meteoroid | at least slicehost lets me spike past 1cpu on this shared box when resources are available | 23:47 |
| Necoro | LarstiQ: yes - at least now | 23:47 |
| Necoro | I know I've done "bzr push" onto this usb stick already | 23:47 |
| Necoro | (though not today) | 23:47 |
| LarstiQ | Necoro: so 1 is indeed EPERM. Could you try running this with BZR_PDB=1? | 23:47 |
| jelmer | meteoroid, the cache should help | 23:48 |
| Necoro | ok - now I'm inside pdb ^^ | 23:48 |
| meteoroid | jelmer: coolio | 23:49 |
| LarstiQ | Necoro: 'up' and 'print e' | 23:49 |
| meteoroid | maybe i should dig into a branch of bzr-svn and see if i can get it to use a configurable svn cache. | 23:49 |
| meteoroid | can't be too complex, just maybe need some tests and testing. :) | 23:49 |
| Necoro | LarstiQ: [Errno 1] Operation not permitted: '/mnt/usb/t/.bzr/README.32365.Zakarumiy.tmp' ... so nothing new | 23:50 |
| meteoroid | jelmer: rawk! 297M for the tm5 checkout, and it does have tags/ and trunk/ in it | 23:50 |
| Necoro | LarstiQ: OSError(1, 'Operation not permitted') | 23:50 |
| meteoroid | now i can be like, "hey frank, yanno how we barely moved you to svn? well, EFF svn! you should use bzr!" :-P | 23:50 |
| jelmer | meteoroid, patches are welcome :-) | 23:50 |
| LarstiQ | Necoro: my thinking is a bit slow at this time, sorry | 23:51 |
| meteoroid | the past couple of days have been really educational, i'm starting to understand bzr a bit more and feel like i might be more comfy trying to contribute | 23:51 |
| Necoro | LarstiQ: no problem ;P - we're in the same timezone ;) | 23:51 |
| LarstiQ | Necoro: how good is your pdb/python foo? What I'd basically want to do is confirm that it is the chmod that is failing. | 23:51 |
| LarstiQ | Necoro: are we? I'm not ircing from my timezone ;) | 23:52 |
| Necoro | LarstiQ: my python fu should be quite to very good ... but I've never used pdb before =) | 23:52 |
| Necoro | oh ok - it says netherlands for you ^^ | 23:53 |
| LarstiQ | Necoro: pdb needs too much thinking from me right now, so just alter bzrlib/atomicfile.py to debug printf style | 23:53 |
| LarstiQ | Necoro: ah, but I'm in Finland this summer :) | 23:53 |
| Necoro | hmm ... finland is even one hour later, iirc ... omg ;) | 23:53 |
| meteoroid | LarstiQ: just put "import pdb" and "pdb.set_trace()" lines at any given point, and you can read the values of things at that point | 23:54 |
| meteoroid | also 'up' and 'down' let you check out stuff nearby | 23:54 |
| meteoroid | eg next line up | 23:54 |
| LarstiQ | meteoroid: yes, I am aware of that :P | 23:54 |
| lifeless | Necoro: can you file a bug too ;> | 23:54 |
| meteoroid | pah it's so much easier than printf but whatev heh | 23:54 |
| meteoroid | whatever makes ya happy | 23:54 |
| LarstiQ | meteoroid: pdb is nice, but it could be better | 23:55 |
| meteoroid | yah but it's not printf ;d | 23:55 |
| LarstiQ | meteoroid: right. But I don't think we need more than printf right now, if I'm wrong and the problem isn't there, then pdb would be indeed less painful. | 23:56 |
| meteoroid | sure, like i says, whatever makes ya happy | 23:57 |
| Necoro | LarstiQ: ok - chmodding is the problem | 23:57 |
| meteoroid | :-P | 23:57 |
| LarstiQ | meteoroid: maybe you know the anwser to something I've been wondering for a while. I'd like to import pdb; pdb.set_trace() with an ipy style shell, not the default pdb one. | 23:57 |
| LarstiQ | ipython that is | 23:58 |
| Necoro | LarstiQ: http://rafb.net/p/rkLbL327.html | 23:58 |
| Necoro | lifeless: ok - tomorrow ;) | 23:58 |
| meteoroid | hm, i don't know off hand but have been meaning to learn more about ipy just for working with other folks | 23:58 |
| lifeless | Necoro: thanks | 23:58 |
| LarstiQ | Necoro: thanks | 23:59 |
| * LarstiQ heads to bed | 23:59 | |
| Necoro | and I already used a repo w/o trees - so there are no filename issues ... | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!