| jml | lifeless: it's consistent with the announcement of Launchpad APIs. | 00:04 |
|---|---|---|
| === rocky1 is now known as rocky | ||
| lifeless | jml: I don't understand | 00:15 |
| markh | jam: so I'm looking at disabling auto-detection of plink as (I think :) everyone agreed. This would means that source-code users who do not have paramiko, but do have pageant/plink setup will not work at all without setting BZR_SSH. ie, we will "fix" plink users that don't use pageant at the cost of "breaking" users that use plink + pageant to manage their keys who work today. Is that the intent? | 00:17 |
| lifeless | markh: why disable plink? | 00:20 |
| lifeless | (short answer is fine, I just missed the conversation) | 00:21 |
| markh | plink is unable to correctly interactively prompt for a passphrase | 00:21 |
| markh | it was disable plink *detection* | 00:21 |
| markh | so setting BZR_SSH=plink would still allow it to work | 00:21 |
| lifeless | have we filed a bug about that ? | 00:21 |
| markh | but - the point I was making is that plink works fine is pageant is used (meaning plink doesn't *need* to prompt for the passphrase) | 00:22 |
| lifeless | so can we detect plink+pagent vs plink w/o pagent ? | 00:22 |
| markh | https://bugs.launchpad.net/bzr/+bug/107593 is the closest IIUC | 00:22 |
| ubottu | Launchpad bug 107593 in bzr "bzr unable to ask password for access over bzr+ssh:// or sftp:// when plink.exe used as SSH client" [Low,Fix released] | 00:22 |
| lifeless | markh: well I was meaning in the plink bugtracker :P | 00:22 |
| markh | but the resolution to that was simply to pass a param to plink that stops it even *trying* to prompt :) | 00:23 |
| markh | there is something funky going on with windows consoles | 00:23 |
| markh | plink executed directly works fine | 00:23 |
| markh | so we'd need more research to file a plink bug | 00:23 |
| * markh idly wonders how a windows GUI app could hope for either ssh or plink to prompt for a passphrase... | 00:25 | |
| markh | so - I actually think the status quo is fine. There is almost an expectation that BZR_SSH needs to be set, and I think the current plink default behaviour helps more people than changing it would. | 00:27 |
| markh | and later we can see if we can convince plink to prompt like ssh, and everyone remains happy (except me with ssh.exe on my path, but I digress ;) ) | 00:28 |
| lifeless | markh: sounds fine to me | 00:30 |
| lifeless | FWIW | 00:30 |
| markh | cool - thx! | 00:30 |
| markh | that was my last task for the binaries too (well, apart from releasing them and submitting changes upstream and working out what we do with them once I've uploaded them :) | 00:31 |
| markh | the bzrsvn plugin isn't working that well, but I think there is still value to including it given we aren't trying to call it anything like stable/final | 00:32 |
| lifeless | cool | 00:32 |
| === mark1 is now known as markh | ||
| markh | heh - bzr just logged "... readv() read unknown bytes rather than unknown bytes at unknown for "http:..." - obviously it doesn't know much about that error :) | 01:08 |
| lifeless | jelmer: lol @ gloom | 01:08 |
| poolie_ | hello markh, lifeless | 01:10 |
| === poolie_ is now known as poolie | ||
| markh | hi poolie | 01:10 |
| jelmer | lifeless, (-: | 01:23 |
| jelmer | lifeless, I hadn't realized the meaning of gloom in English | 01:23 |
| fullermd | Now all we need is a command to Dump the Original Outside Metrics... | 01:23 |
| matthew-_ | so I come from a history of using monotone which I want to move away from, I've just discovered some behaviours with Hg that I don't like and wanted to check see what bzr does | 01:37 |
| lifeless | hi | 01:37 |
| matthew-_ | but firstly, does bzr allow you to name branches? | 01:37 |
| lifeless | yes, our model is that every branch is a directory on disk (we do support sharing the repository and having a single working tree that switches between branches) | 01:37 |
| mwhudson | jelmer: :) | 01:37 |
| matthew-_ | lifeless: yeah, I get the model, I just wanted to see if you can give a name to a branch and then for example, switch to that branch just by going bzr update branchname | 01:38 |
| lifeless | matthew-_: yes, 'bzr switch NAME' will look in $branch/../NAME | 01:39 |
| matthew-_ | ahh ok. so the name of a branch isn't meta data that's attached to a revision? | 01:39 |
| lifeless | we store a nickname in revisions | 01:40 |
| lifeless | but its used for bzr viz and other such reporting, not for switching | 01:40 |
| lifeless | the nickname that will be stored defaults to basename(branchdir); but can be forced via 'bzr nick' | 01:40 |
| matthew-_ | ok, so if two people share the same set of revisions, they would have the same branch names for the same revisions? | 01:41 |
| lifeless | uhm yes but I feel like we're not connecting somehow | 01:41 |
| lifeless | we're not at all like hg in our treatment of branches | 01:42 |
| matthew-_ | no I think we are. It's just that mtn assigns quite a lot of semantics to branch names and I just want to see how much that's carried across | 01:42 |
| matthew-_ | yeah, you seem quite different to hg and mtn | 01:42 |
| lifeless | we don't assign any semantic to branch names | 01:42 |
| matthew-_ | ok, so let me give you a scenario | 01:42 |
| matthew-_ | let's say I'm working on the mainline of my project and then I branch to start work on a new feature. My friend then wants to help me with this new feature. So how do I identify to him which branch he should switch to? | 01:43 |
| lifeless | just tell him the url | 01:44 |
| matthew-_ | right, of course, the branch is reflected in the url | 01:44 |
| matthew-_ | I understand. thank you for your patience :) | 01:44 |
| lifeless | happy to help, I'm here all day :) | 01:44 |
| matthew-_ | so my next question is the following. Say I've made some changes, but not committed | 01:45 |
| matthew-_ | I then do a switch to a different branch, or even just an update to a different revision | 01:45 |
| matthew-_ | what would the output of bzr diff be? | 01:45 |
| lifeless | your uncommitted changes | 01:46 |
| matthew-_ | so it takes the diff from the current revision and then reapplies that diff to the new current revision? | 01:47 |
| lifeless | well | 01:48 |
| lifeless | the switch and update operations do a merge | 01:48 |
| lifeless | a merge preserves edits (though they may conflict and if so you get conflicts as a result) | 01:49 |
| matthew-_ | ok, so I probably didn't mean either switch or update ;) How would I change my current directory to be of a different revision? | 01:50 |
| lifeless | switch moves you to a different branch; so that your commits will go to it | 01:51 |
| fullermd | Depends on how deeply you mean that... | 01:51 |
| lifeless | (its the same as switch on svn/git) | 01:51 |
| fullermd | 'revert' will change the contents (and layout, presence, etc) of the files to be like that revision. | 01:51 |
| lifeless | update is used when you have a tree that is out of date with its branch | 01:51 |
| fullermd | But your WT still considers itself to be at whatever revision you were previously at, so e.g. 'diff' will show a lot. | 01:52 |
| matthew-_ | ok, sorry, so many terms get reused between DVCSs and all with different semantics! | 01:52 |
| lifeless | matthew-_: we've tried quite hard to be consistent with cvs/svn on these common commands, because they have market dominance - less relearning for bzr users | 01:53 |
| matthew-_ | ok, so from revision X I add one line to a file. Then I do bzr revert Y where Y came before X. Then bzr diff will show all of the changes necessary to go from Y to X and to add the extra line? | 01:53 |
| matthew-_ | lifeless: sure, I appreciate that. It's just I use neither :) | 01:53 |
| fullermd | No, revert will blow away the uncommitted changes. | 01:54 |
| lifeless | matthew-_: so you add one line | 01:54 |
| lifeless | matthew-_: why do you want to change the revision the tree is at ? | 01:54 |
| fullermd | Its main purpose is its name; 'revert this {file,dir,tree}'. That you can specify 'to a given revision' is fruit on top of that. | 01:54 |
| lifeless | matthew-_: (as in, whats the follow up operation you want to do) | 01:54 |
| matthew-_ | lifeless: say I've done an hour's work, without committing. I then realise that I'm on the wrong branch and I should commit to another branch, and thank goodness, I realise that the file I've altered is the same in both branches, so I should just be able to switch to the head of the branch I want, and commit there, without having to redo my work | 01:55 |
| lifeless | matthew-_: 'bzr switch BRANCH; bzr diff' will show you just the work you've done | 01:56 |
| lifeless | matthew-_: and it is switch you want, because you want to commit to a different branch | 01:56 |
| matthew-_ | ok | 01:56 |
| igc | morning | 01:56 |
| matthew-_ | and what happens if the branch I switch to has altered the file I've worked on but in such a way that the diff still applies cleanly? | 01:57 |
| lifeless | same | 01:57 |
| matthew-_ | right, so it doesn't just apply my changes, it leaves the whole file unaltered | 01:57 |
| fullermd | It's a little smarter than just 'diff'. It's more like if you committed the change, then merged it in the other branch. | 01:58 |
| lifeless | matthew-_: no, it does a merge | 01:59 |
| lifeless | matthew-_: so you only see your uncommitted work, transformed as needed by the merge | 01:59 |
| matthew-_ | ok cool | 02:01 |
| matthew-_ | ok, sorry, I have another question | 02:05 |
| matthew-_ | say I want to start a branch, but I want to start it from a particular revision | 02:05 |
| bob2 | branch -r /url /tosomewhere | 02:06 |
| matthew-_ | how do I get back to that revision in order to create the branch? | 02:06 |
| bob2 | er, -r nnn /url /tosomewhere | 02:06 |
| lifeless | matthew-_: you don't need to go bac to the revision, you just need to give -r to the branch command, as bob2 says | 02:06 |
| matthew-_ | ugh, this is my problem. I'm used to mtn where you normally have a single working directory that you move all over the place, rather than lots of directories | 02:07 |
| matthew-_ | just a mental shift I guess | 02:07 |
| bob2 | sure, that is what 'bzr switch' is for | 02:07 |
| bob2 | create a repository somewhere, check out a branch from it. want a new branch, 'bzr branch . ~/repository/somename', 'bzr switch somename' | 02:07 |
| bob2 | it is a trivial plugin to simplify that to 'bzr tbranch somename' | 02:08 |
| fullermd | Or it could be a useful addition to 'switch'. | 02:14 |
| bob2 | yeah, I wasn't sure how to integrate it into the existing ui | 02:16 |
| fullermd | '-c' to create the branch (based on the current by default) and -r to specify a revision to start it from (which could include branch: revspecs or the like to specify a different one) | 02:17 |
| fullermd | (I don't say that's the best; just the most obvious) | 02:17 |
| matthew-_ | sorry, is there an ENV Var to set to force merge to use a nice tool? | 02:21 |
| fullermd | I think there's a bzr plugin for meld... | 02:22 |
| bob2 | dunno, but unclean merges leave the 2/3 sources files on disk so you can use any merge tool you like | 02:23 |
| matthew-_ | err, I want to force it to use xxdiff | 02:23 |
| matthew-_ | it won't automatically fire it up for me somehow? | 02:23 |
| fullermd | Well, the existence of meld is the extent of my knowledge of "nice tool"s for merge ;) | 02:23 |
| markh | jelmer: for some reason, bzrsvn is causing blackbox.test_check.ChrootedCheckTests.test_check_missing_branch to hang for me. It stops hanging with --no-plugins, or if I manually remove just svn. It seems to be reading from a socket, but I haven't dug any deeper. Any clues? | 02:25 |
| jelmer | markh: No, sorry. I would guess it's related to the custom log function bzr-svn registers | 02:25 |
| matthew-_ | ahh, extmerge is clearly what I want http://erik.bagfors.nu/bzr-plugins/extmerge/ | 02:25 |
| jelmer | markh, seems strange it would hang in a socket operation though | 02:26 |
| spiv | matthew-_: you can also do "bzr diff --using xxdiff" I think | 02:26 |
| === BasicTheProgram is now known as Basic | ||
| jelmer | markh, if you comment out the custom log code in __init__.py:160, does that fix it? | 02:27 |
| markh | that was just a very quick break into the debugger with no symbolic info... I'll try and repro it from a source version | 02:27 |
| markh | apparently not :( | 02:29 |
| jelmer | markh, where is it hanging then? | 02:30 |
| markh | sorry - commenting 160-163 had no effect | 02:31 |
| markh | bugger - source version is failing that test with an earlier pycurl error. I'll dig a little and see what i find. | 02:33 |
| jelmer | this is probably related to the bug spiv filed | 02:34 |
| jam | markh: I think the chance of someone using bzr +plink without paramiko is vanishingly small, and shouldn't be optimized for | 02:38 |
| jam | paramiko is about 90% away from a "requires" | 02:39 |
| jam | Especially if you are writing an installer | 02:39 |
| jam | we would bundle it | 02:39 |
| jam | So I think moving the plink autodetect to *after* paramiko is fine | 02:39 |
| markh | jam: I'd say the chance of someone using passphrase protected keys with plink on their path but without pageant is approaching zero too. | 02:40 |
| matthew-_ | ahh, so visualise doesn't show all heads of all branchs in the current repo. It just shows the head of the current branch | 02:41 |
| jam | markh: well, if pageant would find the keys for me, I might actually use it :) | 02:41 |
| markh | sure - but as you dont it will not be on your path, so no problem :) | 02:41 |
| jam | matthew-_: ATM, I think there has been work to allow it to show more heads | 02:41 |
| jam | markh: agreed, no problem | 02:42 |
| jam | the problem with plink isn't with keys | 02:42 |
| markh | (otoh, I think its reasonable it *may* be on your path, likes its reasonable ssh may be on mine, which is why I think paramiko is a better default, but I think we've done that already ;) | 02:42 |
| jam | it is that you can't prompt for *any* password | 02:42 |
| jam | markh: so with plink you can't access a password-protected page | 02:42 |
| jam | but you *can* with paramiko | 02:42 |
| markh | right - paramike seems to have everything going for it ;) | 02:43 |
| jam | over plink, yes | 02:43 |
| jam | over ssh, no | 02:43 |
| jam | at least IMO | 02:43 |
| jam | you can't really configure plink to use a config | 02:43 |
| jam | without passing in a command line option | 02:43 |
| jam | you *can* for ssh | 02:43 |
| fullermd | matthew-_: vis can show multiple branches at a time, but normally it just shows your current branch. | 02:44 |
| markh | I think we should wait for the "bug" reports before making things more convoluted. At least the status-quo of "we try and find known ssh vendors on your path, or fall back to paramiko" is easy to explain, and as you point out, setting BZR_SSH isn't hard either - especially when "fixing" plink and/or paramiko to overcome the limitations we are discussing would also change the "best" defaults IMO. | 02:47 |
| jam | jelmer: just to mention, you probably shouldn't do "getattr()" on the plugins, but try a "try import except ImportError" | 02:50 |
| jam | Because you don't know that loom will be imported *before* gtk | 02:50 |
| lifeless | jam: hi | 02:50 |
| jam | hi lifeless | 02:50 |
| lifeless | jam: did you change mail client a month or so back? | 02:50 |
| lifeless | you seem to be quoting much more than you used to | 02:50 |
| jam | lifeless: still using T-bird, why? | 02:50 |
| * igc lunch | 02:50 | |
| jam | probably just depends on my mood | 02:51 |
| lifeless | its a little weird to quote 40-50 lines to reply with 7 | 02:51 |
| lifeless | IMNSHO | 02:51 |
| markh | jelmer: it appears to be in SvnRemoteFormat._open | 02:52 |
| markh | then calling into ra.pyd, which presumably is remote.SvnRemoteAccess | 02:53 |
| jam | lifeless: It would be weirder if I edited *some* of the message but left the rest | 02:53 |
| jam | in this case I just hit reply | 02:53 |
| jam | and replied | 02:53 |
| jam | better than top-posting, IMO | 02:54 |
| lifeless | lol.. ok | 02:54 |
| lifeless | I just thought I'd mention it, because I've had a feeling of wading through quotes to try and find your comments recently | 02:54 |
| === Verterok_ is now known as Verterok | ||
| jam | I'll try to be a bit more terse | 02:55 |
| jelmer | jam, thanks, fixed now | 02:55 |
| lifeless | its not a big deal | 02:55 |
| matthew-_ | ok, I'm confused, again! | 02:57 |
| lifeless | matthew-_: shoot | 02:57 |
| matthew-_ | if I do init-repo --no-trees repo; init repo/trunk; co --lightweight repo/trunk trunk; cd trunk | 02:58 |
| matthew-_ | then commits get sent to repo/trunk | 02:58 |
| lifeless | yes | 02:58 |
| matthew-_ | so it would appear that it's bound to the repo | 02:58 |
| matthew-_ | but unbind says it's not bound to anything | 02:58 |
| lifeless | hmm, bit of plumbing exposed here | 02:58 |
| lifeless | so the --lightweight option means that 'trunk' has no branch object | 02:59 |
| jelmer | markh: So it's probably attempting to open the path specified as a subversion repo | 02:59 |
| lifeless | 'bound branches' are what you get if you omit the --lightweight parameter | 02:59 |
| jelmer | markh: I wouldn't know why that would cause a hang though | 02:59 |
| matthew-_ | ok | 02:59 |
| matthew-_ | so why is there no --lightweight option to branch? | 02:59 |
| lifeless | 'bound branches' are a way to emulate cvs/svn's tree facility while still having full local history | 02:59 |
| matthew-_ | yes, I understand that | 02:59 |
| markh | jam: your last mail said you yourself stick cygwin\bin on your path, and given ssh-agent is almost impossible to use for mere-mortals on Windows, I'm surprised you think it is the "extreme minority" case that people will have an ssh.exe on their path even though they use pageant to manage their keys and use ssh.exe rarely, if at all. But I guess we just have to agree to disagree :) | 02:59 |
| jelmer | markh, what specifically is it hanging on? | 03:00 |
| jelmer | file handle? | 03:00 |
| matthew-_ | because, in trunk, say I do a branch . ../mybranch; cd ../mybranch; nick mybranch | 03:00 |
| jam | markh: well, *I* want to use ssh.exe | 03:00 |
| lifeless | matthew-_: well, because branch makes a new branch object. We could possibly do --lightweight; however there is a command in bzrtools that you may like | 03:00 |
| matthew-_ | I then want commits to go to repo/mybranch | 03:00 |
| jam | markh: that is why I put it in my path | 03:00 |
| lifeless | matthew-_: alled 'cbranch' | 03:00 |
| lifeless | matthew-_: well, you probably want to do 'bzr branch repo/trunk repo/mybranch' bzr switch mybranch | 03:01 |
| markh | jam: I fully understand that, but its just I'd think *you* are in the extreme minority for a windows developer in this regard ;) | 03:01 |
| markh | I want to use various cygwin tools - that's why its on my path | 03:01 |
| jam | markh: I think the effort to put things in your path means you want them there | 03:01 |
| matthew-_ | lifeless: ahh! brilliant, thank you | 03:01 |
| markh | and I'm not so careful to remove every tool I don't currently use | 03:01 |
| jam | I think for *real* windows developers, they don't use cygwin | 03:01 |
| lifeless | matthew-_: broad description - you want all your branches as repo/BRANCHNAME | 03:02 |
| lifeless | and you want one lightweight checkout somewhere else | 03:02 |
| markh | I don't use *everything* in my cygwin dir directly - but lots of build processes do. | 03:02 |
| lifeless | switch in that checkout will accept just BRANCHNAME | 03:02 |
| lifeless | most other commands want a longer relative or absolute path | 03:02 |
| matthew-_ | lifeless: right. this is closer to the mtn model I'm used to than I thought | 03:02 |
| lifeless | this is a bug - the logic for switch just needs to be hooked into these other commands | 03:02 |
| markh | jam: is that because they don't understand them, or have alternatives for everything cygwin provides? | 03:03 |
| lifeless | matthew-_: is that good or bad ? :) | 03:03 |
| markh | all windows developers I know use them! | 03:03 |
| matthew-_ | good, for me ;) | 03:03 |
| lifeless | cool | 03:03 |
| markh | I'd go so far to say "any windows developer who regularly uses the command prompt would use them". My concern is that includes our "target" developer, particularly in the early days until the GUIs get better. | 03:04 |
| markh | s/any/many/ ;) | 03:04 |
| matthew-_ | lifeless: ahh, but it doesn't seem to like switching when you have divergence | 03:05 |
| markh | jelmer: sorry - it seems to be reading a socket, but I've not got symbolic info for the svn binaries | 03:06 |
| matthew-_ | I don't want to merge. I just want to change my lightweight checkout to a different branch | 03:06 |
| lifeless | spiv: http://rafb.net/p/0xKkTQ77.html | 03:06 |
| lifeless | matthew-_: thats what switch does | 03:06 |
| lifeless | matthew-_: what is happening | 03:06 |
| matthew-_ | but it tried to do a merge. I was ci'd and everything | 03:06 |
| markh | top of the stack is ntdll.dll, then below that is mswsock.dll, and below that ws2_32.dll, so that sure smells like a socket :) | 03:07 |
| lifeless | matthew-_: the machinery of merge is whats used | 03:07 |
| lifeless | matthew-_: so thats not surprising. Tell me what happened though | 03:07 |
| jam | markh: I can agree with that, and if pageant +plink wasn't so crummy I would be fine putting paramiko first | 03:07 |
| jam | but as it stands | 03:07 |
| jam | pageant can't find a ssh-key | 03:07 |
| jam | unless you add it every time you boot | 03:07 |
| jam | whereas ssh.exe can find it in its "standard" location | 03:08 |
| matthew-_ | ok. so I added a file with some lines and ci'd. Then I branched. Then, still in trunk, I added some more lines, ci'd. Then I switched to the new branch, added further lines (creating devergence) and ci'd. So far so good | 03:08 |
| matthew-_ | then I switched back to trunk and it tried to merge | 03:08 |
| matthew-_ | which I didn't want | 03:08 |
| lifeless | matthew-_: what do you mean by tried to merge ? | 03:09 |
| jam | matthew-_: you might be confused by the progress bar | 03:09 |
| jam | it shouldn't merge the changes | 03:09 |
| lifeless | (I use switch with diverged branches *all the time*) | 03:09 |
| jam | just uses the "merge" logic to safely reset your tree | 03:09 |
| matthew-_ | no, I got file.THIS, file.OTHER, file.BASE | 03:09 |
| lifeless | matthew-_: did it leave the wrong content in your tree? | 03:09 |
| matthew-_ | yes | 03:09 |
| jam | matthew-_: hm... I haven't seen that | 03:09 |
| lifeless | ok, run bzr st | 03:09 |
| lifeless | do you have pending merges? | 03:09 |
| markh | jam: and you use ssh-agent, correct? | 03:10 |
| matthew-_ | err, I hit bzr revert in order to tidy up the mess ;) | 03:10 |
| jam | markh: occasionally, but not all the time | 03:10 |
| matthew-_ | let me try again | 03:10 |
| jam | the problem is you can't get it to start at the beginning | 03:10 |
| jam | so I just type my password a lot | 03:10 |
| jam | but if it couldn't find the key, then I couldn't connect to LP | 03:11 |
| jam | at one point I had a hacked up startup script | 03:11 |
| jam | that would check if ssh-agent was started | 03:11 |
| jam | if not, start it, and save the env vars | 03:11 |
| jam | so the next bash shell would re-use it | 03:11 |
| markh | jam: right - and as paramiko can prompt for passphrases, your only practical issue with paramiko being the default is that HOME is set differently in a cygwin environment than a "normal" one, so the same keys aren't found by paramiko? | 03:11 |
| jam | but then the prompt would hang when you exit, etc | 03:11 |
| matthew-_ | lifeless: I didn't nick the new branch. is that important? | 03:11 |
| matthew-_ | it's just the path that's important right? not the nick? | 03:12 |
| lifeless | matthew-_: not important | 03:12 |
| jam | markh: well, and when I *do* use the agent I can't with paramiko | 03:12 |
| jam | and pageant being worse... | 03:12 |
| matthew-_ | ok, I must have done something wrong. It is behaving as you describe. sorry, my fault. | 03:13 |
| markh | I certainly understand where you are coming from - I guess the question is - who is in the smallest minority, as they should probably take the "pain" of setting BZR_SSH. So we are back to agreeing to disagree about who that is ;) | 03:13 |
| lifeless | matthew-_: I would wager you had uncommitted changes that conflicted | 03:14 |
| markh | I'd say ssh-agent is such a world of hurt that its use is absolutely tiny - you are the first person I've ever met who uses it on windows. I understand why you do though. | 03:14 |
| mwhudson | jelmer: here-p? | 03:15 |
| jelmer | mwhudson: Hello | 03:16 |
| mwhudson | jelmer: thumper would like to talk to you :) | 03:16 |
| jam | well, even if you explicitly install cygwin, you have to install openssh as well | 03:16 |
| thumper | jelmer: hi | 03:16 |
| thumper | jelmer: we're talking about bzr-svn | 03:16 |
| jelmer | mwhudson, He's too shy to say that himself ? :-) | 03:16 |
| jelmer | thumper, hi! | 03:16 |
| markh | jelmer: I can probably extract more of the stack trace if you are interested? | 03:16 |
| thumper | jelmer: and when the version 4 mapping will be available | 03:16 |
| markh | python stack trace | 03:16 |
| mwhudson | we're doing the 'bzr-svn for code imports' conversation again | 03:16 |
| jam | well, plink is far worse than ssh.exe | 03:16 |
| thumper | jelmer: I was trying to get mwhudson to be the typer | 03:16 |
| matthew-_ | ok, thanks very much for all your help. I think I shall be using bzr from now on :) | 03:16 |
| jam | regardless the agent | 03:16 |
| jml | but this time we are all in a room! | 03:17 |
| thumper | jelmer: except you | 03:17 |
| mwhudson | jml: irc has rooms, right? | 03:17 |
| jelmer | markh: yeah, that would probably be useful | 03:17 |
| markh | we agree about how poor pageant is in those cases - just seem to disagree how many people use it over ssh-agent anyway :) | 03:17 |
| jelmer | Heh | 03:17 |
| jelmer | So it may be a good idea to list what mapping version 4 is going to be exactly | 03:18 |
| lifeless | matthew-_: cool | 03:18 |
| thumper | yeah, something like that | 03:18 |
| jelmer | It's mainly about supporting the storage of bzr metadata in revision properties | 03:18 |
| jelmer | and removal of branching schemes | 03:18 |
| thumper | ok | 03:18 |
| jelmer | and whatever happens to be around by the time it's put out | 03:18 |
| thumper | jelmer: and this would be when? | 03:18 |
| lifeless | jml: I am still confused about this xmlrpc thing | 03:19 |
| lifeless | spiv: can you tell me if that test looks plausible to you | 03:19 |
| thumper | lifeless: it is a way to call methods on a remote machine :) | 03:19 |
| jelmer | Hopefully 0.4.11 + 1 or 2 months | 03:20 |
| jml | lifeless: So, we've published the requestMirror method over Launchpad APIs. The client library (and documentation) isn't released yet.p | 03:20 |
| jelmer | (0.4.11 is intended to be released together with bzr 1.6) | 03:20 |
| lifeless | jml: so the bug isn't fixed - I as a user can't use it yet | 03:21 |
| lifeless | jml: if I could, I could patch bzr's launchpad plugin to let 'bzr push' trigger a mirror | 03:21 |
| jml | lifeless: the bug is fixed in Launchpad Bazaar. | 03:22 |
| lifeless | so where is it not fixed, can we add a task on that | 03:22 |
| jelmer | most of the other possible candidates for inclusion in mappingv4 rely on changes in bzr core | 03:23 |
| jml | lifeless: Launchpad. If you add a task, I'll have to mark it as a duplicate of whatever bug is releasing the client API. | 03:23 |
| jelmer | for the list, see https://bugs.edge.launchpad.net/bzr-svn/+bugs?field.tag=requires-mapping-upgrade | 03:23 |
| lifeless | I think you are saying 'jml has no more code to write to make this work', which is fine; I'm saying 'I want the bug to be marked closed when I can use it' | 03:24 |
| markh | jelmer: see /msg | 03:24 |
| wgrant | How can I convince bzr to not attempt bzr+http? It seems to be disagreeing with SourceForge's Subversion server. | 03:25 |
| jelmer | wgrant, svn+http:// | 03:25 |
| wgrant | jelmer: Aha, thanks. | 03:25 |
| jelmer | wgrant: although it should work even if there's no bzr server remotely - what error are you getting? | 03:25 |
| wgrant | jelmer: It's SF's fault: | 03:25 |
| wgrant | Connection error: while sending POST /svnroot/ivle/trunk/.bzr/smart: (104, 'Connection reset by peer') | 03:26 |
| matthew-_ | is there some way to get bzr to show you all the branches in a given repo? | 03:26 |
| matthew-_ | or do you just tend to do an ls and assume the same layout model? | 03:27 |
| bob2 | matthew-_: bzr branches | 03:27 |
| lifeless | bzr branches PREFIX | 03:27 |
| lifeless | matthew-_: but yeah, I use shell tab completion :P | 03:27 |
| matthew-_ | ahh, it needs the path to the repo. ok, thanks | 03:27 |
| lifeless | matthew-_: repositories are purely storage otimisation | 03:28 |
| matthew-_ | indeed | 03:28 |
| lifeless | matthew-_: they aren't part of the semantic of commands | 03:28 |
| spiv | lifeless: that does look plausible, yeah. | 03:28 |
| wgrant | jelmer: It seems that SF is just very broken at the moment. Sorry for the noise. | 03:28 |
| matthew-_ | ok. so with mtn I wrote the tab completion for branches and there you have an attached repo, which is a sqlite db | 03:28 |
| jelmer | wgrant, they sent out an email announcing downtime for ~12 hours | 03:29 |
| jelmer | wgrant, apparently work on performance improvements | 03:29 |
| wgrant | It has been ridiculously slow for a couple of weeks. | 03:29 |
| wgrant | Minutes to commit a trivial change. | 03:29 |
| jelmer | *.nz: Still there? | 03:29 |
| jml | jelmer: yes. | 03:29 |
| matthew-_ | oh, branches can't be nested? | 03:30 |
| thumper | jelmer: we're talking again | 03:30 |
| mwhudson | jelmer: sorry | 03:31 |
| thumper | jelmer: I think I'm pretty much done, I was just wondering about timings | 03:31 |
| bob2 | matthew-_: as in /repo/a and /repo/a/b are branches? they can. | 03:31 |
| lifeless | matthew-_: yah. One reason we use regular directories is to allow standard toolchains like bash, nautilus etc to all be useful directly | 03:32 |
| matthew-_ | sorry, I'm an idiot. I created the branch and forgot to switch to it | 03:33 |
| lifeless | :P | 03:34 |
| jelmer | thumper: Within one or two months after bzr 1.6 is released I think | 03:35 |
| jelmer | The main thing left to be done is tests for the upgrade from v3 to v4 mappings | 03:35 |
| thumper | jelmer: ok, thanks | 03:35 |
| * jelmer gets some sleep | 03:38 | |
| matthew-_ | another question, with mtn, you commit locally, then sync with your shared repo across the network. syncing is both push and pull but does that for all branches at the same time. How would you do this for bzr? Do you have to do a push and pull for every branch? | 03:47 |
| matthew-_ | ahh ignore that, I've found repo-push | 03:53 |
| lifeless | matthew-_: indeed; this is one of the things in mtn that is clever but doesn't work that well IMO | 03:55 |
| lifeless | matthew-_: because you can't keep a private branch due to it always doing a full sync; the network sync logic depends on a full convergence for performance | 03:56 |
| fullermd | The result is that I've ended up doing horrible hacks like having 2 mtn repos and very carefully crafted setups to have the private branches :| | 04:07 |
| lifeless | fullermd: or use bzr :P | 04:08 |
| fullermd | Well, I do that where possible :p | 04:08 |
| fullermd | I'm waiting for Samba to move to mtn, so jelmer writes bzr-mtn... | 04:08 |
| lifeless | cjwatson: ping | 04:12 |
| jam | fullermd: doesn't mtn allow you to slightly modify history, by attaching a new certificate? | 04:12 |
| lifeless | jam: annotate history I would say | 04:13 |
| jam | not so much modify, as annotate/extend | 04:13 |
| fullermd | Well, that's how you merge [propogate], but... | 04:13 |
| bob2 | matthew-_: there is a 'repo-push' plugin | 04:14 |
| jam | bob2: yeah, he mentioned it already :) | 04:15 |
| bob2 | bah, oops | 04:15 |
| jdobrien | any idea why a selftest run with -q would have different results than -v | 04:41 |
| jdobrien | my blackbox tests has 3 tests...with -v (failures=2) with -q (failures=3) | 04:42 |
| Odd_Bloke | jdobrien: That suggests that there's something wrong with the blackbox tests. How are you invoking bzr? | 04:45 |
| lifeless | jdobrien: interesting | 04:45 |
| jdobrien | Odd_Bloke: ./bzr selftest RelativePathStatus | 04:48 |
| jdobrien | this is a new set of blackbox tests | 04:48 |
| jdobrien | there are 3 tests in all | 04:49 |
| jdobrien | 2 are expected to fail | 04:49 |
| jdobrien | (failures-2) when ./bzr selftest RelativePathStatus | 04:49 |
| jdobrien | (failures=3) when ./bzr selftest -q RelativePathStatus | 04:50 |
| jdobrien | why i am using -q with only 3 tests is related to my laziness :-) | 04:51 |
| lifeless | jdobrien: I've never used -q with selftest | 04:52 |
| lifeless | jdobrien: you'll need to debug the failure that is caused | 04:52 |
| jdobrien | indeed | 04:52 |
| jdobrien | lifeless: indeed | 04:52 |
| * meteoroid just started a new project using svn and populated it with bzr-svn | 04:52 | |
| mwhudson | beuno: still awake? | 04:56 |
| beuno | mwhudson, yeap | 04:56 |
| mwhudson | so i'm looking at fix_setup | 04:57 |
| mwhudson | and seeing some things that don't appear to make heaps of sense | 04:57 |
| mwhudson | like | 04:58 |
| mwhudson | class InstallData(install_data): | 04:58 |
| mwhudson | def run(self): | 04:58 |
| mwhudson | install_data.run(self) | 04:58 |
| lifeless | mwhudson: ping; what do you know about buffer objects ? | 04:58 |
| mwhudson | lifeless: as in 'things returned by the buffer() builtin' ? | 04:58 |
| lifeless | http://python.active-venture.com/api/bufferObjects.html | 04:58 |
| lifeless | PyBufferProcs | 04:58 |
| mwhudson | oh that | 04:59 |
| beuno | mwhudson, ah, right. THat used to do more things, but then I moved it around. I left if as-is because I wasn't sure how complex the installer will get | 04:59 |
| beuno | (doesn't jsutify it, just explains it) | 04:59 |
| mwhudson | beuno: i think i'd call yagni for now | 04:59 |
| mwhudson | beuno: also, there are both unecessary and missing imports | 04:59 |
| beuno | distuils leftovers? | 05:00 |
| mwhudson | lifeless: i know some stuff, what do you want to know? | 05:00 |
| mwhudson | beuno: yeah | 05:00 |
| mwhudson | beuno: and missing the import of bzrlib.errors | 05:00 |
| lifeless | mwhudson: well, we do a lot of parsing | 05:00 |
| lifeless | mwhudson: I'm wondering if we can use buffer objects to expose the raw data we have (which starts out as a python string because we get it over a transport) as a string, without causing a mem copy | 05:01 |
| beuno | mwhudson, ok, I'll fix that. I'm also tempted to add an uninstaller, and move the dependency-checking to somewhere we can re-use | 05:01 |
| lifeless | PyStringFrom* copies AFAIK | 05:01 |
| mwhudson | beuno: i think the ultimate installation thingy is going to be 'apt-get' | 05:01 |
| mwhudson | beuno: so i wouldn't bother too much with an uninstaller | 05:02 |
| lifeless | beuno: I suggest you don't do dep checking or uninstallers | 05:02 |
| mwhudson | lifeless: you can't export it _as a string_ without copying | 05:02 |
| lifeless | beuno: because they will both break badly, routinely, and you'll be in the job of writing a build tool | 05:02 |
| mwhudson | (PyString's own their buffers) | 05:02 |
| lifeless | mwhudson: something implementing the string protocol then, and as fast. ;) | 05:03 |
| beuno | mwhudson, I agree, and jelmer has already packaged it, and is waiting for a release | 05:03 |
| lifeless | beuno: two reasons not to do dep checking - installation is orthogonal to execution | 05:03 |
| beuno | lifeless, makes sense. I may of been a bit over-cautious since dependency used to be a bit hell-ish | 05:03 |
| lifeless | beuno: and it can be problematic to do well anyhow | 05:04 |
| mwhudson | lifeless: maybe | 05:04 |
| lifeless | mwhudson: top level goal: | 05:04 |
| lifeless | actually, it starts out as the output from zlib.decompress() | 05:04 |
| beuno | ok, so, remove dependency checking, fix sloppy imports, and remove un-needed class | 05:04 |
| mwhudson | beuno: right | 05:04 |
| lifeless | which happens to be a python strign because we use pythons zlib wrapper; but we could change that | 05:04 |
| beuno | I may even do it now. DebConf is starting, and I'm housing Debian Developers at my place, so I can't do anything else :) | 05:05 |
| * beuno fires up vim | 05:05 | |
| mwhudson | heh | 05:05 |
| lifeless | mwhudson: top level goal: take a 20MB region of memory, and iterate over a couple thousand full texts which have been compressed into that region | 05:06 |
| lifeless | do that as quickly as possible | 05:06 |
| mwhudson | lifeless: it sounds like buffer objects might help there | 05:07 |
| mwhudson | how do you find the fulltexts? | 05:07 |
| lifeless | the iterator needs to expose a few things, the key of the text, the sha1 (which we validate by sha1ing the fulltext when its extracted) | 05:08 |
| lifeless | each full text is a obtained by processing a recipe contained within the region of memory | 05:08 |
| lifeless | a recipe is a series of control codes; one code is 'insert', the other is 'copy' | 05:09 |
| lifeless | copy references bytes from earlier in the region | 05:09 |
| lifeless | insert embeds new bytes for the fulltext inline in the control data | 05:10 |
| mwhudson | lifeless: "hmm" | 05:11 |
| lifeless | so I can generate the sha by feeding the bytes referenced through a sha object, and giving them to the user at the same time; but there is no need to copy them them (the cost of copy is not the memcpy; its the allocation overhead) | 05:12 |
| mwhudson | it seems that you can feed buffer(bigstring, start, stop) objects into sha | 05:13 |
| lifeless | ok | 05:14 |
| mwhudson | i wouldn't be _entirely_ certain that this won't end up being copied in the sha code | 05:14 |
| mwhudson | but i'd hope not | 05:14 |
| lifeless | it shouldn't be | 05:15 |
| lifeless | is buffer() available in 2.4? | 05:15 |
| mwhudson | (and you can tell my hard drive died fairly recently, i don't have the cpython source here) | 05:15 |
| mwhudson | buffer() is pretty seriously ancient | 05:15 |
| lifeless | also, this is for an extension module | 05:15 |
| mwhudson | any python released in the last ten years or so should be ok | 05:15 |
| lifeless | I don't care if the python version is _fast_, rather that its _clear_ | 05:15 |
| mwhudson | er | 05:16 |
| mwhudson | then i don't entirely understand | 05:17 |
| lifeless | :) | 05:18 |
| mwhudson | (probably because my brain has about the consistency of blancmange by now) | 05:18 |
| beuno | mwhudson, tweaked and pushed | 05:18 |
| lifeless | here, have some red spraypaint | 05:18 |
| mwhudson | but on the one hand you care about speed and on apparently the same hand you don't? | 05:19 |
| lifeless | mwhudson: do you know the bzr policy for extension modules? | 05:19 |
| mwhudson | lifeless: yes, so you're talking about things like patiencediff_py vs patiencediff_c ? | 05:19 |
| lifeless | yes - we keep a python implementation for things we write extension modules of; | 05:19 |
| lifeless | the python implementation focuses on clarity and being easy to debug in the effect that something needs analysis | 05:20 |
| lifeless | the C/pyrex version focuses on being the fastest possible implementation | 05:20 |
| mwhudson | so where do you want to use buffer objects for efficiency? | 05:20 |
| lifeless | in the C/pyrex version | 05:20 |
| mwhudson | ah | 05:20 |
| lifeless | e.g. we might even look at have a prefixed instruction-count length so we could preallocate the right length instruction object count and so on | 05:22 |
| mwhudson | so you'll be doing PyImport_ImportModule("sha") &c ? | 05:22 |
| lifeless | the sha part is not important to our discussion | 05:23 |
| lifeless | it was an example of where I know how to do zero-copy already | 05:23 |
| mwhudson | ah | 05:23 |
| lifeless | though being able to do it with roughly python code is easier ;P | 05:24 |
| mwhudson | so i guess a buffer object is basically a pyobject header, a char* and a pair of indexes | 05:27 |
| mwhudson | and some implementations of sequence methods | 05:27 |
| mwhudson | but if you're writing c already, i'm not quite sure why you'd want it | 05:27 |
| lifeless | mwhudson: because its smaller than strings, and less memory writes are good; because I can probably work up a array allocatable version of it so we can alloc an array and do in-place initialization etc | 05:29 |
| mwhudson | lifeless: but i guess don't know why you'd use buffer objects over just passing pairs of ints around in your code | 05:29 |
| lifeless | mwhudson: because the code exposes an iterator to random python usage | 05:30 |
| lifeless | 14:06 < lifeless> mwhudson: top level goal: take a 20MB region of memory, and iterate over a couple thousand full texts which have been compressed into that region | 05:30 |
| mwhudson | lifeless: _ah_ | 05:30 |
| mwhudson | lifeless: wasn't clear there that the client of the code was python | 05:30 |
| mwhudson | (to me) | 05:30 |
| lifeless | thats ok | 05:30 |
| lifeless | unclarity FTW | 05:31 |
| mwhudson | :) | 05:31 |
| mwhudson | so yes, having your iterator return buffer objects would appear to make sense | 05:32 |
| poolie | lifeless: i think you or abentley told me the other day you thought autopacking would fail on a stacked repositoyr | 05:33 |
| poolie | my test for that is not failing | 05:33 |
| lifeless | poolie: cool | 05:33 |
| poolie | i'm going to poke at it a bit more and make sure it's actually exercising it properly | 05:33 |
| lifeless | autopacking and packing should behave the same | 05:33 |
| poolie | i'm just changing a one line file and maybe that's always storing fulltextst therefore not relevant | 05:33 |
| lifeless | so you don't need to fiddle the code to trigger an auto pack boundary | 05:34 |
| lifeless | the easiest test would be | 05:34 |
| lifeless | one (say 10-line) file | 05:34 |
| lifeless | branch --stacked | 05:34 |
| lifeless | commit a line line change | 05:34 |
| lifeless | run pack | 05:34 |
| poolie | sure | 05:34 |
| poolie | that's what i'm doing | 05:34 |
| mwhudson | lifeless: so i expect the python code will probably have to be a little careful to avoid effectively converting the returned buffers into strings and so copying the data anyway | 05:34 |
| lifeless | poolie: that *could* be creating a fulltext | 05:35 |
| lifeless | so a more sophisticated test | 05:35 |
| poolie | mm | 05:35 |
| lifeless | base branch, 10 line file | 05:35 |
| lifeless | branch stacked | 05:35 |
| lifeless | in the base branch commit a 1 line change | 05:35 |
| lifeless | scratch that | 05:35 |
| lifeless | in a third branch made from the base | 05:35 |
| lifeless | commit a 1 line change | 05:35 |
| lifeless | then pull the third branch into the stacked one | 05:35 |
| lifeless | that should guarantee a delta | 05:36 |
| lifeless | then pack | 05:36 |
| lifeless | igc: you have mail heading your way; its a little brief sorry - I'm fighting some sinus thing this week, got a permanent headache :( | 05:40 |
| mwhudson | beuno: | 05:43 |
| mwhudson | cmdclass={'install_data':install_data} | 05:43 |
| mwhudson | that's not doing anything, right? | 05:43 |
| beuno | mwhudson, it *should* run install_data | 05:45 |
| mwhudson | but what that does is change the install_data command to run ... the default install_data command | 05:46 |
| mwhudson | i think | 05:46 |
| mwhudson | i guess i should test it :) | 05:46 |
| beuno | it's the first time I've fiddled with distutils, so I'm not 100% sure on anything :) | 05:46 |
| beuno | hm, it doesn't seem to do anything after all... | 05:47 |
| markh | yeah, that overrides how 'install_data' is run - but doesn't force that cmd to be run | 05:47 |
| markh | you probably also need data_files or something | 05:47 |
| === mario_ is now known as pygi | ||
| beuno | markh, ah, it makes sense now | 05:48 |
| beuno | thanks :) | 05:48 |
| markh | np :) | 05:48 |
| * beuno removes, commits, pushes | 05:48 | |
| beuno | it makes a lot of sense actually | 05:49 |
| * beuno 's lightbulb just lit | 05:49 | |
| mwhudson | beuno: oh, i made some tweaks of my own and merged the branch | 05:50 |
| mwhudson | beuno: i guess we should see if we made the same changes :) | 05:50 |
| beuno | mwhudson, heh, right. I'm just happy to scratch one more release-critical bug off the list | 05:51 |
| mwhudson | well, i removed the import too | 05:51 |
| beuno | ok, yours was better then :p | 05:51 |
| mwhudson | beuno: bug 242270 would be nice | 05:51 |
| ubottu | Launchpad bug 242270 in loggerhead/1.6 "Directory listing page doesn't use a template" [High,Confirmed] https://launchpad.net/bugs/242270 | 05:51 |
| beuno | mwhudson, that's next on my list | 05:52 |
| mwhudson | beuno: awesome | 05:52 |
| beuno | I just wanted to get the setup thing out of the way before it found more victims | 05:52 |
| mwhudson | sure | 05:52 |
| mwhudson | thanks for that! | 05:52 |
| beuno | happy to do it :) | 05:53 |
| beuno | are the current bugs filed for 1.6 reasonable to release, or is there something else you want in on this cycle? | 05:54 |
| beuno | we should probably wait for bzr 1.6 to release, for starters | 05:55 |
| mwhudson | just looking | 05:55 |
| mwhudson | well yes, there's the weave_store/not weave_store thing | 05:55 |
| beuno | ah, right | 05:55 |
| beuno | I'll file a bug for that | 05:56 |
| jdobrien | * | 05:56 |
| beuno | I was planning on trying one method, and if it failed, default to the 1.6-compatible one. We can probably remove that after a few releases | 05:56 |
| mwhudson | beuno: https://bugs.edge.launchpad.net/loggerhead/+bug/242806 | 05:57 |
| ubottu | Launchpad bug 242806 in loggerhead "log rotation actually doesn't save old logs (it truncates them)" [High,Confirmed] | 05:57 |
| mwhudson | probably should be investigated | 05:57 |
| beuno | true | 05:57 |
| * mwhudson nominates | 05:57 | |
| mwhudson | beuno: isn't https://bugs.edge.launchpad.net/loggerhead/+bug/243420 fixed now? | 05:59 |
| ubottu | Launchpad bug 243420 in loggerhead "Link to removed file in changelog tracebacks" [High,Confirmed] | 05:59 |
| Peng_ | I thought you just took out the link. | 05:59 |
| mwhudson | right | 05:59 |
| mwhudson | which seems to fix the bug :) | 05:59 |
| beuno | mwhudson, yeap yeap | 05:59 |
| lifeless | FWIW I think running with just current bzr is fine | 06:00 |
| lifeless | because the older loggerheads are still available | 06:00 |
| poolie | exclennet | 06:00 |
| poolie | or however you spell it | 06:00 |
| poolie | that does make it fail | 06:00 |
| mwhudson | beuno: what's the story with https://bugs.edge.launchpad.net/loggerhead/+bug/248018 ? | 06:00 |
| ubottu | Launchpad bug 248018 in loggerhead "slow search results override fast ones" [High,Confirmed] | 06:00 |
| poolie | lol | 06:01 |
| Peng_ | Fully fixing the bug would mean having a functional link. | 06:01 |
| poolie | they must be more important, i worked so hard on them? :) | 06:01 |
| beuno | mwhudson, that's javascript-related | 06:01 |
| mwhudson | beuno: should i nominate it for 1.6? | 06:01 |
| * jdobrien head drops on his keyboard........................... | 06:02 | |
| Peng_ | IMO, adding a functional link is low priority, but should be done before closing the bug. | 06:02 |
| lifeless | oh yeah | 06:02 |
| lifeless | mwhudson: beuno: did you consider my patch for sqlite3 bindings? | 06:03 |
| lifeless | python-sqlite is older and slower :) | 06:03 |
| beuno | mwhudson, yeah, it shouldn't be more than a few hours work | 06:03 |
| beuno | lifeless, you made a patch for that? | 06:03 |
| mwhudson | lifeless: i keep losing that | 06:03 |
| mwhudson | beuno: https://bugs.edge.launchpad.net/loggerhead/+bug/237914 ? would be nice-to-have | 06:04 |
| ubottu | Launchpad bug 237914 in loggerhead "please provide downloadable and applicable diffs" [Medium,Confirmed] | 06:04 |
| beuno | either way, I have something half-baked that will use ajax to bring changed files on request, which may let us eliminate the cache completely | 06:04 |
| lifeless | http://bazaar.launchpad.net/~lifeless/loggerhead/squid3/revision/153 | 06:04 |
| beuno | mwhudson, it would. I've already had to ge diffs manually for people wanting them from LH :) | 06:05 |
| beuno | lifeless, I'll apply the patch now | 06:06 |
| beuno | it's a no-brainer | 06:06 |
| lifeless | probably need to update some other docs etc | 06:08 |
| lifeless | about what packages are wanted | 06:08 |
| beuno | yeah, although it's optional now, and I'm obsessed with getting rid of it | 06:08 |
| lifeless | concretely python-pysqlite1.1 is what my patch offers IIRC | 06:11 |
| mwhudson | i think there have been some loggerhead bugs reported against launchpad-bazaar since the theme rollout | 06:11 |
| beuno | lifeless, trying for the other sqlite versions doesn't make sense anymore then, doesn't it? | 06:11 |
| beuno | http://bazaar.launchpad.net/~lifeless/loggerhead/squid3/annotate/153?file_id=changecache.py-20061220030353-d5l6vj7xp2vff655-1 | 06:11 |
| mwhudson | but i'm hilariously far behind on my bug mail | 06:12 |
| beuno | mwhudson, there have | 06:12 |
| beuno | I assigned them to me | 06:12 |
| mwhudson | beuno: did you add loggerhead tasks? | 06:12 |
| beuno | they are all simple to fix, and generally wishlists | 06:12 |
| lifeless | beuno: well the point is that sqlite3 is better than sqlite2 :) | 06:12 |
| beuno | mwhudson, let me check, I think so | 06:13 |
| mwhudson | beuno: ok :) | 06:13 |
| lifeless | jml: so back to the xmlrpc to mirror a branch; should I open a task on launchpad ? | 06:13 |
| jml | lifeless: no. | 06:13 |
| lifeless | or am I just not making sense to you | 06:13 |
| beuno | mwhudson, they where filed to LH in the first place :) | 06:14 |
| jml | lifeless: you are making sense to me, but opening a task isn't going to help. | 06:14 |
| mwhudson | beuno: oh good :) | 06:14 |
| lifeless | jml: so there is nowhere to track the further progress of this? | 06:15 |
| jml | lifeless: https://blueprints.edge.launchpad.net/launchpad/+spec/api-python-library | 06:16 |
| lifeless | ok, I've linked the bug report | 06:18 |
| beuno | mwhudson, is #156453 ready to be closed? | 06:23 |
| mwhudson | bug 156453 | 06:23 |
| ubottu | Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,Confirmed] https://launchpad.net/bugs/156453 | 06:23 |
| mwhudson | beuno: no, we still have problems in production :/ | 06:23 |
| beuno | :( | 06:24 |
| beuno | mwhudson, btw, has the new theme changed anything in performance? | 06:24 |
| mwhudson | beuno: not so that i've noticed | 06:24 |
| mwhudson | i haven't checked at all mind | 06:24 |
| beuno | it generates smaller files, so it uses less BW and does it faster | 06:24 |
| beuno | ok, I suppose that if it didn't slap you in the face then it's not significant at the very least | 06:25 |
| beuno | mwhudson, what about bug 156599 ? | 06:27 |
| ubottu | Launchpad bug 156599 in loggerhead "need documentation on how to run loggerhead under apache" [Undecided,New] https://launchpad.net/bugs/156599 | 06:27 |
| mwhudson | beuno: hmm, i'm not sure about that | 06:27 |
| mwhudson | there's some stuff in readme, i think, there could probably be more | 06:27 |
| beuno | ok, so maybe we should confirm it as wishlist | 06:28 |
| mwhudson | sounds good | 06:28 |
| beuno | and the last one, I thing bug 246764 is not possible with bzr at all | 06:28 |
| ubottu | Launchpad bug 246764 in loggerhead "Recreate "Download a Directory" feature" [Undecided,New] https://launchpad.net/bugs/246764 | 06:28 |
| beuno | and I don't want to do anything LH-specific about that | 06:28 |
| beuno | just want to check with you before I invalidate it | 06:29 |
| lifeless | beuno: exporting a subtree sounds useful | 06:30 |
| beuno | lifeless, it is. How would we do it? | 06:30 |
| lifeless | export | 06:30 |
| mwhudson | beuno: i think it should be wishlist | 06:31 |
| mwhudson | beuno: and edit the summary to not say "recreate" :) | 06:31 |
| lifeless | beuno: bzrlib.export.export with a tree object | 06:31 |
| lifeless | beuno: all it needs is a tree decorator that gives you 'doc' as the root rather than '/', for instance | 06:31 |
| beuno | ok, if you make it sound that simple it makes me feel bad to not do it | 06:32 |
| beuno | lifeless, is there a reason we can't do that right now in bzr? | 06:32 |
| lifeless | beuno: none at all | 06:32 |
| beuno | ok, so it would make sense to try and get a patch into bzr, and work on top of that | 06:33 |
| lifeless | we could also tweak the exporter protocol to accept a limit parameter | 06:33 |
| lifeless | rather than using a decorated tree; I don't have an opinion about which is better | 06:33 |
| lifeless | yes, a bzrlib patch would be good | 06:34 |
| beuno | I'll dive into it when I get to bug 240580 | 06:34 |
| ubottu | Launchpad bug 240580 in loggerhead "Ability to download a tarball for a revision" [Undecided,Confirmed] https://launchpad.net/bugs/240580 | 06:34 |
| beuno | and see which one produces cleaner code, etc | 06:35 |
| lifeless | should be the same thing :) | 06:35 |
| beuno | (which approac) | 06:35 |
| beuno | approach | 06:35 |
| beuno | well, one we can do now, the other needs bzrlib tweaking | 06:35 |
| beuno | but yes | 06:35 |
| mwhudson | beuno: you managed to commit a conflict marked to README on trunk :) | 06:38 |
| beuno | mwhudson, what? how!? | 06:38 |
| mwhudson | +<<<<<<< TREE | 06:38 |
| lifeless | beuno: strictly speaking it doesn't need a bzrlib tweak; its just that the tweak /can/ go into bzrlib ;P | 06:38 |
| mwhudson | only one part of it though | 06:38 |
| beuno | mwhudson, you mean NEWS? | 06:39 |
| mwhudson | ah | 06:39 |
| mwhudson | beuno: yes, sorry | 06:39 |
| beuno | argh, yeah | 06:39 |
| beuno | mwhudson, mind if I uncommit --overwrite? | 06:40 |
| mwhudson | beuno: sounds appropriate | 06:40 |
| Peng_ | I already pulled it, I think. | 06:40 |
| Peng_ | Never mind; I haven't. | 06:41 |
| lifeless | quick quick pull it | 06:41 |
| beuno | Peng_, really?? it was like 5 minutes ago! | 06:43 |
| beuno | Peng_, pull --overwrite then :) | 06:43 |
| beuno | oh, codebrowse is actually scanning in *minutes* instead of hours now | 06:43 |
| beuno | lol | 06:43 |
| Peng_ | beuno: Yeah, I hadn't, but I have now, but that's no problem. | 06:43 |
| beuno | Peng_, I already uncommitted and pushed | 06:44 |
| Peng_ | Yeah, you have *now*. | 06:45 |
| mwhudson | beuno: yeah, we fixed the scanner some more | 06:45 |
| beuno | mwhudson, neat. That should drop confusion for new people pushing code by 80%! | 06:46 |
| mwhudson | and foundhttps://bugs.edge.launchpad.net/bzr/+bug/252481 | 06:46 |
| ubottu | Launchpad bug 252481 in bzr "readonly, chrooted, http transport fails to be smart about readvs with many ranges" [Undecided,New] | 06:46 |
| mwhudson | beuno: fixing it even more is on the list for next week | 06:46 |
| beuno | mwhudson, cool, I expect it may be hard to keep up with the growth in branches | 06:47 |
| beuno | (on Launchpad, that is) | 06:47 |
| rockstar | beuno, hi | 06:47 |
| beuno | hey rockstar | 06:48 |
| mwhudson | beuno: one might suspect difficulties along those lines, yes | 06:48 |
| rockstar | It sounds like I'll be doing some Loggerhead hacking in the near future. | 06:48 |
| beuno | rockstar, oh? very cool! | 06:48 |
| rockstar | Indeedy. | 06:49 |
| beuno | anything specific in mind already? | 06:49 |
| beuno | at this rate, it may even make sense to use Bundlebuggy! :) | 06:49 |
| rockstar | Just the theming support and packaging probably | 06:49 |
| mwhudson | i guess we should really be testing that code review thingy launchpad has now | 06:49 |
| beuno | ah, right | 06:50 |
| rockstar | Yea, I heard the developers added something like that recently | 06:50 |
| beuno | BB shows diffs, which is hard to give up | 06:50 |
| beuno | of course, I could file a bug and poke people to get diffs on LP too | 06:51 |
| beuno | even LH links would do, I suppose | 06:51 |
| mwhudson | the bug exists | 06:51 |
| mwhudson | and we'd like to fix it :) | 06:52 |
| * beuno looks for it | 06:53 | |
| beuno | rockstar, if you have any questions about LH theme n' stuff, feel free to ping me about it | 06:55 |
| rockstar | beuno, I sure will | 06:55 |
| mwhudson | dinner time | 06:58 |
| beuno | ok, it's bed time for me | 06:58 |
| beuno | see you all tomorrow :) | 07:00 |
| poolie_ | lifeless: if you didn't already could you send me that note re the new compression format | 07:22 |
| === poolie_ is now known as poolie | ||
| poolie | spiv, how are you going with the cloning format seleciton? | 07:23 |
| lifeless | poolie: its in progress | 07:24 |
| poolie | thanks | 07:24 |
| lifeless | I'm on cons at the moment | 07:24 |
| poolie | thanks for your reply about the comment | 07:24 |
| cody-somerville | When creating a repo, if I don't care about old versions of bzr is --dirstate-tags optimal? | 07:30 |
| poolie | cody-somerville: giving no options will give you the default for that version of bzr | 07:31 |
| cody-somerville | default doesn't mean optimal <g> | 07:32 |
| lifeless | cody-somerville: no, dirstate-tags is not optimal | 07:32 |
| cody-somerville | lifeless, is the default optimal? | 07:32 |
| lifeless | cody-somerville: default is the best choice unless you have some specific need | 07:33 |
| cody-somerville | Well, there will be very little local operations | 07:33 |
| cody-somerville | Majority will be via network | 07:33 |
| lifeless | cody-somerville: unless you're dealing with 10's of GB's of data in thousands of branches, default will be fine | 07:33 |
| lifeless | and if you are dealing with that scale operation, nothing in trunk is sufficient for nice operation, though I have some plugins you may be interested in | 07:34 |
| cody-somerville | Do you have a link? | 07:35 |
| cody-somerville | It is 14GB of data | 07:35 |
| lifeless | what sort of data? ISO's ? | 07:35 |
| lifeless | 100's of thousands of files? | 07:35 |
| lifeless | how many branches do you expect? | 07:36 |
| cody-somerville | Sorry, was afk | 07:39 |
| cody-somerville | lifeless, Okay, so the story is that I'm trying to complete a migration from no RCS (they're currently modifying source code on production server) to Bazaar. | 07:39 |
| cody-somerville | There is two products but they share a lot of code and are located at /home/product1/xyz and /home/product2/xyz | 07:40 |
| lifeless | ok, definitely go with default | 07:40 |
| lifeless | which will be pack-0.92 | 07:40 |
| cody-somerville | Inside each respective xyz directory, there is one directory that contains backend source code and one directory containing shared code and then a whole bunch of other directories for each instance for each client | 07:41 |
| cody-somerville | So I'm thinking of creating a repo in each xyz directory and having each client instance a branch and then the two other directories a branch | 07:42 |
| cody-somerville | so that roughly 943 branches | 07:43 |
| lifeless | that should be fine | 07:44 |
| cody-somerville | Is that the best way to set it up? | 07:44 |
| lifeless | it doesn't sound like there is actually 14GB of unique data, rather many copies of stuff | 07:44 |
| cody-somerville | lifeless, yes, unfortunately | 07:44 |
| cody-somerville | lifeless, is there anyway to create a repo that would encompass both products? | 07:45 |
| cody-somerville | just bzr init-repo /home/ ? | 07:45 |
| lifeless | sure | 07:45 |
| cody-somerville | Actually, I think I'll create symlinks in /srv/ - that'll work, eh? | 07:46 |
| poolie | lifeless: so it looks to me like the existing kvf code will never store texts crossing a physical repo boundary | 07:47 |
| poolie | i'm going to check this a bit more | 07:48 |
| poolie | you do actually have a comment in a test that asserts this though the test itself is not very robust | 07:48 |
| poolie | because in the way described above it uses a one-line file that the code might choose to store in full regardless of the stacking | 07:48 |
| poolie | i think this means we do not have in principle a problem with people upgrading the underlying repository | 07:49 |
| poolie | um | 07:49 |
| lifeless | poolie: I thought you managed to trigger a test failure? | 07:49 |
| poolie | yes, but it's fixed by aaron's change, the one i asked about on the list | 07:50 |
| poolie | and having re-derived that answer i think it's good | 07:50 |
| poolie | s//a good fix | 07:50 |
| Odd_Bloke | lifeless: If you have the chance at some point, a final checkup of http://bundlebuggy.aaronbentley.com/project/pqm/request/%3C20080718095350.18ab03f6%40lapbert%3E (which you've reviewed previously) would be appreciated. | 07:51 |
| lifeless | poolie: oh, interesting. Let me think if I can find a hole. But this email first. | 07:52 |
| cody-somerville | can I ignore exceptions.UnicodeDecodeError? lol | 07:54 |
| * cody-somerville is getting a few UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 13: ordinal not in range(128) | 07:55 | |
| poolie | lifeless: np, i'm going to try some blackbox-level tests to try to poke holes in it, and also make that test more rigorous | 07:55 |
| lifeless | poolie: my mail has been sent | 07:57 |
| poolie | thankyou! | 07:57 |
| lifeless | cody-somerville: probably that means you have a file on disk that doesn't match your locale | 07:57 |
| poolie | and with 3 minutes to spare :) | 07:58 |
| lifeless | poolie: please let me know asap if it doesn't tell you enough | 07:58 |
| poolie | indeed | 07:58 |
| * poolie reads | 07:58 | |
| lifeless | poolie: more needed? | 08:05 |
| poolie | not now | 08:06 |
| poolie | that looks cool, both in content and summary | 08:06 |
| poolie | you should have put the 'what to do to help' at the top maybe | 08:07 |
| lifeless | thanks :) | 08:07 |
| lifeless | I also should have added links etc | 08:07 |
| lifeless | but you needed it in a timely manner | 08:08 |
| lifeless | I'm going to call it a day; started at 0630 | 08:08 |
| === gdmfsob is now known as mishok13 | ||
| spiv | poolie: I think I have a fix, just waiting for the test suite to finish successfully before I mail it. | 08:31 |
| poolie | yay way to go | 08:32 |
| poolie | night lifeless | 08:32 |
| cody-somerville | Whats the easiest way to make sure the remote host's working tree is always current? | 08:43 |
| spiv | cody-somerville: there's a push-and-update plugin | 08:44 |
| cody-somerville | Awesome. | 08:45 |
| spiv | cody-somerville: a slightly different approach is the bzr-upload plugin, which uploads just a working tree (i.e. not a branch), which can suit web development | 08:45 |
| spiv | Another option is just don't have a working tree on the remote host -- maybe you don't actually need one. Or maybe you do :) | 08:46 |
| cody-somerville | spiv, I'd like to use the former so that way if someone were to accidentally modify something on the development server the plugin will barf | 08:46 |
| cody-somerville | err. | 08:46 |
| cody-somerville | production server directly | 08:46 |
| bzr | Good morning. Is there any way to use Bazaar as a mere file synchronization tool between two computers, without having a history at all? If so, I could use it to synchronize my music and stuff between home and work computer, without wasting lots of additional disk space. I currently do this with Unison, but this tool has several drawbacks, e.g., no renaming support. Furthermore, I'd like to have only one tool for managing my code and managing my mul | 08:48 |
| cody-somerville | ugh | 08:51 |
| AfC | um | 08:51 |
| spiv | bzr: not really. bzr is pretty focussed on recording history. | 08:51 |
| AfC | bzr: (you might want to pick another IRC nick. Just a thought) | 08:51 |
| spiv | (Also, your IRC nick is going to be very confusing :) | 08:51 |
| bzr | aehm ... my first time at all on irc. i probably did something wrong. | 08:52 |
| unlink | what is the safest way to convert hg to bzr? | 08:52 |
| lifeless | bzr: type '/nick yourname' without the ' marks | 08:52 |
| === bzr is now known as goldi | ||
| lifeless | unlink: fastexport-fastimport is probably best today | 08:52 |
| goldi | that should be better now | 08:52 |
| AfC | bzr: "#bzr" is the channel you are in; each user is also identified by a "nickname" | 08:52 |
| spiv | goldi: yep, thanks | 08:52 |
| spiv | Oh, and welcome to irc! | 08:53 |
| goldi | thx :-) | 08:53 |
| AfC | goldi: so, there is a way I could think of that you could do the transferring you are talking about while constantly jettisoning history | 08:54 |
| AfC | goldi: but as spiv noted, that's not entirely how Bazaar's authors expect the tool to be used. | 08:54 |
| cody-somerville | Is this error bad? | 08:54 |
| cody-somerville | KnitCorrupt: Knit <bzrlib.knit.KnitVersionedFiles object at 0xb7899f2c> corrupt: incorrect number of lines 1775 != 1774 for version | 08:54 |
| goldi | spiv and AfC: If things are like that, I will have to find something else for this purpose. Thank you anyway. | 08:56 |
| lifeless | cody-somerville: what bzr version? | 08:56 |
| cody-somerville | lifeless, 1.6b3 | 08:57 |
| unlink | lifeless: thanks, checking it out now | 08:57 |
| spiv | cody-somerville: that usually means there's a newline in a filename | 08:57 |
| cody-somerville | How does... that happen? | 08:58 |
| lifeless | spiv: we should error earlier though | 09:00 |
| unlink | it's easy | 09:00 |
| lifeless | cody-somerville: its a problem; its unexpected, and you should file a bug | 09:00 |
| spiv | lifeless: If you have a bzr older than 1.5 and your install uses pyo rather than pyc, then you don't :( | 09:00 |
| lifeless | spiv: well I did ask the version first :) | 09:01 |
| spiv | Ah, good point. | 09:01 |
| * spiv is still wary of that case after it bit Mary... | 09:01 | |
| nandersson | goldi, use rsync for keeping directories in sync | 09:02 |
| unlink | bzr fast-import tells me to run bzr update, but bzr update says "No WorkingTree exists" | 09:02 |
| lifeless | unlink: you can create a working tree with bzr checkout . | 09:04 |
| lifeless | or in a different location with 'bzr checkout --lightweight URL' | 09:04 |
| unlink | bzr checkout . gives me bzr: ERROR: Not a branch | 09:05 |
| unlink | i've just done a conversion of an hg repository | 09:05 |
| unlink | oh i see, it is the master directory i want to be looking in | 09:06 |
| unlink | ok ... how do i get the bzr-gtk log viewer? | 09:12 |
| mthaddon | lifeless, I can reproduce the problem (with PQM connecting to LP) with a simple python -c "from bzrlib.branch import Branch; Branch.open('sftp://bazaar.launchpad.net/~mthaddon/pycairochart/devel')" | 09:14 |
| mthaddon | lifeless, works on my local machine with bzr 1.3.1, pqm box appears to be using bzr 0.93 | 09:15 |
| mthaddon | lifeless, simple matter of upgrading bzr on PQM box? | 09:15 |
| mthaddon | going to try it with 1.5 and see if that fixes it | 09:17 |
| mthaddon | lifeless, success! | 09:19 |
| lifeless | mthaddon: heh | 09:21 |
| mthaddon | lifeless, I'm not sure if I should switch ~pqm/source/bzr.dev to use bzr-1.5 or leave as is, and just set it for this project - any thoughts on that? | 09:22 |
| lifeless | what machine is this? | 09:23 |
| mthaddon | balleny | 09:23 |
| lifeless | ballent already has a much newer bzre than 0.93! | 09:23 |
| mthaddon | lifeless, not in ~pqm/source/bzr.dev, which is set in the PYTHONPATH for PQM's cron | 09:24 |
| lifeless | oh indeed | 09:24 |
| lifeless | I'd pull 1.5 into that directory | 09:24 |
| mthaddon | ok, cool - thx | 09:24 |
| lifeless | I really wish the debian maintainers for apache2 and exim would stop making spurious config file changes | 09:30 |
| lifeless | and dovecot | 09:35 |
| lifeless | sheese | 09:35 |
| lifeless | comments in config files should not cause me to have to read the entire freaking thing again | 09:36 |
| uws | Hmm. Can I diff between 2 remote revisions? | 09:40 |
| uws | I want to diff from e.g. 123..124 on a remote branch, to see whether to cherry pick this | 09:41 |
| lifeless | bzr diff -r 123..124 REMOTEBRANCH | 09:41 |
| uws | lifeless: Thanks. I was looking in the wrong place methinks... fiddling with branch: urls and stuff | 09:42 |
| uws | bzr merge -r928..929 sftp://.... | 09:45 |
| uws | M lib/.... | 09:45 |
| uws | All changes applied successfully. | 09:45 |
| uws | But I already cherry-picked this one | 09:45 |
| uws | so "bzr diff" on the local branch is empty afterwards | 09:45 |
| uws | strange that it says "M lib/..." | 09:46 |
| AfC | uws: I've wondered about that myself. I think it boils down to "those files were touched" even though there is no actual textual diff change. Still, it's a bit strange. | 09:47 |
| uws | yeah. and there's no pending merge either | 09:47 |
| uws | cherry picking would be ok | 09:47 |
| uws | if it were tracked; ) | 09:48 |
| lifeless | cherry picks don't create pending merges today | 09:48 |
| uws | lifeless: but is the revid stored somewhere? | 09:48 |
| fullermd | It's because the cherry pick isn't recorded that you see the M lib/ line | 09:48 |
| uws | AfC: (btw, how are you. you weren't at guadec) | 09:48 |
| uws | fullermd: So how does it find out that I already have that patch in my branch? | 09:49 |
| fullermd | If it were, you'd get a "already have that". Since it's not, it does the same thing it did the first time around, which ends up with no diff. | 09:49 |
| AfC | uws: (yes, I'm a bit bitter about that) | 09:49 |
| fullermd | It doesn't. It just ends up at the same place. | 09:49 |
| uws | fullermd: I'm wondering why it doesn't cause a patch conflict | 09:49 |
| fullermd | If that cherrypick were to end up in a conflict, and you resolved and committed it, doing the cherrypick again would bring you back to the conflicted state. | 09:49 |
| uws | AfC: (IST was a great place) | 09:50 |
| fullermd | Because there's no conflict. It just ended up right back where it went the first time (reasonable, since it's in the same state, mod the change that's the same... wow, that's clear...) | 09:50 |
| fullermd | Try it this way; a 3-way merge, with an identical change on both sides, leads to a clean result with that change. | 09:50 |
| fullermd | The first time you cherry pick, it merges in whatever that change was you were cherrypicking, with $SOME_OLD_REV as the merge base. | 09:51 |
| AfC | uws: I think I can head this off by observing (without hostility) that Bazaar's interaction with cherry-picking type activities is unfortunately not quite as optimal as they someday hope it will be. | 09:51 |
| cody-somerville | guh | 09:51 |
| fullermd | The second time your cherrypick, the same old rev is still the merge base (since no new merge point is created), and the 3-way merge will, because of that, end up with the same result it had the last time, which is what you committed last time, which is why there's no visible change. | 09:51 |
| cody-somerville | more dying on the newline in name | 09:51 |
| uws | fullermd: ah, $SOME_OLD_REV is used as base. that makes things clear (at least form e) | 09:51 |
| lifeless | uws: no we don't record the cherry pick todau | 09:52 |
| uws | is there a shorthand notation for bzr diff -r123..124 ? | 09:52 |
| lifeless | merging in other systems (except darcs) also ignores cherrypicks | 09:52 |
| uws | e.g. like svn diff -c124 ? | 09:52 |
| fullermd | (the results may be different with --weave; I think that gets crankier about the same textual change being on both sides, with different originators) | 09:52 |
| fullermd | You mean like bzr diff -c124? :p | 09:52 |
| AfC | uws: bzr diff -c 124 | 09:52 |
| uws | lifeless: It's a bit annoying though. I'm hand pulling some stuff (cannot completely merge for many reasons) using bzr log --line sftp://$remote | 09:53 |
| uws | and then using diff (to check) and merge (to pull it in) to pick some changes | 09:53 |
| uws | when I've done a few, they still end up in the "bzr missing --other" listing | 09:54 |
| uws | (eh, where I said "bzr log" 3 lines ago, I meant "bzr missing") | 09:54 |
| uws | fullermd: wow. | 09:55 |
| uws | fullermd: but the docs should be improved | 09:55 |
| uws | Difference between revision 2 and revision 1: | 09:55 |
| uws | bzr diff -r1..2 | 09:55 |
| uws | ^^ from "bzr help diff" | 09:55 |
| uws | the -c stuff is only in the parameter listing | 09:55 |
| uws | if someone could add another example there, right below the one I pasted above... | 09:55 |
| fullermd | Mmm. That example probably should be a larger range, and another entry for -c | 09:55 |
| uws | stating something like "To see the changes a single revision introduced, you may also use...." | 09:56 |
| uws | trivial fix, and I'm not running bzr.dev, so I'll leave it to you guys | 09:56 |
| LarstiQ | hah :) | 09:56 |
| lifeless | :) | 09:56 |
| uws | dag wouter. | 09:56 |
| LarstiQ | middag wouter :) | 09:57 |
| uws | LarstiQ: je zit niet in UTC+0200? | 09:57 |
| LarstiQ | uws: correct, although 3 minutes early, but I am in Finland. | 09:57 |
| uws | is there already support for branch shortcuts? | 09:59 |
| uws | I have a few "other" branches | 10:00 |
| uws | one of which is my parent brnach | 10:00 |
| uws | and 2 others are colleagues | 10:00 |
| uws | I'd like to easily use e.g. bzr missing on those without typing complete urls | 10:00 |
| fullermd | :-aliases for saved locations, bookmarks plugin for others. | 10:00 |
| uws | fullermd: :-aliases? which help topic covers that/ | 10:00 |
| fullermd | (the former is post-1.5, though) | 10:01 |
| uws | hmm 1.5 here. | 10:01 |
| fullermd | Well, none, AFAIK; only doc I know of for it is in NEWS :| | 10:01 |
| uws | fullermd: can you give me an example syntax? | 10:01 |
| fullermd | bzr missing :parent bzr pull :push | 10:02 |
| AfC | uws: missing uses against a default | 10:02 |
| AfC | s/against // | 10:02 |
| fullermd | The bookmarks plugin should with with 1.5 though (and it gives you more options) | 10:03 |
| AfC | uws: which is parent: , I believe | 10:03 |
| AfC | uws: use `bzr info` to see what's what, and just run a bare `bzr missing` and see what happens. | 10:04 |
| fullermd | It is. | 10:04 |
| fullermd | if other_branch is None: | 10:04 |
| fullermd | other_branch = parent | 10:04 |
| lifeless | uws: missing won't help with cherrypicking; sorry :( | 10:05 |
| AfC | Hm. parent: gets set to what you branched from, I know that, but is there a convenient way to reset it? I assume `bzr pull --remember` changes parent:, but I'm not certain. | 10:05 |
| * fullermd nods at AfC. | 10:05 | |
| AfC | uws: there you go | 10:05 |
| poolie | spiv, thanks for the #251871 patch! | 10:12 |
| uws | fullermd: Ah, thanks | 10:15 |
| uws | AfC: vi .bzr/branch/branch.conf ;-) | 10:16 |
| AfC | uws: I try to avoid recommending that sort of thing, but yes | 10:17 |
| uws | AfC: (agreed) | 10:17 |
| poolie | night all | 10:17 |
| uws | To merge the changes introduced by 82, without previous changes: | 10:20 |
| uws | bzr merge -r 81..82 ../bzr.dev | 10:20 |
| uws | fullermd: ^^ same there for the -c flag | 10:20 |
| uws | (from bzr help merge) | 10:20 |
| asabil | hi all | 10:23 |
| asabil | I have some troubles with loggerhead | 10:23 |
| asabil | it seems to trigger bzr exceptions in the front page | 10:23 |
| asabil | and it generates Html code with things like: var global_path = Exception: type object 'branch' has no attribute 'url'; | 10:24 |
| lifeless | asabil: what bzrlib do you have? | 10:31 |
| asabil | 1.5 | 10:31 |
| cjwatson | lifeless: pong | 10:36 |
| lifeless | asabil: hmm, I think you need 1.6b4 at the moment | 10:42 |
| lifeless | cjwatson: the branch with the fetch error, I tracked down the root cause | 10:42 |
| lifeless | cjwatson: its not an easy fix; can you do a baz-import of mdz's branches and fetch-ghosts, that should fix it up for you | 10:43 |
| asabil | lifeless: oh ok thanks | 10:43 |
| cjwatson | lifeless: ok, I was already on that road, unfortunately there are (IIRC) five branches with ghosts and I've been getting SHA-1 mismatches after fetching ghosts because evidently I haven't got the history combinations quite right | 10:44 |
| lifeless | cjwatson: possibly they are bugs in the converter | 10:46 |
| lifeless | cjwatson: it shouldn't be stuff *you* do triggering, so I'd suggest filing additional bugs on baz-import (part of bzr-tools) | 10:46 |
| cjwatson | fetch-ghosts says "Still missing:" and then five further branches. 'bzr log' doesn't show the ghosts from revision 1. Has it done anything useful? | 10:47 |
| cjwatson | 'bzr branch' in the fetched-into branch still says that a revision is missing. | 10:47 |
| cjwatson | and it's a revision that 'bzr log --show-ids' says is in the branch I just fetched | 10:47 |
| cjwatson | so if I can force the fetch to proceed somehow ... | 10:48 |
| lifeless | fetch-ghosts should DTRT | 10:50 |
| lifeless | I'm not going to dig into it right now though | 10:50 |
| lifeless | tired/done for now | 10:50 |
| cjwatson | http://paste.ubuntu.com/32537/ | 10:51 |
| lifeless | ls --show-ids isn't a very useful command for this | 10:53 |
| lifeless | I'm not sure what you think it does | 10:53 |
| lifeless | but it shows you what a specific revision refers to, not what fetch will need to do | 10:54 |
| cjwatson | bzr branch claimed that a revision was missing in a particular file-id, and I just wanted to demonstrate that that file-id did indeed exist in the fetched-from branch | 10:54 |
| lifeless | it doesn't demonstrate that though | 10:54 |
| cjwatson | seemed to me that one possible failure mode would have been that the other branch had been imported with mismatching file-ids | 10:54 |
| lifeless | it demonstrates that an inventory refers to a file id, not that the file ids content is present | 10:55 |
| lifeless | yes, thats a possible failure mode, but more likely is a reference to an incorrect last-altered revision | 10:56 |
| cjwatson | hm, ok, I don't see a way to do the latter from the command line | 10:56 |
| lifeless | bzr check should be reasonable at catching most things | 10:56 |
| cjwatson | iter_ghosts in fetch_ghosts.py simply doesn't seem to report that revision | 10:56 |
| lifeless | it may not be a ghost anymore | 10:56 |
| lifeless | report the current error with backtrace somewhere and throw a tarball of the current branch up too | 10:59 |
| lifeless | I'll look tomorrow | 10:59 |
| jelmer | menesis, hi | 11:50 |
| jelmer | menesis, can you please submit your merge request for bzr-gtk to bundlebuggy (see details on the wiki) | 11:50 |
| jelmer | we don't use launchpad for merge requests | 11:50 |
| Odd_Bloke | http://twitter.com/bzr_tweet | 12:20 |
| === sabdf1 is now known as sabdfl | ||
| james_w | Odd_Bloke: nice | 12:44 |
| james_w | the URL in the sidebar is messed up, apparently twitter doesn't believe in https:// | 12:44 |
| cjwatson | lifeless: casper material in bug 246880 | 12:48 |
| ubottu | Launchpad bug 246880 in bzr "ghost fetch issue: fail when fetching a text referenced by a live revision introduced by a ghost revision" [High,Triaged] https://launchpad.net/bugs/246880 | 12:48 |
| menesis | jelmer: ok, will try | 13:01 |
| james_w | any clues to what may be going on in the following would be greatly appreciated: | 13:11 |
| james_w | I have import code that imports a directory, this leads to a kind change, with a file being added to the directory that used to be a file | 13:11 |
| james_w | tree.path2id("dir/file") gives a file id and tree.changes_from(tree.basis_tree()) lists the addition of the file and the kind change | 13:12 |
| james_w | tree.commit() is then run, and leads to a new commit, but only the kind change is committed, not the file addition. | 13:12 |
| james_w | the file is still marked as added if "bzr st" is run after the commit | 13:13 |
| james_w | however, running "bzr st" before the commit leads to the addition being committed | 13:13 |
| james_w | does anyone have an idea why the addition isn't being committed, or what "bzr st" may be doing to change this. | 13:14 |
| luks | bzr st updates the dirstate, maybe your import code is messing it up? | 13:14 |
| grahal | i'm trying to checkout bzr-fastimport | 13:15 |
| grahal | bzr branch lp:bzr-fastimport fastimport | 13:15 |
| grahal | bzr: ERROR: [Errno 2] PROPFIND request failed on '/svn/testsvn' | 13:15 |
| grahal | ... | 13:15 |
| james_w | maybe, but I would have thought that the changes_from() would not include the addition if the dirstate didn't have it | 13:15 |
| grahal | it's the second day it's hapenning | 13:15 |
| grahal | any ideas? | 13:16 |
| james_w | grahal: weird | 13:16 |
| james_w | bzr-svn is getting involved somehow, but I'm not sure how | 13:17 |
| grahal | oh I see | 13:17 |
| grahal | let me try to uninstall bzr-svn | 13:17 |
| grahal | I thought it could be setup related on server side | 13:17 |
| james_w | does "bzr branch http://bazaar.launchpad.net/~bzr/bzr-fastimport/fastimport.dev" work? | 13:18 |
| jelmer | grahal, can you perhaps pastebin the full traceback ? | 13:18 |
| jelmer | it's working fine here with bzr-svn installed | 13:18 |
| grahal | same thing | 13:20 |
| grahal | bzr: ERROR: [Errno 2] PROPFIND request failed on '/svn/testsvn' | 13:20 |
| grahal | hmm, bzr-svn is not even installed.. | 13:22 |
| grahal | I thought it was | 13:22 |
| grahal | maybe my install is completely messed somehow | 13:22 |
| grahal | will reinstall pkgs | 13:22 |
| luks | grahal: `bzr -Derror branch lp:bzr-fastimport fastimport` and pastebin the full traceback | 13:23 |
| grahal | luks: http://pastebin.com/m27a0d995 | 13:25 |
| grahal | I did have bzr-svn installed | 13:28 |
| grahal | I moved the /usr/lib/python2.5/site-packages/bzrlib/plugins/svn away | 13:28 |
| grahal | then things worked | 13:28 |
| grahal | pastbin tells bzr-svn version | 13:28 |
| grahal | it was a dev version so maybe it could be that | 13:28 |
| james_w | yeah, the dirstate still marks the directory as a file | 13:41 |
| jelmer | grahal, it looks like you have a svn checkout in one of the parent directories of your cwd | 13:52 |
| rexbron | hey jelmer, I snaged a copy of trunk but am having some issues. When I installed the latest intrepid ppa of bzr, it uninstalled brz-rebase and bzrtools. Do I need to get newer versions of each of those? | 14:15 |
| jelmer | rexbron: bzr-rebase isn't maintained in the ppa | 14:17 |
| jelmer | nor is bzr-svn, I'm not sure about bzrtools | 14:18 |
| rexbron | jelmer: ok, I installed 1.6 because that was required. I'll look into getting newer versions of each | 14:19 |
| TheEric | how do you set the bzr_ssh variable? | 14:25 |
| rexbron | jelmer: would you be able to comment on http://pastebin.ca/1088418? If it is a more serious problem than just configuration on my end, I'll report a bug. | 14:32 |
| rick_h_ | anyone know what bzr-svn you need to get working with svn 1.5? I updated to 1.5 via a ppa and grabbed 0.4.9.1 bzr-svn | 14:33 |
| jelmer | rick_h_, 0.4.10 | 14:33 |
| rick_h_ | ah, ok thanks. I'll see if I can find that one then | 14:33 |
| jelmer | rexbron, you need a newer version of bzr | 14:34 |
| rexbron | jelmer: newer than 1.6? | 14:34 |
| jelmer | rexbron: A recent snapshot of bzr.dev | 14:40 |
| jelmer | rexbron, 1.6 isn't out yet | 14:40 |
| jelmer | both bzr-svn 0.4 and bzr.dev are moving targets | 14:40 |
| rexbron | jelmer: ok, snaging current trunk | 14:40 |
| jelmer | rexbron, you may also want to apply the patch I just attached to https://bugs.edge.launchpad.net/bzr/+bug/251871 | 14:43 |
| ubottu | Launchpad bug 251871 in bzr "assumes source_branch format is the same as result branch format" [Critical,New] | 14:43 |
| rick_h_ | jelmer: any reason that the bzr devs ppa has 1.5 for gutsy, feisty, dapper, but no hardy. | 14:48 |
| jelmer | rick_h_, sorry, don't know | 14:48 |
| jelmer | poolie, ^ | 14:48 |
| rick_h_ | ok, thanks | 14:49 |
| rick_h_ | yea, the bzr-svn needs 1.4 > and hardy has 1.3, so trying to get 1.5 | 14:49 |
| jelmer | rick_h_: ? Afaik there is no bzr-svn in the ppa at all | 14:50 |
| rick_h_ | jelmer: no, but you can download the plugin for .bazaar/plugins | 14:50 |
| rick_h_ | the .tar.gz | 14:50 |
| rick_h_ | jelmer: any suggestion what branch I should use to get bzr-svn 0.4.10-2? The latest tar was just 0.4.10 and there's a bug fix I need for: 246683 | 15:06 |
| grantgm | before I file a bug, I want to make sure I'm using bzr svn-push right: it should be able to create a new directory within the svn repo if I push to a location that doesn't yet exist, right? | 15:08 |
| grantgm | because I'm getting an AssertionError when I try to do that | 15:09 |
| TheEric | how do you set the bzr_ssh variable? | 15:10 |
| === stickwithjosh is now known as joshuablount | ||
| === mvo_ is now known as mvo____ | ||
| === mvo____ is now known as mvo | ||
| === mvo is now known as mvo____________ | ||
| === mvo____________ is now known as mvo__ | ||
| === mvo__ is now known as mvo | ||
| jelmer | rick_h_: 0.4.10-2 is only available from Debian and Ubuntu | 15:40 |
| jelmer | rick_h_, e.g. http://packages.ubuntu.com/intrepid/bzr-svn | 15:40 |
| TheEric | how does one set the bzr_ssh variable? | 15:47 |
| james_w | hey TheEric, are you on Windows? | 15:49 |
| TheEric | I am. | 15:51 |
| rick_h_ | jelmer: thanks, I tried out the lp branch for debian since I saw the last commit was merge 0.4.10-2, but error so then I figured I'd try to do 0.4 trunk and gcc wouldn't build | 15:52 |
| rick_h_ | so I think I'm just going to hold off a bit and go back to just running svn against that project for now | 15:53 |
| jelmer | rick_h_: What error did you get exactly? | 15:53 |
| jelmer | rick_h_, ok | 15:55 |
| rick_h_ | when checking out lp:~debian-bzr-svn/bzr-svn/unstable into .bazaar/plugins/svn I still got the Assertion `*path != '/'' failed. error | 15:55 |
| rick_h_ | when trying to build the .4 series of bzr-svn I got client.c:819: error: expected ‘{’ at end of input | 15:56 |
| rick_h_ | and then gcc exited with status 1 | 15:56 |
| james_w | TheEric: you need to set it in your environment. I haven't used Windows in so long that I've forgotten how to do that, sorry. | 15:57 |
| james_w | TheEric: searching for setting environment variables in windows should find you something | 15:57 |
| rick_h_ | it's something like "right click my computer, go to advanced, env variables" | 15:57 |
| rick_h_ | of course that was xp | 15:58 |
| rick_h_ | http://vlaurie.com/computers2/Articles/environment.htm | 15:58 |
| pygi | jamesh, poke | 16:02 |
| james_w | jam: hi, do you have a moment? | 16:09 |
| jam | james_w: a little | 16:09 |
| james_w | jam: for a test I need to do something like find out the kind recorded for an entry in the dirstate, is that possible? | 16:09 |
| james_w | it looks like the working tree will tell me the kind on disk | 16:09 |
| jam | james_w: you want the kind in the dirstate, but not the kind on disk? | 16:10 |
| jam | Technically, if you cheat and go "wt.inventory[file_id].kind" it should give you the last-recorded kind | 16:10 |
| james_w | I currently have a problem because they disagree | 16:10 |
| jam | but would you want to use the one in the basis_tree instead? | 16:10 |
| james_w | it turns out my TreeTransform file->directory fix wasn't complete, as it leaves the directory marked as a file in the dirstate, which means that children of the dir aren't recorded in the next commit | 16:11 |
| james_w | I want to write a test to check this, and the only thing I can think of is checking that the dirstate reflects what's on disk | 16:12 |
| james_w | unless I have mis-diagnosed this and it's ok for the dirstate to be like that and I'm missing something else | 16:12 |
| TheEric | yah, none of the fixes work... | 16:17 |
| TheEric | putty & bazaar just don't get along | 16:18 |
| TheEric | I've added plink.exe to the path, renamed it ssh.exe, set BZR_SSH = the path to plink | 16:23 |
| TheEric | none of it works. The same error message : Don't know how to handle SSH connections. Please set BZR_SSH enviroment variable | 16:23 |
| jam | james_w: Well, you could test the symptom you just described | 16:25 |
| jam | that changing a file => directory and then committing commits the children of that directory | 16:25 |
| jam | as an aside, calling WT4.get_file_sha1(file_id, [path=XXX]) will actually update the dirstate record | 16:27 |
| jam | you need to call something that does 'update_entry()' | 16:27 |
| rick_h_ | TheEric: I don't think it takes a path | 16:27 |
| rick_h_ | I recall seeing a bug/ticket that it didn't | 16:27 |
| jam | And ATM only get_file_sha1 and iter_changes() do that :( | 16:27 |
| jam | so *commit* doesn't trigger re-reading the on-disk state | 16:27 |
| jam | TheEric: you can only set "BZR_SSH=paramiko" or "=plink" or "=ssh" | 16:28 |
| james_w | jam: that sounds like a more sensible test, thanks. | 16:28 |
| jam | It doesn't take a path | 16:28 |
| james_w | jam: do you think that TreeTransform should be leaving the dirstate correct against the disk? | 16:28 |
| jam | james_w: as much as possible, yes | 16:28 |
| rick_h_ | TheEric: https://bugs.launchpad.net/bzr/+bug/176292 | 16:29 |
| ubottu | Launchpad bug 176292 in bzr "BZR_SSH should allow setting the path to ssh, not just the kind of ssh" [Undecided,Confirmed] | 16:29 |
| rick_h_ | you might want to follow that bug | 16:29 |
| james_w | jam: thanks for your help | 16:31 |
| TheEric | I never had this many issues with svn | 16:34 |
| TheEric | Narrowed it down further, and now it's giving me another error - connection closed: please check connectivity and permissions | 16:35 |
| TheEric | figured that out. the host key wasn't cached. a simple log on to the host with plink, and presto chango | 16:38 |
| TheEric | anyone gets that error again. go to my computer / properties, enter a new enviroment variable / BZR_SSH / plink | 16:39 |
| TheEric | if they get the other error, just log on to the host with plink, cache the key, and poof. | 16:39 |
| rocky | don't suppose there's any better progress with getting bzr 1.5 and bzr-svn running on hardy at this point? | 16:55 |
| jelmer | rocky: You can use the bzr-svn from intrepid | 16:56 |
| rocky | jelmer: right, i think i'm still stuck with no bzr 1.5 tho | 16:56 |
| jelmer | 1.5 should be available in intrepid as well | 16:56 |
| rocky | an intrepid binary will work on hardy for bzr? hmm | 16:57 |
| rocky | i guess if it's all python | 17:00 |
| luks | it's not all python | 17:01 |
| rocky | oh | 17:01 |
| rick_h_ | rocky: let me know if you get it working. I was trying this morning | 17:10 |
| rocky | k | 17:13 |
| rocky | rick_h_: well, these intrepid deb's installed fine for me... just about to start testing them (i downloaded them from the intreprid section on packages.ubuntu.com) http://users.carterscove.com/~rocky/bzr-on-hardy/ | 17:27 |
| rocky | jelmer: when bzr-svn checks out a svn url ... does it check it out to some private location *first* and then move it into the proper local dir? i'm running a checkout here on dial-up atm and there's no status showing me how much is checked out | 17:33 |
| rick_h_ | rocky: I got the 1.5 deb from the gutsy ppa and it installed and bzr works fine | 17:35 |
| rick_h_ | but I couldn't get a working svn plugin, did you get the bzr-svn from intrepid then? | 17:35 |
| rocky | yes i did | 17:37 |
| rocky | hrm, how do i tell what revisions have been made to my local branch but not pushed back? | 17:44 |
| james_w | wow, TreeTransform is actually starting to make sense to me, I never thought I'd see the day. | 17:45 |
| rick_h_ | rocky: bzr missing? | 17:50 |
| rocky | huh? | 17:50 |
| rick_h_ | wondering if bzr missing is what you want to show local commits vs remote repo | 17:51 |
| rocky | i dunno... i'm still learning bzr here ;) | 17:51 |
| uws | rocky: bzr missing, perhaps with --other or --mine flag | 17:51 |
| rocky | oh... missing is a bzr cmd | 17:51 |
| uws | rocky: (just type "bzr missing") | 17:52 |
| rocky | lol | 17:52 |
| uws | no lol'ing in here please. | 17:52 |
| rocky | heh | 17:53 |
| rocky | if i branch a local branch as another local branch and then move the first local branch, how do i tell the second local branch that it's parent branch has moved? | 17:54 |
| rick_h_ | rocky: you can always specify the new path when doing a merge or pull I think | 17:54 |
| rick_h_ | it recalls the last path used by default, but still takes a new one if you want | 17:55 |
| rocky | right | 18:06 |
| rocky | just wish i could convince it to "remember" the new path | 18:07 |
| * rocky is reading tons of bzr stuff today | 18:07 | |
| james_w | rocky: bzr pull --remember URL | 18:08 |
| rocky | don't suppose there's a patch or something for setuptools to embed bzr rev info via setup.cfg ? | 18:17 |
| rick_h_ | rocky: there was a blog post recently on a plugin for template tags or something like that | 18:20 |
| rick_h_ | like the svn $id or whatever | 18:20 |
| rocky | hm | 18:20 |
| rick_h_ | that's not the right term, template tags. Grrr, I know I just saw it | 18:22 |
| rick_h_ | http://jam-bazaar.blogspot.com/2008/07/last-week-in-bazaar.html | 18:22 |
| rick_h_ | rocky, keyword expansion is the phrase | 18:22 |
| james_w | rocky: bzr version-info is something that will work now | 18:27 |
| james_w | it takes a little bit of work to integrate it in to your build system though | 18:28 |
| rocky | jelmer: is there anyway to turn some sort of debugging on for bzr-svn to see what svn operations it's performing? | 18:32 |
| jam | james_w: I've done it if you want examples :) | 18:34 |
| === thekorn_ is now known as thekorn | ||
| rocky | does anyone know if current bzr-svn trunk still works with bzr 1.5 ? | 18:37 |
| jam | lifeless: If you get a chance, can you look at bug #198646 | 19:49 |
| ubottu | Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released] https://launchpad.net/bugs/198646 | 19:49 |
| jam | I think I should actually split it out to a new bug | 19:50 |
| jam | just a sec | 19:50 |
| rocky | ugh, getting nasty svn error from using bzr-svn 0.4.10 | 19:52 |
| jam | lifeless: bug #253745 should have the more relevant details | 19:58 |
| ubottu | Launchpad bug 253745 in bzr "Fail to parse boundary if multiple Content-Type headers are given" [High,Triaged] https://launchpad.net/bugs/253745 | 19:58 |
| rocky | when would "bzr add somerandomdir" return with nothing actually added? | 20:01 |
| rocky | heh, when there are .svn dirs present apparently | 20:02 |
| === mw is now known as mw|food | ||
| tstellar | John A Meinel from launchpad suggested you might be able to help me with this bug https://bugs.launchpad.net/bzr/+bug/198646 | 20:13 |
| ubottu | Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released] | 20:13 |
| tstellar | lifeless | 20:13 |
| Tsmith | i'm in a bind... | 20:23 |
| beuno | Tsmith, bzr unbind (?) | 20:23 |
| Tsmith | I need to revert just -r6, but i'm at -r18. Should I do the typical SVN thing of bzr diff -r5..6 > bad_push.diff; patch -p0 -R < bad_push.diff; bzr ci -m'Reverted -r6.' ? | 20:24 |
| james_w | beuno: that was bad :-) | 20:24 |
| beuno | james_w, I know, I know... | 20:25 |
| LarstiQ | Tsmith: 'bzr merge -r6..5 .' should work | 20:25 |
| beuno | Tsmith, you might be able to: bzr merge -r6..5 | 20:25 |
| LarstiQ | Tsmith: and then the commit | 20:25 |
| Tsmith | what's that do? | 20:25 |
| Tsmith | ::prays:: | 20:25 |
| LarstiQ | Tsmith: combines the diff and patch dance you did above | 20:26 |
| Tsmith | o wow | 20:26 |
| pickscrape | !seen pygi | 20:27 |
| ubottu | Sorry, I don't know anything about seen pygi | 20:27 |
| Tsmith | hey! THANKS! | 20:27 |
| Tsmith | <3 | 20:27 |
| LarstiQ | well, I'm glad he's happy. | 20:27 |
| pickscrape | Anyone know how pygi is getting on with cheezburger? | 20:28 |
| james_w | pickscrape: what's cheezburger? | 20:31 |
| james_w | his dinner? | 20:31 |
| === emgent_ is now known as emgent | ||
| LarstiQ | pickscrape: I'm not aware of him being involved with anything cheezburger (icanhaz?) | 20:36 |
| james_w | hey LarstiQ | 20:37 |
| beuno | it's a project | 20:37 |
| beuno | with bzr | 20:37 |
| beuno | that was supposed to be cool | 20:37 |
| beuno | but I can't remember *what* it was | 20:37 |
| james_w | as long as it's cool | 20:37 |
| beuno | https://edge.launchpad.net/cheezburger | 20:37 |
| awilkins | That's not the engine that runs i can haz cheezburger is it ? | 20:38 |
| Jc2k | no | 20:38 |
| pickscrape | I'd supposed to be a esrver-side tool for bzr | 20:39 |
| pickscrape | which provides things like per-branch access configuration | 20:39 |
| james_w | I'm still none the wiser from looking at the page :-) | 20:39 |
| beuno | to serve repositories, if IIRC | 20:39 |
| pickscrape | I was going to ask him how he's getting on iwth it | 20:44 |
| jelmer | re | 20:45 |
| mcmillen | What's the recommended way of getting bzr 1.5 for Ubuntu Hardy? I tried adding the suggested lines to sources.list (pointing to ppa.launchpad.net), but apt-get still tells me bzr is the newest version, even though I have 1.3.1 installed. | 20:46 |
| pickscrape | 1.6 beta got accidentally uploaded to that PPA, and subsequently removed. Since then 1.5 hasn't been put back for some reason. | 20:48 |
| mcmillen | looking at the pool/ directory directly, there seems to be files like bzr_1.5.0-1~bazaar1~{dapper,feisty,gutsy}1_i386.deb, but no hardy or intrepid. | 20:49 |
| beuno | mcmillen, there was an issue with bzr hardy package | 20:50 |
| beuno | 1.6 will land when it's released | 20:50 |
| beuno | meanwhile you can get 1.6b3 from: https://edge.launchpad.net/~bzr-beta-ppa/+archive | 20:50 |
| * beuno is off to the dentist | 20:51 | |
| awilkins | How much do you reckon using encrypted storage containers would slow Bazaar down? | 21:12 |
| james_w | awilkins: you mean an encrypted repository format? | 21:13 |
| LarstiQ | or just plain disk encryption? | 21:13 |
| mtaylor | If you're sure that it's not being modified, use bzr break-lock lp-147258572:///~andrey-mysql/drizzle/cleanup-branch/.bzr/branch/lock | 21:31 |
| mtaylor | sort of ugly error message ^^ | 21:31 |
| mtaylor | (since bzr break-lock lp-147258572:///~andrey-mysql/drizzle/cleanup-branch/.bzr/branch/lock doesn't actually work) | 21:31 |
| lifeless | moin | 21:48 |
| james_w | hey lifeless | 21:49 |
| james_w | mtaylor: yeah, there's a bug open on that, launchpad shouldn't really expose implementation details like that | 21:49 |
| mtaylor | james_w: k. thanks | 21:50 |
| james_w | you know how to really break the lock if you need to? | 21:50 |
| awilkins | james_w: I mean an encryted repo format | 21:57 |
| james_w | awilkins: I think it would slow it down considerably, but you could probably come up with a scheme that reduced the impact | 21:57 |
| lifeless | we had a soc project to do this | 21:58 |
| lifeless | the wiki notes are tehre as is discussion on the list | 21:58 |
| james_w | for instance encrypting the indexes with something less than say AES, as you would just expose things like file and revision ids, which give some information, but no content | 21:58 |
| rocky | jelmer: when i check out or do somthing with a branch from svn using bzr-svn ... does it do some sort of checks on every since dir in the svn repo (even above my branch) ? | 21:59 |
| awilkins | james_w: I was thinking about it in terms of medical records ; I'm not sure they need a version control system. | 21:59 |
| awilkins | james_w: But I'm thinking about multiple-encrypted master key containers protecting multiple threads of medical records producing a medical record system with proper privacy. | 22:01 |
| james_w | awilkins: probably encrypted hard disks are the way to do | 22:01 |
| james_w | awilkins: sounds like fun. Good luck :-) | 22:01 |
| awilkins | Heh, yeah | 22:01 |
| james_w | that would be an interesting problem though | 22:01 |
| awilkins | The idea is that the record remains private while being accessible by the patient and any contributors to the record | 22:02 |
| james_w | the bzr thing was more about storing a branch on a server you don't control where you only have bzr access and want to protect your data to some extent | 22:02 |
| uws | awilkins: luks disk encryption supports multiple passphrases | 22:06 |
| uws | awilkins: you can try it out if you have a spare USB disk lying around | 22:06 |
| lifeless | I'd say for the medical records thing that bzr is a bad fit; schema evolution is important in databases | 22:14 |
| lifeless | secondly I don't see a patient manually authorising every individual access - when they turn up unconscious at A&E they need treatment and their records available. | 22:15 |
| lifeless | I'd look more for strong auditing and reporting | 22:16 |
| pickscrape | Are there any plans/intentions/objections to in the future having coloured output a configurable part of bzr core? | 22:19 |
| james_w | pickscrape: you mean "cdiff", or more than that? | 22:20 |
| pickscrape | Yes, things like cdiff | 22:22 |
| pickscrape | Or rather, diff | 22:22 |
| pickscrape | I'm looking at adding coloured output to diffstat, but I want it to be optional and I don't want to have to add another command in order to do it. | 22:22 |
| pickscrape | In this case I like the way git does it: let the user configure it how he wants. | 22:23 |
| lifeless | pickscrape: I think its fine to have optional colourisation as part of the core | 22:24 |
| pickscrape | lifeless: That's good to know. | 22:26 |
| stickwithjosh | Is bzr+ssh the preferred method of setting up a remote bar repo to shoot to for backup / deployment ? | 22:27 |
| lifeless | stickwithjosh: its the most featureful; but we support bzr+ssh just as much as sftp and http etc | 22:28 |
| stickwithjosh | lifeless: thanks! | 22:31 |
| === abentley1 is now known as abentley | ||
| stickwithjosh | Nice, I like how bzr automatically realizes that .pyc files shouldn't be added (by default). | 22:37 |
| === mtaylor is now known as SteveJobs | ||
| === SteveJobs is now known as mtaylor | ||
| === mw|food is now known as mw | ||
| pickscrape | lifeless: do you have any thoughts on how color options should work in the config file? | 22:47 |
| pickscrape | e.g. a section called [COLOR] or [COLOUR] (spelling arguable) | 22:47 |
| pickscrape | With options under there for everything that supports it. | 22:48 |
| pickscrape | If I'm going to add it to diffstat I want it to work in a way that will be used by other things going forward. | 22:48 |
| lifeless | does it need a section? | 22:49 |
| lifeless | why not just use_colour=True|False ? | 22:49 |
| pickscrape | Because you might want it turned on for some commands but off for others | 22:49 |
| lifeless | seriously? | 22:49 |
| pickscrape | Yes | 22:49 |
| lifeless | why? | 22:50 |
| pickscrape | People are funny like that :) | 22:50 |
| awilkins | You might want to supress it if you are piping diffs to a file or to patch? | 22:50 |
| lifeless | awilkins: thats a one-shot task though, not a persistent config value | 22:50 |
| pickscrape | You also might want to be able to configure what the colours are. | 22:50 |
| lifeless | you don't want to be editing a config file just to make a patch :) | 22:51 |
| lifeless | pickscrape: per command ? | 22:51 |
| lifeless | pickscrape: anyhow let me rephrase | 22:51 |
| lifeless | sections are complex | 22:51 |
| awilkins | <voice name='Neo'>Pink. Lots of pink</voice> | 22:51 |
| lifeless | they may not work as well in e.g. branch.conf and locations.conf | 22:51 |
| lifeless | (then again they might, I dunno) | 22:51 |
| fullermd | Well, if you're not outputting to a terminal, you'd never want to color anyway. | 22:52 |
| lifeless | fullermd: cdiff | less -R | 22:52 |
| fullermd | Hush, you. My declamations are _simple_. Correct is way too much work. | 22:52 |
| lifeless | anyhow | 22:53 |
| lifeless | I don't use colourisation - red/green colourblind | 22:53 |
| lifeless | so I tend to avoid colour for stuff | 22:53 |
| pickscrape | lifeless: a prime example for wanting to be able to customise the colours (if I'm understanding properly) | 22:54 |
| lifeless | pickscrape: no, I'd rather just have them off | 22:54 |
| lifeless | takes too long to try and figure out a set that works for me | 22:55 |
| pickscrape | ok, but somebody else might be ok putting the time in | 22:55 |
| lifeless | sure | 22:55 |
| lifeless | I wasn't talking about the code, but about me | 22:55 |
| pickscrape | yes, sure | 22:55 |
| lifeless | colour_settings=.... | 22:55 |
| lifeless | use_colour=True|False | 22:56 |
| lifeless | colour_commands=... | 22:56 |
| pickscrape | My personal perference is that it helps readability enormously so I want it everywhere I can get it. | 22:56 |
| pickscrape | But I'm also particular about the colours used | 22:56 |
| james_w | pickscrape: I'd start with "colour = True|False", and then we can make it more configurable later | 22:57 |
| pickscrape | Yes, I was going to say that would be the lowest common denominator for the whole thing. | 22:58 |
| fullermd | And what about setting whether you want color? ;p | 22:58 |
| pickscrape | All or nothing to start with. | 22:58 |
| radix | someone write a dict subclass which considers "color" and "colour" equivalent | 22:58 |
| awilkins | Hmm, a buddy of mine is RGCB ; I wonder if it's correlatede with programming tendencies | 22:58 |
| awilkins | But possibly not, it's rather common | 22:58 |
| fullermd | I wouldn't think so; it's sufficiently common in men... | 22:58 |
| pickscrape | Would be interesting to provide a 'theme' tailored for RGCB. | 22:59 |
| fullermd | I've got a hint of very pale colorblindness, but it's not noticeable day-to-day. | 22:59 |
| lifeless | awilkins: 15% of population or some huge number | 22:59 |
| awilkins | 2% isnt it? | 22:59 |
| lifeless | oh maybe | 22:59 |
| lifeless | its just numbers :P | 22:59 |
| pickscrape | About 94.2% of stats are made up anyway | 23:00 |
| lifeless | still 2% is freaking lage | 23:00 |
| lifeless | *large* | 23:00 |
| awilkins | Heh, 8% | 23:00 |
| awilkins | 2% is auxilliary nipples | 23:00 |
| radix | hahaha | 23:00 |
| radix | 2% could be a lot of things... | 23:00 |
| * awilkins has a load of useless medical trivia in head from medical degree | 23:00 | |
| lifeless | theres 120MILLION extra nipples on the planet? | 23:01 |
| lifeless | Oh Noes | 23:02 |
| fullermd | The question is how many acres is that? | 23:02 |
| lifeless | depends how thin you slice them? | 23:02 |
| radix | fullermd: please don't get into an Inappropriate Comment battle with lifeless. he will probably win, and it will probably go too far | 23:03 |
| radix | ;-) | 23:03 |
| lifeless | hehe | 23:03 |
| fullermd | I wouldn't try, in my pre-caffeinated state. | 23:04 |
| awilkins | Another excellent question is how many of them are female | 23:04 |
| AmanicA | http://www.reference.com/search?q=Colourblind | 23:05 |
| pickscrape | That would definitely affect the potential acreage. | 23:05 |
| awilkins | And of course, the prevalence of multiple pairs of auxilliary nipples, and the subset of them willing to wear cat ears and a furry tail :-P | 23:05 |
| lifeless | ROTFL | 23:05 |
| radix | take it to #furries | 23:06 |
| lifeless | radix: theres been exactly one furry comment... has it offended you? | 23:06 |
| radix | lifeless: no, I'm over in #furries waiting for more chatter | 23:07 |
| pickscrape | :) | 23:07 |
| lifeless | oh I am so tempted to check | 23:07 |
| radix | hahah | 23:07 |
| * lamont has a stupid question | 23:23 | |
| * lamont tries answering it himself | 23:23 | |
| fullermd | The advantage of doing that is you rarely have to explain your answer in more detail. | 23:28 |
| lamont | yeah | 23:28 |
| lamont | and yeah. no worries. thanks lamont for the answer. ;-) | 23:29 |
| lamont | https://bugs.edge.launchpad.net/bzr/+bug/253806 | 23:45 |
| ubottu | Launchpad bug 253806 in bzr "bzr: ERROR: The file id "foo-20080731224042-7ogu3b3hk0bwnpo3-1" is not present in the tree" [Undecided,New] | 23:46 |
| james_w | lamont: I assume adding it again is the crucial bit? | 23:47 |
| lamont | which is the end result of my question to myself | 23:47 |
| james_w | I would assume so | 23:47 |
| lamont | yes. bzr rm --keep foo will make bzr cat work again | 23:47 |
| lamont | committing doesn't help though | 23:47 |
| james_w | it looks up the file id in the current tree, and then uses that id | 23:47 |
| james_w | it should look up the file id in the target tree | 23:48 |
| james_w | we suck at this in places | 23:48 |
| lamont | this is all separate from the fact that I didn't mean to commit the tree with that file removed... | 23:49 |
| lamont | in the larger bzr tree where I first hit it, the re-added foo is identical to the one 4 revs back, which should not have been deleted 3 commits ago | 23:49 |
| james_w | ah, it's not as simple as I though | 23:51 |
| james_w | thought | 23:51 |
| james_w | it looks up both revids, but assumes that if the newer is present then it will also be present in the earlier | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!