| lifeless | moin | 00:06 |
|---|---|---|
| igc | morning | 00:38 |
| beuno | Peng_, jusy sasw your reviews | 01:17 |
| beuno | thanks | 01:17 |
| Peng_ | Oh, you're welcome. | 01:18 |
| beuno | I wonder what that TooManyConcurrentRequests thing is about | 01:21 |
| Peng_ | Soo. Anyone got IPv6 access? Run an IPv6 bzr server? | 01:28 |
| beuno | too crazy for me :) | 01:30 |
| Peng_ | I missed my medication and wound up setting up an IPv6 tunnel on my server. :D | 01:30 |
| === arjenAU2 is now known as arjenAU | ||
| lifeless | beuno: TMC is a masking error | 01:33 |
| lifeless | beuno: it means that some code is trying to make smart RPC calls a after an error left the smart connection in a bad state | 01:34 |
| lifeless | beuno: e.g. attempting to unlock a lock after the server bailed | 01:34 |
| lifeless | beuno: -Dhpss can be a useful way to get some info on it | 01:34 |
| beuno | lifeless, ah | 01:34 |
| beuno | hrm | 01:34 |
| Peng_ | lifeless: Oh, thanks. | 01:35 |
| lifeless | fixing it requires finding the fault,and correcting it so that when this failure occurs it leaves the connection in a good state | 01:35 |
| lifeless | bb is down :( | 01:36 |
| beuno | I wonder how to get loggerhead to do that for me | 01:37 |
| lifeless | beuno: try:except; :P | 01:37 |
| lifeless | beuno: there is another possible cause | 01:37 |
| lifeless | beuno: which is using a single connection from threads | 01:37 |
| lifeless | beuno: smart connections do not overlap requests, you need separate connections if you want to make a second request before the first is finished | 01:38 |
| lifeless | or finally, if you have a generator response, you need to exhaust the generator before making new requests | 01:38 |
| Peng_ | lifeless: You mean a multithreaded server or a multithreaded client? | 01:41 |
| lifeless | Peng_: user of a connection | 01:42 |
| Peng_ | Wait, where does TMCR happen? Client or server? | 01:42 |
| * Peng_ 's brain isn't fully engaged today. | 01:42 | |
| lifeless | Peng_: could happen on either, but in practice clients have a much larger surface area to get wrong | 01:42 |
| Peng_ | FWIW, the subject of this is https://code.edge.launchpad.net/~beuno/loggerhead/serve-config/+merge/6821#comment17559 | 01:47 |
| Peng_ | I just realized that there might be two smart servers in play which...is totally confusing. | 01:47 |
| lifeless | there are two in play | 01:50 |
| lifeless | where is the exception coming from | 01:50 |
| lifeless | the bzr client, or loggerheads client ? | 01:50 |
| Peng_ | lifeless: bzr client. | 01:51 |
| Peng_ | I think. | 01:52 |
| lifeless | do this | 01:52 |
| lifeless | start loggerhead in one terminal | 01:52 |
| lifeless | run bzr log in another | 01:52 |
| Peng_ | Yeah, that's what I did. The bzr client is the one that displayed the traceback, but it's possible it got it somewhere else. Or something. | 01:55 |
| lifeless | so that means that the client is leaving a hpss connection in a bad state | 01:56 |
| lifeless | run with -Dhpss | 01:56 |
| lifeless | its likely getting an error from loggerhead | 01:56 |
| lifeless | though I didn't know that loggerhead provided hpss calls over its http connection | 01:56 |
| Peng_ | lifeless: It doesn't, yet. Though there's a branch up about it. | 01:57 |
| Peng_ | Like I said, my brain is pretty fried right now. | 01:57 |
| lifeless | Peng_: does this branch do that? | 01:58 |
| lifeless | soliciting for reviews of | 02:00 |
| lifeless | https://code.launchpad.net/~lifeless/bzr/Commands.hooks/+merge/6936 | 02:00 |
| Peng_ | lifeless: No. | 02:00 |
| lifeless | Peng_: in any event, if the exception is in the client, debug the client | 02:01 |
| lifeless | you'll find a bug there for sure; once fixed we can see whats wrong with loggerhead | 02:02 |
| lifeless | and as I said before -Dhpss is a good starting point | 02:02 |
| lifeless | that said, if you're fried. Go sleep. | 02:02 |
| lifeless | igc: ^ if you have a few that branch would love a review | 02:04 |
| igc | shall do lifeless - consider it done | 02:05 |
| lifeless | igc: thanks | 02:05 |
| igc | i.e. I'm about to spent today reviewing all I can | 02:05 |
| igc | bbiab | 03:17 |
| * igc lunch | 04:24 | |
| === timchen1` is now known as nasloc__ | ||
| tc-rucho | I have a little question that I should know, but since I've heard bzr now uses git's packs.... bzr tracks files? or content? I mean if it tracks content with solid renaming | 05:30 |
| lifeless | tc-rucho: bzr does not use git's packs. | 05:31 |
| lifeless | tc-rucho: bzr tracks file names and content separately; it has excellent renaming support. | 05:31 |
| tc-rucho | lifeless: http://bazaar-vcs.org/BzrVsHg#Mercurial%27s%20Earlier%20Advantages then what's that? | 05:34 |
| lifeless | a wiki page? | 05:34 |
| tc-rucho | .... | 05:34 |
| lifeless | :) seriouslly, give me a sec to refresh my memory | 05:34 |
| tc-rucho | I mean that about "Git's format - packs" | 05:34 |
| lifeless | the page is accurate, as it says 'similar to' | 05:34 |
| lifeless | git's packs are a different format to bzr's packs | 05:35 |
| lifeless | they are conceptually similar | 05:35 |
| tc-rucho | ok, the question of the million. If I take a file with history, split it in two, then save in 2 different files; will bzr track that it's just a reallocated content or treat this as new coded being entered into the repository? | 05:36 |
| tc-rucho | (git would track the content and this would keep history of every single line in the two resulting files) | 05:36 |
| lifeless | currently bzr considers it new content | 05:39 |
| lifeless | we have a plan to address this | 05:39 |
| lifeless | igc: thanks; I hadn't seen your reply | 06:12 |
| igc | lifeless: np | 06:13 |
| lifeless | I think of New Features as things for developers-using-bzr, not plugin authors so much | 06:13 |
| lifeless | and that plugin authors should be reading 'Internals' | 06:14 |
| lifeless | igc: replied - thanks for catching all the little noise in that patch | 06:40 |
| igc | lifeless: cool. I'll take a look. As I said, it looked pretty promising so I'm keen to get it through review | 06:41 |
| lifeless | I'm fading right now | 06:42 |
| lifeless | but if you have any questions feel free to chat here for faster turnaround | 06:42 |
| === abentley1 is now known as abentley | ||
| bialix | does it only for me http://doc.bazaar-vcs.org is not available? | 08:50 |
| bialix | main site works ok | 08:50 |
| bob2 | wfm | 08:51 |
| Peng_ | me too | 08:51 |
| awilkins | Question : (sorry, I know I could read the source), are all commit times stored UTC and presented local-time? | 08:53 |
| Peng_ | Hm. | 08:55 |
| Peng_ | awilkins: Well, by default they're presented in their original time zone | 08:55 |
| awilkins | So, if I commit at 0800 on a server in PDT, when I pull that revision to UTC the time will still say 0800 and not 0000 ? | 08:56 |
| awilkins | Oops, 1600 (confusing!) | 08:56 |
| Peng_ | ISTM that on disk, a UTC timestamp and the offset from UTC are stored. | 08:56 |
| * awilkins has the opportunity to test this | 08:56 | |
| Peng_ | awilkins: Look at $ bzr cat-revision -r 123 | 08:56 |
| Peng_ | awilkins: What do you mean, "pull that revision to UTC"? | 08:57 |
| awilkins | Peng_: Pull the revision into a branch hosted on a box running in the UTC timezone (or rather, GMT. Which is BST at present anyway) | 08:57 |
| awilkins | Although I think UTC should be a valid locale..... | 08:57 |
| Peng_ | awilkins: The local time zone won't change the revision's data. | 08:58 |
| Peng_ | awilkins: Like I said, ISTM that the UTC timestamp + time zone offset are stored on disk. With that information, bzr can display it using the orignal time zone, local time, or (theoretically) anything else; it's all the same time, so it doesn't matter. | 08:59 |
| awilkins | Peng_: No, but does it change the presentation of the commit time ; - will 0800 PDT display as 1600 in the BST zone (because that's when it happened) | 08:59 |
| awilkins | I'm checking this now | 08:59 |
| awilkins | Ok, the logs have zone into | 08:59 |
| awilkins | info | 08:59 |
| Peng_ | Yeah. | 09:00 |
| awilkins | Right, so logs jsut display the time + zoneinfo | 09:01 |
| Peng_ | awilkins: From "bzr help log": " --timezone=ARG Display timezone as local, original, or utc." | 09:01 |
| awilkins | I think my questions are probably more about qlog now then | 09:01 |
| Peng_ | I definitely don't know anything about that. | 09:01 |
| awilkins | And qlog seems to do it right by me - it uses local | 09:01 |
| Peng_ | You could compare with "bzr log" to see what qlog doe -- yeah. | 09:01 |
| awilkins | Ok, I'm glad that's all in order :-) | 09:02 |
| awilkins | lifeless: ? | 09:06 |
| awilkins | Who else is a loom-person? | 09:06 |
| AfC | Does anyone know off-hand if there is a newer version of push_and_update than 0.2dev around? | 10:48 |
| awilkins | lifeless: ? | 11:58 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| === gdmfsob is now known as mishok13 | ||
| cdecarlo | hi, a friend and I are working on a project together and we decided to go with a decentralized with a shared mainline workflow, however, I want to work on more than one machine, I can do that right? I'm coming from svn and the only way to do that there is to make a lot of commits, but with bzr I can just treat my working copy both ways, peer-to-peer for me and team colaboration for us, right? | 14:06 |
| beuno | cdecarlo, yeap | 14:14 |
| cdecarlo | beuno: thanks | 14:16 |
| cdecarlo | beuno: and that's b/c bzr isn't tied to a repos in the way svn is right? each working copy I have is a repos in itself? | 14:17 |
| beuno | cdecarlo, exactly | 14:17 |
| beuno | as long as you use "bzr branch" and not "bzr checkout" to get the branches | 14:18 |
| cdecarlo | beuno: sweet | 14:18 |
| === fta_ is now known as fta | ||
| mattl | hey, can anyone recommend a bzr hosting service that isn't launchpad or savannah? :) | 15:10 |
| LeoNerd | What's a "hosting service"..? | 15:10 |
| LeoNerd | bzr doesn't need anything special on a server.. Anything you can HTTP from, or FTP/SFTP to will suffice.. | 15:10 |
| mattl | right, but i'm thinking of something which also provides trac and backs things up, etc. | 15:11 |
| LeoNerd | hmm.. personalyl I've never had much luck with trac against bzr.. It doesn't quite understand it | 15:12 |
| LeoNerd | And for backup I just use rsync. Though probably I should use bzr push | 15:12 |
| awilkins | Wait for July and Launchpad goes OSS.... | 15:20 |
| awilkins | (apart from the bestest bits, alas) | 15:21 |
| luks | what will that solve? | 15:21 |
| awilkins | Not much | 15:21 |
| awilkins | Well, it might give me some more options | 15:21 |
| awilkins | twas directed at mattl | 15:21 |
| mattl | awilkins: code hosting part won't be free software. | 15:22 |
| mattl | which is why i'm looking at non-launchpad options. | 15:22 |
| luks | I know, but "wait for LP to go OSS" doesn't seem as a very useful answer to "recommend a hosting service" | 15:22 |
| mattl | heh | 15:23 |
| mattl | i might be waiting a while | 15:23 |
| luks | what's wrong with a regular web hosting, though? | 15:24 |
| mattl | i want a bug tracker too. ideally one that can actually work with bzr. | 15:24 |
| luks | sourceforge? if you don't mind a crappy bug tracker :) | 15:25 |
| mattl | heh. | 15:25 |
| awilkins | BugsEverywhere, but I have my reservations about how useful the in-tree-tracker model is | 15:25 |
| mattl | same problem as launchpad. | 15:25 |
| luks | I'd still just setup my own trac | 15:26 |
| awilkins | Sourceforge has an OSS version | 15:26 |
| mattl | doesn't need to be bugs in bzr... just something that can see that, for example, a commit message that closes a bug. | 15:26 |
| awilkins | You could write a hook that pokes at Trac's XMLRPC | 15:27 |
| awilkins | Last time I tried something with that I was pleased at how easy it was | 15:27 |
| luks | you could also just add a link to the trac comment when you close a bug | 15:28 |
| mattl | well, i am wondering what tracbzr does... | 15:28 |
| luks | and from the other side you have many local bzr tools | 15:28 |
| awilkins | qbzr has a "fixes" entry in it's commit dialog - which trackers does that work with? | 15:28 |
| luks | awilkins: bzr commit --fixes just stores metadata about the bug urls, nothing else | 15:29 |
| awilkins | Aha, it goes with te fixes arg for commit | 15:29 |
| awilkins | luks: Is there a hook that has access to that data? | 15:29 |
| luks | it's in the revision object | 15:29 |
| luks | so any hook can access that | 15:29 |
| dvheumen | hey, I wanted to try bzr-svn, but I got an error about the module 'tdb' not supporting the attribute 'open'. I couldn't find anything on the gmane mailinglist search. Anyone got an idea? | 15:30 |
| awilkins | Needs a newer tdb version? What OS are you on? | 15:30 |
| awilkins | And how did you install bzr-svn? | 15:31 |
| jelmer | dvheumen, you need a new version of tdb or to deinstall tdb? | 15:31 |
| dvheumen | jelmer: hey, I think it was your package I used, from the archlinux AUR repository | 15:31 |
| jelmer | dvheumen, I don't do archlinux packaging, I'm upstream | 15:32 |
| dvheumen | jelmer: ow okay, than I'm confusing you with someone else ... no matter :P | 15:32 |
| dvheumen | jelmer: I'll try finding a new tdb package, tnx for the info | 15:32 |
| mattl | luks, awilkins... thanks for your help :) | 15:33 |
| dvheumen | jelmer: what version should I minimally have? | 15:34 |
| jelmer | dvheumen, Git snapshot from after december I think | 15:34 |
| dvheumen | okay | 15:35 |
| rotund | Can someone tell me if there's a way to have a file in VCS, but I ignore updates unless explicitly asked to update it? | 15:59 |
| rotund | I know it's a weird request, but there's files generated by the IDE that really should never need to update. They also contain window positions and recently used lists. Obviously, we don't care about those. | 16:00 |
| jelmer | rotund, I don't think there's anything like that at the moment | 16:05 |
| luks | can't the new wt views do something like that? | 16:06 |
| luks | e.g. svn (or at least tortoisesvn) has a ignore-on-commit changelist | 16:06 |
| luks | which is not processed by status/diff/commit unless you explicitly ask it to | 16:07 |
| rotund | jelmer: Thanks. That's what I thought. | 16:07 |
| rotund | what's a wt views? | 16:07 |
| dash | morning | 16:11 |
| dash | i'm trying to reacquaint myself with the use of loom | 16:11 |
| dash | i've got a codebase in an svn repo that's been copied from the original project's repo | 16:12 |
| dash | i.e., one revision was copied, no history is shared between them | 16:12 |
| dash | i'm using bzr-svn and I want to develop a set of patches that can be applied to my current branch, and then adapted for application 'upstream' | 16:14 |
| dash | do I understand correctly that to produce a series of patches like that, i'd do 'up-thread' for each, commit my changes, then do 'down-thread' and use the diff result as the patch? | 16:15 |
| adaran | does anyone here use bzr on windows? i'd like to know how ssh works with (using the windows installer package) | 16:30 |
| sidnei | adaran: you'd use putty, much the same way it's setup for subversion | 16:32 |
| adaran | sidnei, i don't have putty installed - and yet it seems to work "out of the box" | 16:32 |
| sidnei | adaran: oh, it might be using paramiko then | 16:32 |
| sidnei | which is a python library for ssh | 16:32 |
| adaran | sidnei, i simply installed it and i can do bzr ls bzr+ssh://foo.bar just fine - which, of course, bothers me =) | 16:32 |
| LarstiQ | adaran: bzr has support for multiple ssh providers | 16:33 |
| dash | does the windows install use paramiko? | 16:33 |
| adaran | LarstiQ, that's fine. i just need to find out which one it uses at the moment and see if it's secure enough | 16:33 |
| LarstiQ | adaran: openssh and putty at least, but what might be going on is the bundled pycrypto+paramiko in this case | 16:33 |
| LarstiQ | adaran: try to supply -Dtransport and look at .bzr.log? | 16:34 |
| LarstiQ | dash: the all in one installer? I'd certainly think so | 16:34 |
| sidnei | im pretty sure the installer bundles paramiko (im working on setting up a nightly build for the installer and it's a requirement) | 16:34 |
| LarstiQ | sidnei: cool | 16:34 |
| adaran | LarstiQ, where'd that .bzr.log end up? | 16:36 |
| luks | bzr version should tell you | 16:36 |
| adaran | in "My Documents" | 16:37 |
| adaran | oh boy.. | 16:37 |
| vxnick | is --no-trees implied when running bzr init-repo? I haven't used it on an old repo but I don't see the files in its directory | 16:37 |
| LarstiQ | adaran: bzr --version will say, it differs over windows versions afaik | 16:38 |
| adaran | LarstiQ, it's using paramiko, it seems | 16:38 |
| LarstiQ | vxnick: it does. Long time ago it didn't. | 16:38 |
| vxnick | LarstiQ: thanks | 16:39 |
| LarstiQ | vxnick: see `bzr reconfigure` if you want to change that. | 16:39 |
| vxnick | don't want to change it, just wanted some clarification :) | 16:39 |
| LarstiQ | ok :) | 16:39 |
| === herb__ is now known as herb | ||
| === beuno_ is now known as beuno | ||
| adaran | hmm, where am i supposed to put my keys btw? | 16:44 |
| adaran | on windows, that is | 16:44 |
| LarstiQ | I don't know with bare paramiko | 16:44 |
| luks | paramiko uses the putty key agent | 16:45 |
| LarstiQ | adaran: it's not mentioned in the userguide? | 16:45 |
| adaran | LarstiQ, i'll go have a look | 16:45 |
| luks | Pageant | 16:45 |
| LarstiQ | luks: pageant, or is that something else? | 16:45 |
| LarstiQ | ah | 16:45 |
| jam | anyone know if there is a new qbzr version? | 17:03 |
| jam | I thought that 0.10 or 0.9.10 was due "real soon now" | 17:03 |
| jam | but I don't think it has been released yet | 17:03 |
| jam | btw, jelmer didn't mark subvertpy 0.6.6 as a release on https://edge.launchpad.net/subvertpy, but I see it as a tarball in http://samba.org/~jelmer/subvertpy/ | 17:04 |
| jam | Anyone know why? | 17:04 |
| jam | I suppose he didn't put 0.5.4 in https://edge.launchpad.net/bzr-svn | 17:04 |
| jam | And I *know* that exists... | 17:05 |
| dash | Crud | 17:16 |
| dash | is there no way to rename threads in a loom? | 17:17 |
| LarstiQ | jam: 0.6.1 is the last bzr-svn release I'm aware of | 17:21 |
| jam | LarstiQ: which brings up a good point, are we supposed to be switching from the 0.5.x series to 0.6.x? | 17:21 |
| jam | I'm pretty sure I packaged 0.5.4 for bzr-1.14 | 17:21 |
| jam | (since that was the state of the release script.) | 17:21 |
| LarstiQ | jam: I've uploaded 0.6.1 | 17:23 |
| LarstiQ | jam: johnf has been doing the ppa for bzr and bzrtools, I've been doing bzr-svn | 17:23 |
| LarstiQ | jam: I have no clue about windows installers | 17:24 |
| LarstiQ | jam: but yeah, I'd go with 0.6.x | 17:24 |
| jam | hmm... it seems we still only have qbzr-0.9.8 in the ppa | 17:24 |
| LarstiQ | bzr-gtk is also old | 17:24 |
| jam | LarstiQ: what about subvertpy 0.6.6 ? | 17:24 |
| jam | I saw a release on jelmer's web page | 17:25 |
| jam | but it doesn't seem to be tagged in whatever trunk I have | 17:25 |
| jam | hmm.. and we only have 0.6.1 in the ppa | 17:25 |
| LarstiQ | jam: I'm not taking care of that (yet) | 17:25 |
| LarstiQ | jelmer might be at pinkpop right now | 17:25 |
| * LarstiQ looks at the subvertpy changelog | 17:27 | |
| LarstiQ | jam: there was no bzr-svn 0.6.1 release either I could find btw | 17:27 |
| LarstiQ | jam: I'm willing to take responsibility for subvertpy too. I'll ask jelmer about 0.6.6, and clearer announcing in general | 17:28 |
| jam | sure | 17:29 |
| jam | As for 'clearer announcing' I don't often remember from email | 17:29 |
| jam | so just having things tagged in the appropriate overview page works best for me | 17:29 |
| LarstiQ | jelmer pinging me on irc works best for me :) | 17:30 |
| jam | well, I have to package about 4 different ones for the bzr release... | 17:30 |
| * LarstiQ nods | 17:30 | |
| LarstiQ | jam: I notice https://edge.launchpad.net/~subvertpy/+archive/ppa has 0.6.1 only too | 17:30 |
| jam | oh, and do you know if he has a "0.6-mirrored" like 0.5? | 17:31 |
| jam | The windows build host has messed up dns | 17:31 |
| jam | so I have to manually register every domain name I want to access | 17:31 |
| LarstiQ | subvertpy or bzr-svn? | 17:31 |
| jam | so having everything on LP helps me a lot | 17:31 |
| jam | bzr-svn | 17:31 |
| LarstiQ | trunk is atm, but that's not stable | 17:31 |
| LarstiQ | (stable, as in pointing to 0.6 always) | 17:32 |
| jam | right, I just saw that | 17:32 |
| jam | I don't care specifically about 0.6 | 17:32 |
| jam | just 'trunk' | 17:32 |
| jam | in the past he had switched to having everything hosted at people.samba.org rather than lp | 17:32 |
| jam | he seems to have switched back | 17:32 |
| LarstiQ | jam: no, hosting is at samba, lp mirrors | 17:33 |
| jam | LarstiQ: at one point, jelmer had it to | 17:33 |
| * LarstiQ nods | 17:33 | |
| jam | "bzr branch lp:bzr-svn" would actually download from samba | 17:33 |
| jam | I don't know *how* he made that work, but it did | 17:34 |
| jelmer | jam: remote branches | 17:34 |
| LarstiQ | jam: oh, https://code.edge.launchpad.net/~jelmer/bzr-svn/0.6 does exist | 17:34 |
| jelmer | jam, which is different from mirrorred branches | 17:34 |
| jam | sure | 17:34 |
| jam | anyway, /me => lunch for now | 17:34 |
| LarstiQ | jelmer: we just discussed subvertpy 0.6.6 not being clearly tagged/if it should be packaged (windows installer/ppa) | 17:35 |
| LarstiQ | jelmer: do you want me to take care of subvertpy for the bzr ppa too? | 17:35 |
| jelmer | LarstiQ: I've fixed the tag for 0.6.6 | 17:37 |
| jelmer | LarstiQ: If you can, that would be awesome | 17:37 |
| LarstiQ | jelmer: sure. | 17:37 |
| LarstiQ | jelmer: should I start on 0.6.6 now, or are there reasons to stay away from it? | 17:38 |
| jelmer | LarstiQ, no, 0.6.6 should be fine | 17:39 |
| LarstiQ | k | 17:39 |
| jelmer | LarstiQ, actually, it seems there's enough changes to do a 0.6.7 | 17:39 |
| LarstiQ | ok :) | 17:40 |
| LarstiQ | jelmer: should I also care about https://edge.launchpad.net/~subvertpy/+archive/ppa ? | 17:40 |
| jam | jelmer: so I should use 0.6.6 for bzr-1.15? | 17:43 |
| jelmer | jam: Ideally 0.6.7, which I've just pushed | 17:44 |
| jelmer | and tagged | 17:44 |
| jam | seems to be going | 17:45 |
| === brainsik_ is now known as brainsik | ||
| LarstiQ | jelmer: do you use something for release automation? | 18:23 |
| Kissaki | you can't ignore changes on a tracked file, right? eg, never commit that file anyway (so you don't have to deselect it each time) | 18:25 |
| LarstiQ | Kissaki: correct. You could unversion it. | 18:26 |
| LeoNerd | I've often wanted a "bzr freeze PATH" command | 18:27 |
| LarstiQ | Kissaki: or perhaps an appropriate idiom is to version a template, copy, edit and ignore for local use. | 18:27 |
| LarstiQ | LeoNerd: what would that do? | 18:27 |
| LeoNerd | Yup. exactly for that use case... that a repo contains a template config file for general use. Each checkout on a machine edits it for local use | 18:27 |
| LeoNerd | A "bzr freeze"ed file is never looked at, presumed to always be pristine | 18:27 |
| LarstiQ | ah | 18:27 |
| Kissaki | k, thx | 18:27 |
| LeoNerd | "bzr stat" will not show changes, "bzr commit" will not submit it | 18:27 |
| LarstiQ | you might be able to pull that off with a plugin | 18:28 |
| LeoNerd | Offhand I can't quite think on the behaviour what might happen if upstream has a patch for it.. Do we attempt to merge locally anyway, or just ignore it? | 18:28 |
| LeoNerd | It suggests the commands 'freeze PATH', 'unfreeze PATH' and 'frozen' (to list them) | 18:28 |
| Kissaki | the file not being selected for commit would be enough really... | 18:28 |
| LarstiQ | Kissaki: -x | 18:28 |
| Kissaki | hm? | 18:29 |
| LarstiQ | Kissaki: bzr commit -x filetoexclude | 18:29 |
| Kissaki | ah, hmm | 18:29 |
| LarstiQ | Kissaki: if aliases work per branch, you could alias commit to that | 18:29 |
| LarstiQ | not sure, and seems a bit risky to me | 18:29 |
| Kissaki | well, -x doesn't even work for qci | 18:30 |
| LarstiQ | the requirements keep mounting! :) | 18:30 |
| LarstiQ | Kissaki: file a bug on qbzr | 18:31 |
| LarstiQ | personally, as I said, I'd reevaluate wether the file needs to be versioned in the first place | 18:31 |
| Kissaki | yes, it has to... But I think that setting I changed doesn't even change the proj file itself... :P | 18:32 |
| Kissaki | -h doesn't list -x for qci, so it's probably supposed to be that way | 18:33 |
| LarstiQ | Kissaki: hmm, I'd think it's an oversight for qci | 18:34 |
| luks | yes, it's just a missing feature | 18:34 |
| LarstiQ | Kissaki: oh boy, a (VS) project file? | 18:34 |
| LarstiQ | yeah, those things are irritating | 18:34 |
| Kissaki | yep | 18:34 |
| jelmer | LarstiQ, I hope to use moap at some point | 19:05 |
| LarstiQ | jelmer: ah | 19:06 |
| LarstiQ | jelmer: I had http://liw.iki.fi/liw/unperish/ in mind, hand't heard of moap before | 19:08 |
| LarstiQ | jelmer: liw coincidentally (and some other .fi Debian people) I'm meeting up with this week in Amsterdam. If you want to join us you're welcome. | 19:09 |
| jelmer | LarstiQ, I hadn't seen unperish before :-) I like the idea behind moap but it doesn't work well enough in practice, I'll give it a try | 19:11 |
| jfroy | jelmer: sorry it took so long, finally updated https://bugs.launchpad.net/bzr-svn/+bug/342065 | 19:12 |
| ubottu | Ubuntu bug 342065 in bzr-svn "KeyError due to missing file id while running bzr check on SVN repository" [Undecided,Incomplete] | 19:12 |
| jelmer | LarstiQ, sounds like fun | 19:12 |
| jelmer | bleh, somebody should make up a word for gezellig in English | 19:13 |
| jelmer | jfroy, thanks | 19:13 |
| LarstiQ | jelmer: kodikas, viihtyisä, seurallinen; according to my dictionary ;) | 19:14 |
| adaran | i've been trying to branch or checkout a remote repository on windows xp. however, after downloading all the data, the tree is built (according to the status message), after which only a ton of gibberish is put out in my console. can anyone tell me why? | 19:21 |
| sidnei | never seen that before | 19:22 |
| adaran | trying with torquoise bzr now, see if it makes any difference. i've had RAM problems before (apparently, 1,25 GB page file were needed, which is an awful lot to download and extract ~ 50 MB of data to 500 MB), but i've had no more warnings about that when making the last attempt | 19:23 |
| adaran | same error with the GUI | 19:27 |
| LarstiQ | adaran: could you pastebin that? | 19:29 |
| adaran | LarstiQ, no, it's too large | 19:29 |
| adaran | LarstiQ, I need to find a way to capture the head of it first. it seems to dump a lot of binary data | 19:29 |
| adaran | LarstiQ, i get python repr()'s of some binary stuff | 19:30 |
| LarstiQ | adaran: that certainly sounds wrong | 19:30 |
| adaran | LarstiQ, shouldn't bzr produce a log? | 19:31 |
| LarstiQ | adaran: yup. `bzr --version` tells you where it's stored | 19:31 |
| adaran | aw, shit. it's grown to 200 MB and notepad can't open it :P | 19:32 |
| adaran | LarstiQ, http://pastebin.com/m18f9561 -- there | 19:36 |
| adaran | LarstiQ, bzr check on server runs fine | 19:37 |
| ddaa | Hopefully, this the appropriate place to rant about hg. | 19:50 |
| ddaa | I'm trying it on a new project | 19:50 |
| ddaa | and boy, is their "log" feature broken. | 19:50 |
| ddaa | I understand why they spend so much time destroying their history with queues and rebase kind of gross stuff. | 19:51 |
| ddaa | The reason is that log just displays everything flat, in order in which it got into the repository, no merge hierarchy. | 19:51 |
| * ddaa feels better | 19:51 | |
| fullermd | Pfft. You're missing the point, man. It's FAST. | 19:52 |
| * ddaa hits fullermd with a plank studded in spiky and rusty nails | 19:53 | |
| ddaa | fullermd: thanks for helping my catharsis :) | 19:54 |
| fullermd | I've sometimes thought the rabid joy of gitk springs from the same well, actually... | 19:54 |
| * Kinnison grins | 19:54 | |
| ddaa | Kinnison: hello you cuddly red-haired man. | 19:55 |
| ddaa | hgk does help, but then this "flat log" attitude then engenders the "fast forward pull on no divergence" idea, which just completely screws away the notion of a mainline. | 19:57 |
| fullermd | Well, they dovetail. | 19:58 |
| ddaa | The log breakage engender a whole view of how to do dvcs, which is just WEAK. | 19:58 |
| fullermd | If your tool doesn't do anything useful with the first parent path, it won't aim at workflows which preserve it, which makes it useless, which makes it not preserved, which... | 19:59 |
| Kinnison | ddaa: salut | 19:59 |
| fullermd | 's why trying to explain across that divide just ends up with both sides looking puzzled. | 19:59 |
| ddaa | It produces a tool that makes people think "let's do the svn dogpile branch thing, except distributed". | 19:59 |
| ddaa | fullermd: actually, you can prove this is a bad idea by pointing that some implications are absurd. | 20:00 |
| fullermd | Only to people who care about and pay attention to theory :p | 20:01 |
| ddaa | Specifically, the idea that people should not do small frequent commits because it pollutes the logs. | 20:01 |
| fullermd | Oh, they can do small frequent commits. You just use rebase to squish them together logically later. See how easy it is? | 20:01 |
| ddaa | You do not need to pay attention to theory to find value in "oops, I have done shit in the last 30 min, let's do revert" | 20:02 |
| ddaa | fullermd: that precludes early sharing of work. | 20:02 |
| fullermd | Nah, you just tell all your peers to rebase on your new rebase. That's what distributed means, isn't it? | 20:03 |
| ddaa | No it isn't. | 20:03 |
| ddaa | I need to finish this presentation about "Why Bazaar is better" | 20:04 |
| ddaa | Or "Advanced Bzr" | 20:04 |
| ddaa | To explain all the non-obvious stuff that people new to do DVCS just don't see. | 20:05 |
| dash | yes, the ability to get a clean trunk log is the #1 reason I decided to sue bzr over hg | 20:05 |
| dash | s/sue/use/ | 20:05 |
| sevenseeker | I might not be looking in the right places, but where are good docs on bzr-svn workflows? | 20:05 |
| rbriggsatuiowa | is there a way to do a bzr ignore that is only local? | 20:05 |
| rbriggsatuiowa | to my working copy? | 20:05 |
| ddaa | rbriggsatuiowa: no, there isn't. | 20:06 |
| rbriggsatuiowa | alright - thanks | 20:06 |
| jelmer | sevenseeker, whatever workflow works for bzr itself should work for bzr-svn generally | 20:06 |
| fullermd | rbriggsatuiowa: You can add per-user ignores, but they affect any of your branches. | 20:07 |
| rbriggsatuiowa | that's fine | 20:07 |
| sevenseeker | ok, I am doing this wrong then. I did 'bzr checkout foo' and then I can't branch from foo with 'bzr branch foo foo_branch' | 20:07 |
| ddaa | Actually, my distaste for hg just crossed the line where I'm willing to discard history instead of waiting for someone to fix bzr-hg. | 20:08 |
| rbriggsatuiowa | I have one config file I don't want checked in when I'm on our production machine | 20:08 |
| jelmer | sevenseeker, what about it doesn't work | 20:08 |
| jelmer | sevenseeker, ? | 20:08 |
| rbriggsatuiowa | where do I add the per user ignore? | 20:08 |
| fullermd | rbriggsatuiowa: That's in ~/.bazaar/ignore I believe. | 20:08 |
| abentley | ddaa, rbriggsatuiowa: .bzrignore doesn't have to be versioned. So if *none* of the ignores need to apply to others, you can do that. | 20:08 |
| rbriggsatuiowa | thanks | 20:08 |
| dash | the other nice thing about bzr is that you can do almost everything without having to change your thinking from svn :) | 20:08 |
| sevenseeker | jelmer: let me clean this out and try again... troubleshooting I did silly things I think | 20:09 |
| ddaa | Anyway, let's try this thing. Maybe I'm going to realize that I do not actually care about clean mainlines. | 20:11 |
| dash | quelle horreur | 20:12 |
| ddaa | Actually, I can't help it... I do care. | 20:12 |
| ddaa | (wow, it took me all of one minute of pondering) | 20:13 |
| sevenseeker | jelmer: no .svn or .bzr in any workingcopy dir | 20:13 |
| sevenseeker | jelmer: this was via 'bzr co http://foo.bar/svn/foo' | 20:14 |
| jelmer | sevenseeker, that should create a .bzr directory in the checkout | 20:14 |
| sevenseeker | ok it did, just not further down... I was expecting .svn dirs for some reason (habit I guess) | 20:15 |
| jelmer | sevenseeker: bzr only creates a control directory in the root | 20:16 |
| sevenseeker | ok, so if I want to split up then I just do smaller checkouts? | 20:16 |
| jelmer | sevenseeker: "bzr co --lightweight" will create .svn directories | 20:16 |
| sevenseeker | can I bzr branch off of subdirs then? | 20:17 |
| jelmer | sevenseeker: yeah, you should be able to | 20:17 |
| sevenseeker | ok, I will try this... thanks a bunch | 20:17 |
| jelmer | sevenseeker: I'm not entirely sure though, it only works because of the nature of svn if it does | 20:18 |
| beuno | jelmer! | 20:18 |
| jelmer | beuno: Hey! | 20:19 |
| jelmer | back in .ar? | 20:19 |
| beuno | jelmer, hi | 20:19 |
| beuno | yes! | 20:19 |
| beuno | :) | 20:19 |
| beuno | it's cold | 20:19 |
| beuno | but feels-like-home cold | 20:19 |
| beuno | so not too bad | 20:19 |
| beuno | how about you? | 20:19 |
| sevenseeker | jelmer: success! thanks again | 20:27 |
| jelmer | beuno, It's actually not too bad here, though not as good as bcn | 20:27 |
| jelmer | sevenseeker, np | 20:27 |
| beuno | jelmer, did you see my comment about your broken branch? | 20:28 |
| beuno | the loggerhead-smart one | 20:28 |
| jelmer | beuno, yeah, just tried to submit using a bundle | 20:29 |
| jelmer | maybe that'll work better | 20:29 |
| * LarstiQ hugs ddaa | 20:29 | |
| jelmer | I suspect I have a broken repo somewhere though not sure how it was corrupted | 20:29 |
| LarstiQ | adaran: aha | 20:30 |
| === nevans1 is now known as nevans | ||
| adaran | LarstiQ, there may be memory problems | 20:30 |
| LarstiQ | adaran: could you try `bzr reconcile` instead/next to `bzr check`? | 20:30 |
| adaran | LarstiQ, copying the repository (in a zip) to windows works, then i can branch it locally on the machine | 20:31 |
| === nevans1 is now known as nevans | ||
| LarstiQ | adaran: ah, and maybe save a copy of that zip? | 20:32 |
| LarstiQ | adaran: which bzr version is this? | 20:32 |
| adaran | LarstiQ, checking | 20:33 |
| adaran | LarstiQ, won't be able to hand out a zip, sorry | 20:33 |
| adaran | LarstiQ, commercial stuff | 20:33 |
| LarstiQ | adaran: that's fine | 20:34 |
| adaran | LarstiQ, 1.3.1 on the server | 20:35 |
| adaran | LarstiQ, latest windows release on the client | 20:35 |
| LarstiQ | reproducability is the main thing. | 20:35 |
| LarstiQ | adaran: ok | 20:35 |
| * ddaa hugs LarstiQ back | 20:36 | |
| adaran | LarstiQ, i'm thinking it may be memory | 20:36 |
| * LarstiQ wonders if it is bug 347979 | 20:36 | |
| ubottu | Launchpad bug 347979 in bzr "KnitCorrupt listing _KnitGraphIndex when pulling" [Undecided,New] https://launchpad.net/bugs/347979 | 20:36 |
| LarstiQ | ddaa: I have recently started using hg (for sphinx), hadn't figured out how to use log properly yet, postponed it in the hope I'm missing something. | 20:37 |
| ddaa | LarstiQ: I'm pretty sure you're not missing something. | 20:38 |
| LarstiQ | you make me think so too. | 20:38 |
| ddaa | A lot of strange thing the git/hg folks care about make sense once you realize they are working around a broken log... | 20:39 |
| ddaa | and going in direction that would be wrong with a working log. | 20:40 |
| LarstiQ | not having a mainline does make some things simpler/faster. | 20:40 |
| ddaa | Sure. Not tracking dir renames too. | 20:40 |
| LarstiQ | fair enough. | 20:40 |
| ddaa | A lot of things are simpler when you only solve half the problem. | 20:40 |
| ddaa | I think the bzr people as a community are really bad at explaining what those things are that they are solving better than the competition. | 20:41 |
| * LarstiQ nods | 20:41 | |
| adaran | LarstiQ, what's with the huge memory usage as well? i've seen my page file go up to 1,4 GB or so for a 450 MB source repository | 20:42 |
| adaran | LarstiQ, is that a bug or "normal"? it seems a bit much | 20:42 |
| LarstiQ | adaran: let me dig up a mail/bug for you | 20:42 |
| LarstiQ | adaran: short answer, right now, that's about to be expected I'm afraid. | 20:43 |
| ddaa | LarstiQ: BTW, did you mean "simpler/faster" to implement, or to use? | 20:43 |
| LarstiQ | adaran: https://bugs.launchpad.net/bugs/109114 | 20:44 |
| ubottu | Ubuntu bug 109114 in bzr "commit holds whole files in memory" [Medium,Confirmed] | 20:44 |
| LarstiQ | ddaa: program model/implement. No claims about that being a simpler user model or not. | 20:45 |
| LarstiQ | ddaa: I'm personally unconvinced by the rebase arguments that an unrebased history will become unwieldly. | 20:45 |
| ddaa | It does become unwieldy when your log is broken. | 20:46 |
| LarstiQ | ddaa: _but_ bzr does have performance problems due to issues related to the mainline | 20:46 |
| jelmer | beuno, I think I'm going to just recommit | 20:46 |
| LarstiQ | ddaa: mainly the O(history) topological sort for the dotted revnos numbering | 20:46 |
| LarstiQ | or well, possibly less if you can find a merge point faster | 20:46 |
| beuno | jelmer, cool, thanks | 20:47 |
| ddaa | LarstiQ: mainly, that translates into "log is slower", right, or does it commonly affects other operations? | 20:47 |
| LarstiQ | ddaa: log | 20:47 |
| ddaa | So, the alternative is "broken log" and "slower log". | 20:47 |
| LarstiQ | ddaa: igc did a lot on this front, one change is to not display non-mainline revisions by default | 20:48 |
| LarstiQ | ddaa: ie, bzr log -n1 vs bzr log -n0 | 20:48 |
| ddaa | There would certainly be value in having a hierarchical log that does not show dotted revnos | 20:48 |
| LarstiQ | ddaa: surely git/hg people must deal with their log some way? | 20:48 |
| ddaa | AFAICT, they deal with it by requesting that people do not make frequent commits, or collapse their commits. Witness jelmer. | 20:50 |
| adaran | LarstiQ, does bzr really use readlines() et. al. when handling binary files? | 20:50 |
| luks | I was really surprised that git log is not even topologically sorted by default, it uses the commit date | 20:51 |
| ddaa | They are happily throwing away half of the baby with the bath's water, and think it's fine because the remaining half baby is better than what they had before. | 20:51 |
| LarstiQ | adaran: I don't know on which object that is a readlines() method, but yes. | 20:51 |
| ddaa | luks: AFAICT hg log is not sorted either, it just print stuff in repository order, which HAPPENS to be topologically sorted. | 20:51 |
| LarstiQ | ddaa: well, already having data in sorted order is nice of course :) | 20:52 |
| adaran | LarstiQ, makes it - on the outside - look as if bzr is very bad at handling large files and/or binary files. =/ | 20:52 |
| LarstiQ | adaran: I don't directly see that, binary lines are still lines. | 20:53 |
| LarstiQ | adaran: and the differ works on (binary) lines. | 20:53 |
| adaran | LarstiQ, yes, but i was more referring to the fact that there are a lot of copies floating around | 20:53 |
| ddaa | It's sorted in a way that depends on how the repository was built (the sequence of "pull" commands), but I'm not sure how much it matter in practice. | 20:54 |
| LarstiQ | adaran: yes, there are multiple file copies around during commit. This is indeed bad for files that don't fit in memory that many times. | 20:55 |
| ddaa | I mean, it's not topologically sorted in a way that only depends on the structure of the history. | 20:55 |
| ddaa | (as bzr log is) | 20:55 |
| LarstiQ | ddaa: ah | 20:55 |
| luks | it just makes the numeric revision ids unusable | 20:55 |
| luks | but it doesn't really affect the log otherwise, as far as I know | 20:55 |
| LarstiQ | luks: they're still stable within one repository though? | 20:56 |
| ddaa | well, it does affect it, but since it's already half unusable by virtue of not being hierarchical, it does not make thing substantially worse. | 20:56 |
| luks | sure, but not across multiple repositories | 20:56 |
| luks | even if used in the same branch, with the same head revision | 20:56 |
| pygi | hi | 20:57 |
| beuno | pygi, hi | 20:57 |
| beuno | I replied to your email :) | 20:57 |
| LarstiQ | adaran: jam said he'd look at possibly having a different codepath for those big files, but didn't follow up. You could comment and ask if there is any progress? | 20:57 |
| LarstiQ | luks: right | 20:58 |
| LarstiQ | luks: so less usable than bzr revnos, but still of some use | 20:58 |
| adaran | LarstiQ, i will drop a comment. though at the moment, it seems tempting to find out how git and others do it, for example | 20:58 |
| pygi | beuno: I saw, thank you sir! | 20:58 |
| pygi | beuno: I just came home, was about to respond later on that I agree with locations.conf stuff | 20:58 |
| LarstiQ | adaran: sure | 20:58 |
| jam | LarstiQ, adaran: I have been invoked, but I don't know the start of the thread | 20:58 |
| LarstiQ | jam: sorry, let me fill you in | 20:59 |
| beuno | pygi, how was your trip back? | 20:59 |
| pygi | beuno: it was ok, thank you :) | 20:59 |
| adaran | jam, don't even attempt to step out of the circle! | 20:59 |
| pygi | beuno: I just wished I don't have a cold, freaking air conditioning! | 20:59 |
| LarstiQ | jam: adaran is experiencing http://pastebin.com/m18f9561 on a pull/branch. Zipping it up, copying and unpacking doesn'y. | 20:59 |
| LarstiQ | jam: with 450mb files, and earlier MemoryErrors if I got that right, the suspicion is memory usage. | 21:00 |
| LarstiQ | sorry, at least one file of size 450mb | 21:00 |
| adaran | jam, LarstiQ i should add that i can branch locally just fine, and remotely (network) on my linux machine. i'm having issues on a virtual machine with windows XP and 378 MB of ram, pagefile < 1,2 GB | 21:00 |
| beuno | pygi, yeah, it was brutal | 21:00 |
| LarstiQ | jam: so I dug up bug 109114 | 21:00 |
| ubottu | Launchpad bug 109114 in bzr "commit holds whole files in memory" [Medium,Confirmed] https://launchpad.net/bugs/109114 | 21:00 |
| adaran | LarstiQ, sorry again, the whole repos is 450 MB or so unzipped, 50 MB bzr transfer, 100 mb zipped. let me find the largest file... | 21:01 |
| jam | I would be rather surprised to get a KnitCorrupt when there is really a MemoryError | 21:01 |
| LarstiQ | jam: which isn't exactly the issue right now, but anyway | 21:01 |
| pygi | beuno: Oh well, at least we got some things done, setup a plan for further work and stuff :p | 21:01 |
| pygi | and it was great to finally meet all of you :) | 21:01 |
| adaran | jam, LarstiQ largest file is 181 MB, text file with short lines | 21:02 |
| LarstiQ | jam: bug 347979 seemed a closer hit, but not really helpful | 21:02 |
| ubottu | Launchpad bug 347979 in bzr "KnitCorrupt listing _KnitGraphIndex when pulling" [Undecided,New] https://launchpad.net/bugs/347979 | 21:02 |
| beuno | pygi, absolutely. Enjoyed it as well | 21:02 |
| jam | adaran: even better, does the file have a final newline? | 21:02 |
| LarstiQ | jam: other than the immediate issue at hand, adaran has some concern about bzr handling big files | 21:02 |
| adaran | jam, yes. \r\n | 21:03 |
| jam | LarstiQ: sure, I've mentioned some specifics in 109114 | 21:03 |
| * LarstiQ nods | 21:03 | |
| jam | and certainly ways we could improve bits | 21:03 |
| LarstiQ | jam: so now we've arrived at the jam invocation :) | 21:03 |
| jam | which essentially resolves into.... we'd like to change some bits as according to 109114, to avoid splitting and joining over and over again | 21:04 |
| adaran | LarstiQ, jam well the other concern is, i've known people that keep their whole $HOME in VCS'es. if it's only a few GB, it's a bit unconventional - but a breeze to backup and replicate | 21:04 |
| jam | adaran: we shouldn't have to keep the content of *all* files in memory at once | 21:04 |
| jam | just one at a time | 21:04 |
| * LarstiQ nods at adaran | 21:04 | |
| jam | So the total size of GB isn't terrible | 21:04 |
| jam | It is the 181MB single large text file of small lines that would be killing you for 'commit' | 21:05 |
| jam | though it shouldn't effect things like 'pull' very much | 21:05 |
| adaran | LarstiQ, jam it looks as if that'd be hardly possible with bzr at the moment - if you had a large picture - which is something you'd want to put in a repository if it was part of an app or a project anyway - you'll run into trouble, especially on a small server with little ram | 21:05 |
| jam | adaran: well, someone is exploring versioning all of 'debian', which is approx 7.5M files | 21:06 |
| adaran | jam, i'm having problems branching and checking out. there's no way for me to tell well though, if i'm running out of memory or not. | 21:06 |
| jam | (num files, not num bytes) | 21:06 |
| adaran | jam, would be nice if it fit on a few floppies though =) | 21:06 |
| adaran | jam, but few big files in there! even if they included binary packages, i'd be rare to see a file above 40 MB or so | 21:07 |
| jam | adaran: your KnitCorrupt traceback is gzip telling us we don't have a valid gzip stream | 21:07 |
| adaran | jam, my other suspect was that embedded python ssh library somehow messing up, but since i'm - at the moment - paid to work instead of fixing bugs in bzr, i decided not to pursue that end, sorry =/ | 21:07 |
| jam | adaran: the embedded ssh lib uses pyCrypto as the ssl handler, and I would be quite surprised if that was specifically buggy | 21:09 |
| jam | not to mention that I use paramiko many times a day | 21:09 |
| jam | and have never seen corruption | 21:09 |
| jam | though it is possible that paramiko is getting a memory error and then supressing it | 21:10 |
| jam | causing us to see a short read that looks corrupted | 21:10 |
| jam | or something like thta | 21:10 |
| jam | that | 21:10 |
| adaran | well, unlikely, yes. but other than that, you haven't run into the error i've encountered a lot, or it would be fixed, i'd assume =) | 21:10 |
| jam | adaran: true, though I don't often version 100+ MB text files, either :) | 21:11 |
| adaran | jam, it's a "test-case" db dump =) | 21:12 |
| Tak | jelmer: http://img39.imageshack.us/img39/3043/mdannotate.png | 21:24 |
| jelmer | Tak, AWESOME | 21:25 |
| jelmer | Tak, Seriously, that's way cool | 21:25 |
| Tak | :-D | 21:27 |
| beuno | jam, any ideas on what this could be: http://paste.ubuntu.com/186006/ | 21:32 |
| beuno | not sure if I should file a bug or not | 21:32 |
| beuno | branch seems broken | 21:33 |
| jam | beuno: well, if it wasn't loggerhead I would say it was a ghost issue | 21:33 |
| jam | but IIRC loggerhead shouldn't have any, right? | 21:34 |
| beuno | all commands error out | 21:34 |
| beuno | right, no ghosts AFAIK | 21:34 |
| jam | Otherwise, it might be: | 21:34 |
| jam | 4392 Canonical.com Patch Queue Manager 2009-05-29 [merge] | 21:34 |
| jam | (jam) Fix bug #373455, allow --dev6 repos to stack. | 21:34 |
| ubottu | Launchpad bug 373455 in bzr "brisbane-core doesn't support stacking but should" [High,Fix committed] https://launchpad.net/bugs/373455 | 21:34 |
| jam | And some issues wrt missing parent inventories and stacking | 21:34 |
| beuno | it's not --dev6 though | 21:34 |
| beuno | its 1.9-r-r | 21:34 |
| jam | beuno: sure, but see: https://code.edge.launchpad.net/~jameinel/bzr/quick-fix/+merge/6948 | 21:35 |
| jam | in case you are using the latest bzr.dev | 21:35 |
| beuno | I'm on 1.15 | 21:35 |
| jam | beuno: if you are using bzr.dev or bzr nightlies, you might try reverting to 4391 | 21:35 |
| beuno | bzr nightlies stopped working :( | 21:35 |
| beuno | jam, did that rev get into 1.15? | 21:36 |
| jam | beuno: I don't think so | 21:36 |
| jam | otherwise 1.15 would have gc stacking :) | 21:36 |
| Tak | oops, forgot one of the cooler parts - http://img39.imageshack.us/img39/5305/mdannotates.png | 21:37 |
| beuno | I wonder if I broke it when doing the upgrades | 21:37 |
| jam | beuno: so the traceback makes it seem like the workingtree thinks it is on revision: 'argentina@gmail.com-20081223183723-7vgehy3i4p6cr1lu' | 21:37 |
| jam | but that revision isn't in your repository | 21:37 |
| jam | which seems pretty strange | 21:37 |
| jam | are you using a lightweight checkout? | 21:38 |
| beuno | htm | 21:38 |
| beuno | hrm | 21:38 |
| beuno | no, it's a branch | 21:38 |
| beuno | now | 21:38 |
| beuno | my loggerhead repo b0rks with bzr check | 21:38 |
| jam | with a shared repo that you copied from elsewhere? and missed other stuff? | 21:38 |
| beuno | it's a shared repo | 21:38 |
| beuno | and I upgraded it to 1.9-r-r | 21:39 |
| beuno | check breaks with: http://paste.ubuntu.com/186013/ | 21:39 |
| beuno | reconcile went through it just fine | 21:40 |
| beuno | jam, any ideas on how to get out of that mess ^ | 21:59 |
| jam | beuno: find a repository with the text key: ('wsgitest.py-20080612051902-5y0zpdi6fhxgun6z-1', 'jelmer@samba.org-20090529150418-05on2fgizfqs77fj') | 22:01 |
| jam | and have it inserted... | 22:01 |
| jam | it looks like you have a revision which mentions a file text which does not actually contain that text | 22:01 |
| jam | which is sort of bad | 22:01 |
| beuno | jam, just an FYI: https://code.edge.launchpad.net/bzr/+activereviews | 22:23 |
| beuno | maybe you know it already | 22:23 |
| beuno | and the bug you filed it so figure out what needs merging | 22:23 |
| jam | beuno: I didn't specifically, but in that case, I would recommend changing the link that exists here: | 22:25 |
| jam | https://code.edge.launchpad.net/~bzr/bzr/trunk | 22:25 |
| jam | I'm not sure why it gives "24 branches proposed for merging" | 22:25 |
| jam | or how you are supposed to reach +activereviews via the web ui | 22:25 |
| Peng_ | You can get to +activereviews from https://code.edge.launchpad.net/bzr | 22:40 |
| mxpxpod | when you do a bzr mv with bzr-svn, will it preserve history of those files? | 23:07 |
| jelmer | mxpxpod, yes | 23:12 |
| mxpxpod | jelmer: thanks | 23:13 |
| ddaa | Oh joy! I can combine hg-fast-export.py and bzr "fast-import" to move history from hg to bzr. | 23:26 |
| ddaa | it gets the order parents the wrong way around, but otherwise it looks like it works | 23:31 |
| beuno | jelmer, did you manage to re-push your smart server branch? | 23:32 |
| jelmer | beuno, yeah, but no luck; launchpad seems to ignore my merge requests | 23:32 |
| jelmer | (probably because it isn't able to deal with the bundle) | 23:32 |
| jelmer | so I'm just going to do the recommit in a few minutes | 23:32 |
| jelmer | from a fresh clone | 23:33 |
| beuno | jelmer, cool. I assigned the bug to you | 23:33 |
| jelmer | oh, I wasn't aware there was a bug open :-) | 23:33 |
| ddaa | mh, rename data is lost in the process :( | 23:34 |
| jelmer | jam, Interesting results from bencode | 23:37 |
| rowinggolfer | I am uncertain as to whether I need to file a bug over a recurring problem I am having. | 23:39 |
| rowinggolfer | http://pastebin.ubuntu.com/186084/ | 23:40 |
| rowinggolfer | everytime I make a push, bzr hangs. | 23:40 |
| rowinggolfer | with a "too many concurrent requests" error. | 23:40 |
| rowinggolfer | I push again... account is locked (naturally) | 23:40 |
| beuno | rowinggolfer, could you upgrade to a newer version of bzr? | 23:41 |
| beuno | and see if it still happens? | 23:41 |
| rowinggolfer | the command line returned for the lock is incorrect. | 23:41 |
| beuno | 1.6 is quite old | 23:41 |
| rowinggolfer | I'm on intrepid. | 23:41 |
| rowinggolfer | beuno: one quick question. | 23:42 |
| beuno | rowinggolfer, use the PPA: https://edge.launchpad.net/~bzr/+archive/ppa | 23:42 |
| rowinggolfer | thanks I will. | 23:42 |
| rowinggolfer | beuno: one quick question | 23:42 |
| beuno | shoot | 23:42 |
| rowinggolfer | I installed ssh-server on this machine. | 23:42 |
| rowinggolfer | and that seems to co-incide with this problem | 23:42 |
| rowinggolfer | ie. 105 commits went ok. | 23:43 |
| rowinggolfer | the last 15 have all had this issue | 23:43 |
| rowinggolfer | my keys wouldn't be messed up perhaps? | 23:43 |
| rowinggolfer | I can't see they would be the same? | 23:43 |
| beuno | can you ssh with no problems? | 23:44 |
| rowinggolfer | to other machines, yes. | 23:44 |
| rowinggolfer | do you mean to a launchpad server? | 23:44 |
| beuno | yes | 23:44 |
| beuno | try: sftp://bazaar.launchpad.net | 23:45 |
| rowinggolfer | sorry, how would I try that? | 23:46 |
| beuno | sorry | 23:46 |
| beuno | try: sftp bazaar.launchpad.net | 23:47 |
| rowinggolfer | beuno - yes. no probs. | 23:48 |
| rowinggolfer | ok.. I'll upgrade my bzr. | 23:48 |
| rowinggolfer | thanks. | 23:48 |
| beuno | rowinggolfer, that way at least we can confirm the bug :) | 23:48 |
| === Kissaki is now known as Kissaki^0ff | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
