| ToyKeeper | Heh, I wouldn't exactly say it hurts, but it can definitely confuse people who don't expect it. | 00:03 |
|---|---|---|
| fullermd | NOBODY expects the rich root transition! | 00:05 |
| mathepic | I know rich-root adds some info thats not in the others, but what specifically is that? | 00:05 |
| spiv | The root of the tree gets a unique file-id and version like any other directory. This means operations like "bzr mv . subdir" can be tracked accurately, and is also useful for merging a branch into a subdir of an unrelated branch, as well as just generally making our data model a little more consistent. | 00:08 |
| spiv | (IIRC some (all?) non-rich-root formats did allow the file-id to be stored, but they didn't support tracking a version; it was just implicitly considered to be last modified by the current revision) | 00:09 |
| === davidstrauss_ is now known as davidstrauss | ||
| igc | morning | 01:01 |
| === davidstrauss_ is now known as davidstrauss | ||
| === davidstrauss_ is now known as davidstrauss | ||
| * igc lunch | 03:12 | |
| davidstrauss | Where can I find the docs on X.Y.Z revision numbers? | 03:34 |
| Peng_ | I know the current scheme was explained in detail on the list back when it was designed . . . . | 03:36 |
| === timchen119 is now known as nasloc__ | ||
| RenatoSilva | Is there a way to make 'bzr ignore' use the conf in ~, not the branch? | 04:35 |
| === AnMaster_ is now known as AnMaster | ||
| bialix | hello all | 07:02 |
| mneptok | ssssshhhhhhh! the maestro is decomposing. | 07:05 |
| bialix | ? | 07:06 |
| mneptok | looking for meaning in anything i say is like looking for the hot dog vendor at a bar mitzvah. | 07:12 |
| igc | hi bialix, mneptok | 07:17 |
| bialix | hi igc | 07:17 |
| bialix | igc: do you need windows installer for bzr-explorer? | 07:17 |
| igc | bialix: if you get a chance, yes please | 07:17 |
| mneptok | igc: good morning! | 07:18 |
| bialix | mneptok: what is mitzvah? | 07:18 |
| bialix | mneptok: ok, I found | 07:19 |
| bialix | hot dogs are not cosher food? | 07:19 |
| mneptok | no. anything from a pig is not kosher. | 07:20 |
| bialix | never think that sausage made from pig | 07:22 |
| vila | hi all | 07:29 |
| bialix | bonjour vila | 07:31 |
| vila | hi bialix | 07:31 |
| * vila restore babune after yesterday crash, may be on and off for a couple of hours | 07:39 | |
| bialix | igc: after translations update it makes sense to run `python setup.py build_mo` to refresh auto-generated english translation | 07:43 |
| igc | bialix: oh - ok | 07:43 |
| bialix | installer has uploaded | 07:44 |
| igc | bialix: thanks | 07:44 |
| bialix | my pleasure | 07:44 |
| igc | bialix: wrt http://doc.bazaar-vcs.org/explorer/en/processes/making-a-release.html ... | 07:44 |
| spiv | vila: when are you going to finish and land lp:~vila/bzr/405745-http-hangs btw? It's been lingering in the queue for a while. | 07:45 |
| igc | is step 2 needed there? or only after downloading the translations? | 07:45 |
| igc | bialix: I tried python setup import_po btw and it fell over IIRC | 07:46 |
| vila | spiv: I should mark it in progress because it hangs under some circumstances, | 07:46 |
| igc | see http://doc.bazaar-vcs.org/explorer/en/processes/updating-translations.html | 07:46 |
| igc | hi vila! | 07:46 |
| bialix | igc: step 2. Build binary translations files (bialix to confirm) -- required for installer | 07:46 |
| bialix | step 3 has error: should be iscc extras/explorer.iss | 07:46 |
| vila | spiv: that was an important motivation to work on bug #392127 but, | 07:47 |
| ubottu | Launchpad bug 392127 in bzr "bzr >= 1.16 on gentoo: can't start new thread" [High,In progress] https://launchpad.net/bugs/392127 | 07:47 |
| vila | spiv: while I reached a point where hardy. jaunty and karmic weren't failing nor hanging in any way, | 07:47 |
| bialix | igc: fellover? | 07:47 |
| bialix | igc: fell over? | 07:47 |
| igc | bialix: yes | 07:47 |
| bialix | how? | 07:48 |
| vila | spiv: I'm now experiencing hangs again on Freebsd and OSX :-/ | 07:48 |
| bialix | traceback? | 07:48 |
| spiv | vila: Ah :( | 07:48 |
| bialix | igc: traceback? | 07:49 |
| igc | bialix: yes. | 07:49 |
| bialix | igc: can I see it? | 07:49 |
| igc | it was late so I didn't collect it :-( | 07:49 |
| * igc tries again | 07:49 | |
| bialix | you can run it again | 07:49 |
| * vila needs to reboot, bbl | 07:50 | |
| igc | bialix: http://pastebin.com/d8883196 | 07:51 |
| bialix | interesting | 07:51 |
| bialix | tarball support is broken for you? | 07:51 |
| bialix | igc: what is your python version? | 07:52 |
| * bialix suspects bad thing | 07:52 | |
| igc | bialix: 2.6.4rc1 | 07:53 |
| bialix | python devs killed Kenny? | 07:53 |
| spiv | lifeless: Mind if I "bzr upgrade --2a lp:bzr-pqm" ? | 07:53 |
| bialix | igc: oh, I see, explorer -> po/explorer <-- there is no file extension, should be explorer.pot -> po/explorer.pot | 07:55 |
| bialix | igc: can you send me export tarball? | 07:55 |
| igc | bialix: sure | 07:55 |
| bialix | it seems lp devs killed Kenny and changed the format of export tarball again | 07:55 |
| spiv | lifeless: (I have a slightly rough patch to allow me to pqm-submit branches I don't have locally, but my local copy of the bzr-pqm branch has already been upgraded to 2a) | 07:56 |
| lifeless | spiv: doit | 07:57 |
| spiv | lifeless: ta | 07:57 |
| * spiv blows away the old backup.bzr | 07:58 | |
| bialix | igc: http://pastebin.com/d36e98da0 | 07:59 |
| * bialix starts to hate python 2.6 | 08:00 | |
| bialix | igc: I dunno why it does not work for you | 08:00 |
| bialix | igc: maybe recent regression in 2.6.4rc1? | 08:00 |
| igc | bialix: ok - thanks for looking | 08:00 |
| igc | bialix: while I have your attention ... | 08:01 |
| igc | that qexport patch? | 08:01 |
| igc | what's required to tweak it to make you happy? | 08:01 |
| bialix | igc: ha! | 08:01 |
| bialix | igc: I've got the same error with pythopn 2.6 on my machine | 08:01 |
| bialix | Python 2.6.2 | 08:02 |
| igc | bialix: I'm planning to fix some qbzr bugs over coming nights | 08:02 |
| bialix | igc: qexport? | 08:02 |
| igc | bialix: is there a rough date for the 0.15 release? | 08:02 |
| bialix | igc: that old discussion how to better | 08:02 |
| bialix | igc: when it will be ready | 08:03 |
| bialix | igc: I'm too busy at work until the end of the month | 08:03 |
| igc | bialix: end of month is good for me fwiw | 08:03 |
| bialix | igc: about qexport: I'm not quite agree with your latest changes | 08:04 |
| bialix | you saw my comments though | 08:04 |
| igc | bialix: I did. There were lots of comments though - I'll take another look soon | 08:04 |
| bialix | from other hand I don't have enough time to polish it right now, so I can close my eyes if you merge anything you think is appropriate for you or bzr-explorer | 08:05 |
| igc | bialix: ok. I'll land the bits we agree on | 08:05 |
| bialix | igc: my main concern is change of controls order | 08:05 |
| bialix | igc: I don;t agree that archive format should be first item | 08:06 |
| igc | bialix: fair enough | 08:06 |
| igc | bialix: my bigger issue was defaulting to zip on Windows ... | 08:06 |
| bialix | ping me or send mail to qbzr ml if needed so we can reach some consensus | 08:07 |
| igc | and sohlud tar.gz instead of tgz, etc. | 08:07 |
| igc | showing | 08:07 |
| igc | sure | 08:07 |
| bialix | what's problem with zip default on Windows? | 08:07 |
| igc | no problem - it defaults to tgz now | 08:07 |
| igc | zip is better known to windows users | 08:08 |
| bialix | in some unmerged-yet-patch it was changed | 08:08 |
| igc | yep - this one :-) | 08:08 |
| fullermd | igc: ping | 08:51 |
| igc | hi fullermd | 08:51 |
| fullermd | Howdy. You wanna chat about revspecs? | 08:51 |
| igc | sure | 08:51 |
| fullermd | So, re your (2) (where revid falls in the list), one of my criteria in order choice was a WAG of relative expenses. | 08:52 |
| igc | wag? | 08:53 |
| fullermd | I figured checking if a name exists as a tag is fairly fast, since it's a list in one place that's probably pretty short. Checking the history for a revid would take longer 'cuz there's more to look at. | 08:53 |
| fullermd | Wild Ass Guess. | 08:53 |
| fullermd | And date would take longer than revid, 'cuz you have to peek inside the revs. | 08:53 |
| spiv | fullermd: all of a sudden I'm imagining Aretha Franklin singing "R-E-V-S-P-E-C, find out what it means to me..." | 08:54 |
| igc | :-) | 08:54 |
| fullermd | That was weighed against my feeling for how often we'd enter certain things. I'd want to paste in tags all the time, and revids probably next. | 08:54 |
| fullermd | (though it's kinda a tossup how often I'd put in dates vs revids maybe, but given the expenses...) | 08:55 |
| fullermd | And branch:... well, I sorta threw that in 'cuz I could :p | 08:55 |
| al-maisan | hello there, I have a question re. ignored files: they continue to appear in "bzr diff" output .. is there a way to *not* have ignored files in "bzr diff" output? | 08:55 |
| spiv | Although thinking about it, "You wanna chat about revspecs" sounds more like "Let's talk about revspecs baby, let's talk about you and me..." | 08:55 |
| spiv | al-maisan: only versioned files appear in "bzr diff" output | 08:55 |
| al-maisan | ignored files are versioned files | 08:56 |
| igc | spiv: it's clearly late there :-) | 08:56 |
| igc | fullermd: hmm | 08:56 |
| al-maisan | spiv: so there's no way to exclude them from "bzr diff" output | 08:56 |
| fullermd | al-maisan: The main thing 'ignore' directly affects is whether 'bzr add' will add it; it doesn't have any affect on files that are already versioned. | 08:56 |
| al-maisan | fullermd: I see, thanks. | 08:57 |
| spiv | al-maisan: the ignore rules don't control which files which files are versioned, they control which files are automatically added by 'bzr add', and which unversioned files 'bzr st' will complain about, etc. | 08:57 |
| spiv | You can always explicitly add a file that matches an ignore rule. | 08:57 |
| al-maisan | OK .. understood. | 08:57 |
| igc | fullermd: one simple answer is to take revid out of the dwim list altogether | 08:57 |
| spiv | al-maisan: you might find the filterdiff command helpful | 08:58 |
| igc | fullermd: we can always add it in later | 08:58 |
| fullermd | I don't overly like that. It and tags are the two things that first occured to me I'd want to DWIM. What's the motivator? | 08:58 |
| al-maisan | spiv: thanks for the hint .. will take a look. | 08:58 |
| spiv | al-maisan: it's part of the 'patchutils' package on ubuntu | 08:58 |
| igc | fullermd: and the trade-off of speed vs convenience worries me, cause revids aren't convenient regardless | 08:59 |
| igc | fullermd: in bzr, revids can worry in form based on where they came from | 08:59 |
| igc | vary | 08:59 |
| igc | e.g. a svn import has svn:... | 09:00 |
| Peng_ | For me, DWIM revids are most useful. | 09:00 |
| igc | which *looks* like a revspec | 09:00 |
| fullermd | Well, but is "-rsvn:asdf" more eyetwisting than "-rrevid:svn:asdf"? | 09:01 |
| fullermd | You're probably unlikely to type a meaningful revid without meaning to, thinking you're typing a revno or tag or something. | 09:01 |
| igc | the problem is that svn:xxx is a real revspec for xxx in the svn repo | 09:01 |
| spiv | Looking to see if a single revid is present or absent in a repo should be pretty quick... what's the concern about speed? | 09:01 |
| igc | so, iiuic, a dwim revspec for foreign branches will break? | 09:02 |
| spiv | igc: I think the svn revids are svn-v4:...? | 09:02 |
| fullermd | Oh. Well, in that case, that would never get to the DWIM (since it checks for a registered revspec first) | 09:02 |
| fullermd | So you'd have to use the full revid:blah form. | 09:03 |
| spiv | andrew@steerpike:~/code/twisted/trunk$ bzr revision-info | 09:03 |
| spiv | 15278 svn-v4:bbbe8e31-12d6-0310-92fd-ac37d47ddeeb:trunk:27226 | 09:03 |
| spiv | (or svn-v3 for earlier versions of bzr-svn, and anything before that is simply ancient...) | 09:03 |
| igc | spiv: I wonder whether git and hg also have the same form - probably | 09:03 |
| fullermd | Well, 'ancient' is no counter-argument; it's a VCS, ancient craps stays around forever ;) | 09:04 |
| spiv | So for the specific case of revisions converted by bzr-svn its shouldn't be an issue. | 09:04 |
| spiv | And I think it's probably good practice for foreign revid mappings to be versioned like that. | 09:04 |
| fullermd | So, that case seems like "not all revids can just be DWIM'd, 'cuz they'll be grabbed earlier". I don't think that's a deal-breaker, it just means you can't always use the short form. | 09:04 |
| spiv | fullermd: "bzr foreign-mapping-upgrade" :P | 09:04 |
| spiv | igc: I'd guess the bzr-git and bzr-hg plugins do, but I don't know for sure. | 09:05 |
| igc | spiv: right, but there's no certainly re what form a revid will take | 09:05 |
| igc | it can be almost anything | 09:05 |
| spiv | Yeah, you're right that a revid could look like a revspec. | 09:06 |
| fullermd | Yah. But "Most Of The Time"(tm), they probably won't start with "valid-revspec:", so would DWIM OK. And when it does, you'd just have to disambiguate. | 09:06 |
| spiv | But weird revids are definitely not the norm. | 09:06 |
| igc | spiv: the issue we're discusisng btw is dwim ordering ... | 09:07 |
| igc | fullermd is proposing ... | 09:07 |
| Peng_ | Oh man, I forgot about "foreign-mapping-upgrade" when bzr-git's revids changed, and wound up pulling everything again. Shoot! | 09:07 |
| igc | revno, tag, revid, date, branch iirc | 09:07 |
| spiv | Peng_: but it's such a memorable command name! ;) | 09:07 |
| igc | spiv: I suggested moving revid to last | 09:07 |
| fullermd | So the big trap would be when it starts with valid-revspec:, AND the remainder under that revspec actually translates to a revision. I don't think that's likely enough that it would cause problems in practice. | 09:07 |
| igc | or putting it immediately after revno | 09:07 |
| igc | fullermd: I agree it's most unlikely | 09:08 |
| Peng_ | Would the DWIM stuff actually break reverring to revspec:whatever explicitly if "whatever" looks like a revno/tag/etc.? | 09:08 |
| Peng_ | referring*! | 09:08 |
| fullermd | No, once it catches revspec: it passes to that class to handle it. DWIM only triggers when you fall off the end of from_string() | 09:09 |
| fullermd | (the place where it used to assume it was a revno if it were numeric, else die) | 09:09 |
| spiv | igc: hmm. It's too late in the day here for me to form a sound opinion on that, I think :) | 09:09 |
| Peng_ | fullermd: OK, good. | 09:09 |
| fullermd | igc: So, one reason (perf to one side) I like it after tag is because the user controls tags; revids, generally not. | 09:10 |
| Peng_ | I've always liked that bzr's revspecs are unambiguous, so you can have tags like "123" or "2009-10-14" or whatever you want. :) | 09:10 |
| spiv | igc: I do think that in practice there will never be ambiguity between a tag, a date, a branch name, and a revid. | 09:10 |
| fullermd | So if there IS a tag that mirrors a revid (unlikely though that may be), it's because the user meant it to, so we should probably prefer that. | 09:10 |
| spiv | Er, I mean: | 09:10 |
| igc | fullermd: right. | 09:10 |
| fullermd | (and in general, if a tag mirrors a valid date/branch/etc, we should prefer it) | 09:10 |
| spiv | never be ambiguity between a revid and any one of of those others. | 09:11 |
| spiv | (i.e. revid vs. date, revid vs tag, etc. I can imagine tag vs. branch or date clashing) | 09:11 |
| fullermd | I don't have any religious objection to changing the order; it just feels right to me as-is. | 09:12 |
| igc | fullermd: i like your order ... | 09:12 |
| igc | I'm just not sure where revid best fits within it :-) | 09:12 |
| igc | the others are good | 09:13 |
| spiv | If we're uncertain, let's try fullermd's ordering and see how it feels? I don't really see where revid is placed mattering very much, because it's so unlikely to conflict. | 09:13 |
| fullermd | Well, until we get branch-by-name rather than branch-by-location, specifying branches is going to be pretty rare. So having that last fits. | 09:14 |
| igc | if a user cut-and-paste a revid, they really would expect it | 09:14 |
| fullermd | I mostly added it because I looked at the list of revspecs, and it said to me "Hey, I s'pose people might use me, sometimes..." | 09:14 |
| igc | fullermd: so let's go with your order given no-one feels strongly | 09:14 |
| fullermd | (also rare because I can never mentally figure out whether/how a branch: spec is going to WORK...) | 09:15 |
| spiv | And because revids are so unlikely to conflict, I think that a) we don't need to worry about it now, and b) if we change where revid is in that order later, no-one will be disturbed. | 09:15 |
| igc | I just wasn't sure and though we ought to open it up for debate | 09:15 |
| * fullermd nods. | 09:15 | |
| fullermd | 'k, so that leaves your (1) (quick-fail if it looks like a revno but wasn't). | 09:15 |
| fullermd | About the only thing that's likely to trigger on if it gets past there is probably tag. Though I guess you could have a branch at a path like ./5. | 09:16 |
| igc | tag is the only clash in my mind | 09:16 |
| spiv | fullermd: well, there's another possibility... | 09:17 |
| fullermd | So if you expected a revno and one wasn't there (and you don't have a tag named that), it means bzr eats more time before handing you the error. | 09:17 |
| spiv | fullermd: try them *all*, and if multiple dwim candidates match refuse to guess. | 09:17 |
| spiv | fullermd: (and so force the user to disambiguate with an explicit revspec) | 09:17 |
| igc | that gets expensive | 09:17 |
| fullermd | Yeah. I'd guess thatn 95% (or 99%) of the time, you're entering a revno. | 09:18 |
| fullermd | So going through the expense of loading the whole history tree and checking the timestamp of each rev would be Bad(tm). | 09:18 |
| fullermd | After all the work to AVOID doing all that extra work on simple stuff, I'd get lynched for suggesting that ;) | 09:18 |
| spiv | Incidentally, this discussion suggests to me that perhaps we should disallow tags that look like a natural number... | 09:19 |
| igc | spiv: we can't I feel - roundtripping | 09:19 |
| spiv | i.e. any matching '[1-9][0-9]*'. But probably few users would do that, and won't be too surprised by the results if they do. | 09:19 |
| spiv | igc: *nod* | 09:20 |
| igc | spiv: I just think if something looks like a revno, we should assume it is | 09:20 |
| spiv | Yeah. | 09:20 |
| igc | not try tags | 09:20 |
| spiv | Even if there is no revno 99999, but there is a tag 99999? | 09:21 |
| spiv | I think that's probably reasonable. | 09:21 |
| igc | and we can encourage projects to use tag names that aren't revno like | 09:21 |
| igc | and they get nicer dwim revspecs for their trouble :-) | 09:22 |
| spiv | Right. | 09:22 |
| spiv | Ok, I'm off. | 09:22 |
| spiv | Happy UI designing :) | 09:22 |
| fullermd | Is the motivation "If user entered a numeric, they'd be unpleasantly surprised if it hit something that wasn't a revno", or "Get the error back to the user faster without loading all the history"? | 09:22 |
| igc | more the former | 09:23 |
| fullermd | OK. | 09:24 |
| igc | it's not a strong feeling though - more a preference | 09:24 |
| fullermd | So I have a mild preference to keep going, on the theory "if it hits something else, it's because the user probably meant to". | 09:25 |
| igc | fair enough | 09:25 |
| fullermd | It's not a particularly strong conviction, but more than an offhand whim. | 09:25 |
| fullermd | We can let democracy take its course on that I guess. | 09:26 |
| bialix | igc: http://kashfarooq.wordpress.com/2009/10/12/integrate-bazaar-source-control-with-your-preferred-merge-application/ | 09:26 |
| igc | fullermd: so I think it's worth emailing the list just to see if others feel strongly either way | 09:26 |
| bialix | igc: this man wrote series of articles already | 09:26 |
| fullermd | (when two people disagree enough to not just abandon their positions, but not enough to fight for them, you don't even get good flamewars ;) | 09:26 |
| igc | fullermd: otherwise, I'm happy to change my vote to approve | 09:26 |
| fullermd | 'k. I'll drag it onto the list later. Thanks 8-} | 09:28 |
| igc | bialix: interesting. I want to make qconfig easier to configure merge tools. I'll look at that soon. | 09:32 |
| * igc dinner | 09:32 | |
| bialix | yeah, this old nasty problem with merge tools :-/ | 09:33 |
| bialix | igc: re import_po error: in python2.6 getnames() method of opened tarball archive now returns names of directories as well as plain files. in 2.5 there was no directories in list. and nothing mentioned about this fact in 2.6 documentation. nice, huh? | 09:44 |
| bialix | igc: no, I'm wrong! even funny. Now directory name has no trailing slash in 2.6. | 09:48 |
| bialix | anybody knows what's difference between REGTYPE and AREGTYPE (re tarball items)? | 09:50 |
| fullermd | A glance at google says AREGTYPE is for historic compatibility. | 09:55 |
| bialix | hm... ok | 09:55 |
| fullermd | (so the same thing, just don't use AREG for new stuff) | 09:56 |
| jelmer | igc: hi | 09:57 |
| jelmer | igc: I managed to convert svn-fast-export to subvertpy-fast-export | 09:57 |
| jelmer | igc: as far as I can tell it's not leaking any file escriptors (highest fd is around 10 or 11 usually) | 09:58 |
| jelmer | igc: I'm on GPRS at the moment so uploading is a bit expensive, I'll push later today | 09:59 |
| spiv | jelmer: hooray! | 09:59 |
| bialix | jelmer: cool | 09:59 |
| bialix | igc: problem with import_po has fixed | 09:59 |
| jml | what _exactly_ does 'bzr ls' print by default? | 10:01 |
| spiv | jml: bzr: ERROR: Not a branch: "/home/andrew/". | 10:03 |
| spiv | ;) | 10:03 |
| spiv | As for the question you meant to ask, I don't know :) | 10:03 |
| jml | spiv, wow, now I feel confused, belittled and still unhelped :P | 10:05 |
| spiv | A new personal best! | 10:05 |
| jelmer | :-) | 10:05 |
| LarstiQ | jml: unrecursive argument listing iirc | 10:06 |
| jml | LarstiQ, it also seems to list the contents of the tree. afaict, it behaves like regular 'ls' unless told otherwise. | 10:07 |
| LarstiQ | jml: yes | 10:07 |
| jml | LarstiQ, ok, thanks. | 10:07 |
| igc | jelmer: my hero! thank-you! | 10:56 |
| igc | bialix: thanks - I'll try it | 10:56 |
| fullermd | jelmer: BTW, re adding a registry for DWIM specs: It's not entirely trivial, since there are differing lists of exceptions to catch. | 11:28 |
| igc | night | 12:18 |
| bialix | anybody knows the nick of jszakmeister | 13:02 |
| bialix | ? | 13:02 |
| bialix | what it means "super client" as in jszakmeister’s article: http://www.szakmeister.net/blog/2009/oct/12/bazaar-subversion-super-client/ | 13:03 |
| spiv | bialix: https://launchpad.net/~jszakmeister says it is jszakmeister | 13:03 |
| spiv | I don't know if that's accurate or not. | 13:04 |
| bialix | ok, thanks spiv. because it's not here right now can you shed some light on english words? | 13:04 |
| spiv | I've only just glanced at that link, but I think there "super" is in the sense of "better" or "has a superset of features" compared to SVN's native client. | 13:06 |
| bialix | ok, thanks | 13:07 |
| spiv | No worries. | 13:08 |
| bialix | ok, I won't :-) | 13:08 |
| ploum | Hello | 13:15 |
| ploum | More than a year ago, I've set a shared repository to host our project with loggerhead interface | 13:15 |
| ploum | works fine | 13:15 |
| ploum | but now I realize that every project is under the very same shared repository | 13:16 |
| ploum | which is not, AFAIK, the goal of shared repository (because our project have nothing in common) | 13:16 |
| ploum | also, while doing big push the whole server is nearly frozen, all the ram being taken | 13:17 |
| ploum | is there a way to optimize this and to "unshare" a shared repository ? | 13:17 |
| beuno | ploum, you can unshare a branch with "bzr reconfigure --standalone" | 13:18 |
| beuno | ploum, also, what format are the branches? | 13:18 |
| beuno | the new format is a *lot* faster | 13:18 |
| beuno | (bzr info should tell you the format) | 13:19 |
| ploum | I upgraded | 13:20 |
| ploum | so it's the latest format | 13:20 |
| beuno | ploum, have you run "bzr pack" on it? | 13:20 |
| ploum | no | 13:21 |
| ploum | what is bzr pack ? | 13:21 |
| ploum | I admit that the new format is faster but it also seems to take more ram | 13:21 |
| beuno | it should re-pack it to optimize it's size | 13:21 |
| beuno | right, I hear that's the current trade off | 13:22 |
| ploum | is there any risk to run bzr reconfigure --standalone ? | 13:22 |
| ploum | what will it do, exactly ? | 13:22 |
| beuno | but, to be honest, I stopped having memoery problems when upgrading 2a, so I'm not sure how true that is | 13:22 |
| beuno | ploum, it should create a standalone branch | 13:22 |
| beuno | as I understand it, there's close to zero risk | 13:22 |
| beuno | as usual, backup, etc | 13:22 |
| ploum | on the server, I did bzr reconfigure --standalone then bzr pack in one of the repository | 13:26 |
| ploum | now, pushing to it from an existing branch craches bzr | 13:26 |
| ploum | ah ok, it was just a permission problem | 13:28 |
| ploum | repacking as root, I have to chown everything to www-data | 13:28 |
| beuno | yeah, root is always trouble | 13:30 |
| ploum | yep but www-data has no shell on the server | 13:30 |
| ploum | so, it works | 13:31 |
| ploum | do you believe it makes sense to make every repository a standalone one with this method ? | 13:31 |
| ploum | and (I ask a lot ;-) ) | 13:31 |
| beuno | well, if they don't share revisions, then it doesn't make sense to have a shared repo | 13:32 |
| ploum | how can I change the repo so, from now, every new repository pushed to the repository is automatically a standalone one | 13:32 |
| beuno | not 100% sure that can have such a large impact on performance, but I wouldn't be surprised if it did | 13:32 |
| beuno | to do that, you will need to completely remove the shared repo, as bzr will look for it whenever you push | 13:33 |
| beuno | be sure that all the branches are standalone before removing it | 13:33 |
| beuno | (and that they work properly) | 13:33 |
| ploum | ok | 13:33 |
| ploum | simply removing the .bzr folder is enough ? | 13:33 |
| beuno | yeap | 13:34 |
| ploum | nice | 13:34 |
| ploum | very informative talk | 13:34 |
| ploum | thanks a lot | 13:34 |
| beuno | glad it helped | 13:34 |
| ploum | is there a way to delete the history of a repository ? | 14:01 |
| ploum | I've some old repositories with heavy changes in binary files but I'm not interested anymore in the history | 14:02 |
| gioele | ploum: bzr fast-export and bzr fast-import --filter (available in a separate plugin) | 14:03 |
| beuno | ploum, me aware that such a change will make existing branches incompatible | 14:06 |
| beuno | so make sure nobody has an existing branch if you're going to re-write history | 14:06 |
| ploum | understood | 14:06 |
| ploum | it makes sense | 14:06 |
| ploum | but it's the case here | 14:07 |
| ploum | in the case of one of our branch that was used by a student to store big binary files | 14:07 |
| === mrevell is now known as mrevell-lunch | ||
| spiffyte1h | Does anyone know of a Debian Stable backport for a newer version of bzr-svn? | 14:34 |
| spiffyte1h | The version in the Stable repo has a critical bug. | 14:34 |
| vila | spiffyte1h: you want jelmer for an answer, providing version numbers for what you found may help him though | 14:36 |
| vila | spiffyte1h: Or maybe LarstiQ is aware of the available debian versions and packaging policies... | 14:37 |
| spiffyte1h | jelmer, LarstiQ: Debian Stable ships with bzr-svn version 0.4.10-2, which has a critical bug (see bzr-svn bug #343543, Debian bug #496164). the bzr-svn ticket indicates that newer versions of bzr-svn resolve the issue, and I'd like to find a .deb package to upgrade with. | 14:42 |
| ubottu | Launchpad bug 343543 in bzr-svn "Segfaults bzr if the first action in a directory is 'ci'" [Undecided,Fix released] https://launchpad.net/bugs/343543 | 14:42 |
| ubottu | Debian bug 496164 in bzr-svn "[bzr-svn] "bzr selftest svn" crashed" [Normal,Open] http://bugs.debian.org/496164 | 14:43 |
| spiffyte1h | Ooooo, that's nice. | 14:43 |
| vila | ubottu: good bot, have a cookie | 14:44 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 14:44 |
| gioele | ubottu: so you prefer chips to cookies, don't you? | 14:47 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 14:47 |
| jam | mroning vila | 14:49 |
| vila | hi jam ! | 14:49 |
| jam | did you check if my 64-bit patch fixed buildbot for you? (It should be in bzr.dev now) | 14:49 |
| vila | jam: I'm running a bunch of runs on babune now if only because installing pyrex on tiger and leopard trigger the leaking-tests bugssss | 14:51 |
| jam | really... | 14:51 |
| vila | jam: go figure.... | 14:51 |
| jam | because they actually start running the tests? | 14:51 |
| jam | or because that triggers the bug? | 14:51 |
| vila | jam: not sure exactly yet, I'm searching for a revision old enough and still passing the whole suite | 14:52 |
| jam | there may be a significant bug in the new "SimpleSet" code. | 14:52 |
| jam | I'm seeing some weird stuff trying to do a full 'bzr branch' | 14:52 |
| vila | my gut feeling is that running with the extensions compiled on OSX brings more tests, change the way they are split, trigger the leak bug, nothing SimpleSet realted | 14:53 |
| jam | vila: k, I just wonder if I have a stray pointer somewhere | 14:53 |
| jam | which can cause all sorts of undefined behavior | 14:53 |
| vila | yeah :-/ | 14:53 |
| vila | jam: so far, hard(32), jaunty(64), karmic(64), gentoo(??), freebsd8(64) passed the full test suite | 14:54 |
| vila | hardY | 14:54 |
| awilkins | Ok, weird bug | 14:55 |
| vila | err, freebsd8 is still running | 14:55 |
| vila | awilkins: no thanks, I have ,u share already | 14:55 |
| awilkins | - I have a file in my tree and bzr has decided that if it's x-bit is set, then it was originally unset, and that's a diff | 14:55 |
| awilkins | But if you clear the x-bit, it then thinks that it should be set, and that's also a diff | 14:56 |
| awilkins | So you can't win. Every time you revert the file it flips the x-bit and still thinks it's been flipped afterwards | 14:56 |
| jam | awilkins: do you know what version of bzr you have? (and what platform) | 14:56 |
| vila | awilkins: that vaguely rings a bell, I'm sure it should ring one for bialix or jam too... | 14:56 |
| jam | I remember that behavior with really old versions of bzr on win32 | 14:57 |
| awilkins | jam: bzr 2.0.0 ubuntu jaunty | 14:57 |
| jam | and that would just be weird | 14:57 |
| awilkins | The one thing I can think of is the file name is fairly unusual in that it has a comma in it | 14:57 |
| awilkins | That sounds pretty tenuous though | 14:58 |
| awilkins | No idea why all the x-bits are turning up flipped in here anyway, unless someone is using bzr on a posix machine accessing a FAT32 partition | 14:59 |
| awilkins | Not using any plugins that claim to handle xbit myself | 14:59 |
| awilkins | ls | 14:59 |
| awilkins | oops | 14:59 |
| awilkins | Still does it without plugins | 15:00 |
| vila | awilkins: waitaminute you're seeing that on jaunty ? | 15:01 |
| awilkins | vila: Yes | 15:01 |
| vila | awilkins: then you can look at the x bit with 'ls -l' and check whether it has changed or not | 15:01 |
| vila | if it keeps changing, *someone* or *something* is changing it, but not bzr | 15:01 |
| awilkins | Colours say that they are all set in this folder | 15:02 |
| awilkins | They have no reason to be set | 15:02 |
| awilkins | Now, they came from an SVN repo, so I'll check the x-bit props on the original branch | 15:02 |
| awilkins | All these files are DITA resources | 15:02 |
| vila | s/D/P/ ? :D | 15:03 |
| * vila has no idea what DITA means otherwise... | 15:03 | |
| awilkins | First time I didn't know what it was and got a lot of nice videos of an attractive lady in a giant martini glass | 15:03 |
| awilkins | It's one of the multitude of XML documentation authoring frameworkds | 15:04 |
| awilkins | Ok... SVN has not got their x-bits set | 15:06 |
| fullermd | Ah, so 'P' is right then. :p | 15:06 |
| awilkins | That's really rather annoying | 15:07 |
| awilkins | ONE of the files in this folder has no x-bit | 15:07 |
| awilkins | All the others do. One of the files is doing this "flip" thing | 15:07 |
| vila | fullermd: hi ! | 15:08 |
| vila | fullermd: there was rumors about vim on freebsd8 not being recent enough for its fans.... a bit chinese for me so I promised to ask you about that :) | 15:09 |
| fullermd | Well, it's currently at patch 239... | 15:12 |
| * fullermd checks vim.org. | 15:12 | |
| fullermd | So 267 is the current patch. | 15:13 |
| fullermd | 239 was from July. David usually updates the pl every few months or so... | 15:14 |
| vila | hmm, strange, it looks like vim wasn't installed.... may be "they" used vi instead ? | 15:15 |
| vila | thanks for checking anyway | 15:16 |
| fullermd | Well, the base system 'vi' is nvi, not vim. | 15:16 |
| fullermd | So, I guess you could say it's a really old vim maybe :p | 15:16 |
| === mrevell-lunch is now known as mrevell | ||
| awilkins | This x-bit thing is a real bug methinks | 15:19 |
| awilkins | I'm getting the impression that one particular inventory item is causing the global xbit state to flip.. and thereafter the xbit gets set for the rest | 15:20 |
| awilkins | or maybe it's horrible disk corruption... | 15:21 |
| fullermd | Always think positive :) | 15:21 |
| fullermd | "Hey, these new light bulbs are pretty bright... or maybe the sun's just going supernova." | 15:22 |
| awilkins | I have a bad history with USB drive controllers | 15:22 |
| awilkins | They last a few months and then go phut | 15:22 |
| awilkins | All the ones I've bought use the chipsets from the same manufacturer when you look inside | 15:22 |
| awilkins | However, the rest of my system is running off the same drive and isn't dead yet... | 15:23 |
| awilkins | A fresh checkout seems better | 15:23 |
| awilkins | Or not | 15:24 |
| awilkins | Lots of x-bits still | 15:24 |
| awilkins | Where none are warranted | 15:24 |
| awilkins | Oh boo, maybe I'm wrong | 15:25 |
| awilkins | They are set in SVN | 15:25 |
| awilkins | Just my lame-ass SVN gui client that doesn't display the properties in a grid properly | 15:25 |
| vila | still a bug, different target :) | 15:25 |
| awilkins | The flipping thing was weird | 15:26 |
| vila | but came from the svn side right ? | 15:26 |
| awilkins | I don't know | 15:26 |
| awilkins | I don't think it should happen that it considers the original xbit value to be the opposite value of what's present | 15:27 |
| awilkins | I don't think the svn:executable property takes "heisenberg" or "schroedinger" as a parameter | 15:27 |
| fullermd | You'll never know 'till you take it out of the box. And then it's too late to set it. | 15:28 |
| ploum | hello | 15:28 |
| ploum | does loggerhead now includes smart-server ? | 15:28 |
| awilkins | I can't build this damn source anyway... the author has made it depend on a whole toolchain on his machine and not mavenized it properly. Git. | 15:28 |
| awilkins | so that was a charming and joyful waste of an hour | 15:28 |
| jam | ploum: you can always try it and see... :) but last I checked they had not hooked up calls to .bzr/smart | 15:29 |
| fullermd | Well, it took me longer than that to get Mosaic running the other month :p | 15:29 |
| awilkins | The xbit flipping thing is now happening in the other branch too. | 15:29 |
| fullermd | So really, you're ahead. Sorta. | 15:29 |
| * awilkins curses | 15:29 | |
| awilkins | ls | 15:30 |
| ploum | jam: because the bug is closed but I can make it work | 15:30 |
| jam | ploum: "can't" ? | 15:30 |
| awilkins | AHAHAHAHAHAHAHAH | 15:30 |
| awilkins | I think I've got it | 15:30 |
| awilkins | Maybe | 15:30 |
| awilkins | Ah, might be my fault | 15:30 |
| awilkins | I ran a "link files to save space" script on this folder | 15:31 |
| awilkins | And I think it's linked some files that have an x-bit to some files that don't | 15:31 |
| awilkins | Hardlinked, that is | 15:31 |
| awilkins | You clear the x-bit on a file that's linked in another folder, and it pops up in the next one | 15:32 |
| awilkins | Stupid number of x-bit for files that are resources though | 15:32 |
| jam | ploum: it looks like there might be something if you do "bzr serve --http" w/ loggerhead 1.17 or so | 15:32 |
| jam | but I'm not user if that also does the smart server | 15:32 |
| fullermd | Data compression. You can use the x bit as an overflow to save a bit in the file contents. | 15:33 |
| ploum | jam: indeed, can't ;-) | 15:33 |
| jam | looking at it, I don't see it actually setting up the rpc stuff | 15:34 |
| jam | ploum: well, nm, it is there | 15:35 |
| jam | def app_for_bazaar_data(self, relpath): | 15:35 |
| jam | if relpath == '/.bzr/smart': | 15:35 |
| jam | wsgi_app = wsgi.SmartWSGIApp(self.transport) | 15:35 |
| jam | return wsgi.RelpathSetter(wsgi_app, '', 'PATH_INFO') | 15:35 |
| ploum | but I'm using loggerhead through an apache proxy | 15:36 |
| ploum | maybe it's related | 15:36 |
| ploum | I was also wondering how you could have permission support in loggerhead | 15:37 |
| jam | ploum: Are you using loggerhead 1.17? | 15:38 |
| ploum | 1.17-0ubuntu1 | 15:38 |
| jam | second, from the places I've been able to trace, it seems to always go to BranchesFromTransportServer, which handles smart requests | 15:38 |
| jam | (or thinks it does :) | 15:38 |
| ploum | (not sure I understand everything you are saying ;-) ) | 15:39 |
| jam | ploum: The code looks like it should be handling '.bzr/smart' requests | 15:39 |
| jam | someone like beuno or mwhudson might know more | 15:40 |
| ploum | is there a need for any .htaccess in my repository ? | 15:40 |
| jam | ploum: so... once I actually got loggerhead to start, it indeed exposes smart requests | 15:47 |
| ploum | even through apache ? | 15:47 |
| jam | the specific problem *I* had was that inside their code base | 15:47 |
| jam | 'import loggerhead' worked | 15:47 |
| jam | but 'import loggerhead.apps.branch' did not (from a subdir) | 15:48 |
| jam | ploum: doing 'bzr serve --http" | 15:48 |
| jam | presumably from apache you just redirect requests to a given ":80/URL" to ":8080/" | 15:48 |
| jam | beuno: When you get a chance, I'd like to help debug why loggerhead wouldn't "just work" for me. | 15:49 |
| ploum | yes, that's what I'm doing | 15:49 |
| ploum | # Loggerhead proxies. | 15:49 |
| ploum | RewriteRule ^bzr2/(.*)$ http://localhost:8080/$1 [L,P] | 15:49 |
| beuno | jam, hi | 15:52 |
| beuno | jam, what's up? | 15:52 |
| jam | beuno: https://bugs.edge.launchpad.net/loggerhead/+bug/451335 | 15:52 |
| ubottu | Launchpad bug 451335 in loggerhead "serve --http fails to find 'loggerhead.apps.branch'" [Undecided,New] | 15:52 |
| jam | basically, from inside 'bzrlib.plugins.loggerhead/__init__.py" | 15:53 |
| jam | "import loggerhead" seems to work | 15:53 |
| jam | but "import loggerhead.apps.branch" fails | 15:53 |
| jam | I'm guessing a subtle python2.6 breakage | 15:53 |
| === mnepton is now known as mneptok | ||
| jam | I'm running from bzr source and loggerhead in my $PLUGINS directory | 15:53 |
| beuno | jam, I think the LH plugin broke a while back | 15:54 |
| jam | anyway, if i change the line, the import fails, so it sets the path, and things work again | 15:55 |
| jam | I don't quite understand why just "import loggerhead" works | 15:55 |
| jam | my short guess is that python2.6 is trying to be somewhat compatible | 15:55 |
| jam | but fails at full backwards compatibilty for relative imports | 15:55 |
| jam | of course, my recommendation is to switch to absolute imports ... :) | 15:56 |
| jam | though I guess the code base is a bit divided | 15:56 |
| jam | between wanting to be a plugin | 15:56 |
| jam | and wanting to be a standalone app | 15:56 |
| jam | with the latter being the original code | 15:56 |
| ploum | must go | 15:58 |
| ploum | thanks for the chat and the informations | 15:59 |
| jam | beuno: maybe something like this: http://docs.python.org/whatsnew/2.6.html#pep-366-explicit-relative-imports-from-a-main-module | 16:04 |
| beuno | jam, can you see if it happens with 2.5 as well? | 16:05 |
| beuno | ah | 16:05 |
| beuno | that sounds like it's it | 16:05 |
| jam | I get stuff like: "No module named pkg_resources" I assume I need to install more of the dependency chain, etc. | 16:07 |
| jam | give me a bit | 16:07 |
| beuno | I thought we removed the deps on setuptools | 16:07 |
| jam | beuno: obviously not entirely | 16:09 |
| jam | I did see that commit | 16:09 |
| jam | I get the same failure w/ python2.5 | 16:09 |
| jam | $ bzr serve --http | 16:09 |
| jam | bzr: ERROR: No module named loggerhead.apps.branch | 16:09 |
| jam | You may need to install this Python library separately. | 16:09 |
| jam | sorry | 16:09 |
| jam | well, the first line is wrong, but the rest is the same | 16:09 |
| beuno | I did see it break with a landing, I don't recall which | 16:10 |
| beuno | I think mwhudson knows about it | 16:10 |
| * beuno tries to remember what the issue was | 16:10 | |
| jam | well, I can't run using bzr.dev with anything less than 386... | 16:14 |
| jam | with the 'bzr-2.0.x' branch, I get the same failure at revno 370 | 16:15 |
| jam | and the first version that supports bzr-2.0.x is 368, also has the failure | 16:15 |
| beuno | jam, I'll try and look into it this afternoon. I'm sure I have a note *somewhere* about the problem and the potential fix | 16:17 |
| beuno | thanks for filing the bug | 16:17 |
| jam | beuno: well, IME the fix is as simple as updating the import line :) | 16:17 |
| jam | also, the original fix that jelmer did to 'avoid polluting sys.path' means that it probably actually runs the wrong version of loggerhead | 16:18 |
| jam | at least, it would run one from a different location. | 16:18 |
| beuno | jam, to what would you update it? | 16:18 |
| jam | 'import loggerhead.apps' is enough to trigger the bug | 16:18 |
| jam | and get sys.path updated | 16:18 |
| jam | the alternative is to just *always* update sys.path | 16:19 |
| jam | well, *an* alternative | 16:19 |
| beuno | jam, as in every __init__? | 16:23 |
| beuno | sys.path.append(os.path.dirname(__file__)) | 16:23 |
| vila | jam: so it seems that bzr.dev pass the full test suite for freebsd8 after all but I can't find any revision passing for OSX (tiger & leopard), and I'm back to 1.16 :-/ | 16:24 |
| jam | beuno: in 'serve_http' | 16:24 |
| jam | vila: ouch... but not *my* fault :) | 16:24 |
| jam | I thought you submitted quite a few patches for a clean test suite on OSX | 16:24 |
| beuno | jam, ah, so basically remove the try | 16:24 |
| vila | jam: not your fault at all, except for pushing me to install pyrex.. | 16:25 |
| vila | jam: Oh yes, I fixed a bunch of visible issues, now I'm discovering new ones :-) | 16:25 |
| jam | *argh**** | 16:26 |
| jam | PyObject_IsTrue(Py_NotImplemented) == TRUE | 16:26 |
| jam | bastards | 16:26 |
| vila | now that I started scratching that thread/socket leak bug, it's triggering all over the places, even where it was silent before, well know fact about vicious bugs that behaviour :) | 16:26 |
| jam | beuno: right | 16:26 |
| beuno | jam, we have 5 failing tests due to this same problem: http://paste.ubuntu.com/293202/ | 16:30 |
| beuno | removing the import doesn't fix them | 16:30 |
| jam | beuno: that only triggers if you are running serve_http | 16:31 |
| jam | and why are you running 'nosetests' rather than | 16:31 |
| jam | bzr selftest -s bp.loggerhead | 16:31 |
| jam | I would at least think the latter would be the way to test loggerhead as a plugin | 16:32 |
| jam | ah, you know what | 16:32 |
| jam | the issue is that "." is called "loggerhead" *and* it has an __init__.py | 16:32 |
| jam | I bet when doing "import loggerhead.apps" it is trying to import higher up | 16:33 |
| jam | though in your case it is named 'trunk' | 16:33 |
| jam | so that wouldn't necessarily be it | 16:33 |
| jam | I don't know how nose sets the path, thuogh | 16:33 |
| jam | though | 16:33 |
| beuno | me neither. Imports make me dizzy, which is why I haven't addressed this yet :) | 16:34 |
| beuno | if I remove the __init__.py on the root dir, the tests work just fine | 16:35 |
| jelmer | spiffyte1h: You should be able to use the package from testing | 16:49 |
| jelmer | spiffyte1h: it wouldn't be very trivial to get a fixed version in, we'd need to also upload subvertpy | 16:49 |
| spiffyte1h | jelmer: OK, thanks | 16:52 |
| === beuno is now known as beuno-lunch | ||
| phinze | alright, i've run into this problem so many times, that i've attempted to document it along with a couple of potential solutions | 17:21 |
| phinze | http://gist.github.com/210162 | 17:22 |
| phinze | if anyone is willing to take a look and give me a "you're doing it wrong" with some advice, i would appreciate it muchly :) | 17:22 |
| luks | question in form of a blog post? | 17:23 |
| luks | :) | 17:23 |
| phinze | luks: well it turned into that | 17:23 |
| phinze | summary would be: how to handle directories shared across multiple branches of mainline development | 17:23 |
| phinze | perhaps 'mainline' is not proper term, perhaps 'heavy active' | 17:24 |
| luks | I'm not sure I understand the branch structure | 17:26 |
| luks | as long as I understand if, you are using bzr branches like a svn repository | 17:29 |
| luks | that is, you have several "projects" in one branch | 17:29 |
| phinze | luks: yeah sorta... mostly centralized development too | 17:29 |
| phinze | luks: ack i gotta run to lunch now -- back in ~1hr... :( | 17:30 |
| luks | ok, so that would be the "you're doing it wrong" point | 17:30 |
| luks | the best solution is to use one branch per project | 17:30 |
| phinze | luks: oh sorry no each project is it its own branch | 17:30 |
| luks | where the shared libraries should be considered separate projects | 17:31 |
| phinze | ahh | 17:31 |
| phinze | yes so that would be #3 below | 17:31 |
| phinze | but how do we pull the libraries in to BLUE and RED? | 17:31 |
| phinze | svn:externals is dead, no? | 17:31 |
| luks | bzr doesn't have a good built-in solution for that yet | 17:31 |
| luks | in svn I'd use svn:externals | 17:31 |
| phinze | yeah | 17:31 |
| luks | there is http://bazaar-vcs.org/ScmProj which might or might not work for you | 17:32 |
| phinze | ahh that looks interesting | 17:32 |
| phinze | i'll have a look at that this afternoon, thanks luks :) | 17:32 |
| * phinze zooms | 17:33 | |
| luks | if you have a problem with scmproj, you can ask on the mailing list | 17:33 |
| luks | bialix (the author of scmproj) is usually active there | 17:33 |
| jam | phinze: the other possible solution is to have your developers *not* commit changes to BLUE at the same time they commit changes to SHARED_LIB-X | 17:36 |
| jam | so that 'bzr merge -c1001' can grab just the changes you want. | 17:36 |
| luks | jam: you would still have to cherry-pick | 17:36 |
| jam | luks: sure, but it would be a bit cleaner | 17:36 |
| luks | I expect that would turn bad eventually | 17:36 |
| jam | luks: I completely agree that separate projects is the $RIGHT way | 17:36 |
| jam | but it is not trivial to set up (yet) | 17:37 |
| === beuno-lunch is now known as beuno | ||
| === mfer is now known as mfer-food | ||
| === davidstrauss_ is now known as davidstrauss | ||
| eross | should I use sourceforge or launchpad for simple game development in ubuntu/linux and prob cross-platform? which represents the open source ideal better? | 18:44 |
| beuno | eross, for starters, Launchpad's full source code is open source | 18:46 |
| vila | eross: which one runs with open source ? | 18:46 |
| vila | beuno: That's cheating ! You shouldn't give the answers before the question !! | 18:47 |
| beuno | :) | 18:47 |
| * beuno always blows it | 18:47 | |
| eross | thanks beuno, sorry vila.. i've got googly eyes :P | 18:47 |
| eross | oh gawd.. it tracks 'karma', i'm going to be so negative on my simple project | 18:55 |
| === davidstrauss_ is now known as davidstrauss | ||
| eross | have to purchase $250/year for a commerical project | 18:57 |
| beuno | yes, didn't you say it was for open source? | 18:58 |
| eross | yes but i like to twist the knife | 19:00 |
| beuno | then sure | 19:02 |
| === mfer-food is now known as mfer | ||
| jam | is there a losa around? | 19:38 |
| jam | like, perhaps, mthaddon ? | 19:38 |
| Chex | jam: hello I am around | 19:40 |
| jam | hi Chex. mthaddon just created a couple of pqm managed branches for me, but when I try to submit anything to them | 19:40 |
| jam | they seem to get blackholed | 19:40 |
| jam | I don't get an error | 19:40 |
| jam | but I don't see any progress, either. | 19:40 |
| jam | ah... maybe it just took a hile | 19:40 |
| jam | as I finally see something about 10min later... | 19:41 |
| jam | Chex: however, I submitted from a couple different places. Can you check if there are some failures in the log that I'm missing? | 19:41 |
| Chex | jam: can you give me a link to one of the branches, please? I am missing context | 19:43 |
| jam | lp:~bzr-pqm/bzr/2.0.1 | 19:43 |
| jam | Chex: maybe it is just something weird about the email setup. As suddenly I'm seeing everything in the queue. But usually it takes <1min, and this time it took > 10 | 19:48 |
| jam | Chex: anyway, you probably don't need to spend a lot of time on it. as things seem to be working. I just got a bit concerned, as I'm trying to get a release out. | 19:49 |
| === davidstrauss_ is now known as davidstrauss | ||
| mathepic | When you made a branch specifically for a bugfix and its merged now, should you remove it from LP if you don't think it needs any more development? | 20:14 |
| === EdwinGrubbs is now known as Edwin-lunch | ||
| beuno | mathepic, I don't see any reason to | 20:18 |
| beuno | branches stack on launchpad, so they don't use up much space | 20:18 |
| jam | mathepic: also, the default view hides branches marked as 'Merged'. | 20:45 |
| jam | I generally don't bother deleting old things, especially since they might be useful later | 20:45 |
| jam | (tracking down a bug, etc.) | 20:46 |
| mathepic | k | 21:03 |
| mathepic | I'm giving -p to bzr mkdir | 21:03 |
| mathepic | When it adds, should it always use smart_add | 21:03 |
| mathepic | or only use smart_add if -p is enabled | 21:03 |
| mathepic | And same thing for adding the directories (always use os.makedirs or use os.mkdir if -p is not enabled) | 21:04 |
| mathepic | Oops, I need to check | 21:10 |
| jam | mathepic: I don't think you want 'smart_add' during makedirs because I *think* it adds all children, and you probably just want to add that one dir | 21:30 |
| jam | also, I would say "makedirs" is dangerous if you are intending to create only one entry. | 21:30 |
| jam | typos, etc. | 21:30 |
| mathepic | Can you take a look at the diff at https://code.edge.launchpad.net/~mathepic/bzr/mkdir-recursive/+merge/13380? | 21:38 |
| mathepic | Oh, your right | 21:38 |
| mathepic | Does add add recursively | 21:38 |
| mathepic | I checked the docs, apparently not | 21:40 |
| mathepic | Since it is working with "bzr mkdir", in theory, there wouldn't be any files in the directory anyway | 21:40 |
| mathepic | Because "bzr mkdir" fails if the directory itself already exists | 21:41 |
| mathepic | Oh wait, it won't work because if its multiple directories, then the files in the lower directories would be added as well | 21:44 |
| mathepic | is there any method in bzrlib that adds directories recursively but does not add the files? | 21:45 |
| jam | mathepic: tree.add(['dir', 'dir/subdir', 'dir/subdir/subdir']) | 21:45 |
| mathepic | So I just need to build that list myself in the code? | 21:45 |
| jam | mathepic: probably | 21:49 |
| mathepic | Question about smart_add: Does it add files in parent directories of the target subdirectory? | 21:49 |
| jam | you also don't want to add things that are already there | 21:49 |
| jam | smart_add does add parent dirs, IIRC | 21:49 |
| mathepic | Okay | 21:49 |
| mathepic | I'm looking at the smart_add code to try and find a way to do this - Is this the part where it finds all the parent dirs it needs to add? | 21:52 |
| mathepic | # only walk the minimal parents needed: we have user_dirs to override | 21:52 |
| mathepic | # ignores. | 21:52 |
| mathepic | prev_dir = None | 21:52 |
| mathepic | is_inside = osutils.is_inside_or_parent_of_any | 21:52 |
| mathepic | for path in sorted(user_dirs): | 21:52 |
| mathepic | if (prev_dir is None or not is_inside([prev_dir], path.raw_path)): | 21:52 |
| mathepic | dirs_to_add.append((path, None)) | 21:52 |
| mathepic | prev_dir = path.raw_path | 21:53 |
| mathepic | L429 in mutabletree.py | 21:53 |
| jam | mathepic: i think that is 'minimizing' the set of paths passed in, but I may be wrong "or_parent_of_any" makes me wonder | 21:53 |
| === Edwin-lunch is now known as EdwinGrubbs | ||
| mathepic | The help of cmd_mkdir is that it is equivalent to constructing the directory and then adding it | 21:58 |
| mathepic | So therefore, is it possible that it SHOULD use smart_add since "mkdir DIR + bzr add DIR = bzr mkdir DIR" | 21:59 |
| mathepic | I just did a test - bzr add does not add files in parent directories of the target directory | 22:02 |
| mathepic | So therefore it should work fine | 22:02 |
| mathepic | Is there any particular reason why lazy_import generates an error when attempting to host a pydoc server over bzrlib? | 22:27 |
| venia | Ok, need to ask a quick question. | 22:31 |
| venia | I'm involved in a project on launchpad, pulled the code off and everything, made some changes. | 22:31 |
| venia | Now I go to push it back and it gives me this error: bzr: ERROR: RemoteRepository([...]) is not compatible with KnitPackRepository([...]) different rich-root support | 22:32 |
| venia | Any ideas how to fix that? | 22:32 |
| fullermd | Well, depends on which is which (I wish the error message told more details). But probably the remote is RR and your local isn't. | 22:38 |
| fullermd | If that's the case, upgrade your local to a RR format (2a probably, unless the remote is on an older one) | 22:39 |
| mathepic | When making a blackbox test, what do I need to include in load_tests | 22:43 |
| venia | Thanks for the reply fullermd. So I just run 'bzr update --default-rich-root'? | 22:43 |
| bob2 | --2a | 22:45 |
| venia | Ah, thanks | 22:46 |
| fullermd | venia: Yeah, that'll probably work. | 22:46 |
| fullermd | The potential downside is that if you go 2a and the remote is in a pre-2a RR format (1.9-rich-root, say), shuffling data between them could be slow. | 22:47 |
| fullermd | It's probably fairly likely that the remote IS 2a though. If they made the poor->rich transition since you branched (otherwise you'd have a RR branch already), they probably went 2a. | 22:47 |
| venia | Wait, (I'm new to bzr) the project leader told me to get the code by doing a bzr pull. Was that wrong? If so, what was I supposed to do? | 22:49 |
| fullermd | Well, it's not obviously wrong. | 22:50 |
| venia | Sorry, but nothing is "obvious" to me right now. Still trying to get my head around bzr. Are there any decent starting documents out there? (I looked at the manual and it was so immense it made my brain hurt) :p | 22:54 |
| fullermd | Well, what you're "supposed to" do depends on what precisely you're trying to accomplish. Without knowing the former, it's impossible to judge the correctness of means :) | 22:56 |
| venia | Ah, gotcha. :) | 22:56 |
| fullermd | However, "pull" is how you (roughly speaking) update a mirror of code, so it stands a reasonable chance of being the correct thing to have done. | 22:56 |
| venia | Well, let me explain. | 22:56 |
| venia | I didn't have the code or the bzr repository. | 22:56 |
| venia | And I needed to get them. So I used pull. | 22:57 |
| fullermd | No, you didn't, 'cuz that wouldn't work. | 22:57 |
| venia | (which apparently something didn't sink or was changed on the server) | 22:57 |
| fullermd | You used branch. | 22:57 |
| venia | sync* | 22:57 |
| fullermd | (pull only updates, it won't create) | 22:57 |
| venia | I'm pretty sure--oh. | 22:58 |
| venia | In my naive-ness I must have 'bzr init' then done a 'bzr pull' | 22:58 |
| venia | Which probably cause those errors, correct? | 22:58 |
| fullermd | No, not really. | 22:59 |
| fullermd | When you 'branch', it uses [some of] the format[s] of the remote branch to determine the local formats (in this case, the repository format). | 22:59 |
| venia | Alright. | 22:59 |
| fullermd | Well.. wait. Maybe I'm... mmm... | 22:59 |
| fullermd | Alright, let's stop guessing. What format does 'bzr info' say your local branch is in? | 23:00 |
| mathepic | Can someone help me with making a blackbox test for Mkdir? | 23:00 |
| mathepic | I have the functions written out | 23:01 |
| mathepic | I just need the load_tests() | 23:01 |
| mathepic | Whatever | 23:01 |
| jam | mathepic: you probably don't need a 'load_tests' function, just add the 'test_mkdir.py' to blackbox/__init__.y | 23:02 |
| jam | lifeless: are you around? | 23:02 |
| venia | fullermd: Which version thing? It has 3. | 23:02 |
| jam | lifeless: I'm on my way out... pqm tests seem to be running slow (about 2hrs to run 2.0.1's test suite). ISTR something about /tmp getting full on that machine, does it ring a bell? | 23:03 |
| fullermd | venia: Just the rollup name from the first line. | 23:03 |
| fullermd | venia: Unless it's 'unknown', of course. In that case, the Repo format is probably enough. | 23:03 |
| venia | repository: Packs containing knits with rich root support | 23:04 |
| venia | That the one? | 23:04 |
| fullermd | Huh. That's weird. You must have specified a --format to 'init'; no rr pack format was ever the default. | 23:04 |
| fullermd | OK, so the problem is the other way around; you've got a rich root repo, and the remote doesn't. That's uglier. | 23:05 |
| venia | So what are my options? To upgrade the server (probably to be avoided at all costs even if even possible) or to start over? | 23:06 |
| fullermd | venia: So the basic issue is that you can't put rich-root revisions in a poor-root repo. | 23:06 |
| fullermd | So you'd need to either get the remote side moved to RR (which WILL happen sooner or later, but they may not be ready to do right now), or recreate your revs in a poor-root repo. | 23:07 |
| venia | My revisions will be easy, I didn't do much actual editing, just added some files | 23:07 |
| venia | So to proceed from here I actually do the 'bzr branch' thing? | 23:08 |
| venia | And then move my files over? | 23:09 |
| mathepic | I've been running the development bzr directly with bzr.py in my bzr.dev directory | 23:09 |
| mathepic | But I just tried to selftest | 23:09 |
| mathepic | bzr: ERROR: exceptions.ImportError: cannot import name user_encoding | 23:10 |
| mathepic | It works fine on bzr 2.0 | 23:10 |
| lifeless | jam: we've had various things; /tmp is in a chroot, but its still worth checking. | 23:11 |
| lifeless | jam: we haven't had a repeated 'X makes it slow and happens repeatedly' though - we've fixed each occurence completely each time. | 23:11 |
| fullermd | venia: Yah. | 23:11 |
| venia | fullermd: Alright, thanks I think that answers my question :) | 23:12 |
| venia | Oh, one other thing. What's the difference between checkout and branch? | 23:13 |
| fullermd | A checkout is a working tree (which is hooked to a branch somewhere). A branch is... well, a branch. | 23:14 |
| fullermd | So the difference is whether your changes are made on the existing branch, or on a new one. | 23:14 |
| venia | Ok. | 23:14 |
| venia | Switching computers really quickly | 23:15 |
| venia | Alright, back, sorry about that. | 23:17 |
| venia | So a checkout it linked, say the remote server and all commits go straight to it? | 23:18 |
| venia | Whereas a branch is a copy of whatever is on the remote server and your commits to your copy, then you 'push' them to the remote server, correct? | 23:19 |
| fullermd | That's a way of looking at it, yah. | 23:20 |
| fullermd | When you run 'branch', what you [generally] get is a branch, and a colocated checkout of that new branch. When you run 'checkout', you get a local checkout of the remote branch ('remote' may just mean somewhere else on the local filesystem of course). | 23:21 |
| venia | So I guess what had me confused was branches as the command, and branched as the launchpad thing. | 23:21 |
| fullermd | So any time you run 'commit', you're technically doing it in a checkout, not a branch; and the new rev goes into the branch that checkout points at, whether it be right-there or off-somewhere. | 23:22 |
| mathepic | checkout = centralized, branch = distributed. | 23:22 |
| venia | I see now. | 23:23 |
| venia | So what's the benefit of using either way? | 23:23 |
| * jelmer hugs spiv | 23:23 | |
| jelmer | ~ expansion in bzr+ssh URLSs \o/ | 23:23 |
| fullermd | Well, that you use the means what fits what you're trying to do ;) | 23:24 |
| venia | Ah. Makes sense. :) | 23:25 |
| fullermd | Checkouts can certainly be used for all sorts of setups, but the most common (and mathepic alluded to) is a centralized dev style, where multiple people work on a single branch. | 23:25 |
| spiv | jelmer: :) | 23:25 |
| venia | Thanks, this discussion has enlightened me much more than 10's of manuals and technical documents. :p | 23:25 |
| fullermd | (everybody just has their own checkout; it's just like working with CVS/SVN) | 23:25 |
| venia | Ah, gotcha. | 23:26 |
| mathepic | Benefit of using branch is that you don't have to waste time with net connections and such | 23:26 |
| venia | So just to clarify this again, a when you commit and push a branch, it goes straight to the original, correct? | 23:27 |
| fullermd | Mmm. Kinda. | 23:28 |
| fullermd | I'd avoid thinking in terms like "original"; it biases you toward thinking of a hierarchy of some sort. | 23:28 |
| venia | Ok, the "trunk" I think they call it. | 23:28 |
| fullermd | Which is perfectly correct socially, but meaningless technically. Technically, all branches are peers. | 23:28 |
| fullermd | 'push' takes revs from one branch and stuffs them into another. Usually, the 'one' is a local branch you're in [a checkout of], and the other is a branch "off somwhere". | 23:29 |
| venia | I'm really getting tempted to write a bzr for utter newbies right now. :p | 23:29 |
| fullermd | And it can be common to 'branch' from one place, 'commit' some changes, and then 'push' back to the same place. But it's far from the only place you might push, so... | 23:30 |
| fullermd | Give in to temptation. It might not pass your way again. | 23:30 |
| venia | Yeah. It'd be helpful, but I've got NO experience writing docs. | 23:31 |
| fullermd | That's too ba... hey, I just thought of a neat way you could get some experience writing docs! | 23:31 |
| venia | So if you have a fork (that's what they're called right?) how do you get changed from one to the trunk? | 23:32 |
| venia | Uh-oh! 0.o | 23:32 |
| * venia looks for a place to hide. | 23:32 | |
| venia | Err, get the changes* | 23:32 |
| fullermd | Not quite sure I'm parsing the question... ah. | 23:33 |
| fullermd | So phrase it as "How can I see the differences between one branch and another". | 23:33 |
| venia | And move those changes between branches. | 23:33 |
| fullermd | The answer is probably 'missing', which shows you which revs each branch has that the other doesn't. | 23:33 |
| fullermd | (possibly, you might mean 'diff', looking at the actual textual differences between branches, but you probably mean 'missing') | 23:33 |
| venia | Sorry, sometimes my typing/grammar skills aren't up to par, especially when I'm tired. | 23:34 |
| venia | Gotcha. | 23:34 |
| fullermd | As for shuttling the changes amongst branches, the general ways are 'push', 'pull', and 'merge'. | 23:34 |
| fullermd | I did a big elaboration on that a few weeks ago here... I should really pull it out of my logs and stick it somewhere to reference. | 23:35 |
| venia | Gotcha, so you can push and pull between repos's? I'll have to look the syntax up on that. | 23:35 |
| venia | Yeah, totally. | 23:35 |
| venia | Bazaar has a wiki, right? | 23:35 |
| fullermd | Don't really have time now, though; I've got a lot of work to try and get done tonite :| | 23:35 |
| fullermd | Yah. Not quite sure how to directly hit it since the new site was rolled out though, other than by knowing a URL that's on it. | 23:36 |
| venia | I'll probably look around and maybe start building "For Newbs" document | 23:37 |
| venia | Best way to learn is by doing! :) | 23:37 |
| venia | That's fine, I know the feeling of a crunched schedule. School does that to me. =\ | 23:37 |
| venia | Thanks for the help! | 23:38 |
| fullermd | Ask me again in a week or so, hopefully I can find time to at least C&P the logs somewhere. | 23:38 |
| venia | Sure. | 23:38 |
| fullermd | (it's the best way, really. I get to act like I'm all helpful, while actually being lazy as hell. Win-win 8-) | 23:38 |
| venia | Hehe. Totally. | 23:39 |
| venia | Anyway, again, thanks for the help, now I need to go get my fixes up! | 23:40 |
| igc | morning | 23:52 |
| * fullermd waves at igc. | 23:54 | |
| mathepic | Hi. | 23:54 |
| igc | hi fullermd, mathepic | 23:54 |
| fullermd | igc: I forwarded some notes on that review to the list; make sure I didn't misrepresent your position. | 23:55 |
| igc | ok | 23:55 |
| fullermd | (I'm all scatterbrained today :|) | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!