| === mwhudson_ is now known as mwhudson | ||
| Peng | Anyone who knows bzrlib.commit here? | 00:29 |
|---|---|---|
| Peng | I decided to take a stab at bug 172612 (change the first line of commit's output to say "Committing to: <dir>" instead of 'Committing revision N to "<dir>"'), but I ran into something: the location passed to NullCommitReporter and friends is optional. Is it ever actually not given? In Commit, it's either self.master_branch.base or self.branch.base. Are those ever None? | 00:32 |
| ubotu | Launchpad bug 172612 in bzr "new commit is overly verbose" [Low,Confirmed] https://launchpad.net/bugs/172612 | 00:32 |
| Peng | I changed it to throw an assertion if it's not given and ran the testsuite (well, at least the commit part of it) and it never failed. | 00:34 |
| Admiral_Chicago | a lightweight checkout grabs the repo withou the history correct? | 00:34 |
| poolie | Admiral_Chicago, right | 00:35 |
| poolie | Peng, that sounds reasonable then | 00:35 |
| poolie | though if it's just for the message, maybe it'd be better to handle it not being passed | 00:35 |
| Admiral_Chicago | poolie: is there a way to grab the history after I do a lightweight checkout? | 00:36 |
| Peng | poolie: Yeah. I'm wondering what the message should say then, though. It used to just say "Committing revision N", but now it would say, what, "Committing"? Nothing? | 00:36 |
| * Admiral_Chicago waves to jam | 00:36 | |
| poolie | Admiral_Chicago, i would think 'reconfigure --checkout' but i'm not usre | 00:36 |
| poolie | maybe just 'committing' | 00:36 |
| poolie | but i can't think of a good case where we wouldn't know the location | 00:36 |
| === me_too is now known as too_short | ||
| === too_short is now known as me_too | ||
| Peng | poolie: In the current code, it's either self.master_branch.base or self.branch.base (depending on if it's a checkout or not). Is it possible for those to be None? | 00:37 |
| Admiral_Chicago | okay thanks, I'll look at the man page, perhaps that has some info | 00:37 |
| poolie | Peng, i suggest you just post a patch with the assertion in | 00:38 |
| Peng | poolie: Really? Okay. | 00:39 |
| poolie | easier to look at it in the actual text | 00:48 |
| poolie | don't forget [merge][#172612] in the subject | 00:48 |
| Peng | poolie: use commit --fixes too? | 00:49 |
| poolie | yes, --fixes lp:172612 | 00:49 |
| Peng | poolie: Update NEWS, you think? | 00:54 |
| poolie | yes, as a bug fix | 00:54 |
| Peng | 'kay. | 00:59 |
| * Peng is reading the mailing list thread on this. | 00:59 | |
| jam | Peng: branch.base will never be None | 01:02 |
| jam | it is the URL to that branch | 01:02 |
| jam | (and we have to have a location to have a branch) | 01:02 |
| jam | *however* | 01:02 |
| jam | I think the =None is there | 01:02 |
| jam | to support people who might have been using that api | 01:02 |
| jam | before the location was required | 01:02 |
| jam | It is unlikely that there are many people doing it | 01:03 |
| Peng | Well, Daniel Watkins only added .started() in that patch. It's been required from the moment it was added. | 01:03 |
| jam | well, obviously for some reason he wanted the ability to pass None... | 01:03 |
| jam | Isn't Daniel Watkins Odd_Bloke ? | 01:03 |
| jam | (maybe that will summon him :) | 01:03 |
| * Odd_Bloke appears from his lamp. | 01:04 | |
| jam | Odd_Bloke: any reason why you wanted location=None? | 01:04 |
| Odd_Bloke | If the other hooks in CommitReporter use it, then it's probably because I just used one of those as a model. | 01:05 |
| Peng | Hmm. | 01:06 |
| Odd_Bloke | So it's probably a case of YAGNI. | 01:06 |
| Peng | As of now, none of the other commit reporter methods take a location. | 01:06 |
| Odd_Bloke | OK, I'll have to have a look at the code in the hopes it'll remind me. :p | 01:06 |
| poolie | jam, i commented on the get_ancestry patch | 01:07 |
| Peng | Hell, Smallville is on, and it's a repeat, but I missed the first 15 minutes of this episode last time. BRB. | 01:07 |
| poolie | is there anything else you'd like tonight? | 01:07 |
| jam | poolie: I saw that... so what is your feeling for bzr.dev versus 1.0? | 01:07 |
| poolie | btw you didn't mark that as [merge] | 01:07 |
| jam | I really think it should be in 1.0 | 01:07 |
| poolie | i think just put it in both | 01:07 |
| poolie | me too | 01:07 |
| poolie | and when we fix it to avoid that call, great | 01:08 |
| poolie | (robert's just at the station, going to meet him) | 01:08 |
| jam | I do understand Robert's point about wanting to provoke the devs and the community into fixing the real issues | 01:08 |
| jam | (not going through all of history) | 01:08 |
| Odd_Bloke | Peng: AFAICT, the 'location=None' part is an artefact from when I refactored the location notification from the 'completed' hook to the 'started' hook. As the completed hook already existed, I had to add an extra parameter to avoid breaking the API and this got carried over, unnecessarily, to 'started'. | 01:12 |
| Peng | Odd_Bloke: Oh. | 01:16 |
| Peng | Hmm. Is making it non-optional worth an unannounced API break? | 01:16 |
| Peng | Or deprecation warning? | 01:16 |
| Peng | Or just an ugly workaround? :P | 01:16 |
| Peng | Is it possible to deprecate an argument? | 01:17 |
| Peng | Well, deprecate the optionalness of an arg. | 01:18 |
| spiv | Peng: sure | 01:18 |
| spiv | Peng: if the argument is not passed, do warnings.warn(..., DeprecationWarning). There may be a fancy decorator somewhere too. | 01:19 |
| Peng | I don't see a fancy decorator in symbol_versioning. | 01:19 |
| Peng | I see an FIXME from 2006 about adding one. | 01:19 |
| Peng | (*January* 2006) | 01:20 |
| Odd_Bloke | Heh. | 01:20 |
| Peng | Smallville's back. BRB. | 01:21 |
| Peng | So, before I come back, what should I do? Deprecate it? Break API compatibility since it's minor? | 01:23 |
| Peng | Also, if I do deprecate it, how would I do that? I mean, what message should I use? "location must be passed"? And then how do I tie that into symbol_versioning? | 01:29 |
| jam | Peng: you *could* do something like: | 01:38 |
| jam | if location is None: | 01:38 |
| jam | symbol_versioning.warn('As of bzr 0.93 you must pass a location to starting') | 01:39 |
| jelmer | jam: Do you know whether lp already uses --fixes lp:... in some way? | 01:39 |
| jam | jelmer: afaik it does not use it yet | 01:39 |
| jam | poolie: ^^ ? | 01:39 |
| jelmer | I don't see an open bug against launchpad-bazaar about it either >-) | 01:39 |
| Peng | Yet another question about my one-line code change: In NEWS, it should go under improvements, right? | 01:40 |
| jam | Peng: since it has a bug associated with it | 01:40 |
| jam | I always put it under bugfix | 01:40 |
| jam | it is a bit grey, though | 01:40 |
| Peng | There's one thing in the improvements section that does have a bug. | 01:40 |
| jam | so you can put it under improvements if you prefer | 01:40 |
| === kiko is now known as kiko-zzz | ||
| Peng | Oops. commit.py imported symbol_versioning but didn't use it at all. | 01:49 |
| ubotu | New bug: #172970 in bzr "packs regression: 'bzr pull ../other'" [Medium,Triaged] https://launchpad.net/bugs/172970 | 01:55 |
| Peng | Ooh, I just thought of something. I should deprecate it in the base class too, right? Just copy and paste the warning? | 02:07 |
| poolie | spiv, hi | 02:07 |
| Peng | When there's a base class that's, you know, all empty and NotImplemented, and I deprecate something, do I deprecate it in the base class and the, err, child class too? | 02:09 |
| spiv | poolie: hello | 02:09 |
| poolie | Peng, you should deprecate every concrete implementation | 02:09 |
| Peng | poolie: What's that mean? | 02:09 |
| poolie | because python doesn't inherit the decorators or now about deprecation itself | 02:10 |
| poolie | what i mean is | 02:10 |
| poolie | if there's a method in the base class that just says raise NotImplemented | 02:10 |
| Peng | Actually, it says "pass", but yeah. | 02:10 |
| poolie | then just add something to the docstring about it being deprecated | 02:10 |
| poolie | oh, in that case people may actually call it | 02:10 |
| poolie | and i'd say you should add @deprecated_method | 02:10 |
| Peng | It's a deprecated argument so I call warn() myself inside it. So just add that? | 02:11 |
| Peng | s/add/copy and paste/ | 02:11 |
| Peng | Oh! NullCommitReporter is used with --quiet. | 02:17 |
| poolie | spiv, i meant to ask, how's bug 164626 | 02:23 |
| ubotu | Launchpad bug 164626 in bzr "branching from hpss doesn't preserve repository format" [High,Confirmed] https://launchpad.net/bugs/164626 | 02:23 |
| poolie | jam, hi? | 02:27 |
| jam | poolie: hi | 02:27 |
| jelmer | poolie: are there any plans for launchpad to recognize and use --fixes lp:# ? | 02:28 |
| jelmer | poolie: hi, btw :-) | 02:28 |
| jelmer | poolie: (for example, automatically change bug status to "fixcommitted" and point at the branch that contains the revision with the bug marked as fixed) | 02:29 |
| poolie | jelmer, that's jml's department | 02:30 |
| poolie | jam, hi, i was wondering about bug 165290 | 02:30 |
| ubotu | Launchpad bug 165290 in bzr "packs do not check for missing compression parents" [Critical,In progress] https://launchpad.net/bugs/165290 | 02:30 |
| poolie | did you say you had a patch for it? | 02:30 |
| jelmer | poolie: ah, thanks - I'll ask him | 02:30 |
| jam | poolie: I'm close to having a patch for it | 02:31 |
| spiv | poolie: just composing the email with the merge directive. | 02:31 |
| poolie | cool | 02:31 |
| jam | but I wanted to merge in Robert's reconcile patch | 02:31 |
| poolie | cool! | 02:31 |
| poolie | yay | 02:31 |
| jam | and to do that | 02:31 |
| jam | I had to create a separate branch | 02:31 |
| jam | because his submission was a cherrypick | 02:31 |
| poolie | jelmer, or you could ask thumper | 02:31 |
| jam | which means that I ran into bug 172970 | 02:31 |
| ubotu | Launchpad bug 172970 in bzr "packs regression: 'bzr pull ../other'" [Medium,Triaged] https://launchpad.net/bugs/172970 | 02:31 |
| poolie | (i can call spirits from the vasty deep) | 02:31 |
| jam | which means that instead I'm focusing on the buffering patches | 02:31 |
| jam | so that I can at least have a bzr that doesn't take 30s to complete a simple operation | 02:31 |
| poolie | jelmer, i *think* at the moment it creates a link between the bug and the branch | 02:33 |
| poolie | but it may not | 02:34 |
| poolie | jelmer, thumper should still be awake so i expect he'll be back soon | 02:34 |
| jam | poolie: from what I've seen, if you use a commit message of "bug #XXXX" it will show you a bug link in the revision view | 02:34 |
| jelmer | poolie: thanks, I'll check back tomorrow though | 02:34 |
| jelmer | well past 3 AM here | 02:34 |
| jam | (code.lp.net/~user/project/branch/ | 02:34 |
| Peng | Odd_Bloke: Mind if I quote your explanation of location=None in a mailing list message? | 02:35 |
| poolie | oh that too | 02:35 |
| Peng | Wow. If this patch is an example of my usual productivity, I can produce about 2 lines of code an hour. :P | 02:36 |
| Peng | And I ask about 10 questions per LOC. | 02:36 |
| fullermd | Well, I remember years ago seeing the stat than an average programmer produces 10 good LOC a day, so I guess that means you get to go home after only 5 hours :p | 02:36 |
| spiv | Hmm, thunder and rain. | 02:37 |
| spiv | poolie: sent. | 02:37 |
| * spiv -> lunch | 02:37 | |
| Odd_Bloke | Peng: That's fine. | 02:43 |
| Peng | Thanks. | 02:44 |
| Peng | Question #39 of the night, where do I put a deprecation of something in NullCommitReporter in NEWS? API breaks? | 02:45 |
| * poolie reads spiv's patch | 02:56 | |
| poolie | Peng, yes | 02:56 |
| Peng | Oops. I uncommitted and rewrote the commit message and patch so much that it triggered a repack. | 03:08 |
| lifeless | :) | 03:10 |
| lifeless | jam: have a good friday | 03:18 |
| jam | thanks | 03:19 |
| jam | have a fun weekend | 03:19 |
| lifeless | jam: I'm off now, and if I've done ~8 hours, I know you have too :) | 03:19 |
| lifeless | I shall, its slug night shortly | 03:19 |
| lifeless | and we're tryin out Twilight Imperium tomorrow | 03:19 |
| lifeless | jam: have a good weekend too | 03:19 |
| jam | sounds like a good time | 03:19 |
| jam | lifeless: quick question | 03:20 |
| jam | does get_graph().is_ancestor() answer True | 03:20 |
| jam | if the candidate is the NULL_REVISION? | 03:20 |
| jam | I guess I can just test it | 03:20 |
| lifeless | I'd have to try to tell you | 03:20 |
| ubotu | New bug: #172975 in bzr "bzr log slower with packs" [Medium,Triaged] https://launchpad.net/bugs/172975 | 03:20 |
| lifeless | I think it will say True | 03:20 |
| jam | lifeless: it does say true, but it takes it a while to get there (since it traverses all of history) | 03:22 |
| jam | so I'll leave the shortcut in for now | 03:22 |
| jam | I was going to just deprecate the function entirely since only merge uses it | 03:23 |
| lifeless | ah | 03:23 |
| lifeless | get_heads() is usually more useful anyhow I think | 03:23 |
| jam | lifeless: merge needs to know to know whether it can set a pending merge | 03:25 |
| jam | or whether it was a cherrypick | 03:25 |
| lifeless | I'm off; if you need to talk about something I can be reached on mobile | 03:25 |
| jam | k | 03:26 |
| poolie | spiv, so did you read my review comments? | 03:40 |
| Necrogami | how's it going tonight? | 03:42 |
| Necrogami | Funny Randomness do you use bzr to version control bzr? | 03:42 |
| Odd_Bloke | Necrogami: We do indeed. | 03:42 |
| === i386 is now known as not | ||
| === not is now known as i386 | ||
| === i386 changed the topic of #bzr to: Not a automato | ||
| === i386 is now known as customisation | ||
| === customisation is now known as i386 | ||
| Necrogami | Bzr is funded by Mark Shuttleworth? | 03:45 |
| poolie | yes | 03:50 |
| poolie | spiv, did you read my review? are you ok to merge it? | 03:50 |
| Peng | Necrogami: Bazaar is "sponsored" by Mark Shuttleworth's company, Canonical. | 03:52 |
| * Peng points in the direction of the website. | 03:52 | |
| Peng | .... | 03:52 |
| Peng | Is it just me, or does this channel have a useless topic? | 03:52 |
| Peng | /topic, I mean. | 03:52 |
| Peng | Oh. That just happened. | 03:52 |
| fullermd | Yeah, I was just noticing that... | 03:52 |
| === poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | ||
| === poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org/ | ||
| === fullermd changed the topic of #bzr to: The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.92 is out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d | ||
| fullermd | (last I have in my logs...) | 03:53 |
| poolie | jam, you didn't attach a patch to your mail about get_revision_graph | 03:56 |
| jam | hmm.. ok | 03:56 |
| Peng | Yeah, that's the most recent topic. | 03:57 |
| Peng | (Unless someone changed it during a netsplit.) | 03:57 |
| jam | poolie: I seem to have an attachment, but it may be 0 length | 03:57 |
| jam | I hit send too soon | 03:57 |
| Peng | Aww, you threw out the first month of bzr.dev's history when converting it to bzr, didn't you? :( | 04:02 |
| poolie | Peng, when it was stored in Baz? | 04:02 |
| Peng | poolie: I think so. | 04:03 |
| Peng | First log message is "import from baz patch-364" | 04:03 |
| poolie | jam, i'm going to make a tarball soon | 04:04 |
| poolie | i think i'll at least merge your index fix to the 1.0 branch | 04:05 |
| poolie | if you're free, maybe you could look at http://bundlebuggy.aaronbentley.com/request/%3C1196392148.32300.468.camel@lifeless-64%3E | 04:05 |
| === mw|wicked-busy is now known as mw|out | ||
| spiv | poolie: ping | 04:27 |
| Peng | jam: How did you get directory listings on bzr.arbash-meinel.com to show the .bzr directory? | 04:37 |
| jam | Peng: IndexIgnore .????* *~ *# HEADER* README* RCS CVS *,v *,t | 04:38 |
| jam | The default is ".*" | 04:38 |
| jam | which ignores everything starting with a '.' | 04:38 |
| jam | I changed it | 04:38 |
| jam | to ignore only those that are longer than '.bzr' | 04:38 |
| jam | A bit of a cheap hack | 04:38 |
| jam | but it worked | 04:38 |
| jam | It will also show .svn | 04:39 |
| jam | or | 04:39 |
| jam | .hid | 04:39 |
| jam | .foo | 04:39 |
| jam | etc | 04:39 |
| jam | but not | 04:39 |
| jam | .long | 04:39 |
| poolie | spiv, hi | 04:42 |
| spiv | poolie: you'd like me to review Robert's fix for 165304? | 04:42 |
| poolie | thanks, yes | 04:44 |
| Peng | jam: One has to have access to httpd.conf to do that, right? | 04:45 |
| jam | Peng: that is where I do it | 04:45 |
| jam | poolie, spiv: I'm reviewing it right now | 04:45 |
| jam | but you are welcome to review it too | 04:45 |
| spiv | jam: ok, I'll do that. I'm interested in this code anyway :) | 04:47 |
| spiv | (plus I've already started ;) | 04:47 |
| jam | spiv: i finished | 04:48 |
| Peng | jam: I don't know of a way to un-ignore something from a .htaccess. Shoot. I should get a VPS. | 04:49 |
| jam | my apache-fu is generally look at the docs, and try something, reboot and see if it works | 04:50 |
| jam | repeat until desired effect is reached | 04:50 |
| poolie | Peng, according to the docs there does not seem to be a way to reset it | 04:50 |
| jam | I've always found it to be a bit of voodoo | 04:50 |
| poolie | if it's set at a higher level | 04:50 |
| jam | especially when a trailing '/' matters and when it doesn't | 04:51 |
| jam | and when you are working in URL space | 04:51 |
| jam | versus when you are in "disk" space | 04:51 |
| jam | etc | 04:51 |
| Peng | Heh. | 04:52 |
| Peng | Lighttpd anyone? :P | 04:52 |
| Peng | poolie: Mm-hmm. | 04:53 |
| igc | poolie: ping | 04:54 |
| igc | poolie: I'm just pushing the latest User Guide work to my public branch right now | 04:56 |
| igc | I'll be submitting it to pqm in minutes | 04:56 |
| poolie | ok | 04:58 |
| poolie | you'll need to send a merge to the 1.0 branch too... | 04:59 |
| Peng | IBM Hash Suffix Array Delta Compression: http://alphaworks.ibm.com/tech/hsadelta?open&S_TACT=105AGX59&S_CMP=GRsite-lnxw02a&ca=dgr-lnxw02aawhsadelta | 05:05 |
| igc | poolie: public branch is http://people.ubuntu.com/~ianc/bzr/ianc-integration | 05:12 |
| igc | submitted to pqm now | 05:12 |
| igc | night all | 05:27 |
| === poolie2 is now known as poolie | ||
| poolie | spiv, could you try fixing the insert_data_stream review comments? | 05:44 |
| spiv | poolie: I'll give it a stab. | 05:47 |
| poolie | thanks | 05:48 |
| Necrogami | i wonder if IBM use's that in ther VCS | 05:49 |
| Peng | IBM has a VCS? | 06:01 |
| Odd_Bloke | Peng: http://www-306.ibm.com/software/awdtools/clearcase/ | 06:01 |
| Peng | Oh, ClearCase. | 06:01 |
| Peng | Doesn't that suck? | 06:01 |
| poolie | spiv, thanks for the bug 164626 patch | 06:03 |
| ubotu | Launchpad bug 164626 in bzr "branching from hpss doesn't preserve repository format" [High,Fix committed] https://launchpad.net/bugs/164626 | 06:04 |
| poolie | can you please either also merge it to bzr.1.0, or tell me a url i can merge your fixed version from? | 06:04 |
| * Peng wanders off. | 06:04 | |
| Peng | The default RAM size for the tool based on that algorithm is 200 MB. Not exactly great for a VCS. | 06:06 |
| poolie | ? | 06:06 |
| Peng | poolie: IBM's delta algorithm. http://alphaworks.ibm.com/tech/hsadelta?open&S_TACT=105AGX59&S_CMP=GRsite-lnxw02a&ca=dgr-lnxw02aawhsadelta | 06:06 |
| spiv | poolie: ok, just pushing up now so I can submit to pqm. | 06:06 |
| Peng | poolie: Did you miss anything when you disconnected? igc linked to http://people.ubuntu.com/~ianc/bzr/ianc-integration | 06:07 |
| * Peng wanders off. | 06:07 | |
| poolie | oh thanks for that | 06:07 |
| Necrogami | http://people.ubuntu.com/~ianc/bzr/ianc-integration/ <--- Empty Folder | 06:08 |
| poolie | actually no, just a branch with no working tree | 06:08 |
| Necrogami | heh | 06:08 |
| spiv | Necrogami: look at http://people.ubuntu.com/~ianc/bzr/ianc-integration/.bzr ;) | 06:09 |
| spiv | Necrogami: or try "bzr info http://people.ubuntu.com/~ianc/bzr/ianc-integration/" | 06:09 |
| Necrogami | heh | 06:09 |
| Necrogami | don't have bzr installed | 06:09 |
| Necrogami | :-\ | 06:09 |
| Necrogami | if i ran my repo in bzr | 06:09 |
| Necrogami | it'd kill a system | 06:09 |
| poolie | are you the guy with the 50GB file? | 06:10 |
| Necrogami | yep | 06:10 |
| Necrogami | 44gb~ but close enough | 06:11 |
| poolie | heh | 06:11 |
| Necrogami | We started killing that thing today | 06:11 |
| poolie | well, i guess in ~6 years we'll have that much mem on our laptops | 06:11 |
| Necrogami | lol | 06:11 |
| Necrogami | but yeah we started working on converting the XML to a SQLite database for temp storage and transfer | 06:12 |
| Necrogami | Don't let me kill the channel heh | 06:16 |
| poolie | spiv, https://edge.launchpad.net/bzr/+milestone/1.0alpha1 | 06:24 |
| poolie | spiv, oh, right, the other problem was bug 165290 | 06:30 |
| ubotu | Launchpad bug 165290 in bzr "packs do not check for missing compression parents" [Critical,In progress] https://launchpad.net/bugs/165290 | 06:30 |
| poolie | i think john didn't get to finish it today | 06:30 |
| poolie | after i've looked over the list, i'll see how he got along in that branch | 06:30 |
| spiv | Ok. | 06:31 |
| poolie | BB seems to be down... | 06:38 |
| vila | poolie: often around this hours | 06:43 |
| poolie | oh, really | 06:51 |
| poolie | i wonder why | 06:51 |
| poolie | a db cron job maybe | 06:51 |
| Necrogami | gah :-\ i really need to figure out how i'm going to lay out my db structure | 06:53 |
| Necrogami | x = 100705 Miles y= 125 miles ~.~ | 06:53 |
| poolie | spiv, ok, i can see john seems to have most of a test and implementation for bug 165290 | 07:16 |
| ubotu | Launchpad bug 165290 in bzr "packs do not check for missing compression parents" [Critical,In progress] https://launchpad.net/bugs/165290 | 07:16 |
| poolie | but, the thing thta should trap it is not actually reached.... | 07:16 |
| === poolie_ is now known as poolie | ||
| spiv | poolie: ok, I think I've dealt with all the review comments. | 07:46 |
| spiv | poolie: I'm just rerunning tests to make sure I didn't break anything. | 07:46 |
| poolie | yay | 07:46 |
| poolie | i'm making some progress on bug 165290 | 07:47 |
| ubotu | Launchpad bug 165290 in bzr "packs do not check for missing compression parents" [Critical,In progress] https://launchpad.net/bugs/165290 | 07:47 |
| spiv | poolie: I've sent a reply to John's review with a diff attached. | 07:51 |
| spiv | poolie: there was one part I didn't feel confident that I could address with Robert, but I also don't think it's show-stopper for merge. So I think with my patch it's ok to merge. | 07:52 |
| spiv | s/with/without/ | 07:52 |
| spiv | (Sometimes it's too easy to accidentally say the opposite of what you meant!) | 07:53 |
| * poolie reads | 07:53 | |
| poolie | s/thunk_flay/thunk_flag | 07:55 |
| spiv | Oops. | 07:55 |
| spiv | My firewall system is called flay, so it's an easy typo for me to make :) | 07:55 |
| poolie | np | 07:55 |
| poolie | after anything in particular? | 07:55 |
| spiv | The naming scheme is characters from Gormenghast (Mary's idea). | 07:56 |
| poolie | that looks like a reasonable response to the comments | 07:56 |
| poolie | could you send it in please? | 07:56 |
| spiv | Gladly. | 07:56 |
| vila | poolie: did you get feedback for next bzr sprint yet ? Sry to bother you but some decision on the dates mainly will help me planning. | 08:02 |
| spiv | And my previous branch merged to bzr.dev successfully too, excellent. | 08:02 |
| vila | spiv: if you can provide me your squid config I may be able to reproduce your problem too | 08:03 |
| poolie | vila, no more than what's on the list | 08:05 |
| poolie | but it'll probably finish prior to march 13 | 08:06 |
| vila | poolie: ok, I'll take that bet then and plan accordingly, thks | 08:06 |
| poolie | do those dates work for you? | 08:06 |
| spiv | vila: it's a fairly standard config AIUI, but I'll send you my squid.conf by email. | 08:07 |
| vila | spiv: thanks | 08:09 |
| poolie | i'm going to slip 165290 and make an rc now | 08:10 |
| vila | poolie: march 3th to march 10th was planned for reworking kitchen plumbing, but we can postpone that to April. | 08:10 |
| poolie | with andrew's change | 08:10 |
| spiv | poolie: I only landed my fix for 164626 to bzr.dev btw; so if you haven't already could you put it in the 1.0 branch? | 08:12 |
| poolie | yes, i'm merging trunk | 08:12 |
| spiv | Great, just double-checking :) | 08:13 |
| Peng | An rc? Wasn't the last release like 2 days ago? | 08:13 |
| Peng | And aren't packs still not in great shape? | 08:13 |
| poolie | they're in good enough shape that getting some more exposure and testing will be useful | 08:14 |
| poolie | gah | 08:18 |
| poolie | again, failure because assertions are not run on pqm | 08:18 |
| poolie | i don't think the balance there is quite right | 08:18 |
| Peng | Well, at least things aren't entirely broken now, they're just sometimes really slow. But when there's active work being done on that situation, why not wait another few days? | 08:18 |
| poolie | the short answer is, because mark asked us to make a test release today | 08:19 |
| Peng | Heh. | 08:20 |
| Peng | I didn't know he was so involved with bzr. | 08:20 |
| Peng | Well pretend your e-mail's down and wait a few days. :P | 08:21 |
| Odd_Bloke | Peng: It's only an RC. You ever tried running an early kernel RC? :p | 08:27 |
| dewd | I think the RC is welcome. it has been a tough job and it's a refreshing thing to do. it lays the work for a solid Xmas gift as well. :P | 08:27 |
| ubotu | New bug: #173002 in bzr "Branching from hpss doesn't preserve non-repository formats" [Medium,New] https://launchpad.net/bugs/173002 | 08:31 |
| Peng | Usually there are only about 2 new NEWS entries between an rc and release. That makes me feel like they're release-quality, but you just want to be safe. Here, you're not going to lose data or anything, but it's intended for testing, not end users. I don't like that being called an rc. | 08:31 |
| Peng | When was the last time there was an entirely new repo format? | 08:31 |
| Peng | (Well, not 100% new. Packs are still knits inside.) | 08:32 |
| poolie | peng, there will be a small delta between the last rc and the final | 08:33 |
| Peng | Aren't there half a dozen commands that are seriously slower? | 08:34 |
| Odd_Bloke | Might it be worth releasing the first one as an alpha (as it's marked on LP)? | 08:35 |
| poolie | people thought that alpha seemed too low | 08:36 |
| Peng | Beta? | 08:36 |
| poolie | guys, at this point i just want to do the release | 08:36 |
| Peng | Gamma? :D | 08:36 |
| poolie | and we can assess what to do from there | 08:36 |
| * spiv is done for the day | 08:42 | |
| poolie | me too | 08:43 |
| poolie | i've uploaded a tarball | 08:43 |
| poolie | am composing a mail | 08:43 |
| === poolie changed the topic of #bzr to: Bazaar Version Control System | http://bazaar-vcs.org/ | please test http://bazaar-vcs.org/releases/src/bzr-1.0rc1.tar.gz | ||
| Peng | Hey, what? Why is my shared repo empty and everything is in the branch? | 09:03 |
| Peng | Argh, and do to the server's process nazi, 'bzr branch' into another branch got killed. | 09:06 |
| ubotu | New bug: #173007 in bzr "SIGQUIT debugging breaks http networking" [Undecided,New] https://launchpad.net/bugs/173007 | 09:10 |
| === Necrogami is now known as Necrogami|Doingt | ||
| === Necrogami|Doingt is now known as Necrogami|Sleep | ||
| ubotu | New bug: #173010 in bzr "initial branch over http: can show no ui activity for a very long time" [Undecided,New] https://launchpad.net/bugs/173010 | 09:26 |
| mwhudson | wow, bzr.dev get http://bazaar-vcs.org/bzr/bzr.dev is a "bit" faster than bzr.dev get http://bazaar-vcs.org/bzr/bzr.dev.knits | 09:31 |
| dato | oh, I guess I'll package the rc for Debian. | 09:56 |
| dato | siretart: ^ | 09:57 |
| dato | siretart: also, I guess it'd be appropriate for a NEWS.Debian entry warning that the default format has changed, and that created branches will be not operable with bzr < 0.92 ? | 09:57 |
| dato | great; again we still have paramiko 1.6 in Debian. | 10:09 |
| siretart | dato: that would indeed be appropriate. | 10:11 |
| siretart | \o/ bzr has migrated to testing :) | 10:11 |
| dato | ok. | 10:12 |
| dato | I think I'll also notify the paramiko maintainer for my intenton to NMU. | 10:12 |
| === cprov-out is now known as cprov | ||
| === Mathilda is now known as uws | ||
| Peng | Mildly interesting: sizes of packs of 500 top-level revisions of bzr.dev (as in 1-500, 501-1000, etc.): http://paste.pocoo.org/show/13197/ | 11:38 |
| Peng | (I'm not sure about the first 40 KB one.) | 11:38 |
| === kiko-zzz is now known as kiko | ||
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| abentley | vila, poolie: I have no idea why BB would go down around 2:00 am my time. | 13:04 |
| vila | abentley: do you want a report each time I encounter a firefox timeout so that you can check the logs ? | 13:05 |
| vila | not a big concern for me but if that can help you.. | 13:06 |
| Peng | Yikes, UnicodeDecodeError traceback in uncommit. | 13:06 |
| abentley | Well, at this point, BB is slow on the first request generally. | 13:10 |
| abentley | I think it has to swap back into memory or something. | 13:10 |
| abentley | Mine is a pretty hurtin' virtual server. | 13:10 |
| abentley | If it actually times out rather than being slow, I guess I'd like to hear about that. | 13:10 |
| spiv | abentley: I was seeing various database errors (database is locked, and some sort of OperationError as well IIRC) rather than timeouts. | 13:13 |
| spiv | abentley: part of the problem is that it's so immensely useful that even short glitches are very noticeable :) | 13:15 |
| * spiv -> zzz | 13:15 | |
| vila | abentley: indeed, I just connected it was very slow, close to some timeout somewhere, that may be that, I'll try to watch that more closely, I'm used to not use it early in the morning though ;-) | 13:29 |
| blauwal | Hi, my name is Jens-Heiner Rechtien and I'm the SCM guy for OpenOffice.org. We are currently seriously evaluating a new SCM system for replacing our old CVS repository. We've got 7 years of CVS history, some 11 GBytes of it code related, so yes, it's huge. I'm currently trying to setup a bzr+ssh server, can someone point me to some infos about it? I've read the spec on the Wiki page. | 13:45 |
| Peng | bzr+ssh is trivial. Just install bzr. | 13:45 |
| Peng | Okay, not helpful, since that's not just what you meant. Sorry. | 13:46 |
| blauwal | Peng: Well, Python segfaulted for me | 13:46 |
| Peng | Ouch. Doing what? | 13:46 |
| blauwal | Peng: bzr -serve segfaulted when I accessed the repository | 13:47 |
| blauwal | Peng: But I'll figure it out if you say me that bzr -serve is supposed to ve working | 13:47 |
| blauwal | Peng: I found that the docu is not very clear about the status | 13:48 |
| jelmer | blauwal: I think you mean "bzr serve"? | 13:49 |
| blauwal | Another problem I have is the import. Our CVS repsitory is not *that* clean | 13:49 |
| blauwal | yes | 13:49 |
| vila | blauwal: look at cvs-import and summon jam here (fullermd may be helpful too) | 13:50 |
| jelmer | jam: alive? | 13:50 |
| blauwal | Another problem I have is the import. Our CVS repsitory is not *that* clean, but I managed a full history import in SVN. Now I thought it might be asier to import from subversion and yes it works, but svnbzr is so slow that after week it read only 15000 of 500000 revisions | 13:50 |
| jelmer | blauwal: jam has done big imports before, in particular of the mozilla cvs tree | 13:50 |
| jelmer | blauwal: svn2bzr of bzr-svn ? | 13:51 |
| blauwal | svn2bzr | 13:51 |
| blauwal | I've yet to try out bzr-svn | 13:51 |
| blauwal | because it requires subversion 1.5 bindings | 13:51 |
| jelmer | blauwal: is your tree available publicly? | 13:51 |
| blauwal | Yes | 13:51 |
| vila | blauwal: bzr-svn is reputedly superior to svn2bzr and there you should summon jelmer (which may too shy to say that ;-) | 13:52 |
| jelmer | I've never tried bzr-svn on anything > 100000 revisions, so I'd be happy to try it on your repository and fix any scalability issues | 13:52 |
| jelmer | blauwal: is this 500k revisions in a single branch or across multiple branches? | 13:52 |
| blauwal | jelmer: Multiple branches | 13:53 |
| blauwal | We've got some 500 libe branches and 5000 dead ones. | 13:53 |
| blauwal | The dead ones were already excluded | 13:53 |
| blauwal | The subversion repository is about 55GBytes huge | 13:54 |
| blauwal | s/libe/life/ | 13:54 |
| jelmer | whoa | 13:54 |
| blauwal | I've written a page with detail, I'm looking it up, mom | 13:54 |
| blauwal | http://wiki.services.openoffice.org/wiki/SCM_Migration | 13:55 |
| blauwal | jelmer: svnsyncing via http is reported to be slow :) | 13:56 |
| blauwal | jelmer: I've got an 11 GBytes bzipped dump which I yould provide if you want to try you tool on it | 13:57 |
| jelmer | blauwal: I'll try bzr-svn on an individual branch first | 13:57 |
| jelmer | blauwal: no need to import the whole repository | 13:57 |
| blauwal | jelmer: great. I would suppose the .../svn/tags/OpenOffice_2_3_0 tagged version or the trunk version, they represent the current size of OpenOffice.org | 13:59 |
| jelmer | blauwal: thanks, I'll give that a try | 14:10 |
| blauwal | jelmer: I would be very interested how it works. You can reach me via hr @ openoffice.org | 14:11 |
| === cprov is now known as cprov-lunch | ||
| Peng | This isn't related to Bazaar, but is there some sort of etiquette when registering a branch of someone else's project on Launchpad? As long as I file bugs too, is it okay? | 14:22 |
| Peng | Jeepers, 1400 testbzrxxx.log files in /tmp. | 14:22 |
| jelmer | Peng: launchpad keeps track of both author and registrant | 14:22 |
| jelmer | from what I've seen, it's ok to register any branch | 14:23 |
| Peng | I know how Launchpad works. I was just wondering if there was general etiquette. | 14:26 |
| jam | was I summoned this morning? | 14:26 |
| jelmer | jam: yep, see ^^ | 14:27 |
| jam | blauwal: I think we've spoken a bit before (actually on the phone) | 14:28 |
| jam | the thing I was waiting on was some time to hack on cvsps-import so that it could do merge commits | 14:28 |
| blauwal | jam: Yes. I'm doing the OOo SCM stuff | 14:28 |
| jam | since OOo has special tags for that | 14:28 |
| jam | (recording that a branch was merged) | 14:28 |
| jam | CVS natively doesn't support any of that | 14:28 |
| blauwal | jam: Yes, we are doing all sorts of nasty stuff | 14:29 |
| jam | unfortunately, this is getting close to bzr-1.0 release, so I've been using all my cycles for that | 14:29 |
| jam | I would be happy to give some pointers, etc if you want | 14:29 |
| blauwal | jam: moving tags, even branches, partial tags and branches etc | 14:29 |
| blauwal | jam: my most urgent problem is to create an import with history so we can start compare apples with apples | 14:30 |
| jam | jelmer: would you have any time to try an SVN conversion? | 14:31 |
| jam | It probably won't have the merges I wanted to add | 14:31 |
| jam | to cvsps-import | 14:31 |
| jam | but it would at least give linear histories | 14:31 |
| blauwal | jam: All my efforts have failed up to now :-(, cvsps bombs out, and svn2bzr (on an already migrated subversion repository is way to slow= | 14:31 |
| jam | blauwal: that is after the cleanup we discussed, right? | 14:32 |
| blauwal | jam: yes | 14:32 |
| jam | (your script which renames the directories, and deletes old stuff) | 14:32 |
| blauwal | yes | 14:32 |
| jam | blauwal: have you had any chance to try the cvsps patch from kenny | 14:33 |
| jam | (i think it was kenny) | 14:33 |
| blauwal | jam: I've received the patch but did not try it out. Next thing I'll do. | 14:34 |
| blauwal | jam: kendy (Jan) | 14:34 |
| jam | ah, right | 14:34 |
| jelmer | jam: I'll have a look at trying bzr-svn on the repository and fixing any performance issues in bzr-svn I come across | 14:35 |
| blauwal | jam: One other thing I noted was that doing a full local branch on a simple minded flat imported OpenOffice_2_3_0 repository (some 70000 files) is quit slow. Maybe I'm doing something wrong | 14:38 |
| jam | blauwal: 2 things | 14:38 |
| jam | a) You should be using a shared repository | 14:38 |
| blauwal | jam: I did | 14:38 |
| jam | b) you might try packs | 14:38 |
| jam | however, if it is time spent in build_tree | 14:38 |
| jam | blauwal: ok | 14:39 |
| blauwal | b) packs? Ok I don't know what packs are ... | 14:39 |
| jam | (b) bzr upgrade --pack-0.92 | 14:39 |
| Peng | That could take a while. | 14:39 |
| jam | It is a different repository format | 14:39 |
| Peng | Heh heh, run reconcile too! | 14:39 |
| jam | Peng: on anything created post bzr 0.92 you don't need reconcile | 14:40 |
| blauwal | jam: I'll try it. | 14:40 |
| jam | it was pre 0.92 that had small issues about the file graph.s | 14:40 |
| jam | blauwal: what bzr are you using? | 14:40 |
| jam | (bzr --version) | 14:40 |
| jam | 1.0rc1 is just released | 14:40 |
| jam | which has some pretty big improvements for packs | 14:40 |
| jam | (sometimes it is hard to remember where things were at a couple months ago, since we have been actively releasing ~ every month) | 14:41 |
| blauwal | jam: I used 0.92. No problem upgrading to 1.0rc1 | 14:41 |
| blauwal | jam: OK, just that I do the things right. Let's say I want to reimport OOo 2.3.0 without history. I fo | 14:41 |
| blauwal | I do | 14:42 |
| blauwal | 1) bzr init-repos --no-trees bzr | 14:42 |
| blauwal | 2) bzr init bzr/trunk | 14:42 |
| jam | (i think it is 'bzr init-repo' but yes) | 14:42 |
| jam | (and if you want to try packs from the start you can do "bzr init-repo --pack-0.92") | 14:42 |
| blauwal | 3) bzr checkout --lightweight bzr/trunk trunk.dev | 14:42 |
| blauwal | ah ok | 14:42 |
| blauwal | 4) add and commit all files | 14:43 |
| jam | but yes, that sounds correct for starting a new tree with 0 history. | 14:43 |
| blauwal | then, to test the time to do a local branch | 14:43 |
| blauwal | time bzr branch bzr/trunk my.test.branch | 14:43 |
| blauwal | jam: Yes. Branching took 48min even a single history revision | 14:44 |
| blauwal | jam: but I'll try out packs | 14:44 |
| jam | blauwal: what did you do for "branching" ? | 14:45 |
| jam | what was the command? | 14:45 |
| jam | (bzr branch bzr/trunk bzr/olderbranch) ? | 14:45 |
| blauwal | jam: no bzr branch bzr/trunk mybranch | 14:46 |
| blauwal | I also tried out checkout and checkout --lightweight, there were no big differences (no wonder since there isn't really a history in there) | 14:47 |
| jam | blauwal: that is branching *out* of the shared repository | 14:47 |
| jam | which is causing it to copy all of the history | 14:48 |
| jam | if you did | 14:48 |
| jam | bzr branch bzr/trunk bzr/mybranch | 14:48 |
| jam | it would have been a lot faster | 14:48 |
| jam | packs *do* help on the branching to a new repository | 14:48 |
| jam | as they have fewer files to touch | 14:48 |
| blauwal | jam: Yes. I know. The equivalent of "git clone" | 14:48 |
| jam | blauwal: we provide shared repositories as a way to avoid the copying you need with git clone | 14:49 |
| blauwal | jam: Yes, but I was trying to simulate here a developer cloning from a central server | 14:49 |
| jam | ko | 14:49 |
| jam | ok | 14:49 |
| blauwal | jam: not just creating a new branch inside the shared respository | 14:50 |
| jam | sure | 14:50 |
| dato | I'm writing a NEWS entry for this upload of bzr to debian; I'll give a paste line for comments, but I have one question: | 14:51 |
| blauwal | I did this "git clone" stuff on exact the same amount of data on the same machine and it took 4min instead of 48min | 14:51 |
| dato | in a shared repository with branches, one has to run `bzr reconcile; bzr upgrade` in the top level directory (the repository), in the branches, or in both? | 14:51 |
| blauwal | but, I'll redo it again with packs | 14:51 |
| jam | dato: just the top level, iirc | 14:53 |
| dato | that's what I thought | 14:53 |
| dato | but I read vila say otherwise in the mailing list, I think | 14:53 |
| dato | ah, maybe not | 14:54 |
| dato | robert> To upgrade, please reconcile your repository (``bzr | 14:54 |
| dato | robert> reconcile``), | 14:54 |
| dato | I'm pretty sure many shared repositories users will update their | 14:54 |
| dato | branches only. I think we should be more explicit: | 14:54 |
| dato | reconcile your branches and/or your shared repositories | 14:54 |
| jam | hmm... I would have thought reconciling a branch in a repo would reconcile the shared repo. | 14:55 |
| vila | jam: it doesn't last time I did it (this week IIRC) | 14:55 |
| dato | so, branches inside a shared repo need a reconcile+upgrade or not? | 14:56 |
| Peng | Branches do need an upgrade. | 14:58 |
| Peng | All it upgrades is the minor metadata, but it's still something. dirstate didn't have branch.conf. | 14:59 |
| hsn_ | who converted bzr.dev repo to packs? i cant merge | 14:59 |
| dato | Peng: and? can't pack repositories work with branch5 format? | 14:59 |
| Peng | dato: Well, they don't *need* it. But if you're already upgrading the repo, why not? | 15:00 |
| jam | Peng: they don't *need* an upgrade, but I would recommend it | 15:02 |
| jam | Branch5 works fine in a packs repository | 15:02 |
| jam | Branch6 just is a bit more trim | 15:02 |
| jam | (doesn't store the full mainline on disk) | 15:02 |
| dato | ok, thanks. | 15:02 |
| dato | comments welcome: http://dpaste.com/26320/ | 15:02 |
| jam | hsn_: use http://bazaar-vcs.org/bzr/bzr.dev.knits | 15:02 |
| jam | hsn_: it should by sync'd from the other repo every hour | 15:03 |
| jam | vila: is it that the 'reconcile' doesn't effect the repo, or the 'bzr upgrade' ? | 15:03 |
| jam | I would think reconcile would always do the repo, but upgrade may not upgrade something not in the current dir | 15:04 |
| jam | but I realize that may or may not always be the case. | 15:04 |
| Peng | Yeah, upgrade won't upgrade branches. | 15:05 |
| vila | jam: I don't remember ;-) | 15:05 |
| === cprov-lunch is now known as cprov | ||
| jam | Peng: upgrade at the repository level doesn't recurse and upgrade the branches | 15:06 |
| jam | I was wondering about the reverse | 15:06 |
| jam | does upgrade in a branch | 15:06 |
| jam | upgrade the repository | 15:06 |
| jam | dato: your text sounds ok, but I'm guessing that you only need to run reconcile on the repository | 15:06 |
| jam | and upgrading the repository will give you packs | 15:06 |
| jam | upgrading the branches will give a slightly better branch format | 15:07 |
| dato | jam: reconcile on the repository, yes; but isn't it also needed for branches which are outside a shared repo (since they contain a repository)? | 15:08 |
| jam | dato: outside a shared repository, yes | 15:08 |
| jam | I don't know that your text made that clear | 15:08 |
| jam | and I wouldn't really want to force people to run "bzr reconcile" 200 times for each branch inside a shared repo. | 15:08 |
| dato | oh, you're right on that | 15:09 |
| dato | but I don't want to make the explanation too complex | 15:09 |
| Peng | jam: Oh. | 15:10 |
| dato | jam: hmmm. I have a knit shared repo with branch6 format branches. if I run `upgrade` in the branches, it complains: | 15:11 |
| dato | bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. | 15:12 |
| dato | is that expected? | 15:12 |
| jam | dato: yeah, because it is upgrading the branch, but has nothing to upgrade | 15:12 |
| dato | ok | 15:12 |
| jam | It really shouldn't be telling you the meta-dir is the latest format | 15:12 |
| jam | I'd be happy with a bug report on that | 15:12 |
| dato | what should it say? | 15:12 |
| jam | it should tell you that the bzrdir, and branch are the latest format | 15:12 |
| jam | anything it is trying to upgrade | 15:12 |
| jam | not just the first one | 15:12 |
| jam | (that way it is obvious whether it is or isn't trying to upgrade the repository) | 15:13 |
| dato | ok, I'll quote this in the report | 15:13 |
| luks | hmm, pack repo reloads all indexes every time I lock/unlock it | 15:23 |
| ubotu | New bug: #173061 in bzr "possibly confusing message when upgrading an already-upgradedbranch" [Undecided,New] https://launchpad.net/bugs/173061 | 15:25 |
| dato | jam: http://dpaste.com/26325/ | 15:26 |
| dato | bbiab | 15:27 |
| jam | but only once in the toplevel directory for shared repositories. | 15:27 |
| jam | (s/the case of//) | 15:27 |
| jam | dato: otherwise I like it | 15:28 |
| jam | luks: yes | 15:28 |
| jam | luks: so do knits | 15:28 |
| jam | luks: that is what locks are for | 15:28 |
| luks | yep, but knits don't need locking | 15:28 |
| jam | telling us that you are okay seeing a snapshot | 15:28 |
| luks | that's what I didn't realize | 15:28 |
| jam | luks: they drop the cache as well | 15:28 |
| jam | or at least, they were supposed to | 15:28 |
| jam | a lock tells us that we don't have to check for changes | 15:29 |
| luks | I mean, knits will always have older revisions at the same place | 15:29 |
| luks | so if I don't lock it, I can always use an older version | 15:29 |
| jam | I'm pretty sure internal to the code we still dropped the index caches | 15:29 |
| luks | I guess I'll need to lock the repo globally in qlog | 15:29 |
| jam | so that we would see new items | 15:29 |
| jam | luks: locking it globally will see some pretty big advantages even with knits | 15:30 |
| luks | well, not really in a GUI application | 15:30 |
| luks | because I already have revision data loaded | 15:30 |
| luks | and those are in some state | 15:30 |
| luks | with knits I could always get more info even it new data were added in the meantime | 15:31 |
| luks | maybe it could check pack-names and if it's not modified, then keep the old indexes | 15:32 |
| jelmer | dato: Could you perhaps sponsor another upload of bzr-svn, 0.4.4-2? | 15:42 |
| jelmer | dato: -1 doesn't install the FAQ and there are some other minor changes as well | 15:42 |
| blauwal | jam: thanks for the tip with "pack-0.92", it mades all the difference. "Outside" branching of the trivial OOo repository is down to 5min from formerly 48 minutes | 15:46 |
| jam | blauwal: that is why we implemented them :) | 15:47 |
| jam | the old format just doesn't scale well | 15:47 |
| blauwal | :) | 15:47 |
| jam | It handles a lot of things nicely | 15:47 |
| jam | but we saw ways to do it better | 15:47 |
| dato | jam: thanks | 15:49 |
| dato | jelmer: ok. I guess that upload would not be compatible with 1.0~rc1, by any chance? :) | 15:49 |
| blauwal | jam: are there any drawbacks with the new format? | 15:50 |
| jelmer | dato: not yet, no | 15:50 |
| jam | blauwal: all current drawbacks are being addressed and most of them should be fixed in the final 1.0 release | 15:50 |
| jam | oh, except 'bzr annotate' being slower | 15:50 |
| jam | bzr commit should be faster | 15:50 |
| dato | jelmer: ok. is all the -2 stuff in place? (IOW can I upload already?) | 15:51 |
| jam | but the old commit was annotating at commit time, rather than waiting until you do 'bzr annotate' | 15:51 |
| jam | post 1.0 we will probably have a flag that lets projects choose which they want to do | 15:51 |
| blauwal | jam: I take faster commits over annotate everytime :) | 15:51 |
| jelmer | dato: yep | 15:51 |
| jam | blauwal: well, there is annotated merging which is also effected | 15:52 |
| jam | but that isn't the default merge algorithm anyway | 15:52 |
| jam | (it helps when your ancestry gets really messy) | 15:53 |
| jelmer | dato: do you need a binary package uploaded somewhere? | 15:54 |
| siretart | jelmer: aren't you a DM these days? ;) | 15:55 |
| dato | siretart: but he needs one last sponsored upload to set DM-Upload-Allowed :) | 15:55 |
| jelmer | siretart: yes, but bzr-svn doesn't have XS-DM-Upload-Allowed: set yet | 15:55 |
| blauwal | jam: we do lots of mass merges (CVS style), would they also be affected? | 15:56 |
| siretart | which is going to happen with this upload, I believe, right? | 15:56 |
| dato | yes | 15:56 |
| jelmer | siretart: yep, exactly | 15:56 |
| Peng | blauwal: The "current drawbacks" are mostly/almost all that some commands (log (at least on a file), uncommit, pull on a bundle, others) are several seconds slower, but they're not unusable, so when branching is that dramatically improved, it's definitely worth the upgrade. | 15:56 |
| jam | blauwal: mass-merges are generally not ancestry provoking | 15:56 |
| jam | it is when you have 4 branches that merge back and forth randomly betweent hem | 15:56 |
| jam | between them | 15:57 |
| jam | well, among them | 15:57 |
| jam | Peng: and most of that is addressable | 15:57 |
| jam | Peng: try with my buffer_all patch | 15:57 |
| jam | it helps a lot of those commands | 15:57 |
| jam | Peng: and it should be in 1.0rc1 | 15:57 |
| jam | I'm currently trying to plug through the root causes of them being slow | 15:58 |
| jam | which will mean they end up faster than the knit form | 15:58 |
| jam | (the problem is generally that they use all of ancestry when they don't need to, and packs are a bit slower at all-ancestry stuff, but much faster at partial ancestry stuff) | 15:58 |
| Peng | jam: I know. | 15:58 |
| Peng | jam: I didn't mean to negate that you said they're being addressed; I was just expanding on what you said. | 15:59 |
| jam | Peng: I didn't know if you knew it would be in 1.0rc1, and I'm sure blauwal didn't know :) | 15:59 |
| jam | (And I was expanding on your expansion :) | 15:59 |
| blauwal | jam: ah I see. Ok our development model is rather simple. Developers branch from a milestone (trunk), work on the branch, after a while thy merge new stuff from newer milestones (trunk) into their branch. Later, the branch will be integrated back into the trunk. Problem is that these merges can affect thousands of files | 15:59 |
| jam | blauwal: that shouldn't be a problem for any of our merge code | 16:00 |
| Peng | jam: I didn't know they would all be in 1.0. That relieves me greatly. | 16:00 |
| blauwal | jam: I thought so, even CVS can do it with some help (manual mergetracking) | 16:00 |
| Peng | blauwal: A couple things were broken in 0.92 (bzr cat, bzr pushing over bzr+ssh) with packs, but they have since been fixed. | 16:00 |
| blauwal | Peng: great | 16:01 |
| Peng | blauwal: This was all a long way of saying that there were some rough edges with packs in 0.92, but they're being worked on or have already been fixed, so don't get discouraged. Also, it would be great if you reported any new issues you run across. | 16:02 |
| blauwal | Peng: I'll do. | 16:02 |
| === kiko is now known as kiko-fud | ||
| * dato giggles at `dh_perl -pbzr`; yay cdbs. | 16:05 | |
| jam | vila: ping | 16:06 |
| vila | jam: Peng | 16:16 |
| vila | silly Xchat | 16:16 |
| vila | jam: pong | 16:16 |
| jam | vila: just reviewing your patch | 16:16 |
| jam | I thought I would tease you directly about writing "htpp" | 16:16 |
| jam | you always used to write "hhtp" | 16:17 |
| jam | (my review should be on the list) | 16:17 |
| * vila installs Ktouch and pratice instead of hacking bzr | 16:17 | |
| * vila re-type practice | 16:17 | |
| jam | I was trying to figure out whether it was a sign of improvement | 16:18 |
| jam | that at least your typos are evolving | 16:18 |
| jam | anyway bb:tweak | 16:18 |
| jam | you didn't give yourself enough credit in NEWS | 16:18 |
| vila | about what ? | 16:18 |
| jam | vila: you only talk about -Dhttp and ShortReadv | 16:19 |
| jam | but you also fixed the code when issuing too many range requests | 16:19 |
| jam | (well, to at least only issue 200 at a time maximum) | 16:19 |
| vila | Ha yes, as I said in my email ? | 16:20 |
| vila | regarding the typos, the progress is making them in the comments instead of the code ;) | 16:21 |
| fullermd | blauwal: As far as the CVS conversion, there was a cvs2svn guy in here a month or two ago soliciting for somebody to write a bzr output backend for it, who said it probably wouldn't be too much work. | 16:23 |
| fullermd | That may be an avenue to explore. | 16:23 |
| blauwal | fullermd: yes. Actually cvs2svn does a lot of the heavy lifting - make sense out of not so consistent CVS archives | 16:24 |
| blauwal | fullermd: actually, the last version of cvs2svn that worked for me is 1.5.1. They did something to 2.0.1 which makes it as slow as molasses, I need to talk with him anyway :) | 16:25 |
| fullermd | Yeah. So with a little work on a backend to write into bzr, we get to stea^Wborrow all that work ;) | 16:27 |
| blauwal | fullermd: yeah. I will look into it, but, unfortuantely I'm more of a perl than python expert and don't know anything about bzr to boot (though way too much about CVS) so I don't know if anything will come out of it. | 16:29 |
| fullermd | Oh, I wasn't suggesting locking you in the basement until you came out with it done ;) | 16:31 |
| jam | blauwal: I think fullermd was suggesting locking *me* in a basement. | 16:31 |
| blauwal | jam: :) | 16:32 |
| fullermd | Just that it's alleged to be a fairly simple thing (couple days work for someone familiar), so it may get done by someone else in the coming months. | 16:32 |
| fullermd | jam: Of course not. That would be unhumane. | 16:32 |
| fullermd | That's what attics are for... | 16:32 |
| jam | fortunately, my basement has escape windows | 16:32 |
| jam | hmm... my attic doesn't | 16:32 |
| Peng | jam: Fall through the ceiling. | 16:37 |
| jam | messy, and still an 8-foot fall, but I suppose better than trying to break through a wall and falling 30 ft | 16:37 |
| Peng | You could try to kick a hole in the ceiling and drop down. | 16:39 |
| fullermd | No, no, you gotta crawl through the duct work. It's more dramatic that way. | 16:40 |
| fullermd | And you get to hum the M:I theme while you're doing it. What more could a man want? | 16:41 |
| vila | blauwal: still being more a perl expert than a python myself, I'd say just try it, you are in for some good surprises | 16:51 |
| fullermd | Pshaw. Python doesn't even have $>, how good can it be? | 16:53 |
| blauwal | vila: Yes, python has come a long way. I've only dabbled with it so far. | 16:54 |
| jam | fullermd: don't you mean: $Pshaw. @Python $doesn't $even $have $>, @how $good @can ~/it/be | 16:56 |
| blauwal | but even after working with perl for > 10 years, perl is still good for some surprises, too ... | 16:56 |
| vila | TIMTOWTDI often becomes this is the way to do it, but getting rid of $@% and replacing '->{}' with '.' is quite a relief | 16:57 |
| fullermd | %{@not[$much]}, obviously. | 16:57 |
| jam | vila: you mean that you can do it 10 different ways, but only 1 is good? | 16:57 |
| vila | jam: no, I mean python promote a good way where perl leave decide which one you prefer | 16:58 |
| blauwal | vila: I agrre TIMOWTDI is no really a strength but a weakness of perl | 16:59 |
| blauwal | s/agrre/agree/ | 16:59 |
| jam | s/no/not/ | 16:59 |
| fullermd | Ack! vila's spelling is already infecting you! | 16:59 |
| jam | :) | 16:59 |
| jam | It is all about the UDP connection from brain to hands | 16:59 |
| * vila cries seeing fullermd spoling its own joke while trying to fix his typos... | 16:59 | |
| jam | there really should be some checksums in there | 17:00 |
| vila | 44 | 17:00 |
| jam | not that I'd want to pay the speed of an ACK round trip for each character | 17:00 |
| fullermd | My problem, OTOH, isn't data corruption; it's mixing multiplexed streams. Hands multitask poorly :| | 17:00 |
| jam | fullermd: I beg to differ. *A* hand multitasks poorly. *hands* can do a decent job :) | 17:01 |
| vila | blauwal: I don't think it's a weakness, it makes reading others code harder since nobody agree on how to do things, but it also gives more freedom | 17:01 |
| fullermd | Yeah, you'd THINK that, until the first time you accidentally chew your stomach and pat your gum while walking... | 17:01 |
| blauwal | vila: I admit I love to code perl because of this freedom, but I usually don't love what other guys make out of my carefully crafted perl code :) | 17:02 |
| vila | blauwal: hehe | 17:02 |
| vila | python execptions is a good example, you *can* throw and catch exceptions in perl (die, if ($@)) but since there is no agreement on how to do that, there are rarely used | 17:04 |
| jam | $@ ???? | 17:05 |
| jam | ouch | 17:05 |
| jam | I guess it makes your perl start to look more like math notation | 17:05 |
| jam | since everything is in symbols | 17:05 |
| blauwal | vila: yes. Actually I use die; if ($@) all the time, but no here seems to understand it | 17:05 |
| vila | jam: see, you talk perl ! $@ contains the reason of your 'ouch' ;-) | 17:05 |
| blauwal | jam: It's actually a very nice regular syntax | 17:06 |
| jam | blauwal: true, but it takes a while to learn the difference between $_ $> $@ @foo $foo $< | 17:06 |
| jam | and implicit operators | 17:06 |
| jam | ~/foo/ | 17:06 |
| jam | chomp | 17:06 |
| fullermd | I do tend to use the names rather than the symbols for all but the handful that I use most often. | 17:06 |
| vila | use English is your friend | 17:07 |
| jam | I could see that once you get used to them, maybe you can parse more symbols per second than | 17:07 |
| jam | you could english words | 17:07 |
| jam | but until then, it is completely opaque | 17:07 |
| blauwal | jam: yes. Now one can code in perl very productive but I bet this also holds for python and maybe ruby, too | 17:07 |
| jam | blauwal: I think python has less implicit stuff in it. | 17:07 |
| fullermd | Well, in ruby, you don't have to be productive; running the code is so slow it doesn't matter if writing was fast ;> | 17:07 |
| jam | So you have to learn less of the language to understand what someone else wrote | 17:08 |
| jam | (certainly one of the main design comments is :Explicit is better than implicit.) | 17:08 |
| blauwal | jam: Actually the biggest obstacle in perl is to learn how to create complex data strcutures. | 17:08 |
| jam | I found perl's argument handling to be.... iffy | 17:08 |
| blauwal | jam: Everything else (objects etc) comes easy later | 17:08 |
| jam | That may have gotten better | 17:08 |
| jam | since I used it | 17:08 |
| fullermd | Yeah. That's the big thing that kills me in perl, since I don't use it enough anymore to remember :| | 17:09 |
| fullermd | Function args are a close #2. | 17:09 |
| fullermd | Supposely, though, both are much better in perl 6, so that should be a nice switch to make in, like, 2025 or so. | 17:09 |
| jam | python's ability to name the arguments at call time is really nice | 17:09 |
| jam | foo(bar=X, baz=Y) | 17:09 |
| vila | blauwal: fully agree, but once you understand than perl references are C pointers and fight perl tendency to make sense of every bogus expression, you define *far* less types than in python | 17:09 |
| jam | often makes it very clear at the call site what you are trying to do | 17:09 |
| jam | vila: well, and perl is happy to auto-cast your variables | 17:10 |
| jam | '1' + '2' == 3 | 17:10 |
| vila | jam: you can name perl arguments, just a hash as an arg | 17:10 |
| fullermd | Oh, that's not the big problem with function args; it's that they're a list, not args, so trying to pass, say, two @arrays requires some hoop-jumping (normally they'll just turn into one large @) | 17:10 |
| blauwal | vila: yes. | 17:10 |
| vila | jam: I'm been bitten more often by python '%d' % '12' -> '12' is not an int than by perl | 17:11 |
| jam | vila: but then can you pass them as positions? | 17:11 |
| blauwal | fullermd: Thats what references are for | 17:11 |
| jam | vila: always use '%s' | 17:11 |
| jam | vila: it works for *all* types | 17:11 |
| jam | But I'm guessing you are doing that because you are *coming from* perl | 17:11 |
| * fullermd is reminded of Jim Fulton's monkeys/snake quote. | 17:12 | |
| vila | jam: yup, and I realized that '%s' was the way in my problematic cases | 17:12 |
| blauwal | My biggest complain about perl is that classes are more or less bolted on and look strange | 17:12 |
| vila | coming from perl one the most annoying one is '' is the same as "" | 17:12 |
| vila | funny one ;-) | 17:12 |
| fullermd | blauwal: Well, yeah, but that's the hoop jumping. Kinda annoying. | 17:12 |
| vila | fullermd: always use references and you're done | 17:12 |
| blauwal | I've written a CVS client library in perl, which is nicely object oriented and looks strange for most | 17:13 |
| vila | @$array is your friend ;-) | 17:13 |
| jam | vila: well, I imagine having perl inline expand is nice when you want it | 17:13 |
| jam | "$foo" versus "%(foo)s" % vars() | 17:13 |
| fullermd | Yes, but you have to use the \ everywhere you call the function then. | 17:13 |
| fullermd | Luckily, I don't hold with OOP, so any weakness perl has there bothers me not at all ;) | 17:14 |
| vila | fullermd: no you *declare* them as references $array = [] | 17:14 |
| vila | instead of @array = () | 17:14 |
| fullermd | Ugh. Trading one problem for another... | 17:15 |
| fullermd | I'll just keep on working in PHP all day, where it works rationally. | 17:15 |
| jam | vila: you point out something, though @$array versus $@ exception object | 17:15 |
| vila | fullermd: TIMTOWTDI ;-) | 17:15 |
| vila | jam: no $@ is a special variable ;-) @$ dereferences an array reference | 17:16 |
| blauwal | fullermd: It's quite funny, but all these $,@,% come quite easily after you get used to it. Well, and you have understood the difference between evaluating them in scalar or list context | 17:16 |
| vila | %$ dereference a hash | 17:16 |
| jam | vila: sure, but $@ means something *very* different from @$ | 17:16 |
| Peng | vila: That line should be quoted. | 17:16 |
| jam | and I don't think the @ symbol in "$@" has any similar meaning to the "@" in @$ | 17:17 |
| jam | sort of like if I named my variables | 17:17 |
| Peng | FWIW, http://www.selenic.com/mercurial/wiki/index.cgi/BzrVsHg | 17:17 |
| jam | foo, fOo, Foo | 17:17 |
| jam | foo = 10 | 17:17 |
| jam | Foo = object() | 17:18 |
| vila | jam: $@ (Mnemonic: Where was the syntax error "at"?) | 17:18 |
| jam | def fOo() | 17:18 |
| fullermd | Yah, but I don't do perl nearly enough to remember all the rules for different contexts and passing and making references in a deep array for easier code writing and yada yada. So it's always a fight. | 17:18 |
| jam | if fOo(foo) == Foo: | 17:18 |
| jam | Foo.foobar() | 17:18 |
| jam | Would be hard to read | 17:18 |
| fullermd | I understand the intent behind "things that _are_ different should _look_ different", but my life is easier when you just reference variables all the same. | 17:18 |
| vila | fullermd: yup, that's the blocking point, I had problems overcoming that and I've seen many block there. | 17:19 |
| jam | die if($@ == @$bar) | 17:19 |
| fullermd | Whether it's a $scalar or a $numeric[$array] or an $associative['array']. | 17:19 |
| vila | jam: true, I don't like the separate namespaces for scalars, arrays, hash and so on | 17:19 |
| fullermd | Or $however['deep'][$one][$may]['go']. Lot simpler. | 17:20 |
| === kiko-fud is now known as kiko-phone | ||
| fullermd | And sometimes in perl you have to $do{'this'}, except for when you have to $do->{'this'}, and the latter often works even when not necessary, except... | 17:20 |
| fullermd | There _is_ rhyme and reason behind it, but if you don't do it every day, it seeps out of your head _real_ quick and leaves you crying. | 17:21 |
| vila | fullermd: my main trick is: $scalar $carS $handler_OF (caps for emphasis) works very well for perl, not for python | 17:21 |
| vila | fullermd: that's why always using references simplifies you only use $do->{this} (stop the silly quote, keys don't need them except if they contain spaces or such) the same trick in python is to do dict(car='2cv', house='small') instead of {'car': '2cv', 'house': 'small'} | 17:23 |
| vila | but $->{} for perl when '.' for python.... far less typos ;-) | 17:23 |
| fullermd | Oh, I always use the quotes. It looks better to me. Bare words are keywords, not data strings ;) | 17:24 |
| vila | fullermd: argh, {'car': '2cv', 'house': 'small'} killed me until poolie showed me the dict() trick | 17:25 |
| jelmer | dato: anything else I should do for the bzr-svn upload? | 17:25 |
| dato | jelmer: no, I'll do it later today | 17:26 |
| jelmer | dato: cool, thanks :-) | 17:32 |
| blauwal | I've got to go for today, but I certainly will come back to this channel and pester^H^H^H^H^H ask you for more infos regarding bazaar and Openoffice. Thanks! | 17:32 |
| dato | jelmer: do you know if bzr1.0 has been branched off, or bzr.dev is still only open for 1.0 stuff? I thought the latter was the case, but I saw bialix talking about opening a new entry in NEWS. | 17:33 |
| vila | blauwal: thanks for OpenOffice ;-) | 17:33 |
| fullermd | dato: I'm pretty sure I've seen an extant 1.0 branch discussed... | 17:35 |
| Peng | Another Launchpad behavior question: Is it worth registering a branch for like a small thing that probably won't be changed and is fine as a bundle? | 17:54 |
| dato | vila: is the "dict trick" dict(a='b', c='d'), or something else? | 17:55 |
| Peng | Worth mentioning is that due to my locations.conf setup, bundles include a source_branch location, so I do create a public branch location anyway. | 17:56 |
| Peng | dato: That's it. | 17:56 |
| === kiko-phone is now known as kiko | ||
| jam | fullermd, dato: 1.0rc1 has been released | 18:05 |
| jam | but it has been done so with an expectation that we will likely see 1.0rc2 | 18:06 |
| jam | Peng: depends on your definition of "worth it" | 18:06 |
| jam | I do it all the time | 18:06 |
| jam | (I think having branches associated with bugs is a nice thing) | 18:06 |
| * Peng giggles and runs off to Launchpad. | 18:06 | |
| dato | jam: yes (I already uploaded it to debian ;); my question was whether development of 1.0rc2 would take place in bzr.dev, or in a separate branch. | 18:06 |
| jam | especially if someone ever wants to backport a fix, etc. | 18:06 |
| jam | dato: you would have to ask poolie | 18:07 |
| jam | I'm guessing bzr.dev | 18:07 |
| dato | jam: that's what I thought; I was asking because bialix was talking about opening NEWS a new. | 18:08 |
| Peng | I mostly feel like I'm imposing, jumping into a fairly inactive project with 3 or 4 bug reports and half a dozen branches. | 18:09 |
| jam | Peng: well, that is what distributed control is all about | 18:09 |
| jam | it lets someone take over the inactive stuff | 18:09 |
| jam | in a friendlier way than a fork | 18:09 |
| jam | And LP helps too, since it gives you a place to announce your stuff | 18:10 |
| jam | near where people. might be accessing the original stuff | 18:10 |
| jam | (without LP a branch on your on host would probably never be seen) | 18:10 |
| jam | Peng: what projecT? | 18:10 |
| jam | project | 18:10 |
| Peng | And now that I can be seen, I'm really wanting to set up HTTPS. Hmph. | 18:10 |
| Peng | jam: pytz. | 18:10 |
| jam | Peng: well it seems like it may not be officially hosted on LP | 18:12 |
| jam | just that stub uses LP + bzr to track upstream | 18:12 |
| jam | hmm, take that back | 18:14 |
| jam | as stub is the developer | 18:14 |
| dato | haha | 18:15 |
| jam | dato: We should start a new section at the top | 19:16 |
| jam | even if it is going to be 1.0rc2 | 19:16 |
| jam | if you look at older NEWS records | 19:16 |
| jam | you can see that we break down the changes by each public release | 19:17 |
| jam | sorry I didn't think about it earlier. | 19:17 |
| dato | bah, you're right :) | 19:17 |
| chiefinnovator | Why is bazaar not working? The first command on the tutortial breaks. $ bzr whoami "John Doe <john.doe@gmail.com>" | 19:18 |
| luks | how does it break? | 19:19 |
| chiefinnovator | I get: bzr: ERROR: extra argument to command whoami: John Doe <john.doe@gmail.com> | 19:19 |
| luks | um, what version of bzr? | 19:19 |
| === mw is now known as mw|food | ||
| chiefinnovator | 0.8.2 | 19:20 |
| fullermd | Whoah. | 19:20 |
| chiefinnovator | It sucks being on Dapper. Everything is old | 19:20 |
| jam | chiefinnovator: http://bazaar-vcs.org/releases/debs/dapper | 19:21 |
| luks | wget http://bazaar-vcs.org/releases/src/bzr-0.92.tar.gz && tar -zxvf bzr-0.92.tar.gz && cd bzr-0.92 && python setup.py install :) | 19:22 |
| chiefinnovator | I just did aptitude install bzr | 19:22 |
| luks | oh, there are debs for dapper... | 19:22 |
| jam | chiefinnovator: http://bazaar-vcs.org/DistroDownloads | 19:22 |
| jam | chiefinnovator: we have a repository for dapper versions | 19:22 |
| jam | I don't think it has the latest latest | 19:22 |
| chiefinnovator | ah I see | 19:22 |
| jam | but it has stuff a lot newer than 0.8 | 19:22 |
| chiefinnovator | So the default did .8 though | 19:23 |
| chiefinnovator | You couldn't identify yourself in .8 :-) | 19:23 |
| luks | you can edit ~/.bazaar/bazaar.conf | 19:24 |
| jam | chiefinnovator: well if you want to use 0.8, you can go to the 0.8 tutorial | 19:24 |
| jam | http://doc.bazaar-vcs.org/bzr-0.8/tutorial.html | 19:24 |
| fullermd | Did email even exist back when 0.8 was current? ;> | 19:24 |
| chiefinnovator | I'll go ahead and get the new one | 19:24 |
| chiefinnovator | So this is better than Mercurial right? I was trying to decide all morning | 19:24 |
| jam | we think so :) | 19:25 |
| fullermd | Obviously, this is the place to come for an unbiased answer to that question... | 19:25 |
| chiefinnovator | isn't | 19:25 |
| jam | chiefinnovator: http://bazaar-vcs.org/BzrVsHg | 19:25 |
| chiefinnovator | Biased is ok, just want to reinforce my decision :-) | 19:25 |
| chiefinnovator | Yeah, I read that one | 19:26 |
| fullermd | Of course, I've long subscribed to the belief that it doesn't matter if I'm biased, as long as I'm right ;) | 19:26 |
| chiefinnovator | sounds good | 19:26 |
| jam | fullermd: a completely true statement, it is just that the former influences the perception of the latter | 19:26 |
| chiefinnovator | well I go ahead and update then, thanks for the help | 19:27 |
| Peng | chiefinnovator: The problem is, they're both better! | 19:27 |
| chiefinnovator | true, coming from SVN | 19:28 |
| fullermd | It would do us well to explain once why hg's hardlinking is not a capable alternative to shared repos, instead of having to fumble it up every time it comes up. | 19:37 |
| Peng | Hg's hardlinking also has its benefits, mainly that you can clone to anywhere on the filesystem, not just inside the shared repo. | 19:39 |
| fullermd | Well as long as you're using a fs that supports hardlinks. And cloning on one fs (though I don't know if shared repos can span fsen; branches can't) | 19:40 |
| jam | Peng: though packs will also support hardlinking without having to ever break the links | 19:40 |
| jam | fullermd: shared repos can span fs | 19:40 |
| jam | you just have to have a containing fs | 19:40 |
| jam | so if you put one it / | 19:40 |
| jam | all your branches would share across all filesystems | 19:40 |
| jam | we do expect that .bzr/* is on the same filesystem as all working files | 19:41 |
| jam | so that we can do atomic "os.rename()" | 19:41 |
| fullermd | (mind you, I have a very low opinion of any fs that _doesn't_ support hardlinks. But they are out there.) | 19:42 |
| jam | fullermd: and there are those like HPFS+ that *do* but very poorly | 19:42 |
| jam | (as in, performance is better without hardlinking) | 19:42 |
| fullermd | Mm. Packs may support hardlinking without strictly speaking having to break, but they still have all the same side effects as breaking. | 19:43 |
| jam | fullermd: the problem with knits is that you have to probe and see if you need to break | 19:43 |
| jam | before writing to them | 19:43 |
| jam | (same thing for revlog) | 19:43 |
| jam | which means it isn't safe to do over sftp | 19:44 |
| jam | etc | 19:44 |
| jam | but it *is* safe to use packs in a similar fashion | 19:44 |
| jam | over sftp when the remote one is hardlinkde | 19:44 |
| jam | hardlinked | 19:44 |
| fullermd | Safety isn't my argument against it. It's that it's not shared; your branches only share storage as long as you don't touch either one. | 19:44 |
| fullermd | Soon's you start commiting in one or the other, you progressively work back toward 2*space. | 19:44 |
| jam | fullermd: completely true | 19:45 |
| jam | and packs have the side effect that changing 1 file 10,000 times | 19:45 |
| jam | will get you back to 2x space | 19:45 |
| jam | because it breaks the link for "unrelated" files | 19:45 |
| fullermd | So saying "We don't need shared repos, hardlinks do just as well" is false, even if it's done completely safely. | 19:45 |
| jam | (though if one file is changing 10,000 times, you probably don't have that much in common anyway) | 19:45 |
| jam | fullermd: I agree (I certainly never made that assertion, I like shared repos) but that doesn't mean it is incompatible with also doing hardlinks | 19:46 |
| jam | probably our bigger impedance to hardlinking packs | 19:46 |
| fullermd | Oh, I'm arguing against the statement I've heard from hg before (and is on their reponse page against our BzrVsHg) | 19:46 |
| jam | is that we garbage collect when you push/pull/branch | 19:46 |
| jam | fullermd: do you have that page? I'd be interested in reading it | 19:47 |
| fullermd | 11:17 <Peng> FWIW, http://www.selenic.com/mercurial/wiki/index.cgi/BzrVsHg | 19:47 |
| Peng | If I had a wiki account, I might add a comparison of shared repo vs. hardlinks. | 19:48 |
| jam | Peng: if you want to write it up in ReST format | 19:48 |
| jam | I'll upload it for you | 19:48 |
| Peng | I meant to the hg wiki. :P | 19:48 |
| Peng | And it would only be one paragraph. | 19:49 |
| kiko | wow, what a nasty page. | 19:52 |
| james_w | wow, you guys have been busy. | 20:00 |
| Peng | They're always busy. | 20:01 |
| james_w | true, *especially* busy. | 20:01 |
| jam | james_w who is "you guys"? the chat channel? | 20:02 |
| james_w | jam: no, everyone flooding my bzr mailbox :) | 20:02 |
| kiko | hey I've been busy too! | 20:03 |
| james_w | all the merge requests, bug triaging :) | 20:03 |
| james_w | kiko: I don't doubt it, feel free to bounce me copies of all your work so that I can marvel at that as well :) | 20:06 |
| kiko | I deal in psychological counseling and disaster management. I wouldn't bounce those to you. | 20:07 |
| kiko | you seem like a nice person. | 20:07 |
| === mw|food is now known as mw | ||
| james_w | ah, thanks kiko. | 20:07 |
| kiko | however if you have a crisis, you can call me! | 20:08 |
| jam | james_w: well that is just a targeted strike to make you unproductive by DOS'ing your email server | 20:09 |
| === cprov is now known as cprov-out | ||
| === kiko is now known as kiko-afk | ||
| lifeless | jam: hi | 20:45 |
| jam | hi lifeless | 20:45 |
| jam | good morning | 20:45 |
| jam | you are actually showing up at a reasonable time | 20:45 |
| jam | I'm so proud of you | 20:46 |
| lifeless | well I have guests | 20:46 |
| lifeless | been doing stuff round the house :) | 20:46 |
| lifeless | given it's my sat, I'm not sure showing up is reasonable :) | 20:46 |
| lifeless | anyhow, I thought I'd ask if there was anything you needed help with; I have somewhat under 2 hours that I can do 'stuff' in if needed. | 20:46 |
| jam | lifeless: I have 3 patches up for review | 20:46 |
| Peng | Make packs more awesome! | 20:47 |
| jam | one is the "fetch checks basis" | 20:47 |
| jam | patch | 20:47 |
| jam | Which depends on your reconcile stuff | 20:47 |
| jam | so get your reconcile merged (if it isn't yet) | 20:47 |
| jam | and then review mine | 20:47 |
| jam | 2 and 3 are performance patches | 20:47 |
| jam | that get rid of some of our poor scaling | 20:47 |
| lifeless | I was going to let your branch merge both | 20:47 |
| jam | lifeless: sure, if you want to approve it... though I did want the comments, etc from you | 20:47 |
| lifeless | right; I'll review now | 20:48 |
| lifeless | abentley: whats my password again ? :) | 20:48 |
| lifeless | I'm not on my normal machine | 20:48 |
| lifeless | Peng: we will make them more awesome | 20:49 |
| Peng | :D | 20:49 |
| lifeless | abentley: nvm, got it | 20:52 |
| lifeless | jam: reviewed one | 20:58 |
| fullermd | Peng: You need bzr init --format=pack-moreawesomeer" | 20:58 |
| Peng | If only improving software were as easy as adding a "--moreawesomer" argument... | 21:00 |
| lifeless | jam: okies, reviews done | 21:11 |
| lifeless | jam: bbiab | 21:11 |
| lifeless | jam: ping | 22:08 |
| jam | lifeless: pong | 22:09 |
| lifeless | so | 22:09 |
| lifeless | I will be going in < 1 hour | 22:09 |
| lifeless | if you need more discussion or review we should do is asap | 22:09 |
| lifeless | *i* | 22:09 |
| lifeless | *it* | 22:09 |
| jam | Nothing that cannot wait the weekend, IMO | 22:10 |
| lifeless | ok | 22:10 |
| lifeless | I have only mon and tuesday next week | 22:10 |
| Peng | lifeless: Changing the delta algorithm will halve disk usage? | 22:10 |
| lifeless | Peng: yes | 22:10 |
| Peng | lifeless: From what to what? | 22:11 |
| jam | k, I only have a couple more hours, and you've given me enough for that | 22:11 |
| jam | lifeless: to xdelta from line-deltas | 22:11 |
| jam | and changing the compression order | 22:11 |
| jam | Peng: ^^ | 22:11 |
| lifeless | Peng: well e.g. 50 to 25M thereabouts, for bzr.dev | 22:11 |
| jam | just changing the order brings the biggest benefit | 22:11 |
| lifeless | jam: something you might find interesting when you get say 2 hours 'spare'. | 22:12 |
| jam | ? | 22:12 |
| lifeless | jam: put your inventory reweave into 'bzr pack' | 22:12 |
| lifeless | jam: that is, subclass Packer to one that regenerates the inventory deltas to be optimal. | 22:12 |
| jam | oh, to change the # of inventory fulltexts | 22:12 |
| lifeless | jam: or at least analyse and decide if it's optimal/blind reinsert. That sort of thing. yes. | 22:12 |
| jam | Peng: there is an interesting property when it comes to deltas and merges | 22:14 |
| jam | in that the delta against left parent when merging | 22:14 |
| jam | is the sum of the chain of commits | 22:14 |
| jam | which means it is usually rather large | 22:14 |
| jam | multiparent diffs help | 22:14 |
| jam | but that means you have to unpack both sides | 22:15 |
| beuno | oook, after two days of using packs, it seems all in all considerably faster then knits. I have ~140 branches at the office spread around the filesystem, is there some clean/automatic way of upgrading all of em to packs? | 22:30 |
| dato | find/locate + script, probably | 22:30 |
| jam | beuno: "for branch in `bzr branches`; do bzr upgrade $branch; done" | 22:31 |
| jam | (if you have bzrtools for 'bzr branches') | 22:31 |
| lifeless | beuno: find .bzr/repository/revisions.knit - dirname twice; reconcile; upgrade | 22:31 |
| jam | which will be a lot slower than "find . -path '.bzr/branch'" | 22:31 |
| dato | jam: (s/path/wholename/, I think, in case you'd be interested) | 22:31 |
| jam | beuno: I would recommend lifeless's solution but dirname 3 times | 22:32 |
| lifeless | jam: does your reweave inventory do anything strange? | 22:32 |
| beuno | we might want to have a nice downloadable script handy once 1.0 hits the stores | 22:32 |
| jam | lifeless: I believe it just inserts inventories into the target using the new algorithm | 22:32 |
| lifeless | jam: or is it just get_graph_with_ghosts + topo_sort + reinsert ? | 22:32 |
| jam | for version in knit.versions(): knit.add_lines(...) | 22:32 |
| lifeless | hmm, I might whip this up | 22:33 |
| jam | it has been a while, though | 22:33 |
| lifeless | another thing that would be niftt | 22:33 |
| lifeless | nifty | 22:33 |
| lifeless | have bzr info -vv | 22:33 |
| lifeless | show how much space each fileid consumes | 22:33 |
| lifeless | - sum the record sizes for everything with that id | 22:33 |
| lifeless | spiv: in case you haven't figured it out; index is self.stream_index compares object instances, (self.stream_index is a _StreamIndex). So its safe, its a string when its a thunk request - that is not self.stream_index. | 22:35 |
| jam | lifeless: another way it could be rewritten... compute what should be a delta and what should be a fulltext. If the current index matches, just copy the data across. only if it misses do we need to do add_lines() | 22:36 |
| jam | it would make it a lot faster | 22:37 |
| lifeless | jam: yah | 22:37 |
| lifeless | jam: same as reconcile's stuff for texts | 22:37 |
| jam | yep | 22:37 |
| lifeless | jam: its what I meant by 09:12 < lifeless> jam: or at least analyse and decide if it's optimal/blind reinsert. That sort of thing. yes. | 22:38 |
| lifeless | jam: another possibility is to consider only the fulltexts | 22:38 |
| jam | lifeless: also, I think if you favored doing a fulltext at a merge revision | 22:39 |
| jam | since those would tend to be larger anyway | 22:39 |
| === mw is now known as mw|brb | ||
| beuno | hey Verterok | 22:40 |
| jam | It seems we don't have any branch_implementation tests that pull(other) will raised DivergedBranches | 22:49 |
| jam | we have 1 blackbox test that happens to exercise it | 22:49 |
| jam | weird | 22:49 |
| jam | (it turns out my pull_set_last_revision stuff broke it, but not branch tests failed) | 22:50 |
| Peng | I have a plugin (bzrtools) installed with bzr 0.92 in my system. But now I'm running bzr.dev. How should I hook up the plugin into it? | 22:52 |
| jam | Peng: I always install it in ~/.bazaar/plugins/bzrtools | 22:53 |
| jam | directly from Aaron's branch | 22:53 |
| jam | because he has to usually update it for each bazaar release anyway | 22:53 |
| jam | so I can just "cd ~/.bazaar/plugins/bzrtools; bzr up" | 22:53 |
| Peng | Ahh. | 22:53 |
| Peng | You run non-release bzrtools too? | 22:54 |
| Peng | Oh, duh. | 22:54 |
| Peng | If I'm using non-release bzr, I need non-release bzrtools too. Hmm. | 22:54 |
| jam | not always, but usually | 22:54 |
| jam | aaron is pretty good about not really breaking stuff | 22:54 |
| jam | actually, I've been spoiled by bzr, such that I feel like running tip of lots of projects | 22:55 |
| jam | only to find out they aren't as careful | 22:55 |
| Peng | Heh. | 22:55 |
| Peng | Run Mozilla from CVS! | 22:55 |
| jam | well, CVS by its very nature will tend to create broken stuff if you do anything but get tags :) | 22:55 |
| jam | and even then | 22:56 |
| jam | ... | 22:56 |
| === Necrogami is now known as Necrogami|Sleep | ||
| jam | oh, I'm wrong, the pqm has just been changed to stop on the first error... shame, I always used the pqm to give me the list of tests I needed to fix :( | 23:02 |
| Peng | Modern computers are fun. I just did a find through my entire home directory to find all of the .bzr dirs, and run upgrade on them, and it took like 30 seconds. | 23:03 |
| Peng | (I had manually gotten all of the repos, but not all of the branches.) | 23:03 |
| === mw|brb is now known as mw | ||
| Peng | There were 45 of them. | 23:04 |
| * lifeless waves | 23:04 | |
| lifeless | oh Peng - are you using bzr again now ? | 23:04 |
| Peng | Only 28 .hg dirs. :P | 23:04 |
| lifeless | Peng: if so, cool, and welcome back to the fold :) | 23:04 |
| Peng | lifeless: Not for that main thing. But I never stopped using it for other things. | 23:04 |
| lifeless | Peng: oh, cool. | 23:05 |
| Peng | (The main thing being where I could stress-test it best. Hmph.) | 23:05 |
| lifeless | Peng: please let us know where we fail w.r.t. that main thing at the moment. | 23:05 |
| Peng | lifeless: I have no idea. | 23:05 |
| lifeless | :) | 23:05 |
| Peng | But even if I wanted to go through the hassle of another conversion, then I would barely be using hg, and I don't want that. | 23:05 |
| lifeless | Peng: well, :) | 23:05 |
| lifeless | ok, gone for real. | 23:05 |
| Peng | lifeless: I'd be happy to do any tests you want me to on a copy of the bzr branch from before the conversion. It's about the same, just a bit smaller. | 23:07 |
| Peng | (Don't really feel like doing it right now, though. Also, Firefox is busy hurting the system's responsiveness.) | 23:08 |
| Peng | (A fun way to measure what Firefox is doing is to time my usual large commit that I do frequently. When Firefox is closed, it's 16 seconds user time and a couple seconds sys and wall-clock time is normal, but when Firefox is really hogging things, wall-clock is always above 50 seconds, rarely above a minute.) | 23:09 |
| fullermd | You can't run Mozilla from CVS. The compile time is longer than their release cycle... | 23:10 |
| Peng | Heh. | 23:11 |
| Peng | You can always be out-of-date *and* unstable. | 23:11 |
| fullermd | No, I don't have a Windows CD. | 23:11 |
| Peng | Mozilla has an hg branch, which is just a direct copy of almost all of the CVS tree. Last I heard, it couldn't compile without CVS. Hmph. | 23:12 |
| Peng | Off-topic, but since everyone here is smart and GPG-signs everything, what do you do about backing up your PGP key? I'd store encrypted backups, but there has to be an unencrypted version somewhere to be able to decrypt the backup of it! Do you put it on a floppy at Grandpa's? Encode it in the Bible and hide it in multiple safes in booby-trapped locations on each continent? Upload it to a hidden directory on your shared web space and hop | 23:29 |
| Peng | e no script kiddies hack your blog? | 23:29 |
| Peng | Ooh, multiple lines. Nice. | 23:29 |
| fullermd | Tattoo it on the inside of your eyelid. | 23:29 |
| Peng | What if I get a new one with a longer algorithm? :( | 23:30 |
| kiko-afk | so somebody tie jam up | 23:30 |
| kiko-afk | jam, do you have all this code in a DVD somewhere and you are slowly unleashing it to the world? | 23:30 |
| fullermd | Write smaller. | 23:30 |
| Peng | Seriously, though. | 23:31 |
| === doko_ is now known as doko | ||
| * fullermd shrugs. | 23:32 | |
| fullermd | I'm not an especially heavy user. | 23:32 |
| fullermd | I follow the methodology of "put all your eggs in one armor-plated basket, and watch it like a hawk" | 23:33 |
| Peng | What's that mean? | 23:34 |
| fullermd | It's the opposite of avoiding putting all your eggs in one basket, because spreading them securely and reliably isn't as easy as a lot of people think. | 23:36 |
| Peng | Hmmph. | 23:42 |
| abentley | jam: are you planning on doing xdelta packs? | 23:42 |
| Peng | I believe Mercurial has had problems with how xdelta scales. | 23:44 |
| Peng | What about IBM's algorithm? http://alphaworks.ibm.com/tech/hsadelta | 23:46 |
| abentley | Well, I'd rather use the MPDiff format we already use in bundles. | 23:47 |
| abentley | But the main thing is, I don't want to duplicate effort with jam. | 23:53 |
| schierbeck | jelmer: ping | 23:53 |
| jelmer | schierbeck: pong | 23:55 |
| schierbeck | jelmer, does the bzr-gtk trunk still reside in ~bzr/bzr-gtk/trunk? | 23:57 |
| schierbeck | even when we have a ~bzr-gtk team? | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!