| lifeless | mtaylor: btw | 00:09 |
|---|---|---|
| lifeless | mtaylor: please tell me if my fix works for you in builddeb | 00:09 |
| mtaylor | lifeless: I will check it | 00:10 |
| lifeless | mgz: yes, interbranch multimethod was extracted from previously plan branch methods | 00:10 |
| lifeless | mgz: most of the tests are just copies of the old branch ones | 00:10 |
| mgz | thanks. | 00:13 |
| mgz | lp:launchpad still hasn't finished branching... | 00:13 |
| lifeless | harh | 00:14 |
| lifeless | its a tad big | 00:14 |
| mgz | ha! ran out of disk space | 00:16 |
| lifeless | >< | 00:17 |
| lifeless | are you hoping to patch launchpad ? | 00:17 |
| lifeless | mgz: ^ | 00:18 |
| mgz | I thought I'd see if the problem with group membership being seen as more important than direct subscription was something as simple as a badly-ordered if chain | 00:19 |
| lifeless | ah cool | 00:20 |
| lifeless | you'll want about 1.5GB | 00:20 |
| mgz | I think I'll check via the web interface before finding a big enough drive :) | 00:20 |
| lifeless | + a bit of slack | 00:20 |
| lifeless | I have a 4G VM | 00:21 |
| lifeless | with 550M free in it, to do LP development | 00:21 |
| lifeless | I documented that on the dev.launchpad.net wiki under running/vm, or something like htat | 00:21 |
| lifeless | I'm off to do various things; shall be back online periodically. | 00:22 |
| exarkun | I'm having difficulties merging some changes from one branch into another. | 00:26 |
| exarkun | http://pastebin.com/PQ2hFcCd | 00:27 |
| exarkun | Is something wrong with that? | 00:27 |
| mgz | branching rev 0 isn't something I've every tried personally. | 00:30 |
| spiv | Good morning. | 01:02 |
| spiv | exarkun: there's a bug about that | 01:03 |
| spiv | exarkun: are you aware that branching rev 0 is essentially the same as doing "bzr init"? | 01:03 |
| spiv | exarkun: IIRC there's a bug that rev 1 cannot be a merge commit. | 01:04 |
| spiv | exarkun: See https://bugs.edge.launchpad.net/bzr/+bug/242175, and the bug it links to (and the bugs linked to from its comments...) | 01:07 |
| ubot5 | Launchpad bug 242175 in Bazaar "Better error message when merging into empty branch (affected: 1, heat: 0)" [Wishlist,Confirmed] | 01:07 |
| exarkun | How about this one, http://pastebin.com/h1Z2U7Qk | 02:25 |
| exarkun | It seems odd to get conflicts when merging like that. | 02:25 |
| spiv | exarkun: that seems odd to me too | 02:27 |
| spiv | exarkun: file a bug :/ | 02:27 |
| exarkun | will do | 02:42 |
| exarkun | I don't know if I'll file all the bugs I ran into tonight :/ | 02:42 |
| exarkun | it's five so far, that seems excessive | 02:42 |
| exarkun | I can't seem to bring myself to try isolating the most recent | 02:43 |
| spiv | Oh, hmm. | 03:00 |
| spiv | exarkun: oh! | 03:01 |
| spiv | exarkun: I'm silly; it would be because "bzr merge -r 2..16" doesn't include the changes from 1->2. | 03:02 |
| exarkun | :( | 03:02 |
| exarkun | That explains some issues, I guess | 03:02 |
| spiv | exarkun: Usually the way you'd express "merge up to point X" is by simply "bzr merge -r X" | 03:03 |
| spiv | I think we could give better feedback in this case, perhaps. | 03:04 |
| exarkun | This whole thing I'm doing has problems. But on the other hand, I'm done now, so I hopefully I don't have to care. | 03:04 |
| spiv | Like explicitly announcing if the merge is a cherrypick. | 03:04 |
| lifeless | mmm sadness | 03:11 |
| lifeless | bzr-builddeb has no direct merge-upstream tests | 03:11 |
| spiv | Hmm, I think I may have stumbled upon a reason why 'get_stream_for_missing_keys' is needed even for initial fetches which. | 07:07 |
| spiv | ...which should be able to easily enough send a complete stream. | 07:07 |
| lifeless | ghosts? | 07:08 |
| spiv | lifeless: overly aggressive calculation of "uninteresting" chk root nodes. The logic doesn't seem to allow for the possibility that two different inventories might refer to the same chk_maps. | 07:20 |
| spiv | Still digging into the details. | 07:20 |
| vila | hi all | 07:59 |
| aidalgol | I'm using the development version of a project that uses Bazaar. Instead of pulling updates from the repository on the Internet onto both my laptop and desktop, I want to pull them from the Internet to only my dekstop and then push them to my laptop. How do I do this? | 08:19 |
| aidalgol | (Without using shared directories.) | 08:19 |
| lifeless | on your desktop run bzr pull | 08:19 |
| aidalgol | Right, figured that much out. :) | 08:19 |
| lifeless | then bzr push bzr+ssh://laptop/path/to/branch | 08:19 |
| aidalgol | Is there a way to not use SSH? | 08:20 |
| lifeless | finally on the laptop run 'bzr update' if there is a tree where the branch is (if there is the push will alert you to that fact) | 08:20 |
| lifeless | btw, shared repositories are totaly unrelated to your request; can I ask why you said you didn't want to use them? | 08:20 |
| aidalgol | Shared? | 08:20 |
| aidalgol | I haven't heard of that. | 08:20 |
| lifeless | ah sorry | 08:21 |
| lifeless | I misread, you said 'shared directories'. My bad - ignore my question. | 08:21 |
| lifeless | uhm yes, you can use any protocol bzr supports. | 08:21 |
| aidalgol | lol OK :) | 08:21 |
| lifeless | But ssh is best. Is it a problem for you? | 08:21 |
| aidalgol | I don't want to set up ssh on my system. | 08:21 |
| aidalgol | I only do this kind of thing at home on a fairly secure LAN. | 08:22 |
| aidalgol | So, for syncing my files, I've been using Unison's unsecure protocol. | 08:22 |
| aidalgol | Because I have good physical security. | 08:22 |
| lifeless | its not about security | 08:23 |
| lifeless | ssh runs the bzr server at the far end so its very very effiicent | 08:23 |
| aidalgol | I'll take a look at the list of protocols bzr supports. | 08:23 |
| maxb | In this case, the recommendation to use ssh is not about security, but because it's an excellent way of making two machines talk to each other | 08:24 |
| maxb | Unless you're stuck running Windows? | 08:24 |
| aidalgol | Convenience is more important than efficiency for me. | 08:25 |
| aidalgol | maxb: No, thank heavens. | 08:25 |
| maxb | Setting up ssh on Linux *is* convenient | 08:27 |
| maxb | Because every distro provides it packaged | 08:27 |
| aidalgol | bzr serve looks like a good option. | 08:27 |
| aidalgol | I agree it's convenient, but I'd rather not run a system daemon if I don't have to. | 08:28 |
| aidalgol | What's the LOCATION syntax? | 08:41 |
| aidalgol | I ran bzr serve --port=X on my desktop. | 08:41 |
| aidalgol | Not I need to run bzr pull [something] on my laptop, right? | 08:42 |
| mwhudson | hmm | 09:13 |
| mwhudson | i seem to be getting bzr bugmail now | 09:13 |
| lifeless | \o/ ? | 09:13 |
| mwhudson | You received this bug notification because you are a member of bzr-qa, which is subscribed to Bazaar. | 09:13 |
| lifeless | oh right | 09:13 |
| lifeless | thats unexpected ;) | 09:13 |
| lifeless | it might be because you're in bazaar-canonical. | 09:13 |
| lifeless | I think the group layout isn't quite right. | 09:13 |
| mwhudson | err | 09:14 |
| lifeless | are you in bazaar-canonical ? | 09:14 |
| mwhudson | i'm in ~bzr, indirectly, which owns ~bzr-qa, but i'm not _in_ ~bzr-qa | 09:14 |
| lifeless | oh | 09:14 |
| mwhudson | lifeless: yeah | 09:14 |
| mwhudson | so i don't know why i'm getting these emails | 09:14 |
| lifeless | right, so poolie rearranged things this morning | 09:14 |
| * mwhudson looks at some headers | 09:15 | |
| lifeless | ~bzr is meant to give you that bugmail anyway | 09:15 |
| mwhudson | i guess i'll see how much mail this results in before complaining further :) | 09:18 |
| lifeless | I'll try to look tomorrow | 09:19 |
| lifeless | feel free to drop me a mail your midday if its driving you batty ;) | 09:20 |
| * lifeless changes a few things, just because | 09:23 | |
| hayalci | Hi, I can't use recorded passwords with bzr-svn | 09:27 |
| hayalci | I tried authentication.conf | 09:27 |
| hayalci | and tried some settings, but bzr either asks for password, or gives the error message : | 09:28 |
| vila | hayalci: svn handles its own cache which bzr-svn is able to use | 09:28 |
| hayalci | bzr: ERROR: Permission denied: ".": OPTIONS of 'http://...." : authorization failed: Could not authenticate to server: rejected Basic challenge | 09:28 |
| vila | hayalci: do one successful auth with svn and things should be fine | 09:29 |
| hayalci | vila: thanks for the info | 09:31 |
| hayalci | that worked with a tweak. I am using KDE, and kwallet for password storage. While svn can store and access passwords in kwallet, bzr-svn couldn't | 09:32 |
| hayalci | after forcing svn to not use kwallet, and storing password in a file, bzr-svn could access the svn repo | 09:33 |
| hayalci | Actually, that's ok with me. That password is not important. | 09:33 |
| vila | hayalci: may be worth filing a wishlist bug against bzr-svn for the record | 09:38 |
| poolie_ | spiv, hi? | 09:57 |
| poolie_ | does https://bugs.edge.launchpad.net/bzr/+bug/601798 ring any bells for you? | 09:59 |
| ubot5 | Launchpad bug 601798 in Bazaar "'NoneType' object has no attribute 'get_config' in filename_matches_config executing bzr switch (dup-of: 559436)" [Undecided,New] | 09:59 |
| ubot5 | Launchpad bug 559436 in Bazaar 2.1 "AttributeError: 'NoneType' object has no attribute 'get_config' (affected: 7, heat: 31)" [High,Fix released] | 09:59 |
| * spiv looks | 10:00 | |
| spiv | poolie_: that's weird, it looks like 559436, but that was fixed in exactly 2.1.1, which is what they are running | 10:02 |
| spiv | Or at least, that's when NEWS claims it was fixed... | 10:03 |
| spiv | The NEWS file in -rtag:bzr-2.1.1 agrees, though. | 10:04 |
| poolie_ | sorry i was offline, more maverick/hardware problems :-( | 10:05 |
| lifeless | poolie_: what did they say ? | 10:06 |
| spiv | poolie_: ouch :( | 10:09 |
| spiv | poolie_: I left a comment on the bug with my thoughts | 10:09 |
| poolie_ | thanks | 10:11 |
| poolie_ | lifeless, it's working now | 10:11 |
| lifeless | poolie_: \o/ | 10:11 |
| poolie_ | burned a cd at low speed, booted from that, reset bios back to ahci | 10:11 |
| poolie_ | despite appearances it can boot from cds in ahci mode, they just appear as a different device | 10:11 |
| lifeless | glub | 10:11 |
| lifeless | ah | 10:12 |
| lifeless | vila: tell me about this config lock patch | 10:14 |
| lifeless | vila: where do you think its up to, is it ready, are you happy with it? | 10:14 |
| vila | lifeless: given the discussions I'm more inclined to wait for the sprint to discuss it, there so many things to do with configs that I didn't even mention in the patch that I think we need to talk about | 10:15 |
| vila | lifeless: the patch itself... | 10:15 |
| vila | well, it needs at least to be split (once or several times) to make my intents and constraints clearer | 10:16 |
| vila | using a transport for example was required to use lockdir but also a good thing in itself if we want all IOs to go thru a transport object | 10:17 |
| vila | _get_parser() is currently abused by tests as a way to create a config file and we need something better | 10:17 |
| lifeless | whats wrong with that ? | 10:18 |
| lifeless | by which I mean | 10:18 |
| lifeless | what problems does that cause | 10:18 |
| vila | overall, far too many things stuffed in this patch were not related to the bugfix itself | 10:18 |
| vila | _get_parser() ? Well, in some cases if the config is not empty, supposing that it came from a file make things simpler | 10:19 |
| vila | I don't remember the exact context/failing test, but at one point it was obvious/knee-jerk that this wasn't worth maintaining (I tried to nevertheless) | 10:20 |
| vila | I think it was related to the ability to use _parser.reload() which itself requires a file name rather than rebuilding a configobj object | 10:21 |
| vila | rebuilding the configobj object helped with failures with the intrumented one (hence the addition of reload() there) | 10:22 |
| vila | and this last addition was a bit silly since its implementation is a no-op | 10:22 |
| vila | kind of: ok this bug fix is simple: oh wait, I need a small refactoring here, oh wait, unrelated tests are failing, one more bit of refactoring, oh wait, etc | 10:23 |
| poolie_ | hi there vila | 11:16 |
| poolie_ | and good night | 11:16 |
| poolie_ | vila, would it make any sense to send an rfc email about config locking just to summarize the progress at a higher level than an mp? | 11:16 |
| vila | poolie_: it would, I have a list of other points I haven't mentioned so far regarding config | 11:18 |
| lifeless | the python-ideas thread on their use of hg makes me sad | 11:23 |
| lifeless | consensus emerging seems to be to not accept branches from non-committers. | 11:23 |
| lifeless | ! | 11:23 |
| poolie_ | really | 11:25 |
| lifeless | really | 11:25 |
| lifeless | bai | 11:25 |
| mwhudson | lifeless: ! | 11:27 |
| lifeless | yeah | 11:28 |
| mwhudson | doesn't that almost completely miss the point? | 11:28 |
| lifeless | 'pulling all the patches generates too much noise people won't review, so people should make a single patch and put that in the bug tracker'. | 11:28 |
| lifeless | mwhudson: you'd think so. | 11:28 |
| mwhudson | err | 11:28 |
| mwhudson | does hg not have merge --preview? | 11:28 |
| mwhudson | or some moral equivalent | 11:28 |
| jamesh | I think there are lots of people who still want linear histories | 11:40 |
| jamesh | even though they're using DVCS | 11:40 |
| jamesh | they consider the extra non-linear history to be noise rather than valuable information | 11:40 |
| lifeless | yes | 11:42 |
| lifeless | add to that | 11:42 |
| lifeless | hg doesn't do nonlinear history - it logs all left-aligned, all patches show. | 11:42 |
| jamesh | they should fix that | 11:45 |
| lifeless | gnight | 12:53 |
| knielsen | Hi, I'm looking for docs on bzr formats (bzr 2.1.1), `bzr info` says format: rich-root-pack and `bzr checkout` says "on-the-fly conversion from RepositoryFormat2a() to RepositoryFormatKnitPack4()". But I didn't find info about those formats in docs (http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/formats-help.html) | 14:33 |
| knielsen | anywhere I can find info on that/those formats? | 14:33 |
| spiv | knielsen: 'RepositoryFormat2a()' is the internal name for the '2a' format | 14:36 |
| spiv | knielsen: and 'RepositoryFormat2a()' is the internal name for the 'rich-root-pack' format | 14:36 |
| knielsen | spiv: right, so RepositoryFormatKnitPack4 and rich-root-pack are two different names for the same format? | 14:37 |
| spiv | Oops, copy-and-paste screwup | 14:37 |
| spiv | Right, 'RepositoryFormatKnitPack4' is the same format as 'rich-root-pack' | 14:38 |
| spiv | 'rich-root-pack' is quite old, it dates back to bzr 1.0 | 14:38 |
| knielsen | spiv: right, so the question is, where can I read about that rick-root-pack format? | 14:38 |
| knielsen | ok, yes I suspected that it was old, that's the main info I need, thanks | 14:38 |
| spiv | Basically you should be using '2a' for everything. | 14:38 |
| spiv | Please file a bug about the documentation being a bit lacking there. | 14:39 |
| knielsen | ok, will do | 14:40 |
| spiv | Thanks! | 14:40 |
| * spiv goes to bed | 14:40 | |
| parthm | knielsen: there is bug #567064 about improving the message. | 14:42 |
| ubot5 | Launchpad bug 567064 in Bazaar "message about on-the-fly conversion is unclear (affected: 2, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/567064 | 14:42 |
| spiv | parthm: that's a related but different bug, I think | 14:45 |
| parthm | spiv: yes. i suppose it could avoid using internal names + give a suggestion of upgrading to 2a. | 14:47 |
| GaryvdM | Hi mgz | 15:08 |
| knielsen | filed as https://bugs.launchpad.net/bzr/+bug/601912 | 15:14 |
| ubot5 | Launchpad bug 601912 in Bazaar "Missing documentation about repo format rich-root-pack (internal nameRepositoryFormatKnitPack4) (affected: 1, heat: 6)" [Undecided,New] | 15:14 |
| rioch | I've written an app which I now want to use bazaar to do version control. If I do bzr init <project> will it pick up everything that is already there, or should I create it blank and then add the files and commit them? | 16:26 |
| GaryvdM | rioch: You can do bzr init in you existing dir. You will then need to do bzr add and bzr commit. | 16:29 |
| rioch | GaryvdM: thanks :) | 16:31 |
| rioch | I created a branch with bzr init, then decided to start again and deleted the project, copied the files across from a backup, and now when I do bzr init I get this error: bzr: ERROR: Already a branch: ".". | 16:52 |
| maxb | Sounds like you deleted all the visible contents of a directory, but kept the .bzr subdir | 16:55 |
| rioch | maxb: I thought that too, but that's gone as well. | 16:56 |
| maxb | That error message is a clear indication there is a .bzr in the location you are trying to init | 16:57 |
| rioch | maxb: well, I emptied my trash and now it works, so maybe it was aware I deleted it? | 16:58 |
| === abentley is now known as abentley-lunch | ||
| === abentley-lunch is now known as abentley- | ||
| === abentley- is now known as abentley | ||
| lifeless | morning | 20:17 |
| GaryvdM | Hi lifeless | 20:25 |
| mgz | hey all. | 20:27 |
| GaryvdM | Hi mgz | 20:27 |
| GaryvdM | mgz: re py2exe extraction - It work for just bzr, but not with plugins. I've not debug much... | 20:28 |
| mgz | you also have a slight problem with both me and you changing the bzr setup.py and those new bits not being copied across yet | 20:29 |
| mgz | easy to fix though. | 20:29 |
| GaryvdM | I'm working on been able to specify revision specs. | 20:29 |
| lifeless | \o/ | 20:29 |
| GaryvdM | mgz: Yes - I'll fix that when I get it to work. :-) | 20:29 |
| mgz | I've just been tracking down the double-auth thing from the other day, it's a mess of abstractions. | 20:34 |
| mgz | basic issue is the http connection creation is deeper than the try-smart-protocol-then-dumb, so if the first bit fails it throws away everything it has set up so far including the auth information | 20:35 |
| mgz | also it doesn't store the credentials unless it actually gets a 200, so 401-404 will raise without recording that it actually got past the auth correctly. | 20:36 |
| lifeless | \o/ | 20:36 |
| mgz | so, it's what I expected, which I might be able to fix, plus a bigger issue in bzrdir that I have no idea for. | 20:37 |
| lifeless | whats the bigger issue? | 20:38 |
| mgz | well, when it's probing for formats, it has no concept of an http connection | 20:43 |
| lifeless | yes | 20:43 |
| mgz | so I don't see any clear way of preserving the auth credentials, that are stored on the connection, across two seperate probes | 20:44 |
| mgz | except some global store, which is sort of what the text file on disk is. | 20:44 |
| lifeless | the probes don't make a new transport object | 20:44 |
| iocor | how do I find out what changed between bzr version 1.18.1 and 2.1.1 | 20:45 |
| mgz | but the auth stuff is on the request, not the transport | 20:45 |
| lifeless | iocor: read the NEWS file for 2.1.1 | 20:46 |
| iocor | lifeless: is that online anywhere? | 20:46 |
| GaryvdM | iocor: http://doc.bazaar.canonical.com/latest/en/release-notes/index.html | 20:47 |
| lifeless | sure | 20:48 |
| mgz | ah, or is it... | 20:48 |
| lifeless | or http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/head:/annotate/NEWS | 20:48 |
| lifeless | I think thats the url anyway, :) | 20:48 |
| GaryvdM | http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/annotate/head:/NEWS | 20:50 |
| GaryvdM | But it breaks because annotate takes to long. | 20:50 |
| mgz | 's on ConnectedTransport._shared_connection which I guess I'll poke and see if it survives | 20:50 |
| mgz | ...does seem to have the same id | 20:53 |
| lifeless | mgz: thats a feature | 20:54 |
| lifeless | tcp is slow. | 20:54 |
| lifeless | reuse is good. | 20:54 |
| mgz | goodie, so, it's cleverer than I feared | 20:54 |
| lifeless | I like to think of it as simpler. | 20:55 |
| lifeless | :P | 20:55 |
| mgz | if it was simple, wouldn't have taken this long to find out ;) | 20:55 |
| mgz | ...now I have to look into writing http tests that don't leak horribly | 21:12 |
| lifeless | \o/ | 21:12 |
| mgz | semi-related, if you get the username or password wrong is it expected to get: | 21:14 |
| mgz | bzr: ERROR: Invalid http response for http://float.endofinternet.org/bazaar/testauth/.bzr/branch-format: Unable to handle http code 401: Authorization Required | 21:14 |
| mgz | it seems... unhelpful. | 21:15 |
| lifeless | mmm, I wouldn't say expected. | 21:15 |
| lifeless | if its a single line then its just the regular exception-printout | 21:15 |
| iocor | i've got some pythoncode that uses bzrlib, and we're attempting to make commits, and for some reason we're unable to make updates to files | 21:26 |
| iocor | anyone got any ideas why? | 21:26 |
| lifeless | paste the code | 21:26 |
| lifeless | I have a few minutes, I'll have a peek for you | 21:26 |
| iocor | thanks man | 21:26 |
| iocor | http://dpaste.com/214900/ | 21:27 |
| iocor | this is the commit function | 21:27 |
| iocor | http://dpaste.com/214902/ class initialiser | 21:28 |
| iocor | http://dpaste.com/214903/ | 21:28 |
| iocor | function to update files | 21:28 |
| lifeless | ok, so you don't have a tree on disk ? | 21:29 |
| iocor | calling commit is meant to write the tree out to disk | 21:30 |
| lifeless | uhm | 21:30 |
| lifeless | some terms | 21:30 |
| GaryvdM | iocor: small nit pick: line 16 of http://dpaste.com/214900/ should not be necessary. | 21:30 |
| GaryvdM | "self.b = bzrlib.branch.Branch.open(self.b.base)" | 21:31 |
| lifeless | iocor: a branch is a line of development | 21:31 |
| lifeless | iocor: a Tree is a single collection of the users files, either editable (a WorkingTree) or immutable (a RevisionTree) | 21:31 |
| lifeless | iocor: a 'commit' takes a Tree and puts it into the branch's Repository, and updates the branch last_revision. | 21:32 |
| lifeless | iocor: so if you have a WorkingTree, to commit you just do 'tree.commit()' | 21:32 |
| iocor | lifeless: ok, so I'm looking to take in some changes, apply them to the current branch to get a new branch | 21:32 |
| iocor | or | 21:33 |
| iocor | an update to the branch | 21:33 |
| iocor | it's very simple linear style committing | 21:33 |
| lifeless | iocor: your code won't work properly prior to 1.18 anyway, I would just not support it. | 21:34 |
| iocor | also, I'm using bzr 2.1.1 but the branch isn't getting updated | 21:34 |
| lifeless | not your fault, just bzrlib internals. | 21:34 |
| lifeless | what is in _update_tree ? | 21:34 |
| iocor | and the #as of 1.18 thing isn't executed | 21:34 |
| iocor | self.PrevTree = self.TransPrev.get_preview_tree() | 21:34 |
| iocor | one line | 21:34 |
| iocor | also, I inherited this system and it isn't particularly well documented or functional on anything other than bzr 1.18.1 | 21:35 |
| iocor | at all | 21:35 |
| lifeless | uhm | 21:35 |
| lifeless | so that one line | 21:35 |
| lifeless | is discarding all the data you've got | 21:35 |
| lifeless | to work with PreviewTree there is a strict sequence you have to follow | 21:36 |
| lifeless | 1) make a Transformpreview | 21:36 |
| iocor | (happens at class init) | 21:36 |
| lifeless | 2) call methods on it to create/move/delete files | 21:36 |
| iocor | lifeless: I note that creating files and deleting files works just fine | 21:36 |
| lifeless | 3) call get_preview_tree() | 21:36 |
| iocor | modifying their contents doesn't | 21:36 |
| iocor | ohic | 21:37 |
| lifeless | 4) call that-tree.commit() | 21:37 |
| iocor | so in fact, this is pretty broken? | 21:37 |
| iocor | aaaaaaaaaaaaaaaaaaaaah | 21:37 |
| lifeless | I may be wrong | 21:37 |
| lifeless | but looking at _PreviewTree.__init__ | 21:37 |
| iocor | lifeless: is this going to be massively painful to fix? | 21:37 |
| lifeless | I don't see why | 21:37 |
| lifeless | just don't call _update_tree where you are | 21:38 |
| iocor | ok | 21:38 |
| lifeless | and don't call self.PrevTree = self.TransPrev.get_preview_tree() in init | 21:38 |
| lifeless | instead, do that line in your commit | 21:38 |
| iocor | I have a merge function also | 21:39 |
| iocor | should I call it there? | 21:39 |
| lifeless | actually | 21:40 |
| lifeless | I may be wrong about risk of making new trees | 21:40 |
| lifeless | jus tshove a self.PrevTree = self.TransPrev.get_preview_tree() call into your commit function | 21:40 |
| iocor | and don't remove the updatetree calls elsewhere? | 21:42 |
| lifeless | yeah | 21:42 |
| lifeless | see how that works | 21:42 |
| lifeless | can I ask, what this is for? | 21:42 |
| iocor | to cut a long story short, an online ide for python that controls robots and has to be deployed in an environment where we can't install software, so it's web-based | 21:42 |
| * lifeless whistles | 21:43 | |
| lifeless | thats pretty cool | 21:43 |
| iocor | :D | 21:43 |
| iocor | lifeless: http://studentrobotics.org | 21:44 |
| iocor | :O | 21:44 |
| iocor | :OI | 21:44 |
| iocor | :O | 21:44 |
| iocor | I think | 21:44 |
| iocor | you just fixed it | 21:44 |
| * iocor waits for the tests to finish | 21:45 | |
| iocor | oh my god | 21:45 |
| iocor | lifeless: I owe you all my internets for a wek | 21:45 |
| lifeless | glad I could help | 21:45 |
| iocor | :D:D:D:D | 21:49 |
| GaryvdM | Bla - just realised, the feature I've been planing for the last hour, was already implement by Ian, just not in use : | 21:56 |
| GaryvdM | :-) | 21:56 |
| lifeless | :P | 21:56 |
| fullermd | Superrelativistic implementation FTW. | 22:00 |
| lifeless | nah | 22:03 |
| lifeless | guido's time machine | 22:03 |
| lifeless | dude just can't seem to keep it locked up | 22:04 |
| fullermd | Well, it's a time machine. If you forget to lock it up ONCE, it's the same as never locking it up. | 22:05 |
| GaryvdM | Bla - SEACOM down for 6-8 days: http://www.seacom.mu/news/news_details.asp?iID=143 | 22:11 |
| GaryvdM | I nice reminder of how slow SAT3 is. | 22:12 |
| === jfroy_ is now known as jfroy | ||
| GaryvdM | For Ian's new window installer build script, he added the ability to define more than one series. | 22:45 |
| GaryvdM | See http://bazaar.launchpad.net/~bzr/bzr-windows-installers/trunk/annotate/head:/bazaar_releases.py | 22:45 |
| GaryvdM | For 2.2 I need to specify defined revisions. | 22:46 |
| GaryvdM | But for .dev, I want it to use the latest version for each plugin. | 22:46 |
| GaryvdM | You can specify a revision spec per Project/Plugin object. | 22:47 |
| GaryvdM | But the way that is currently defined, you can only define the 2 series to have the same plugin versions, as they are shared. | 22:49 |
| GaryvdM | I'm not sure how to change this so that I can have different plugin versions, but not have to repeat plugin details, and be syntactical clean. | 22:50 |
| GaryvdM | Maybe add a copy_write method, define the plugins globally, and copy_write with the specific revision for the series. | 22:52 |
| GaryvdM | Any better ideas? | 22:53 |
| poolie | hi GaryvdM | 23:13 |
| poolie | hi jam | 23:13 |
| GaryvdM | Hi poolie | 23:13 |
| mgz | hm, got another mail with team membership overriding direct subscription for X-Launchpad-Message-Rationale and bottom note | 23:14 |
| lifeless | heh | 23:14 |
| lifeless | hi poolie | 23:14 |
| mgz | as I completely failed to branch launchpad, guess I better just file a bug | 23:15 |
| lifeless | poolie: I was out by 2 hours on my thing this morning :O | 23:15 |
| poolie | in which direction | 23:19 |
| lifeless | just finished | 23:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!