| * thumper out for lunch | 00:07 | |
| thumper | damn | 00:07 |
|---|---|---|
| thumper | wrong channel | 00:07 |
| lifeless | jelmer: is there still a gtk applet for bzr? | 00:09 |
| lifeless | nvm | 00:10 |
| jam | lifeless: With the new remap code (for map and unmap) I'm now able to get farther in converting revisions from bzr.dev to chk inventory | 00:19 |
| jam | Last time it failed around 12.1k revs, I'm now at 14.8k | 00:19 |
| jam | at ~1200s | 00:20 |
| jam | so it will take maybe an hour to finish | 00:20 |
| jam | This is the info for a quick conversion of bzrtools: | 00:25 |
| jam | http://paste.ubuntu.com/79555/ | 00:25 |
| lifeless | jam: cool | 00:31 |
| jml | lifeless: hello | 00:32 |
| jml | lifeless: you pinged me yesterday | 00:33 |
| lifeless | yes, about testresources foo I think | 00:33 |
| jml | lifeless: want to talk about it now? | 00:34 |
| lifeless | nope | 00:34 |
| lifeless | got to leave real sooon | 00:34 |
| jml | lifeless: np | 00:34 |
| jam | lifeless: so it took a total of 39m51s to convert all of bzr.dev into development4 | 00:56 |
| jam | I'm doing the repo-details analysis now | 00:56 |
| lifeless | jam: thats pretty good | 00:57 |
| jam | Also, my first attempt at a quick hack to get knit delta compression failed. I'm not 100% sure why, but I was setting a parent, and it *wasn't* doing a delta. | 00:57 |
| jam | I'll also note that I get a *lot* of collisions with different details | 00:57 |
| jam | I don't quite understand that | 00:57 |
| LaserJock | do people here regularly use multi-pull? | 00:58 |
| LaserJock | I tried using -v (for verbose) and the output seems just as terse | 00:59 |
| jelmer | lifeless, jam: I am allowed to change the inventory returned by Repository.get_inventory(), right? | 01:03 |
| jam | Legal? probably, recommended? | 01:03 |
| lifeless | jelmer: no, and split-inventory will not let you | 01:04 |
| jam | I believe in the chk code we are adding an Inventory.create_by_apply_delta() function, which would be the recommended way to do it | 01:04 |
| lifeless | jelmer: why do you want to? | 01:04 |
| jelmer | just curious, it would be a cheap optimization right now | 01:05 |
| lifeless | jelmer: things could behave badly with aliasing | 01:05 |
| jelmer | lifeless, bzr.dev doesnt' have a Repository.add_inventory_delta() yet, btw | 01:06 |
| lifeless | ah | 01:06 |
| lifeless | its been reviewed, mayhave a name change and so on | 01:06 |
| lifeless | gotta go, ciao | 01:07 |
| jml | ciao | 01:08 |
| awmcclain | Will installing Pyrex make 1.10 run much faster? | 01:08 |
| jam | awmcclain: are you running from an installed bzr, or from source? | 01:09 |
| awmcclain | jam: easy_install -U bzr | 01:09 |
| jam | hmm... I don't know for sure what that gets as a package. | 01:10 |
| jam | I think it gets the released tarball | 01:10 |
| jam | which means you should only need gcc | 01:10 |
| jam | and not Pyrex | 01:10 |
| awmcclain | "The python package 'Pyrex' is not available. If the .c files are available, | 01:10 |
| awmcclain | they will be built, but modifying the .pyx files will not rebuild them." | 01:10 |
| jam | that warning seems fine | 01:10 |
| lifeless | doesn't bzr --version list the optimisers? | 01:10 |
| * lifeless goes | 01:10 | |
| jam | you are watching out for the "could not build XXX using the slower python versions instead" | 01:10 |
| awmcclain | Right, since I'm not modifying the source. | 01:10 |
| jam | lifeless: you may be interested in: http://paste.ubuntu.com/79569/ | 01:11 |
| jam | if you haven't gone yet | 01:11 |
| jam | it is the repo details for chk w/ bzr.dev | 01:11 |
| === kiko is now known as kiko-zzz | ||
| Peng_ | lifeless: Cool. Is it possible to upgrade the indexes or do you have to "rm -rf"/"bzr index"? | 01:43 |
| rockstar | jelmer, still around? | 01:48 |
| jelmer | rockstar, yep | 01:49 |
| rockstar | jelmer, getting a test failure in a fresh subvertpy branch | 01:49 |
| jelmer | if there's a single test failure, that's a known issue | 01:50 |
| rockstar | jelmer, http://pastebin.ubuntu.com/79582/ | 01:50 |
| jelmer | the failure is known, the error isn't | 01:50 |
| rockstar | That's running nosetest on the build | 01:50 |
| rockstar | I did `python setup.py build && cd build/build-* && nosetests` | 01:52 |
| rockstar | make check fails in the same way. | 01:52 |
| jelmer | I moved some things around but forgot to run the tests | 01:52 |
| jelmer | I'm pushing a fix | 01:53 |
| jelmer | thanks for letting me know :-) | 01:53 |
| rockstar | jelmer, sure. | 01:53 |
| jelmer | the other issue is known, and is caused by the fact that subvertpy can't rely on bzrlib.urlutils | 01:53 |
| rockstar | jelmer, why's that? | 01:53 |
| jelmer | it's otherwise independent of bzr, and it would make adoption by e.g. the basie folks harder | 01:54 |
| rockstar | jelmer, basically, I'm back evaluating using subvertpy in cscvs, and, in effect, the launchpad import system | 01:54 |
| jelmer | ah, cool | 01:54 |
| rockstar | jelmer, do you think it could be used in production? | 01:55 |
| jelmer | subvertpy? Yeah, I think so. The bzr-svn tests exercise it pretty well and I haven't seen any other problems either | 01:55 |
| jelmer | the server stuff is still incomplete and unstable, but you won't be using that anyway I presume | 01:56 |
| rockstar | jelmer, nope. | 01:56 |
| rockstar | We want to be able to roundtrip commits as well. | 01:57 |
| jelmer | if you want to roundtrip commits, it's probably more worthwile to look into bzr-svn | 01:57 |
| rockstar | jelmer, did you push the fix to trunk | 01:59 |
| jelmer | rockstar, yep | 02:00 |
| rockstar | I'm on rev 1971, and it's telling me there are no revisions to pull | 02:02 |
| rockstar | :/ | 02:02 |
| jelmer | it's a mirrorred branch, in case you're pulling from lp | 02:02 |
| rockstar | jelmer, ah, that makes sense. | 02:02 |
| jelmer | lifeless: looks like by using inventory deltas I can actually avoid that Inventory copy | 02:21 |
| jelmer | lifeless, that would save another 33 % \o/ | 02:22 |
| jelmer | lifeless, still there? | 02:28 |
| jelmer | abentley1, ? | 02:28 |
| jelmer | or somebody else familiar with inventory deltas? | 02:29 |
| abentley1 | jelmer: hi. | 02:29 |
| jelmer | abentley1, hi! | 02:30 |
| jelmer | abentley1, Is it possible to recursively delete entries using a single inventory delta entry, or do I need to delete all ancestors separately? | 02:30 |
| abentley1 | jelmer: You're supposed to list all the deletions. | 02:31 |
| jelmer | abentley1: Thanks. | 02:31 |
| abentley1 | jelmer: I think deleting the parent works with current implementations, but it's not guaranteed. | 02:31 |
| jelmer | abentley1: Also, is it valid to have two changes for a single ie? | 02:32 |
| jelmer | file_id I mean | 02:33 |
| abentley1 | jelmer: No, the ie describes the target state. | 02:33 |
| abentley1 | So if you had two, and they differed, one would be wrong. | 02:33 |
| === abentley1 is now known as abentley | ||
| jelmer | right, that makes sense. Thanks again. | 02:34 |
| abentley | jelmer: np | 02:34 |
| * jelmer regrets not trying out inventory deltas earlier. I thought they would be complex to deal with in bzr-svn for some reason, but it's actually improving the code in various places | 02:35 | |
| AfC | It's always a treat when you discover {that,} someone else's code {,that} can make your life better. | 02:49 |
| jelmer | abentley, is it valid to remove a file_id first and then re-add it again at a different path? | 02:54 |
| abentley | jelmer: No, a file id should occur at most once in a given delta. | 02:56 |
| abentley | jelmer: Removing the file_id is not needed if you're moving the file. | 02:56 |
| abentley | jelmer: There is no "before" or "after" in a delta. It's ambiguous to perform two operations (deletion or moving) in the same delta. | 02:58 |
| jelmer | abentley: Ah, ok. | 02:59 |
| jelmer | I don't know beforehand which files are only removed but not added again (a rename), but I can obviously keep a set of files that are deleted and remove the ones that are also copied from that and just process the renames at the end | 03:00 |
| === jamesh__ is now known as jamesh | ||
| metajack | Any idea what "bzr: ERROR: The branch lp:poetry has no revision None." means? I've used this launchpad branch plenty in the past. All of a sudden it is being weird. | 04:29 |
| === lamont` is now known as lamont | ||
| Chaosmagi | Do u feel like your life is stuck in a rut, just going around in circles. Do u feel Spirituality left out then all u have to do is !!!!TAKE BACK REALITY!!!! www.ellis69.webs.com | 05:08 |
| Peng_ | Take back reality from who? | 05:09 |
| Peng_ | Is there something up with the mailing list? I've seen replies to several messages I haven't received. | 05:10 |
| Peng_ | In the svn-import performance thread, I see four messages. Gmane only has two. | 05:11 |
| Peng_ | The mailing list archive says there are five messages. So I guess I am missing something for some reason. | 05:12 |
| abentley | Peng_: I see 5 also. | 05:12 |
| Peng_ | So it's just me? Damn. | 05:13 |
| Peng_ | :P | 05:13 |
| abentley | Peng_: #5 is ~ 16 minutes old. | 05:13 |
| Peng_ | abentley: I'm missing the first reply from jam, not the most recent message. | 05:15 |
| AfC | Sorry for a stupid question: if using bzr-svn, does the Bazaar revno == the Subversion revision number? | 05:16 |
| AfC | (fresh branch, etc) | 05:17 |
| abentley | AfC: Not in the general case. | 05:17 |
| Peng_ | AfC: No, because svn revnos are repo-wide while bzr revnos are branch-wide. "bzr log" will show the svn revnos on revisions created with svn. | 05:19 |
| AfC | ah | 05:21 |
| AfC | Peng_: didn't know about that. Nice feature. Thanks. | 05:22 |
| Peng_ | There's also an svn revspec, so you can do e.g. "bzr cat -r svn:123 foo". | 05:22 |
| fullermd | Peng_: Taking reality back is easy. The question is, does reality want YOU back? | 05:22 |
| Peng_ | Gmane seems to have all of hte messages. | 05:29 |
| Peng_ | Hm. | 05:29 |
| AfC | Peng_: you have a blog or homepage? | 06:07 |
| Peng_ | AfC: I own a domain name, but whether you can call an almost-blank index.html a "homepage"... | 06:08 |
| AfC | Peng_: It could hardly be worse than http://audacious-media-player.org/ | 06:09 |
| Peng_ | AfC: By "almost-blank", I seriously meant "almost-blank". It's only one page, with no CSS or images or anything. :) | 06:10 |
| AfC | Fine. I won't link to you. | 06:11 |
| AfC | {shrug} just trying to be polite and attribute when due. | 06:11 |
| Peng_ | AfC: Thank you. :) I'd really rather not be linked. I just imagine the disappointment someone feels when they click a link, expecting to find something interesting, and...don't. :P | 06:13 |
| AfC | Maybe you should endeavour to be interesting, then? :) | 06:13 |
| AfC | [Tricky] | 06:14 |
| AfC | [/me notices in passing that is virtually impossible to make this conversation not make it appear condescending. Oh well] | 06:15 |
| Peng_ | Heh. I didn't take it that way. | 06:15 |
| fullermd | I tried being interesting once, but it was way too much work. I went with irreverant and misanthropic instead; it's surprisingly close to the same thing, but SO much easier. | 07:16 |
| === toytoy_ is now known as toytoy | ||
| vila | hi all | 07:43 |
| * vila had to reset its switch (first time in years, took him a while to even think about it as an explanation for losing internet connectivity :-) | 07:45 | |
| mtaylor | hey all... I was going to upgrade my launchpad branches to 1.6 but now 1.9 exists... should I just go all the way to 1.9 now? or should I hold off and just do 1.6? | 08:21 |
| fullermd | I thought I heard that LP doesn't support 1.9 yet. | 08:23 |
| mtaylor | fullermd: well then - that would be a great reason to not use it yet! | 08:26 |
| fullermd | It makes it harder anyway ;p | 08:34 |
| thekorn | hi, I've got a question about bzr rebase: did I get it right, this plugin can be used to create a new branch containing only the last ten revisions of another branch | 09:12 |
| thekorn | is there some workflow related documentation to rebase somewhere? | 09:15 |
| thekorn | ok, maybe I'm wrong with bzr rebase | 09:41 |
| thekorn | so more general question: is it possible to create a new branch of the last ten revisions of an existing branch? | 09:43 |
| luks | thekorn: you can probably branch the original branch with -r0, then merge everything from revision 0 to -9, `bzr revert --forget-merges`, `bzr commit`, `bzr replay` the rest | 09:45 |
| thekorn | luks, hmm, thanks, this looks like magic, let me try | 09:47 |
| luks | thekorn: basically the problematic part to squash everything from the start of the branch to some point into a single revision | 09:48 |
| thekorn | luks, does not seem to work, maybe I'm doing something wrong, thanks for your help anyway | 10:16 |
| yacc | jelmer, yt? | 10:35 |
| Peng_ | fwiw, he last talked 7 hours ago, so likely not | 10:36 |
| === cprov is now known as cprov-away | ||
| === bac_lunch is now known as bac | ||
| knighthawk | can someone explain the difference between merge, and pull to me? I'm not getting something. | 13:47 |
| luks | perhaps it would be better if you ask specifically what you don't understand | 13:48 |
| === kiko_ is now known as kiko | ||
| enobrev | has anyone here ever seen pack files get corrupted after a push | 14:49 |
| enobrev | ? | 14:49 |
| jelmer | yacc, hi | 14:52 |
| Tak | did anyone file a feature request to make `bzr status -S` not show conflicts in an inconsistent way? | 14:52 |
| enobrev | After a push, when I try to do anything, I get "Unrecognised container format: 'B363'". A couple of the pack files don't have their header ("Bazaar pack format 1 (introduced in 0.18)"). | 15:04 |
| enobrev | "anything" such as bzr update | 15:05 |
| knighthawk | bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. | 15:06 |
| knighthawk | but when I use the merge command I get 'Nothing to do' | 15:06 |
| LarstiQ | knighthawk: could you provide a bit more context on when this happens, what bzr status/missing say? | 15:10 |
| LarstiQ | enobrev: I've seen something like that before, don't recall off the top of my head what the situation was. | 15:11 |
| jelmer | Peng, the mailing list is not sending me everything right away either | 15:11 |
| === abadger19991 is now known as abadger1999 | ||
| === beaumonta is now known as abeaumont | ||
| enobrev | LarstiQ: you were the one to help me with it last time. I ended up killing the repo and re-pulling because adding the header manually didn't work | 15:28 |
| tigger^ | hey peeps | 15:29 |
| LarstiQ | enobrev: ah | 15:29 |
| tigger^ | bzr branch bzr+ssh://myrepo | 15:29 |
| tigger^ | bzr: ERROR: Generic bzr smart protocol error: | 15:29 |
| tigger^ | doesn't give me much to go on.. | 15:30 |
| tigger^ | Bazaar (bzr) 1.7.1 | 15:30 |
| tigger^ | -Dhpss doesn't change the output at all, which strikes me as odd | 15:30 |
| enobrev | LarstiQ, at least that's what I did last time. But just ran into the problem again this morning. I'm waiting for the developer who made the last push to log on so I can debug with him, but just wondering if anyone's seen that happen around here | 15:32 |
| LarstiQ | enobrev: this time, go the launchpad answers/bugs route | 15:32 |
| enobrev | LarstiQ, good call | 15:32 |
| * LarstiQ nods | 15:32 | |
| LarstiQ | enobrev: succes with that | 15:32 |
| * LarstiQ heads downtown | 15:32 | |
| enobrev | LarstiQ: thx | 15:33 |
| tigger^ | branching localy I got bzr: ERROR: exceptions.MemoryError: | 15:38 |
| Tak | wow - `bzr branches localrepodir` => 750MB memory usage | 15:44 |
| tigger^ | swap was disabled on the machine, fixed that, it works now | 15:46 |
| yacc | jelmer, hi ;) | 15:51 |
| jelmer | yacc, hi | 15:51 |
| yacc | jelmer, OT, technically, today #samba-technical is more appropiate ;) | 15:52 |
| knighthawk | LarstiQ, bzr status says nothing. bzr missing says I'm missing 2 revisions. | 16:02 |
| === kiko is now known as kiko-fud | ||
| jam | abentley: ping about bug #304841 | 16:10 |
| ubottu | Launchpad bug 304841 in bzr "bzr push raises RevisionNotPresent" [Critical,Triaged] https://launchpad.net/bugs/304841 | 16:10 |
| jam | When you say "as of revno 3873" is that because that is the bzr.dev you used to test it with | 16:11 |
| jam | or that is the actual revision that shows the bug versus not showing it? | 16:11 |
| abentley | jam: No, that's the version of 1.10 I tested it with. | 16:11 |
| jam | And are you talking the 1.10 branch or the bzr.dev branch | 16:11 |
| jam | ug | 16:11 |
| jam | the new "loom" command hijacked "bzr up" to mean something other than "bzr update" | 16:11 |
| abentley | jam: 1.10 rc does not exhibit the bug, because it gives the ShortReadv | 16:12 |
| jam | k, did you try bzr.dev ? | 16:12 |
| abentley | jam: bzr.dev also gives the ShortReadv | 16:12 |
| jam | I don't expect anything different but just something to compare against | 16:12 |
| jam | hm... k | 16:12 |
| jam | I guess Martin didn't get the revert into bzr.dev yet | 16:12 |
| abentley | jam: Right. | 16:13 |
| abentley | jam: It's possible that the waste you're seeing in packs was introduced by Martin's stacking fix in 1.10. That creates a fulltext if the basis text isn't available. | 16:22 |
| abentley | jam: (but the basis text may arrive later in the stream). | 16:23 |
| jam | abentley: I don't think it would "go away" during autopack | 16:24 |
| jam | Also, this is only in the brisbane-core branch which doesn't have bzr.dev merged in yet | 16:24 |
| jam | I'm pretty sure it is Robert's chk work, which adds things to the repository, then determines the sha1, and if it collides, just omits one of them from the index. | 16:25 |
| jam | abentley: do you get the same failure if you don't use "--use-existing" ? | 16:33 |
| abentley | jam: No, then I get the standard error you get if you push to an existing directory. | 16:33 |
| jam | sure, I'm just wondering if there is something already wrong with the target, that is causing confusion. | 16:34 |
| jam | Do you get the failure if you push do a different branch? | 16:34 |
| jam | Certainly this is the "convert back to fulltext" code, since it is going through "get_bytes()". | 16:35 |
| jam | I can't actually see the branches, though, so I'm a bit limited in what I can poke at. | 16:35 |
| abentley | jam: I would expect so, but I'll verify. | 16:36 |
| abentley | jam: Unfortunately, these are LP branches, so providing a mirror would take significant time. You may be able to reproduce with lp:~abentley/launchpad/web-diffs | 16:39 |
| jam | abentley: I'm not on the private team that has access to lp branches | 16:39 |
| jam | so I can't reproduce at *all* | 16:39 |
| abentley | jam: That seems dumb. I've gotta run. Be back in ~ 2 hours | 16:41 |
| jam | I won't disagree... | 16:41 |
| jam | see you later | 16:41 |
| jam | It would also seem that the CombinedGraphIndex it is using doesn't have any actual indices, so there isn't any way for it to have *any* content. | 16:44 |
| jam | Seems like something is confused as to where the real content is. | 16:44 |
| jam | abentley: I can reproduce it here trying to push a stacked branch of bzr with bzr-1.10 onto launchpad. | 16:51 |
| jam | I get the same: KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex()) failure | 16:51 |
| jam | oddly it takes almost 7m before it gets there... | 16:52 |
| === kiko-fud is now known as kiko | ||
| eferraiuolo | Can someone explain what type of smart server would be the best for the following uses... | 17:19 |
| eferraiuolo | I want controlled user access to my repos, and maybe certain users have access to certain repos. This is on a server which I manage (VPS) | 17:20 |
| eferraiuolo | I would need the connection to the server to be encrypted | 17:20 |
| eferraiuolo | and possibly not want to create SSH or machine-level user accounts for people accessing the repos | 17:21 |
| eferraiuolo | ...I've been reading up on the different smart server configs and not sure which matches with what I want to do the best, any suggestions? | 17:21 |
| jam | eferraiuolo: my recommendation would be to use bzr+ssh with a single account | 17:33 |
| jam | and use different ssh keys for each user | 17:33 |
| jam | you can see some sample info in contrib/bzr_access | 17:33 |
| jam | abentley: it also seems that I can reproduce it locally, without having to connect to LP at all | 17:34 |
| eferraiuolo | okay, so you're suggesting a single user account on my machine that each user would login thru? | 17:34 |
| === Mario_ is now known as pygi | ||
| LaserJock | can running bzr upgrade after installing bzr 1.9 have some bad consequences? | 18:02 |
| LaserJock | I tried it and now bzr says there's no repository present when I try to pull/info/status, etc. | 18:03 |
| beuno | LaserJock, the default format is the same as 0.92 | 18:04 |
| beuno | so there should be no consecuences | 18:04 |
| beuno | what exactly is the error? | 18:05 |
| LaserJock | bzr: ERROR: No repository present: <path to repo> | 18:05 |
| beuno | that's very odd | 18:05 |
| beuno | are you using a shared repo? | 18:06 |
| LaserJock | no | 18:06 |
| beuno | can you check that there's a .bzr dir in there? | 18:06 |
| LaserJock | yeah, it's there :-) | 18:06 |
| james_w | LaserJock: check .bzr/repository | 18:06 |
| LaserJock | I checked that first | 18:06 |
| james_w | there's a bug where it renames .bzr/repository to repository.moved or something | 18:06 |
| LaserJock | james_w: there's a repository.backup | 18:07 |
| james_w | *then* checks | 18:07 |
| james_w | then doesn't move it back if it fails | 18:07 |
| beuno | james_w, really??? | 18:07 |
| james_w | LaserJock: yeah, move that to .bzr/repository | 18:07 |
| beuno | also, why is it upgrading? | 18:07 |
| beuno | it only should upgrade if LaserJock was on knits | 18:07 |
| LaserJock | heah, there we co | 18:07 |
| LaserJock | *go | 18:07 |
| LaserJock | ok, it works now | 18:07 |
| james_w | it happens when rich-root support is not the same | 18:07 |
| beuno | aaah | 18:07 |
| beuno | rich root is evil | 18:08 |
| LaserJock | I've had a bunch of "you should upgrade" messages | 18:08 |
| LaserJock | but I never do it | 18:08 |
| beuno | ok, so you where on knits | 18:08 |
| LaserJock | but I decided to try it on a throw-away branch as it didn't matter if it screwed it up | 18:08 |
| Peng_ | Tak: That's something with bzr-svn. | 18:08 |
| beuno | and you should probably do: bzr upgrade --rich-root-pack | 18:08 |
| Peng_ | Tak: Augh, I was scrolled really far up. Sorry. | 18:08 |
| Tak | that's ok - good to know | 18:09 |
| james_w | bug 145812 | 18:09 |
| ubottu | Launchpad bug 145812 in bzr "Upgrade can leave a broken repository (with backup)" [Low,Triaged] https://launchpad.net/bugs/145812 | 18:09 |
| LaserJock | I think almost all my branches are rich-root-pack | 18:09 |
| LaserJock | that's one of my "issues" with bzr is it seems like I'm always worrying about formats, and I don't understand them and can't keep them straight | 18:10 |
| LaserJock | is pack-0.92 the default? | 18:12 |
| beuno | yes | 18:12 |
| LaserJock | ok, I've got a couple of those | 18:13 |
| LaserJock | now if I upgrade my local branch does that slow down pulls if the branch I'm pulling from has an old format? | 18:15 |
| beuno | it does | 18:16 |
| beuno | you should upgrade the remote one as well | 18:16 |
| LaserJock | well, I never have access to the remote one | 18:16 |
| LaserJock | so i'll just leave them alone | 18:16 |
| LaserJock | I just wondered what would happen | 18:17 |
| === bac is now known as bac_lunch | ||
| jelmer | jam: hi! | 18:24 |
| jelmer | jam: You mentioned a patch to a bug I was seeing in brisbane-core | 18:24 |
| jelmer | jam: Which patch is that? | 18:24 |
| abentley | jam: glad to hear it. | 18:30 |
| kjcole | Hi. Any cure for old (0.8.2) error: Error -3 while decompressing: invalid distance too far back? | 18:43 |
| Peng_ | 0.8.2? That release is older than I am. Does anyone even remember the error codes from back then? | 18:45 |
| kjcole | The error continues, mentioning specifically the same line referred to in a launchpad bug report about memory issues: | 18:48 |
| kjcole | usr/lib/python2.4/site-packages/bzrlib/tuned_gzip.py line 103 | 18:48 |
| kjcole | (It's a very short message resulting from "bzr check" only two or three lines of error, before returning to the prompt. No long stack. | 18:49 |
| ToyKeeper | After using bzr, svn makes me :( :( | 19:00 |
| ToyKeeper | ... especially with this 11 GiB checkout full of dead branches. | 19:01 |
| === bac_lunch is now known as bac | ||
| === doko__ is now known as doko | ||
| === kiko_ is now known as kiko | ||
| pygi | jelmer, how are the duck branches going? | 19:40 |
| crisb | has anyone any suggestions for end of line translation? | 19:41 |
| jelmer | crisb, I think there's a plugin somewhere, not sure what the status of it is | 19:41 |
| jelmer | pygi, Well, they're there | 19:42 |
| jelmer | pygi, I guess it may be a good idea to put up a wiki page about them.. | 19:42 |
| crisb | jelmer: i've seen that one, but is there any plans for anything more in bzr itself? the plugin doesnt really do anything automated (but is still useful in some regards) | 19:42 |
| pygi | jelmer, I mean have you done any work to support them in core? :) | 19:42 |
| crisb | it would be nice to get some info about how other projects manage it. my current idea is to use just LF's in the repository except on files which need CRLFs (ini's etc) - is that how other people do it? | 19:44 |
| jelmer | crisb, yeah, I think most just pick one line ending mechanism | 19:44 |
| crisb | but I can see that without at least the EOL plugin, repositories could become a mishmash of different line endings | 19:44 |
| jelmer | crisb, afaik the plugin did most things automated, but perhaps it's a good topic to bring up on the mailing list again | 19:45 |
| jelmer | crisb, I know we're at least planning on supporting line ending conversions like svn does | 19:45 |
| crisb | jelmer, ah thats good to know. we're converting from PVCS which (supposedly!) has some sort of conversion between line endings and although I dont see it as a real problem, some people are quite precious about it! | 19:47 |
| jam | jelmer: the patch is in the email "CHKMap._check_remap()" | 19:48 |
| jam | abentley: I'm pretty sure I understand the cause and have an idea of a reasonable solution | 19:48 |
| jam | it was one Martin considered originally, but didn't go with | 19:48 |
| jam | namely, requesting topological ordering | 19:49 |
| jam | if we have a fallback vfs | 19:49 |
| abentley | jam: What was the cause? | 19:49 |
| jelmer | jam, Thanks, I'll give it a try | 19:49 |
| jam | If you go back to the bug I mentioned it theree. But basically, Assume you have a delta chani A-B-C-D | 19:49 |
| jam | and only A is present in the fallback | 19:49 |
| jam | if we get the delta "C" | 19:49 |
| jam | we can't extract it to a fulltext | 19:50 |
| jam | because we haven't seen B yet | 19:50 |
| jam | abentley: sound reasonable to you? | 19:50 |
| jam | The actual case I looked at was a bit more confusing than that, because it seemed like I was inserting D, and C was present, but not B. | 19:51 |
| jam | And I didn't understand how *that* could happen. | 19:51 |
| jam | But I'm going to start from there. | 19:51 |
| jam | I should have a patch shortly that you can try. | 19:51 |
| abentley | jam: I thought we were checking for the case where B wasn't present. | 19:52 |
| jam | I'm not sure what you mean by "checking for" | 19:52 |
| jam | The idea is that the stream is "unordered" | 19:53 |
| jam | so it can send "C, B, D" | 19:53 |
| abentley | jam: Only trying to get a fulltext when B was present. | 19:53 |
| jam | abentley: that might actually be why I saw the confusion | 19:53 |
| jam | Imagine we are fetching and we see C, D, B | 19:53 |
| jam | at the point we get to D, C is present | 19:53 |
| jam | but if we want to insert a fulltext, B is not | 19:54 |
| jam | (we only look at the direct parent, and not the whole chain) | 19:54 |
| jam | anyway, I'm not 100% sure | 19:54 |
| jam | But that is the best I could put together | 19:54 |
| abentley | jam: I'm pretty sure we're checking whether C is present in the fallback. | 19:54 |
| jam | (so far) | 19:54 |
| jelmer | hmm, next issue | 19:54 |
| jelmer | CHKInventory doesn't have a apply_delta() function anymore | 19:54 |
| jam | jelmer: you aren't allowed to mutate a CHKInventory | 19:54 |
| jam | you need to use "create_by_apply_delta()" | 19:54 |
| jam | which we should be adding to regular Inventory if we haven't | 19:55 |
| abentley | jelmer: But more likely, you want to use Tree.apply_delta. | 19:55 |
| jelmer | jam: Thanks, I'll look at that | 19:55 |
| jelmer | abentley, A tree would be overkill in this situation I think. I'm only constructing the inventory for internal use by bzr-svn | 19:55 |
| jam | abentley: also, Tree doesn't have apply_delta, right? You have to at least have a MutableTree (I would assume) | 19:56 |
| abentley | jelmer: Oh, I thought you were using it for commit. | 19:56 |
| abentley | jam: Interesting question. Not sure. | 19:57 |
| jam | You can't really do RevisionTree.apply_delta, IMO | 19:57 |
| abentley | jam: Well, it would probably be a bad idea, anyhow. | 20:00 |
| abentley | jam: So I'm looking at the test in knit.py near 1336. | 20:01 |
| jam | This one, right: | 20:02 |
| jam | elif ((record.storage_kind in knit_types) | 20:02 |
| jam | and (not parents | 20:02 |
| jam | or not self._fallback_vfs | 20:02 |
| jam | or not self._index.missing_keys(parents) | 20:02 |
| jam | or self.missing_keys(parents))): | 20:02 |
| jam | And the "self.missing_keys(parents)" is supposed to determine that the fallback doesn't have the parent either | 20:02 |
| abentley | jam: "or self.missing_keys(parents)" should mean that we don't attempt to construct fulltexts unless the parent is present. | 20:02 |
| jam | Right, so imagine a long change A-B-C-D-E | 20:02 |
| jam | We first get C | 20:03 |
| jam | and we see that only A is in the fallback | 20:03 |
| jam | so we go ahead and insert it as a delta. | 20:03 |
| jam | then we get D | 20:03 |
| jam | I guess that should be telling us it is okay to insert as a delta as well, because C is present... | 20:03 |
| abentley | jam: No, that would fail the missing_keys(parents) and the not _index.missing_keys(parents) | 20:04 |
| abentley | jam: Okay, I'm inclined to agree that forcing a topo sort makes sense here. | 20:05 |
| abentley | As it's much simpler. | 20:05 |
| jam | well, I can say that in my test case, forcing topological order made it "just work" | 20:05 |
| jam | but I'd like to make sure I know the problem first :) | 20:06 |
| abentley | So if we have C, we're allowed to make D a fulltext. | 20:06 |
| jam | abentley: supposedly, but we don't have B to *actually* create D as a fulltext | 20:06 |
| jam | but the problem is that I don't understand why we *want* to make D a fultext | 20:07 |
| jam | anyway, here is the "just make it work" patch: | 20:07 |
| jam | http://paste.ubuntu.com/79974/ | 20:07 |
| abentley | jam: Oh, I was trying to explain it to you because of your last comment. | 20:07 |
| jam | A whole 1 line insertion | 20:07 |
| jam | abentley: figured it out | 20:08 |
| jam | it is a merge revision | 20:08 |
| jam | and we check "self.missing_keys(parents)" | 20:08 |
| jam | not "self.missing_keys([compression_parent])" | 20:09 |
| jam | so it *does* have the direct parent | 20:09 |
| jam | but not the merged parent | 20:09 |
| jam | (I'm double checking that) | 20:09 |
| jam | ok, a bit weird, but "self._index.missing_keys(parents)" returns 1 entry and "self.missing_keys(parents)" returns None... | 20:10 |
| jam | so that means that the stacked branch has *merged* the base branch | 20:10 |
| abentley | jam: I'm testing out your patch. | 20:12 |
| jam | I'll also try a different one that isn't so heavy handed. | 20:12 |
| abentley | jam: I can confirm your patch works for me. | 20:13 |
| === jfroy|work is now known as jfroy | ||
| === jfroy is now known as jfroy|work | ||
| jam | abentley: I'm almost done with a patch that just fixes parents => compression_parent | 20:20 |
| jam | give me a sec | 20:20 |
| jelmer | jam, Yeah, "plain" Inventory doesn't have create_by_apply_delta() yet | 20:21 |
| jelmer | jam, Other than that, things at least work now - thanks | 20:21 |
| jam | abentley: try this: http://paste.ubuntu.com/79983/ | 20:22 |
| jam | jelmer: It is trivial to add create_by_apply_delta to plain inventory | 20:22 |
| jam | basically, it is just "new = self.copy(); new.apply_delta(); return new" | 20:22 |
| jelmer | right, that's what I was already doing myself, so I've just added a check for that method :-) | 20:23 |
| jam | I think we would want that actual function in the brisbane branch | 20:23 |
| jam | if you want to write it up quickly | 20:23 |
| jam | abentley: so in testing it here, either patch I proposed to you fixes the bug | 20:23 |
| abentley | jam: testing... | 20:24 |
| abentley | jam: 2nd patch works for me. | 20:26 |
| jam | ok. I feel like I have a good grasp of the problem at least. | 20:26 |
| jam | I'll probably propose both fixes | 20:26 |
| jam | as I think the topological sorting just means things go smoother in general | 20:26 |
| jam | and the other is a "correctness" fix | 20:27 |
| abentley | jam: cool. Thanks for taking point on this. | 20:27 |
| jam | np | 20:28 |
| jam | martin asked me to step up for any stacking problems while he was afk | 20:28 |
| kjcole | Any way to recover damaged "knit" files? I have an old tree that appears to be working fine... Until I try to move to a newer system (or create a branch from it). | 20:29 |
| kjcole | "bzr check" reveals a zlib.error "invalid distance too far back" related -- I think -- to an old memory bug listed on launchpad. | 20:30 |
| kjcole | (the error appears to be at /usr/lib/python2.4/site-packages/bzrlib/tuned_gzip.py line 103, which is listed in the afore-mentioned bug report.) | 20:32 |
| jelmer | jam: I'll look into providing a patch | 20:59 |
| jelmer | jam, while I'm at it it would be nice to also fix this: http://paste.ubuntu.com/79989/ | 20:59 |
| jelmer | any idea what's going wrong there? | 21:00 |
| jam | Probably a problem with an initialization path | 21:00 |
| jam | I believe Robert added an _entry_cache | 21:01 |
| jam | so that it doesn't have to read from disk and deserialize into an InventoryEntry multiple times | 21:01 |
| jam | but I don't know when _entry_cache gets written | 21:01 |
| jam | I would have thought in __init__ but maybe he did it elsewhere | 21:01 |
| jelmer | lifeless, ^ | 21:02 |
| jelmer | jam: is it useful that I test and report these issues this at all atm or are you working on fixing them anyway? | 21:08 |
| jam | ATM, I'm working on some bits lower down in the stack | 21:09 |
| jam | Also, ATM, I'm the only one working on it... :) | 21:09 |
| jam | however, I think it is good to be aware of where things are broken in the branch | 21:09 |
| jam | I believe we want to get tests passing | 21:10 |
| jam | as it makes further development easier | 21:10 |
| jelmer | k, I'll just keep reporting issues and seeing if there's (small) things I can help with then | 21:11 |
| jelmer | speaking of which.. | 21:11 |
| jelmer | InventoryDirectory.children appears to've become a lot slower | 21:11 |
| jam | jelmer: CHKInventoryDirectory.children is quite slow as it has to go out and bring in more pages, etc. | 21:12 |
| jam | Oh, and are you using "--development3" or "--development4" ? | 21:12 |
| jam | --dev4 added a "parent_id,basename => file_id" map | 21:13 |
| jam | the --dev3 code has to iterate the *entire* inventory for every .children request. | 21:13 |
| jelmer | I'm using --development4-subtree | 21:14 |
| jam | so... CHKInventory is now lazily evaluated | 21:14 |
| jam | so when you create one it doesn't read the whole inventory | 21:14 |
| jam | and only pages things in as you go to each IE.children | 21:15 |
| jam | sort of thing | 21:15 |
| jam | So building up that dict should be a lot slower than having already built it and only evaluating a dictionary | 21:15 |
| === bac is now known as bac_afk | ||
| jelmer | right, so I should try to limit inspecting the inventory to the things I actually need | 21:16 |
| jam | yep | 21:17 |
| jam | I wish "bzr shelve" worked on windows.... | 21:17 |
| jam | I keep wanting to use it :) | 21:17 |
| jelmer | yeah, I use it all the time as well :-) | 21:19 |
| jelmer | when add_inventory_delta() has to do an expensive copy of the inventory and apply the delta against that, is there some cheap way to get the resulting inventory? | 21:20 |
| jam | not sure | 21:21 |
| jam | I would guess Robert didn't optimize for that case | 21:21 |
| jam | Certainly you could just have "add_inventory_delta()" return some sort of Inventory object back to you | 21:21 |
| jelmer | but calculating that return value might be more expensive in the case of CHKInventory, no? | 21:25 |
| jam | I would imagine you could just return the CHKInventory | 21:26 |
| jam | it is really "add_inventory_*by*_delta" | 21:26 |
| jam | and I think at some point it needs to work out what the basic shape of the inventory is | 21:26 |
| jam | even if it didn't have to unpack every node. | 21:26 |
| jam | (I believe Martin mentioned wanting a slightly different name for the function.) | 21:27 |
| === bac_afk is now known as bac | ||
| jam | abentley: the plot thickens further... the simple test case doesn't work right because it sees that the parent is missing so it 'buffers' the index entry | 21:39 |
| jam | I have to figure out how to get one of the entries to not be buffered | 21:40 |
| jam | ugh | 21:40 |
| abentley | jam: Did the old shelve work with win32? It's now provided as "shelve1". | 21:41 |
| jam | abentley: yeah, the new one fails because of the WT locking issues | 21:41 |
| jam | you can't actually hold a WT.basis_tree() outside the length of a lock | 21:41 |
| jam | or you end up with 2 references to the dirstate file | 21:42 |
| jam | which both try to lock it. | 21:42 |
| jam | for now "cp" is good enough | 21:42 |
| jam | but yeah, I can probably use shelve1 | 21:42 |
| awilkins | jelmer: Can bzr-svn 0.5 push a bzr branch as a new svn branch? | 22:09 |
| jelmer | awilkins, 0.4 can already do that | 22:09 |
| awilkins | jelmer: Is there a particular syntax? | 22:09 |
| jelmer | bzr svn-push | 22:09 |
| awilkins | jelmer: I'm trying to push a branch into a zero-revision svn repo | 22:09 |
| jelmer | awilkins, you can't push to the root of the repository, as that already exists | 22:10 |
| jelmer | awilkins, but you can push to e.g. /trunk | 22:10 |
| awilkins | jelmer: waah, needs create-prefix :-P | 22:11 |
| jelmer | awilkins, ? | 22:11 |
| jelmer | awilkins, this behaviour is similar to that of bzr push | 22:11 |
| jelmer | awilkins, note that you need "bzr svn-push", not "bzr push" | 22:11 |
| awilkins | Yes, svn-push has no equivalent of the --create-prefix option of "push" | 22:13 |
| jelmer | ahh | 22:13 |
| DeviantPeer | hi all! | 22:21 |
| DeviantPeer | I'm evaluating vcs an trully enjoying bazaar. Just a quick question: is there a way to have local branches whithout using another directory? (something like git does) | 22:22 |
| DeviantPeer | and also mercurial does that kind of branching. | 22:23 |
| lifeless | Peng_: rm-rf, new formats need to reindex anyhow to get more data.'2' isn't really finished yet, I haven'tdone a release.. | 22:23 |
| DeviantPeer | I know that you can use hardlinks in order to keep the storage usage low, but it's so easy to do something like (git checkout branch.name) and start using that branch... | 22:24 |
| lifeless | DeviantPeer: yes, use a shared treeless repository to hold the branches, and then use 'bzr switch' to switch between them. | 22:26 |
| DeviantPeer | lifeless: shared treeless? hum... how? | 22:26 |
| jelmer | lifeless, create_by_apply_delta() forgets to set _entry_cache in the returned CHKInventory to {}, could that right? | 22:26 |
| DeviantPeer | lifeless: or better... where do I start to read about it? any links? | 22:27 |
| NfNitLoop | DeviantPeer: bzr init-repo . --no-trees; bzr branch <remote-branch>; cd <workspace>; bzr co --lightweight <local-branch> :) | 22:28 |
| NfNitLoop | DeviantPeer: check the bzr wiki for the "workflows" page. | 22:28 |
| DeviantPeer | NfNitLoop: ok.. gona try that. thx. | 22:28 |
| NfNitLoop | I'm pretty sure it's one of the ones listed there. (though I don't remember if 'switch' is mentioned specifically.) | 22:29 |
| lifeless | jelmer: yes, looks like thats a bug to me | 22:29 |
| DeviantPeer | NfNitLoop: already open and reading. ;) thx | 22:29 |
| NfNitLoop | DeviantPeer: unfortunately it does use another directory, but with the --no-trees options, the directory only contains .bzr metadata about the branch, and all of the changesets(?) are stored in a shared .bzr in a parent dir. | 22:31 |
| DeviantPeer | NfNitLoop: I understood that. I guess it works by harlinking to the other directory | 22:31 |
| NfNitLoop | nope, no hardlinking. | 22:32 |
| DeviantPeer | NfNitLoop: ups then.. got to read more ;) | 22:32 |
| NfNitLoop | *nod* | 22:32 |
| NfNitLoop | I vaguely remember about one dscm using hardlinking (mercurial?) and wondered how that worked on windows... | 22:33 |
| DeviantPeer | NfNitLoop: so if it doesn't use hardlinking it works even on "not so good" filesystems such as ntfs? (well yes.. at works we have to use it.. damn) | 22:33 |
| NfNitLoop | DeviantPeer: yep! | 22:34 |
| DeviantPeer | :) goody. :) | 22:34 |
| NfNitLoop | I use bzr on windows, osx and linux regularly. :p | 22:34 |
| DeviantPeer | I use wubi on the work computer... and didn't tell anyone about it. | 22:34 |
| NfNitLoop | wubi? | 22:34 |
| DeviantPeer | NfNitLoop: a small utility that installs ?ubuntu on top of windows without erasing anything from the hardisk | 22:35 |
| DeviantPeer | NfNitLoop: I think it's called wubi... I might be giving you the wrong name. | 22:36 |
| NfNitLoop | oh, cool. Installs it on the FAT partition? | 22:36 |
| NfNitLoop | I think I did something like that back when Slackware was cutting-edge. :p | 22:36 |
| DeviantPeer | anyway.. my manager is realy happy 'cause I'm 5 times more productive than my coleagues | 22:36 |
| NfNitLoop | heh. apt-get and free tools will do that. ;) | 22:36 |
| DeviantPeer | NfNitLoop: it creates a biiiiig files on the ntfs (10 or more Gib) | 22:36 |
| NfNitLoop | BTW, I found out that 'meld' works with bzr this week. | 22:37 |
| NfNitLoop | <--happy. :) | 22:37 |
| DeviantPeer | NfNitLoop: and then uses that file as a loopback devide for the linux root. | 22:37 |
| jam | abentley: you may want to review the patch I just sent in, since I don't know if anyone else can get to it. | 22:37 |
| jam | I'm done working for now. | 22:37 |
| NfNitLoop | DeviantPeer: aah. | 22:37 |
| jam | abentley: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493709CC.4090307%40arbash-meinel.com%3E | 22:37 |
| DeviantPeer | on bazaar: it's looking great. tomorow I'm going to try the "speed" of it when compared to others. | 22:38 |
| abentley | jam: thanks. | 22:39 |
| DeviantPeer | on features it rocks. | 22:39 |
| DeviantPeer | the proper versioning of directories is great. | 22:39 |
| DeviantPeer | now I can't even believe that I survived without it for so long ;) | 22:39 |
| NfNitLoop | DeviantPeer: what VCS were you using previously? | 22:40 |
| DeviantPeer | although ClearCase does version directories | 22:40 |
| DeviantPeer | NfNitLoop: uff.. I have used CVS, svn, ClearCase (arghhhh!) and git | 22:40 |
| DeviantPeer | NfNitLoop: now I'm trying some newer ones. | 22:40 |
| NfNitLoop | We actually used MS VSS at one company I was at. >.< | 22:41 |
| DeviantPeer | argh! | 22:41 |
| DeviantPeer | it's even worse than CCase. | 22:41 |
| DeviantPeer | :) | 22:41 |
| DeviantPeer | so much worse than anything actualy ;) | 22:41 |
| metajack | Any particular reason that bzr+ssh would fail but sftp would work? I get 'bash: bzr: command not found' and 'bzr: ERROR: Connection closed: please check connectivity'. ssh host bzr works fine though. | 22:42 |
| metajack | oh wait. no it doesn't. never mind me :) | 22:42 |
| NfNitLoop | metajack: glad to be of service! :) | 22:42 |
| DeviantPeer | metajack: :D | 22:42 |
| DeviantPeer | well... time to go and read... the old fashion way of learning. | 22:44 |
| DeviantPeer | NfNitLoop: thx for the tips. | 22:45 |
| DeviantPeer | lifeless: thx | 22:45 |
| DeviantPeer | bye all. | 22:45 |
| lifeless | jelmer: I've pushed a fix | 22:54 |
| jelmer | lifeless, argh, I was just working on a fix as well.. | 22:54 |
| jelmer | I have a testcase, if that helps.. | 22:54 |
| lifeless | jelmer: won't hurt to have a test | 22:54 |
| lifeless | jelmer: I just made a __init__ | 22:55 |
| markh | jam: kerguelen is back up :) | 22:56 |
| Lutin42 | hi! I have a bzr repository broken and I'm looking for help to fix it (or at least export its content) | 22:58 |
| Lutin42 | I executed the following command: bzr rm documents | 22:59 |
| Lutin42 | and now, with most of the commands (except logs), I get the following errors: bzr: ERROR: exceptions.AssertionError: Could not find target parent in wt: documents | 22:59 |
| Lutin42 | is there any way to fix this? | 22:59 |
| markh | an assertion eh... You have a recent verison of bzr? | 23:00 |
| lifeless | jelmer: feel free to push trivial stuff to brisbane-core directly | 23:01 |
| lifeless | jelmer: [like trivially correct, doco etc] | 23:01 |
| jelmer | lifeless, or this test ? :-) | 23:02 |
| lifeless | jelmer: larger stuff please send a [split-inv][MERGE] to the list, and get an ack before pushing | 23:02 |
| Lutin42 | I was with an old version (1.6 I think) | 23:02 |
| jelmer | k | 23:02 |
| Lutin42 | updated to 1.9, and still the same problem | 23:02 |
| lifeless | Lutin42: that error will persist until you removeo the tree and check it again; it is a cache corruption, not a core data corruptio | 23:03 |
| Lutin42 | ok... now I feel like a noob | 23:03 |
| lifeless | Lutin42: if you have no outstanding changes in the tree, or none you care about, just do 'bzr remove-tree --force; bzr checkout .' | 23:03 |
| Lutin42 | this tree was never pushed anywhere | 23:04 |
| lifeless | Lutin42: do you have outstanding edits you haven't committed? | 23:04 |
| Lutin42 | nothing that is not backed up | 23:05 |
| lifeless | ok | 23:05 |
| lifeless | then do | 23:05 |
| lifeless | 'bzr remove-tree --force; bzr checkout .' | 23:05 |
| NfNitLoop | Lutin42: I'm also curious if you're working on a case-insensitive fs. (Windows) | 23:06 |
| === spmcinern is now known as spm | ||
| Lutin42 | I'm on mac os x | 23:06 |
| Lutin42 | default install | 23:06 |
| Lutin42 | your command seemed to have worked ; produce a lot of conflict though | 23:09 |
| lifeless | Lutin42: you can clean that up though, using bzr revert/resolve etc | 23:12 |
| Lutin42 | yes ; I'm looking into it, as the slightly different workflow is different for an svn guy | 23:13 |
| Lutin42 | Can I safely assume that all my modifs since the last commit have been moved to <file>.normal_extension.moved and that moving this file to the normal name and then do bzr resolve FILE will solve it? | 23:18 |
| Lutin42 | from what I've seen so far, yes, but just in case... | 23:18 |
| === davi_ is now known as davi | ||
| Lutin42 | back to normal | 23:36 |
| Lutin42 | lifeless, thanks a lot for your help | 23:36 |
| uws | Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this) | 23:40 |
| uws | Is it possible this also happens with pull over bzr+ssh:/ if the server is 1.8 and the client is 1.5? | 23:40 |
| maxb | I'm browsing "bzr help commands" ..... what is a ghost and why would I want to fetch it? | 23:43 |
| speakman | using bzr+ssh it says "Unable to determine your name. Use "bzr whoami" to set it.", but the whoami is already set to "Forename Lastname <email@address.com>". | 23:44 |
| fullermd | uws: 1.6 (I think) removed the streaming pull thing for various reasons, so yes. | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!