[00:00]  * timelyx leaves it alone
[00:00] <jam> this is weird
[00:00] <jam> my machine won't allow any new connections
[00:00] <jam> but preserves the connections it has
[00:00] <lifeless> timelyx: so my default is yes; but if its really a problem - create a patch and send it in for review
[00:00]  * timelyx nods
[00:00] <lifeless> jam: in or out or both
[00:00] <jam> so I can't open a *new* ssh connection, or a mail connection, but I can still work on the connection I have
[00:00] <jam> lifeless: out
[00:00] <jam> not sure about in
[00:00] <lifeless> jam: ssh running, I can connect to you if you like ?
[00:00] <lifeless> jam: tcpdump offer any hints?
[00:01] <lifeless> jam: do you have iptables active?
[00:01] <jam> lifeless: ssh isn't running, I might try that
[00:01] <jam> I don't have iptables active
[00:01] <jam> worse case, I can just restart ...
[00:01] <lifeless> it may be upstream of you
[00:02] <lifeless> -> deep hacking mode, interrupt threshold just tripped
[00:07] <jam> restarting fixed it
[00:28] <lifeless> igc: ping
[00:28] <igc> hi lifeless
[00:29] <lifeless> poolie said you were having trouble reading my stacked loom
[00:30] <igc> lifeless: I think I was going about the merging the wrong way
[00:30] <igc> in particularly, I think I should have been looking at diff -rancestor: instead of a plain diff
[00:31] <lifeless> erm thats wrong
[00:31] <lifeless> you were going to merge bzr.dev into it right ?
[00:31] <igc> when merging bzr.dev, the latter was just too big to show anything as suspect
[00:31] <lifeless> do you know how to merge in a loom?
[00:32] <igc> lifeless: so my conclusion was that I needed to know more about your code before trying to 'just merge'
[00:32] <igc> I read the doc if that's what you mean
[00:32] <lifeless> but you haven't been working with a loom yourself?
[00:32] <igc> not until I branched yours, no
[00:32] <lifeless> ok
[00:33] <lifeless> this is roughly 'updating to upstream'
[00:33] <lifeless> in a clean branch made from mine
[00:33] <lifeless> bzr switch bzr.dev
[00:33] <lifeless> (or down-thread until it errors)
[00:33] <lifeless> then bzr pull $bzr.dev
[00:33] <lifeless> bzr up-thread
[00:33] <igc> did that
[00:33] <lifeless> bzr diff -r thread:
[00:33] <lifeless> (that will show the current patch)
[00:33] <igc> right
[00:34] <lifeless> run the test suite if there seems a chance of bzr.dev breaking what the patch does
[00:34] <igc> I was not adding the -r thread: bit
[00:34] <lifeless> st etc
[00:34] <lifeless> commit -m 'merge bzr.dev'
[00:34] <lifeless> bzr up-thread
[00:34] <lifeless> rinse, repeat
[00:35] <lifeless> when you reach the top, after committing do 'bzr record' push it somewhere and I'll pull it
[00:35] <igc> lifeless: cool. I'll do that now.
[00:35] <lifeless> k, back to deep hack for me
[00:35] <igc> I've been feeling pretty lousy lately but my brain ought t be good for a few hours
[00:36] <lifeless> I know the feeling
[00:36] <igc> lifeless: I suspect you feel worse actually
[00:37] <igc> mine is more a long term thing - perhaps something nasty I picked up on my last holiday
[00:37] <igc> off to the specialist tomorrow anyhow so at least I'd know what's going on then
[00:37] <igc> s/I'd/I'll/
[00:37] <lifeless> gl
[00:49] <jml> hmm. bzr just segfaulted on me.
[00:49] <bob2> 100 points
[00:49] <jml> well, my bzr plugin just segfaulted on me :)
[00:49] <jml> I guess I should be clear about that.
[01:13] <Gilgad13> hey has anyone one found a good way to reconcile eclipse's workspace directory structure with good repository layout?
[01:13] <Gilgad13> right now i'm just making links in my projects
[01:13] <Gilgad13> but thats not great because the project itself isn't source controlled
[01:14] <beuno> Verterok, ^
[01:14] <beuno> (and hi)
[01:14] <Gilgad13> and putting it in the same folder could work, but i was wondering if there is something better
[01:16] <beuno> Gilgad13, Verterok is the bzr-eclipse developer, so if you give him a minute or two to settle in, I'm sure he'll be able to give you a good answer
[01:16] <Gilgad13> nice
[01:16] <Verterok> Gilgad13: Hi... I don't know if I understand the idea :P
[01:16] <Verterok> you can have one workspace per repository :)
[01:16] <Gilgad13> yea
[01:16] <Gilgad13> thought of that
[01:16] <Gilgad13> i guess its the best way to go
[01:17] <Verterok> but it's a mess to keep configurations between workspaces :(
[01:17] <Gilgad13> i'm just used to having more control over where my projects go
[01:17] <Gilgad13> are the links in the eclipse project relative
[01:18] <Verterok> you can have the projects outside the workspace
[01:18] <Gilgad13> nvm, that would still mean many little workspaces running around
[01:18] <Gilgad13> really?, then what is the workspace used for?
[01:18] <Verterok> only to keep the .metadata directory
[01:19] <Verterok> so, you can have one workspace, and all your projects in other directory...like /home/<user>/Projects :D
[01:20] <Gilgad13> how would i create those
[01:20] <Gilgad13> just do the normal creation then move them out of my workspace?
[01:20] <Verterok> Gilgad13: take a look to: File --> Import --> Existing project into workspace
[01:20] <Gilgad13> ahh
[01:20] <Verterok> and if bzr-eclipse don't detect the .bzr..please file a bug :D
[01:21] <Gilgad13> certainly, i actually havn't dl'ed the plugin, how usable is it?
[01:23] <Verterok> Gilgad13: it's quite usable, but a bit slow (it uses bzr executable)...but I'm working on this problem right now :)
[01:23] <Gilgad13> alrighty, i'll take a look at it
[01:23] <Gilgad13> good luck
[01:23] <Verterok> thx!
[01:24] <Verterok> beuno: Hi, (and thanks for the pointer :) )
[01:25] <beuno> Verterok, whatever makes you work more  ;)
[01:26] <Verterok> hehe
[01:30] <lifeless> T-27
[01:31] <poolie> hello all
[01:31] <poolie> lifeless: ?
[01:32] <lifeless> poolie: 27 failing fixtures
[01:32] <poolie> oh great
[01:34] <Verterok> hi poolie
[01:46] <poolie> lifeless: jam was also wanting to help with the repository refactoring and stacking branches, could you mail him some pointers on where to get started?
[01:47] <lifeless> sure
[01:47] <lifeless> uhm
[01:47] <lifeless> network network network I would say
[01:51] <poolie> meaning network get_data_stream, or optimizations of what's currently done?
[01:51] <lifeless> the former
[02:01] <beuno> poolie, if you want any help with uploading 1.6 beta to PPA, let me know  :)
[02:01] <poolie> beuno: thanks, should be ok, going to do that soon
[02:03] <beuno> alright, I'm heading home then
[04:00]  * igc lunch
[04:16] <lifeless> T-16 time for lunch
[04:51] <Gilgad13> Verterok: does your bzr-eclipse plugin manage changing the name of the project when you branch?
[04:51] <Gilgad13> because when i try to do it manually, eclipse doesn't let me load more than one project with the same name into the same workspace (which is logical, i guess)
[04:52] <Gilgad13> or do you handle it a different way?
[04:54] <Verterok> Gilgad13: if you branch using the plugin, yes. it aallow to specify the project name
[04:54] <Verterok> Gilgad13: and yes, eclipse don't allow repeat project names or change them during import
[04:54] <Gilgad13> nice
[04:55] <Gilgad13> that seems to be the killer feature, because that is too much effort to do manually
[04:56] <Verterok> Gilgad13: I recently fixed a Bug #180207 related to the branch wizard, I'll try to upload a new build as soon time permits
[04:56] <Gilgad13> yea, looking at that right now, actually
[04:57] <Verterok> :)
[05:10] <lifeless> ok, in theory thats 0 failures
[05:10] <lifeless> running the full suite
[05:21] <Gilgad13> Verterok: thanks for the help
[05:22] <Verterok> Gilgad13: np, y're welcome
[05:22] <Verterok> if you have any other question, don't doubt to ping me
[05:42]  * igc pick up kids
[05:44] <lifeless> ok, zero failures
[05:44] <lifeless> (I'm not going to claim zero defects)
[06:08] <jml> lifeless: woot.
[06:08] <jml> lifeless: Does this make it a 1.6 candidate?
[06:18] <lifeless> no, now for weave_store nukage
[06:33] <igc> lifeless: http://people.ubuntu.com/~ianc/bzr/shallow-branch/ is my progress so far
[06:33] <igc> it's done bar 3 tests that I need to fix up
[06:34] <igc> tracking them down now ...
[07:10] <pygi> hey folks
[07:23] <lifeless> igc: what thread do they start failing in ?
[07:23] <igc> lifeless: they vary ...
[07:24] <igc> one was fixed by removing deprecations from bzr-loom
[07:24] <igc> i.e. merging abentley's branch
[07:24] <igc> one is related to tests/http_server unicode path handling
[07:24] <igc> I think I've just fixed it
[07:24] <igc> the last is test_interprepository - about to do it next
[07:24] <Slant> Is there a way to have bzr call a script after a commit?
[07:27] <bob2> Slant: bzr help hooks
[07:28] <Slant> bob2: Thanks.
[07:33] <Slant> bob2: Can a hook be embedded in a repo?
[07:34] <bob2> probably, but hooks are run by clients
[07:35] <igc> lifeless: shall I upgrade the format # from 1.3 to 1.6 where applicable while I'm in there?
[07:37] <bob2> how's the new rich-as-a-default-format thing looking for 2.6?
[07:37] <bob2> oops, the beta's out
[07:37] <Slant> bob2: Thanks!
[08:14] <poolie> night
[08:28] <igc> current state of merging bzr.dev into the stacked branches loom is now pushed to http://people.ubuntu.com/~ianc/bzr/shallow-branch/
[08:28]  * igc dinner
[09:10] <jelmer> LarstiQ: I just found what is causing the slowness in the bzr-svn testsuite
[09:11] <jelmer> LarstiQ: libsvn_client (the glue between working copy and remote repository access) waits for the next second every time you do a disk operation!
[09:12] <Jc2k> jelmer: that sounds quite yucky!
[09:14] <AfC> Yikes!
[09:15] <AfC> I think that Jelmer should win an award for being the guy who puts up with coding against Subversion so the rest of us can deal with foreign VCSes
[09:16] <Jc2k> he needs our beer, for sure
[09:33] <jelmer> AfC, :-)
[09:33] <jelmer> Jc2k: yeah, it's pretty nasty - but shouldn't be too hard to work around
[09:55]  * mwhudson thinks the jelmer beer fund should be considerable by now
[10:30] <lifeless> jelmer: ah yes, the old '1 sec wait to 'fix' race conditions' bug
[10:30] <liw> . o O (First Internet Bank of Beer)
[10:41] <munckfish> Hi is it possible to specify an alternative SSH key for use with bzr+ssh protocol? I have two keys for separate uses. I'm not seeing an obvious way either in 'push' or in the available config options.
[10:45] <Pieter> stupid first three letter match
[10:45] <Pieter> heh
[10:45] <Pieter> nevermind that
[10:48] <james_w> munckfish: hi, you want a different key to be used for sftp:// and bzr+ssh:// to the same host, or something else?
[10:49] <munckfish> james_w: Hi. I have 2 keys one for work in id_rsa and one for ubuntu which is stored in id_rsa.1
[10:49] <james_w> munckfish: so the differentiation would be by host?
[10:49] <munckfish> I need to select use of the second key
[10:49] <munckfish> Um yes I guess so
[10:49] <james_w> I do this with ~/.ssh/config
[10:49] <munckfish> aha I see
[10:50] <james_w> with stanzas like:
[10:50] <james_w> Host bazaar.launchpad.net
[10:50] <james_w> Hostname bazaar.launchpad.net
[10:50] <james_w> User james-w
[10:50] <james_w> IdentityFile2 ~/.ssh/id_rsa.1
[10:50] <munckfish> james_w: thx I'll try that.
[11:41] <jelmer> lifeless, yep, that's the one
[11:41] <jelmer> lifeless, I'm working around it by simply not using libsvn_client but using the bzr infrastructure to let the diff reporter and commit builder talk to each other
[11:42] <lifeless> jelmer: :P
[11:42] <lifeless> jelmer: that *is* why we wrote bzr's code the way we did
[11:44] <jelmer> lifeless: yeah, that's a big help
[11:45] <jelmer> strangely enough there's no way to turn that behaviour in the subversion client libraries off
[11:45] <jelmer> no wonder their test suite takes so long to run :-P
[13:32] <awilkins> jelmer: I think the "wait next second" thing had a purpose, possibly to do with timestamps, but I can't recall exactly what it is
[13:32] <jelmer> awilkins: yes, it does indeed have a purpose - see lifeless' comment
[13:35] <awilkins> I have half a mind to test bzr using this ext2 driver for windows to see if things get faster
[13:35] <awilkins> Problem is I don't have any internal ext2 partitions so it's not a fair test I suppose
[13:36]  * awilkins waits 'til he gets home
[13:41] <lifeless> awilkins: this is the 1 sec thing: diff is expensive, so vcs's often avoid diffing by using a timestamp comparison on the file - if it hasn't been edited since the vcs last had a empty diff, don't bother diffing
[13:41] <lifeless> awilkins: now filesystems have a granularity (e.g. 2 seconds for FAT)
[13:41] <awilkins> Makes sense
[13:42] <lifeless> awilkins: and the record of when a diff was done has some granularity (e.g. 1 second)
[13:42] <lifeless> so what cvs did at one point (its broken these days) and svn does to, is to wait until the system time is greater than the time it wrote into any of its records as the last diff done
[13:42] <awilkins> Is hashing faster than diff?
[13:43] <lifeless> hashing is faster yes, but still not free
[13:43] <awilkins> Indeed
[13:43] <lifeless> now in principle that delay can be 0 if the last file was modified before the current time when the op finishes
[13:43]  * awilkins potters off to install some software (Including bzr! Hahaha!)
[13:43] <lifeless> but there is a better way
[13:44] <lifeless> which is to not write the time *at all* to disk for a file created during the file systems granularity, and then you can return immediately safely
[13:44] <lifeless> gnight
[13:44] <awilkins> By that, you mean writing the time to the cache?
[13:44] <lifeless> yah
[13:45] <lifeless> just say 'we don't know if the file is modified or not'
[13:45] <lifeless> on small trees this means 'checkout' ends up with no files in the cache after checkout
[13:45] <lifeless> on big trees the first files written will be in the cache
[13:45] <lifeless> so its self limiting
[13:45] <lifeless> and allows extremely fast repeated operations whenever diff can be done in less time than waiting one secod
[13:46] <lifeless> (and as the limit is the time to write files, this is almost guaranteed to be the case)
[13:46] <lifeless> really gone - ciao
[14:08] <mpt> Is "bzr check" supposed to be usable on a remote branch that doesn't belong to you?
[14:13] <jelmer> mpt: I think so
[14:13] <jelmer> at the very least it should give a sensible error if it can't - what are you seeing?
[14:18] <mpt> reported as bug 237067
[14:22] <james_w> it might be a side effect of "Server does not understand Bazaar network protocol 3, reconnecting. (Upgrade the server to avoid this.)"
[14:23] <james_w> or it may just be a missing lock call of course.
[14:24] <spiv> I very much doubt the protocol 3 warning is related.
[14:24] <spiv> After all, that message happens because it *isn't* using the new, shiny protocol :)
[14:26] <james_w> hi spiv
[14:27] <spiv> Good evening.
[15:15] <dash> hi, got a bzr-svn question
[15:16] <Jc2k> whats up
[15:17] <dash> how do I create a new branch in the svn repo? branch, then svn-push?
[15:18] <asabil> jamesh: ping ?
[15:23] <jelmer> dash: Yeah, svn-push is the command to use
[15:23] <dash> i'm trying to use bzr-svn to cheat on our svn workflow a little
[15:24] <dash> normally all branches are created from trunk, due to lack of merge tracking
[15:25] <dash> I want to use bzr-svn to create a branch from an existing non-trunk svn branch
[15:25] <dash> later on i'll probably merge it forward
[15:26] <dash> (meaning, create a new svn branch from trunk, apply the diff of the old branch to its WC, commit)
[15:27] <dash> still trying to figure out how to do that without confusing myself or our other svn users :)
[15:30] <radix> does svn-push create an empty revision for the creation of the branch?
[15:30] <radix> I think it didn't in the past, but I remember hearing about discussion on that
[15:31] <radix> many SVN-based merging methods or tools won't work unless it's there
[15:31] <radix> dash: (such as Combinator)
[15:31] <dash> yeah
[15:32] <dash> radix: right now i'm thinking i'll just not bother with svn-push at all
[15:32] <dash> and make a branch with combinator after the pending branch is merged, and copy the diff manually into it
[15:35] <dash> crude, but effective!
[15:49] <tethridge> is there a known bug where you can't resize the width of olive aka "bzr vis" to make it smaller?
[15:51] <tethridge> I can't find a bug on launchpad or google
[15:51] <tethridge> I'm not sure if olive is considered part of bzr
[15:52] <dash> i'm pretty sure bzr vis and olive are different
[15:52] <tethridge> it looks like the same user interface to me
[15:52] <tethridge> I didn't install olive, I installed bzr-tools
[15:52] <pickscrap1> I thought they were both part of bzr-gtk?
[15:53] <tethridge> that's one way to limit your bug count
[15:53] <tethridge> make it impossible to find the project in launchpad.  :-)
[15:54] <tethridge> I'll add a bug
[15:57] <beuno> tethridge, viz is a part og bzr-gtk
[15:57] <tethridge> beuno, thanks.  I'm adding a bug there now.
[15:57] <beuno> so please file the bug against bzr-gtk, and thanks for reporting it  :)
[15:58] <semslie> jelmer: I didn't manage to reproduce that problem I was having yesterday, but I did find that if I cleared the svn-cache before and after rebasing, then the svn-push worked without a hitch. Perhaps this is worth adding as a comment in that bug?
[16:15] <Stavros> hi
[16:15] <beuno> hey  :)
[16:15] <beuno> well
[16:15] <Stavros> so how do i do that? :P
[16:15] <beuno> bzr branch lp:bzr
[16:15] <Stavros> in my site-packages dir?
[16:16] <beuno> well, this is windows or linux?
[16:16] <Stavros> windows
[16:17] <beuno> hrm, well, in Linux you just symlink the bzr executable to /usr/bin
[16:17] <beuno> so I imagine you can do something similar, but I can't really give you specifics, as I haven't run windows in years
[16:17] <Stavros> hmm
[16:18] <Stavros> i can't even find which script runs when i run bzr in windows...
[16:18] <Stavros> oh wait, "which bzr" works
[16:18] <beuno> markh, maybe you can provide some insight on how to run bzr.dev on windows?
[16:19] <Stavros> beuno: actually i probably only need to pull bzrlib
[16:19] <beuno> (he's probably not around yet)
[16:19] <beuno> Stavros, well, in general, yes
[16:20] <beuno> and, you can't really *just* pull bzrlib
[16:20] <Stavros> hmm, why not?
[16:20] <beuno> well, it's not a separate branch
[16:21] <Stavros> ah
[16:21] <Stavros> well the bzr script that runs imports bzrlib
[16:21] <Stavros> and that's the only thing i have in my site-packages
[16:23] <beuno> well, let me know how that goes  :)
[16:23] <Stavros> will do :)
[16:26] <awilkins> Yeah, just pull bzr.dev and change the script to point to THAT bzrlib instead
[16:27] <Stavros> let me try that
[16:27] <awilkins> I don't dogfood it though, just test it
[16:27] <awilkins> Which is cd <bzr.dev> ; python bzr selftest [options]
[16:28] <muszek> hi... would "bzr: ERROR: [Errno 13] Permission denied" mean that I don't have sufficient permissions somewhere withing .bzr or within working directory?
[16:29] <beuno> muszek, it depends if you're pushing through ssh/sftp/ftp or locally
[16:29] <beuno> locally, yes, because it updates automatically
[16:30] <beuno> remotely, within .bzr
[16:31] <muszek> bueno: I've made a commit from a remote machine (binded to this repo) without a problem... now I want to update this tree and that's the error I get
[16:32] <beuno> muszek, then it's probably within the working tree
[16:32] <beuno> did you peak in .bzr.log?
[16:32] <beuno> it should say what file is complaining
[16:33] <muszek> bueno: I added myself to a group "hotels", chowned everything to belong to this group and then chmodded everything g+w
[16:33] <muszek> bueno: looking now
[16:38] <muszek> bueno: it's just this error + a bunch of python error messages, which I don't really follow... would you please take a look at: http://alpha.muszek.com/bzr.txt ?
[16:40] <beuno> muszek, it seems to be either this file: webroot/css/hotels.css, or the one after it
[16:41] <beuno> could you run a "ls -l" on that dir and check for what permision/users are set??
[16:42] <muszek> bueno: I followed these instructions to make it "multiuser-friendly" - http://buszek.mine.nu/temp/bzr.setup
[16:42] <muszek> everything belonged to tomekg before that.
[16:42] <beuno> oh, so we should blame james_w, that's great news!  :)
[16:43] <muszek> to me permissions seem to be fine... everything belongs to tomekg/hotels
[16:43] <james_w> what did I do this time?
[16:43] <muszek> heh :).  I talked to him maybe 2 months ago when was setting another repo (same server)... it works fine.
[16:43] <beuno> muszek, and you are updating with a user via ssh/sftp, which is the "hotels" group?
[16:43] <beuno> hi james_w   :)
[16:43] <james_w> oh, yeah, I thought something about this was familiar
[16:43] <james_w> hi beuno
[16:43] <james_w> hi muszek
[16:44] <muszek> bueno: in the bzr.setup there's a "newgroup"... I substituted it with "hotels"
[16:44] <muszek> hi james_w ... as you can see, your help isn't forgotten :)
[16:44] <james_w> not forgotten because it didn't work :-)
[16:45] <muszek> :)
[16:46] <muszek> this commit creates/modifies/deletes files and creates a new dir... is it possible that I don't have a permission for something?
[16:47] <muszek> s/commit/revision
[16:51] <muszek> bueno: bzr log -v tells me that hotels.css is a last file... prior to that I manually erased one file that's been outputted after hotels.css (as you can see, previous error starts right after [23902] 2008-06-03 15:26:31.776 INFO: -D  webroot/css/reset-fonts-grids.css)
[16:51] <beuno> muszek, then it's probably a problem with deleting files
[16:52] <beuno> which I can't really understand why, so maybe james_w does  :)
[16:52] <muszek> bueno: but I've been able to delete it from command line (using the same user)
[16:52] <james_w> well the failure is actually in a rename.
[16:53] <james_w> but it looks like that rename is actually part of a delete operation
[16:54] <muszek> hmmm... on my local machine I renamed manually (not via bzr) reset-fonts-grids.css to hotels.old-yui.css ... but I haven't added hotels.old-yui.css to bzr
[16:55] <danielm> hi all :).. sorry the noob question, but any idea why a bzr push to a LP new brach returns me: "but does not have a valid .bzr directory" ¿? maybe a bzr version problem?
[16:56] <james_w> muszek: can you check to see whether you have a .bzr/checkout/pending-deletion directory on the side where you are getting the error
[16:56] <james_w> muszek: and if you do what the permissions on it are.
[16:56] <james_w> danielm: does it work if you supply "--use-existing-dir" as suggested?
[16:57] <danielm> yes
[16:58] <muszek> james_w: no, I don't
[16:59] <muszek> james_w: I mean I don't have such dir
[16:59] <james_w> muszek: ok, can you run "BZR_PDB=1 bzr update" and when it gives you the prompt have another look?
[17:01] <muszek> james_w: http://pastebin.us/?show=m35797f60 (after hotels.css)
[17:03] <james_w> muszek: yup, can you see if you have ".bzr/checkout/pending-deletion" now please?
[17:04] <muszek> james_w: still nothing
[17:04] <muszek> and I am able to create a dir manually in .bzr/checkout
[17:05] <james_w> muszek: ok, so if you haven't got one then that may be why it is failing
[17:05] <james_w> actually, to be sure, can you run "find . -name pending-deletion" please?
[17:06] <james_w> muszek: you didn't exit the debugger before looking for the directory did you?
[17:06] <muszek> james_w: nothing found
[17:06] <muszek> james_w: I didn't exit
[17:06] <muszek> james_w: I did right before using "find", though
[17:07] <james_w> though it would be really odd if the directory were created by you and then you couldn't write to it.
[17:07] <james_w> ok, so can you please run "BZR_PDB=1 bzr update" again?
[17:07] <james_w> then when you get the prompt please type "p from_"
[17:07] <james_w> and then "p to"
[17:08] <muszek> james_w: http://pastebin.us/?show=m7212f682
[17:09] <james_w> ok, and again before quitting, can you see if you have "/var/www/hdev/app/.bzr/checkout/pending-deletion/"
[17:10] <james_w> I'm assuming that "/var/www/hdev/app/app_controller.php" exists.
[17:10] <muszek> app_controller.php exists, pending-deletion still doesn't
[17:10] <muszek> debugger is running
[17:11] <james_w> weird
[17:11] <beuno> muszek, you could you possibly be testing through ssh, and pushing through ftp/sftp?
[17:11] <james_w> and so why is it EPERM and not ENOENT?
[17:12] <james_w> muszek: can you please run (normal shell) "cp /var/www/hdev/app/app_controller.php /var/www/hdev/app/.bzr/checkout/pending-deletion/"?
[17:12] <james_w> it will fail, but I'm interested if it is EPERM.
[17:12] <muszek> jamesh: app_controller.php is a second modified file on the list (first one is .bzrignore)
[17:13] <muszek> bueno: I don't know exactly  what you mean.  I have a local repo that I binded with remote via "bzr bind bzr+ssh://remote.server/var/www/hdev/app" command.  I commited from local machine and now I'm updating on a remote server (via ssh)
[17:15] <muszek> james_w: muszek@alpha:/var/www/hdev/app$ cp /var/www/hdev/app/app_controller.php /var/www/hdev/app/.bzr/checkout/pending-deletion/
[17:15] <muszek> cprov: cannot create regular file `/var/www/hdev/app/.bzr/checkout/pending-deletion/': Is a directory
[17:15] <muszek> do you want me to create pending-deletion first?
[17:15] <cprov> muszek: excuse me ?
[17:16] <james_w> muszek: no need, how about "mv /var/www/hdev/app/app_controller.php /var/www/hdev/app/.bzr/checkout/pending-deletion/new-3"?
[17:16] <muszek> cprov: sorry... my xchat somehow auto-completed cp: to cprov: (don't know how that happened, I pasted the whole two lines)
[17:17] <muszek> james_w: mv: cannot move `/var/www/hdev/app/app_controller.php' to `/var/www/hdev/app/.bzr/checkout/pending-deletion/new-3': No such file or directory
[17:18] <james_w> muszek: ok, thanks, so there is something a bit weird there, but I don't think it's the cause of your problem, let me look at some code for a minute
[17:18] <muszek> james_w: ok...
[17:19] <muszek> james_w: maybe I should try that with a user who owns those files (tomekg)?
[17:19] <muszek> brb (2 minutes)
[17:19] <james_w> muszek: aha, can you in fact make the /var/www/hdev/app/.bzr/checkout/pending-deletion/ dir?
[17:19] <james_w> my guess is not.
[17:22] <muszek> one sec
[17:23] <muszek> created... now update or copying of app_controller.php? (btw... app_controller.php is not the file that was about to be deleted)
[17:24] <muszek> app_controller.php was merely modified in this revision
[17:26] <muszek> I tried bzr update and got an error telling me to delete pending-deletion (something about leftover files)
[17:26] <muszek> I removed it, updated again and this time I got an error... same thing, only with .bzr/checkout/limbo
[17:27] <james_w> telling you to delete limbo?
[17:28] <muszek> yes
[17:28] <james_w> and if you do that what happens
[17:28] <james_w> ?
[17:30] <muszek> "almost" the same, as original error
[17:30] <muszek> I recreated manually deleted webroot/css/reset-fonts-grids.css in the meantime
[17:30] <muszek> james_w: http://pastebin.us/?show=m4225a7de
[17:32] <james_w> ok, can you run again, adding the -Derror argument to bzr plrease?
[17:34] <muszek> james_w: http://pastebin.us/?show=m47e2de21
[17:34] <muszek> james_w: just to be safe, I chowned reset-fonts-grids.css from muszek:muszek to tomekg:hotels
[17:35] <james_w> ok, so it's the same error it seems
[17:36] <muszek> james_w: I could always revert to the last revision locally, remove and commit on the remote machine and commit back... but I'm affraid I'll run into the same thing next time I remove something locally
[17:37] <jam> abentley: BB is down again
[17:37] <james_w> muszek: care to add a line to bzr to test a hypothesis for me?
[17:37] <muszek> james_w: sure
[17:38] <abentley> jam: Thanks.  Back.
[17:39] <james_w> muszek: we need to edit bzrlib/transform.py , what distro are you running? Are you using the packaged version?
[17:39] <beuno> abentley, btw, I did keep on working on migrating BBs DB, I just came to the conclusion that I need to write a script to do it, so it will take a bit more time  :)
[17:39] <andrea-bs> is the launchpad plugin included in bzr 0.15?
[17:39] <abentley> beuno: Oh, okay.
[17:39] <muszek> james_w: hardy, packages from official repos (both machines)
[17:40] <james_w> cool, the easy case
[17:40] <muszek> james_w: the remote machine is installed from some really small image (~100MB, it's a VPS)
[17:40] <james_w> so, please edit /usr/lib/python2.5/site-packages/bzrlib/transform.py
[17:41] <muszek> it was stripped of pretty  much everything (I don't even get a tab completion when I do sudo chmod wwwTAB)
[17:41] <james_w> line 1164, it should currently be
[17:41] <james_w> raise errors.ExistingPendingDeletion(deletiondir)
[17:41] <james_w> please add a line after that is
[17:41] <james_w> raise
[17:42] <james_w> it should be indented to the same level as the "if e.errno == errno.EEXIST:" line just above
[17:42] <muszek> care to remind me how to "go to" or check what line it is in vim? (sorry, I'm not a wiz :/ )
[17:42] <james_w> :1164
[17:43] <james_w> or 1164gg
[17:43] <james_w> and make sure you are indenting with spaces, no tabs.
[17:44] <muszek> single word "raise" inserted there
[17:44] <james_w> yup
[17:45] <muszek> update again?
[17:45] <james_w> I think there may be an error here that is being swallowed.
[17:45] <james_w> yes please.
[17:46] <muszek> did a regular bzr update... same error
[17:46] <james_w> same traceback with -Derror?
[17:47] <muszek> james_w: http://pastebin.us/?show=mfe42e12
[17:47] <james_w> ok, it's not that then
[17:47] <james_w> I'm stumped
[17:48] <muszek> I'm checking a dictionary for "stumped" :)
[17:49] <james_w> care to pastebin the output of "ls -lR .bzr"?
[17:50] <muszek> james_w: http://pastebin.us/?show=m7165e1dc
[17:51] <muszek> (reverting trasform.py back to what it was originally)
[17:52] <james_w> looks fine to me
[17:52] <james_w> would you like to file a bug report?
[17:53] <muszek> sure... only what would I put in it?
[17:54] <muszek> I can attach a log from this conversation.  Pastebins should be there for 1 month.
[17:54] <james_w> the traceback is the most important thing
[17:55] <james_w> can you paste that in directly, rather than relying on the pastebins please
[17:55] <muszek> also (unrelated to a bug report).  would you like me to try deleting locally and updating on a remote server with that repo that you helped me with ~2 months ago?
[17:55] <muszek> it seems to  work, only I'm not sure that I've done this exact operation there
[17:58] <muszek> james_w: I've done it on the other repo - it worked ok
[17:59] <muszek> same machines, same steps followed when setting them up
[18:01] <james_w> odd
[18:01] <muszek> james_w: just updated it with the user that owns all files (tomekg) and it worked fine
[18:02] <muszek> james_w: the last question: is this the output I should attach? http://pastebin.us/?show=mfe42e12
[18:25] <muszek> james_w: thanks a lot for you time.  bug report's here: https://bugs.launchpad.net/bzr/+bug/237140
[18:32] <muszek> I removed anothere file locally, commited and did bzr update on a remote machine - it went fine.  So I can't even reproduce it anymore :/
[18:53] <abentley> muszek: write permission on a file does not confer permission to delete it.  Only write permission on its containing directory does.
[18:53] <muszek> abentley: group had a write permission on a parent directory
[18:54] <muszek> and I was able to delete the file manually
[18:54] <abentley> Then perhaps it was inability to rename into the temporary directory.  Seems unlikely, though.
[18:54] <fullermd> Sure you logged out in between?  Groups are set when your session begins, so it doesn't pick up changes until you relog.
[18:55] <muszek> fullermd: I know, I opened new sessions right after I added myself to that group.
[18:55] <abentley> muszek: Whatever the cause, the permission error was encountered by the underlying OS.  Bazaar just propagated it.
[18:57] <muszek> abentley: I was able to create that file manually.  james____w (mistyped nick, I don't want to ping him) asked me to issue some commands and possibly their goal was to see if .bzr/checkout/pending-deletion  (or similar) was created and it wasn't... but I was able to create it manually.
[18:58] <abentley> muszek: Create which file?
[18:58] <muszek> create dir .bzr/checkout/pending-deletion
[18:59] <abentley> That's very odd.  If that directory cannot be created, you should get an exception immediately.
[18:59] <muszek> imo it's not worth looking into now that I can't even reproduce it.
[19:00] <abentley> Okay, looks like there's a flaw in that creation logic.
[19:00] <abentley> It special-cases ExistingPendingDeletion, and forgets to handle the rest.
[19:01] <james_w> abentley: yup, I asked him to add a raise there, but it didn't seem to show any errors
[19:02] <abentley> james_w: yeah, that doesn't make much sense.
[20:45] <siretart> how to set the 'submit' branch in my branch?
[20:53] <muszek> siretart: you might be looking for bzr bind command (I'm not even remotely good at this stuff)
[20:54] <siretart> muszek: no, that does something completely different
[20:54] <muszek> ok.  sorry, I can't help you then
[20:56] <james_w> siretart: $EDITOR ? :-)
[20:56] <beuno> siretart, you can do:  bzr send BRANCH --remember
[20:56] <james_w> siretart: I think "merge --remember" does it as well
[21:00] <siretart> james_w: ah, but when I don't actually want to do a merge, but just use 'bzr diff -rsubmit:', and fix the broken submit path?
[21:00] <siretart> beuno: that sounds interesting. will try that
[21:01] <james_w> siretart: I think it's in locations.conf, but I know that's not ideal.
[21:01] <james_w> siretart: btw, did you see that I would like an upload of builddeb? It's not urgent, but if you get some time soon then I would appreciate an upload.
[21:16] <siretart> james_w: no, I must have missed that
[21:16] <siretart> james_w: was that on pkg-bazaar?
[21:17] <james_w> siretart: ah, no problem, I snuck it in.
[21:17] <james_w> siretart: yes, and IRC a while before that, but you were away at the time.
[21:17] <siretart> ah, found the mail
[21:17] <james_w> it's sitting in the trunk branch on bzr.debian.org if you get time.
[21:17] <siretart> I'm not sure if I get to it today, but I see that I do that soon
[21:17] <siretart> need to fixup ffmpeg :/
[21:18] <james_w> siretart: good luck
[21:33] <perre> hi... i
[21:34] <perre> i'm using bzr to get a branch... i even tried the bzr devel branch (bzr branch http://bazaar-vcs.org/bzr/bzr.dev). but it gets too slow... i couldn't pass the Copying inventory texts 2/5 step
[21:34] <perre> am i missing sth?
[21:35] <perre> btw, version is 1.5
[21:36] <beuno> perre, is this a public branch?
[21:37] <perre> yes
[21:37] <beuno> perre, what's the URL?
[21:37] <perre> this happens even when i try to get the bzr development branch... but i first tried with mysql
[21:37] <perre> bzr branch lp:mysql
[21:38] <perre> or bzr branch http://bazaar-vcs.org/bzr/bzr.dev
[21:38] <beuno> ah, with big-ish branches
[21:38] <james_w> perre: have you run "bzr lp-login" before?
[21:38] <beuno> could you take a look at ~/.bzr.log?
[21:38] <beuno> james_w, AFAIK, branching through http is faster than ssh, currently, so that shouldn't be the problem
[21:38] <perre> yes, i tried but no success
[21:38] <james_w> beuno: ah, ok.
[21:39] <perre> beuno: yes, taking a look at .bzr.log
[21:39] <perre> what should i look for?
[21:39] <beuno> perre, could you do:  bzr branch lp:bzr -Dhpss
[21:39] <beuno> and then, tail .bzr.log
[21:39] <beuno> we should get more information from there
[21:40] <beuno> (speeds, eventual errors, etc)
[21:41] <perre> just lines like this
[21:41] <perre> 552.563  http readv of 56cec13f12c690045140c0067e99a2b4.pack  offsets => 516 collapsed 3
[21:41] <beuno> perre, could you paste the last ~100 lines from that in pastebin?
[21:41] <perre> hmm.. wait.. it just finished to get the bzr.dev
[21:41] <beuno> ah
[21:41] <beuno> :)
[21:41] <perre> but mysql is taking longer
[21:41] <perre> is because of the size of the branch?
[21:42] <beuno> perre, well, the size of the branch obviously matters a lot, yes
[21:43]  * beuno checks for the size of the mysql branch
[21:43] <perre> i see... the problem is that i didn't get any visual notification of progress...
[21:44] <perre> there is the progress bar, but since it is too big, it was slow
[21:44] <perre> and even using verbose didn't show anything else
[21:44] <beuno> right, we should do better in that area, yes
[21:44] <beuno> we have sucky progress bars  :/
[21:44] <perre> LOL :P
[21:45] <perre> ok... i will let the pc working
[21:45] <beuno> perre, feel free to file a bug for it  :)
[21:45] <perre> thanks folks!!!
[21:46] <beuno> that makes me wonder if http still really is slower than bzr+ssh...   spiv should know, but it may be a but too early
[21:48] <Peng> I benchmarked branch once, and with packs, nosmart+http was quite a bit faster than bzr+http.
[21:49] <Peng> That might've been with artificially low latency though.
[21:49] <beuno> well, lifeless explained why it was slower, but the fix wasn't too complicated, so it may have gotten fixed
[21:51] <beuno> at the last sprint, that is
[21:56] <beuno> Repository:
[21:56] <beuno>      54233 revisions
[21:56] <beuno>     706538 KiB
[21:56] <beuno> that explaines why it's slow to branch mysql  :)
[21:59] <j^> hi, a question, what is the difference between bzr+ssh and sftp?
[21:59] <j^> which one should be faster
[22:00] <beuno> j^, if the server has bzr installed too, than bzr+ssh, which uses the bzr smart server
[22:00] <Peng> j^: sftp simply uses sftp. bzr+ssh sshes in and runs 'bzr serve', which means bzr has to be installed on the server, but it's faster.
[22:01] <j^> ok great, have installed bzr on both sides will use bzr-ssh from now on
[22:01] <j^> pushing still is a bit slow
[22:02] <j^> but that would be ssh key negotiation or something like that
[22:02] <beuno> j^, it's especially fast with push/pull/merge operations, as it can easly find out what it needs to transfer
[22:04] <newz2000> what do you do when you accidentally commit an enormously large file and now your .bzr folder is too large?
[22:04] <mtaylor> buy more disk
[22:04] <Peng> newz2000: "bzr uncommit" ASAP?
[22:04] <Peng> Or that.
[22:04] <mtaylor> ;)
[22:04] <newz2000> hmm. Well, about the asap thing, I realize I did this months ago
[22:04] <Peng> Heh.
[22:04] <Peng> Oops.
[22:05] <j^> if its not the last commit bzr branch -rBEFORE and continue in the other branch
[22:06] <newz2000> what are the consequences of deleting the offending .knit file?
[22:06] <beuno> terrible  :)
[22:07] <beuno> it will probably break the repo
[22:07] <Peng> Ew, you're still using knits?
[22:08] <newz2000> yep, you're write, terrible.
[22:08] <newz2000> something is now foobar'd
[22:08]  * newz2000 tries something else
[22:08] <Peng> You deleted the knit?
[22:08] <newz2000> from a copy of the branch
[22:09] <Peng> When is deleting random files ever *good*?
[22:10] <newz2000> it was worth a try. Maybe I should have just cat /dev/null > the.knit
[22:10] <newz2000> but I'll try your suggestion and make the branch
[22:12] <beuno> newz2000, nothing good will come from anything other than re-branching without that file
[22:12] <beuno> there may be some magic possible with rebase
[22:12] <beuno> but I may be wrong
[22:13] <newz2000> is there detailed instructions on how to do this? I'm still not that experienced with bzr's advanced features
[22:14] <beuno> I'm pretty sure there isn't
[22:15] <newz2000> ok, so I have to find out what version the file was added at, then branch from right before that
[22:16] <beuno> yes, that seems like the safest option
[22:16] <newz2000> then what, copy thew newest versions of my files over to the branch and commit?
[22:16] <beuno> yeap
[22:16] <newz2000> ok, simple enough
[22:16] <beuno> you'll loose the history after that file was committed
[22:16] <beuno> but I guess it's a tradeoff
[22:17] <beuno> btw, newz2000, you do a lot of work with webpages, right?
[22:17] <newz2000> yeah that's no problem. I use bzr for a safety net and collobration
[22:17] <newz2000> beuno: yes
[22:17] <beuno> well, we've been working on a plugin that might interest you
[22:17] <beuno> bzr-upload
[22:17] <newz2000> what does it do?
[22:17] <beuno> it basically uploads files
[22:18] <beuno> no bzr-related information
[22:18] <beuno> remembers the last revision uploaded
[22:18] <Peng> newz2000: You might be able to rebase so that you won't have to recommit everything.
[22:18] <beuno> so bzr-upload will just upload what was changed since the last upload
[22:18] <beuno> main target is obviously for webpage developers
[22:19] <beuno> it's still under development, but I use it almost daily, and it's stable enough
[22:19] <newz2000> so right now I often use sftp to copy an entire site up, and your plugin would only copy the files that changed since the last time I uploaded?
[22:19] <beuno> correct
[22:19] <beuno> sftp/ftp
[22:19] <newz2000> and it leaves out the .bzr folder?
[22:19] <beuno> yeap
[22:19] <newz2000> that is nice
[22:19] <beuno> :)
[22:20] <newz2000> is it on the bzr website?
[22:20] <beuno> not really, but,  http://launchpad.net/bzr-upload
[22:20] <beuno> and/or:  bzr branch bzr-upload ~/.bazaar/plugins/upload
[22:20] <newz2000> I actually think about this quite often
[22:20] <beuno> and you're ready to help us test it  :)
[22:20] <newz2000> well, once a week or so
[22:21] <beuno> yeah, I did too. So, a bzr sprint and vila's magic later, we're pretty close
[22:22] <newz2000> ok, so I apparently bzr rm'd the file a while ago and I'm not sure how to find out what revision to branch from
[22:22] <newz2000> is there a way?
[22:22] <beuno> newz2000, bzr log filename
[22:22] <beuno> should still tell you I think
[22:23] <newz2000> bzr: ERROR: Path does not have any revision history: live.backup.sql.gz
[22:23] <newz2000> how would you interpret that?
[22:23] <beuno> is that the full path?  that file was in the root of the branch?
[22:24] <newz2000> I guess I don't know
[22:24] <newz2000> I think so though, it's not a deeply nested project
[22:25] <beuno> hrm
[22:26] <ToyKeeper> bzr log -v | grep -20 my.file.name ?
[22:27] <beuno> right, it doesn't work once the file is gone
[22:27] <beuno> there should probably be a bug about this...
[22:27]  * beuno looks
[22:28] <newz2000> no luck using log -v. :-) I guess most people who use vcs don't want to delete segments of their history
[22:28] <beuno> right, bug #181520
[22:28] <newz2000> so can I look for missing revisions?
[22:29] <ToyKeeper> Hmm, works for me.  "bzr log -v" with no other parameters shows all files added/removed, even if they on longer exist.
[22:29] <beuno> newz2000, I'd say fo something like:   bzr log -v > log.temp, and then grep log.temp for that file name
[22:29] <ToyKeeper> s/on longer/no longer/ :)
[22:29] <beuno> find the last revision it was added, go form there
[22:30] <newz2000> wow, maybe I'm just really confused, it's not even in log.temp
[22:30] <newz2000> oh
[22:30] <newz2000> my copy is small
[22:31] <newz2000> my copy apparently didn't have the file in its history
[22:32] <beuno> ah, well, that solves a lot  :)
[22:33] <newz2000> ok, well, I have no idea what happened but it's fixed now.
[22:33] <newz2000> Thanks a bunch for your help
[22:33] <beuno> np  :)
[23:22] <mwhudson> so if you have a lightweight checkout and the branch it's a checkout of has moved
[23:22] <mwhudson> is there an easier way of updating things than 'emacs -nw .bzr/branch/location' ?
[23:23] <awilkins> bzr bind <new_location> ?
[23:26] <mwhudson> hm, i thought that complained if it couldn't find the old location
[23:26] <mwhudson> i'll have to remember to try it next time :)
[23:28] <spiv> mwhudson: bzr switch
[23:29] <mwhudson> spiv: no, that definitely complains
[23:30] <beuno> mwhudson, howdy
[23:31] <mwhudson> beuno: hi!
[23:31] <beuno> mwhudson, how's everything?
[23:32] <mwhudson> beuno: ok, still worrying mostly about the ~vcs-imports stuff
[23:32] <beuno> mwhudson, ah, you always get to work on the fun stuff...  :)
[23:32] <beuno> is that what made code scanner crazy the other day?
[23:33] <mwhudson> no
[23:33] <mwhudson> that was something else :)
[23:33] <beuno> heh, I'll keep on guessing then
[23:33] <beuno> did you have a chance to take a peak at the latest branch I uploaded?
[23:34] <mwhudson> no :(
[23:34] <beuno> ah, np
[23:34] <beuno> I've done a few tests, and I can get a 30k diff without many problems
[23:35] <beuno> the current code is still a little hackish, but it does seem promising
[23:35] <beuno> there is a few good reasons, aside from zpt that it does render faster/with less memory, one of them being we don't render/process it twice, for unified/side by side view
[23:36] <beuno> unless you can think of something else that would be better, I'm going to cleanup that branch, and get it into a usable state, with the API upgrades and whatnots
[23:37] <mwhudson> oh yes, that unified/side-by-side stuff is pretty dumb :(
[23:37] <mwhudson> it complicates all kinds of linking stuff with cookies and so on
[23:37] <mwhudson> i think trac's diff view is quite nice, fwiw
[23:39] <beuno> ah, it's more like the unified diff
[23:40] <beuno> but nicer
[23:40] <beuno> I think I actually like the side-by-side more, but we can provide both with this ajaxish interface, and let the user decide
[23:40] <beuno> side-by-side is a bit more expensive to generate, but not terrible
[23:45] <mwhudson> it does tend to be very very wide though
[23:46] <beuno> yes, and I'm only testing on bzr.dev, which is very careful not to go over 80 characters
[23:47] <beuno> Still like it though, it's more vimdiff-ish
[23:51] <jam> beuno: btw, one of the issues with color encoding is when you see the unified diff, the side-by-side doesn't matter as much
[23:51] <beuno> jam, aaah, that makes sense  :)
[23:51] <jam> most people seem to feel side-by-side is prettier
[23:52] <jam> I do prefer vimdiff to unified diff, though I'm comfortable with unidiff at this point
[23:53] <beuno> jam, would adding + and - still address that, or do you think we should opt for different colors anyway?
[23:56] <poolie> hello
[23:56] <beuno> mornin' poolie
[23:58] <lifeless> moin
[23:59] <jam> poolie: I'm around for the call after all
[23:59] <jam> beuno: lifeless is the one you should be asking
[23:59] <jam> he can tell you whether it is all just grey or not
[23:59] <beuno> morning lifeless  :)