[00:05] <poolie> igc, spiv, jam, hi
[00:06] <poolie> skype seems to be broken on my laptop now
[00:06] <igc> hi poolie
[00:06] <jam> poolie: I'm just chatting with lifeless for now, I'll probably skip the standup
[00:06] <poolie> hello igc, how are you today?
[00:06] <lifeless> hi poolie
[00:06] <igc> poolie: not too bad today
[00:07] <poolie> shall we just stand up here?
[00:07] <spiv> Hello.
[00:08] <poolie> for myself i was planning to make sure usertest is running in the datacentre (if it's not at present)
[00:08] <poolie> and then look at the results for 1.6rc1 compared to previous ones
[00:09] <poolie> oh and also update the ppa which i didn't finish yesterday
[00:10] <spiv> Thinking of 1.6rc1... bzr.dev is now open for changes for 1.7?
[00:10] <james_w> is usertest extended to history now?
[00:10] <poolie> yes
[00:10] <poolie> i should mail about that
[00:10] <poolie> james_w, i don't think it does large amounts of history atm
[00:10] <poolie> it should
[00:11] <james_w> just wondered
[00:11] <igc> today, I'm planning to catch up on email and add some more tests to my filtered views branch
[00:11] <james_w> poolie: would you like 1.6rc1 in a distro?
[00:12] <poolie> i may either add that, or run ad hoc tests on a long history
[00:12] <poolie> many distros! :_)
[00:12] <igc> james_w, poolie: if usertest finds a .bzr directory inside a project archive, it skips the initial import task
[00:12] <james_w> igc: ah, cool.
[00:12] <igc> so it will handle whatever history you have already setup
[00:12] <spiv> Today I'm working on the 'effort' tests described in my email from yesterday.
[00:13] <james_w> poolie: I'll see what I can do
[00:13] <poolie> i should check if the ppa packaging has diverged from intrepid
[00:13] <poolie> james_w:  what are you working on on the distro team btw?
[00:14] <james_w> poolie: importing ubuntu in to bzr. I guess no VCS anywhere will have had this much code in it before
[00:14] <poolie> wow
[00:14] <poolie> that must be a lot
[00:15] <james_w> I have tomorrow off though, so I can push 1.6rc1 to the archive, and possibly Debian as well
[00:15] <james_w> poolie: fingers crossed for ~16k packages, ~4 years history of uploads
[00:16] <james_w> sorry to divert your stand-up
[00:17] <lifeless> james_w: :)
[00:17] <lifeless> james_w: single repo ?
[00:18] <james_w> lifeless: no
[00:18] <james_w> maybe I lied then
[00:19] <lifeless> cause I have that megarepo :P
[00:19] <james_w> I'm pretty sure no DVCS will have that much code
[00:19] <ToyKeeper> Wow.  I hope you've got plenty of space and time.
[00:19] <lifeless> I suspect MS's internal repos are pretty big
[00:19] <james_w> lifeless: sure, I'll sell that to the developers. To get started with development just download this 22G repo...
[00:20] <lifeless> james_w: you can pull out of it in millisecond time :)
[00:21] <james_w> lifeless: I should have mentioned the meeting to you, sorry
[00:22] <lifeless> np
[00:22] <thumper> what is the flag to bzr upgrade to do all the branches too?
[00:23] <thumper> in a shared repo?
[00:36] <Peng_> beuno: I think I ended up at /download just by messing with the URL to see what would happen.
[00:37] <james_w> thumper: I don't think there is one. I may have missed it though
[00:37] <james_w> thumper: but in most cases converting the repo is 90% of the work
[00:41] <ToyKeeper> It may be 90% of bzr's work, but it's only one of many commands the user would need to run to convert the repo + branches.
[00:41] <lifeless> dato: which reminds me; no chance on that mail yet I guess?
[00:41] <james_w> ToyKeeper: oh yeah, I realise that
[00:42] <dato> lifeless: nope, sorry; weekend is the safest bet
[00:42] <lifeless> cool, I'll stop inquiring for a while then
[00:43] <beuno> Peng_, so the bug is, if you punch in a random URL, it redirects you to a random place, which, in this case, doesn't work. Correct?
[00:57] <Peng_> beuno: Yep. :)
[00:58] <beuno> Peng_, marked as duplicate of "we don't validate user input", because I think that if we fix that, then we fix that bug.  Feel free to un-duplicate it if you feel differently
[00:59] <Peng_> beuno: +0. Doing the redirect seems like an attempt to validate user input; it's just incorrect.
[00:59] <Peng_> Err, does it incorrectly, I mean.
[01:00] <beuno> yeah, although a pretty bad one I think
[01:00] <beuno> hm
[01:00] <beuno> I'm off to dinner, so I'll leave it to you to decide  :)
[01:03] <Peng_> beuno: I unduped it.
[01:17] <markh> jelmer: you have a moment for my daily bzr-svn on windows question?
[01:17] <jelmer> markh, heh, sure
[01:18] <markh> many of the bzr selftests are failing when bzr-svn is installed - notably the blackbox tests, which seem to be getting an exit code of 0 when they expect a failure code.  Is that known by you?
[01:19] <markh> best I can tell, bzr is actually doing the right thing - just the exit codes are screwy
[01:19] <jelmer> markh, they're failing when bzr-svn is installed and not otherwise?
[01:19] <jelmer> what sort of errors?
[01:19] <markh> yes (although I admit I've only disabled *all* plugins - others are bzrtools and qbzr)
[01:19] <markh> simply that the 'bzr' exit code was zero instead of (say) 3
[01:20] <jelmer> no strange messages in the output?
[01:20] <markh> eg, blackbox.test_merge.TestMerge.test_merge_with_missing_file
[01:20] <markh> nope
[01:21] <jelmer> markh, hmm, that runs fine on linux
[01:21] <markh>   File "bzrlib\tests\blackbox\test_merge.pyo", line 132, in test_merge_with_missing_file \nAssertionError: Unexpected return code\nnot equal:a = 1 \n b = 0
[01:21] <markh> I was afraid you would say that :)
[01:22] <markh> --noplugins makes it work fine for me.  My attempts at debugging have failed so far, but I was guessing that maybe bzr-svn *also* had a chance to handle the 'bzr merge' command being tested somehow...
[01:22] <markh> I'll dig some more...
[01:23] <markh> and it seems that all blackbox test which expect a non-zero exit code are failing
[01:23] <markh> (the log does show the command being executed and, in this case, failing with conflicts.  So its strange but probably just a test issue)
[01:29] <james_w> jelmer: how do you plan on handling bzr for Debian during the freeze?
[01:29] <jelmer> james_w, haven't given it any thought yet
[01:30] <jelmer> james_w, I guess we can just upload 1.6 & friends to sid since they won't propagate now
[01:30] <jelmer> james_w, Not sure if there's a good reason for requesting a freeze exception
[01:30] <jelmer> james_w, what do you think?
[01:31] <Odd_Bloke> I'm not sure we'd want 1.6 in lenny anyways, as it's introducing quite a lot that might be unstable (ha ha).
[01:31] <jelmer> well, 1.5 breaks with bzr.debian.org atm..
[01:34] <james_w> jelmer: I thought maybe experimental
[01:34] <james_w> and maybe fixing the 1.5 problem would be a good thing for a freeze exception
[01:35] <jelmer> james_w, any particular reason for experimental rather than sid?
[01:35] <jelmer> I'm finding that 1.6 works significantly better than 1.5 for me
[01:35] <james_w> jelmer: I was under the impression that was preferred to leave the unstable->testing route open for targeted fixes
[01:36] <james_w> perhaps we should ask the opinion of our tame release assistant tomorrow
[01:37]  * dato waves
[01:38] <jelmer> dato: hi :-)
[01:38] <jelmer> dato: ^
[01:39] <dato> the responsible thing is to upload to unstable; if I was still the maintainer, I would probably had uploaded to sid; but doing that probably reduces your chances of fixing "important" bugs, because it'd have to go through t-p-u
[01:39] <dato> errrrrrrrrrrrrrrrr
[01:39] <dato> the responsible thing is to upload to experimental, of course.
[01:41] <lifeless> :)
[01:42] <james_w> hey dato
[01:42] <Odd_Bloke> Incidentally, I've started using bzr-builddeb for my packaging and it's great.  So thanks to people who wrote that. :)
[01:43] <lifeless> poolie: btw, I want that brainstorm on marks :>
[01:44] <jelmer> dato, thanks
[01:44]  * dato goes to bed
[01:44] <jelmer> Odd_Bloke: Please also set the Vcs-Bzr control field :-)
[01:46] <Odd_Bloke> jelmer: I wasn't sure if that was meant to point to a bzr.debian.org location, which is the only reason I have yet to do so.
[01:47] <Odd_Bloke> (because none of my packages are on bzr.debian.org (yet))
[01:48] <jelmer> Odd_Bloke, no just any URL where your packaging can be found
[01:49] <Odd_Bloke> Cool, I'll add it in.
[01:49] <jelmer> Hmm, looks like bzr is the third vcs for debian atm, behind svn and git
[01:49] <jelmer> although the distance between git and bzr is pretty big
[01:49] <lifeless> I don't think it actually means a lot, though I'm sure people will think it does
[01:50] <lifeless> a bunch of maintainers switched with a disproportionate package count
[01:50] <wildfire> so, I accidently did 'bzr rm --keep .bzrignore' and then realised my mistake and did 'bzr add .bzrignore'
[01:50] <wildfire> and now 'bzr status' says that .bzrignore is being both added and removed
[01:50] <wildfire> normal? should I care?
[01:50] <jelmer> lifeless, I think those numbers reflect reality
[01:51] <jelmer> lifeless, The number of bzr users in Debian seems to've diminished greatly :-(
[01:51] <lifeless> wildfire: normal, but you can do bzr revert .bzrignore to just reset it
[01:51] <jelmer> s/in Debian/under DDs/
[01:51] <wildfire> lifeless, ah-ha, thanks
[01:51] <lifeless> wildfire: that will revert any content changes to the file too
[01:51]  * wildfire hehs
[01:51] <wildfire> yes, I just realised, it had a conflict reverting things
[01:51] <cjwatson> wildfire: (it showed up as remove+add because the add operation gave it a new internal file-id)
[01:52] <wildfire> and moved it all aside to .bzrignore.moved.
[01:53] <lifeless> ah yes, because there is a file there:)
[01:54] <lifeless> bzr rm .bzrignore.moved
[01:54] <lifeless> bzr revert .bzrignore
[01:56] <wildfire> lifeless, in my case I wanted those changes, so easy enough to fix-up
[01:56] <lifeless> good good
[02:05] <lifeless> poolie: ping
[02:05] <poolie> poing
[02:05] <poolie> ok, how about now?
[02:05] <lifeless> cool
[03:45] <Odd_Bloke> How do I send targetted at a one branch (i.e. the mainline) but generating a patch against another branch (a change on which my branch depends)?
[03:46] <lifeless> Odd_Bloke: -r branch:dependent
[03:48] <Odd_Bloke> lifeless: Thanks. :)
[03:51] <lifeless> e.g. -r thread:..
[05:48]  * pickscrape uploads loggerhead branch adding breadcrumb links
[05:56] <mwhudson> ooo
[05:57]  * AfC eats all the breadcrumbs, dipping some of them in hummus.
[05:57] <pickscrape> Hopefuly it's any good. I've not done any python web development before.
[06:02] <mwhudson> hm, maybe an a:hover of a different colour would be nice
[06:03] <pickscrape> Yes, I can see that. Unfortunately I'm the last person you want to be picking colours :)
[06:03] <pickscrape> Do you have one in mind?
[06:04] <mwhudson> not really
[08:53] <kiorky>    /B 3
[09:07] <aquarius> I'm getting a weird error when trying to commit to my sftp repos: bzrlib.errors.KnitCorrupt: Knit None corrupt: incorrect number of lines 318 != 253 for version
[09:08] <aquarius> I've filed it as a bug in launchpad (#254511) but, pending that being fixed, what can I do to make some forward progress? At the moment I can't commit at all :(
[09:55] <meoblast001> oh no
[09:56] <meoblast001> bzr: ERROR: Target directory "xeiso" already exists.
[09:56] <meoblast001> what does that mean
[10:00] <AfC> meoblast001: you're trying to do a new branch [or checkout]?
[10:00] <meoblast001> lol i figured it out
[10:00] <AfC> meoblast001: if so, I would guess that about 30 seconds ago you started doing such a thing, but then ^C aborted, and tried again.
[10:00] <meoblast001> i deleted the file
[10:00] <meoblast001> folder*
[10:01] <meoblast001> and i was cd'd into it
[10:01] <meoblast001> and it cd'd me into the trash
[10:01] <meoblast001> O_o
[10:01] <meoblast001> you learn something new every day
[10:03] <AfC> aquarius: you might try creating a new local branch from the remote repository and then try to create a new remote branch, committing there instead. That sort of thing tends to workaround [partial] corruption that is outside of Bazaar's control.
[10:03] <AfC> aquarius: or recreate remote repository, or...
[10:04] <aquarius> AfC: right, OK. The thing that's in the repos is my home folder; I've committed successfully from machine 1, I've checked it out onto machine 2, but now I can't commit machine 2's changes back.
[10:04] <AfC> aquarius: (ultimately, all branches are peers, so assuming your local branch isn't  missing anything from the remote branch, you can always nuke remote and recreate it)
[10:06] <AfC> aquarius: (and, are you using "I checked out" colloquially or do you really mean you did `bzr checkout` rather than `bzr branch`)
[10:07] <AfC> aquarius: (and, sftp://, huh? Can't get bzr installed on the remote machine? That's a shame; bzr+ssh:// might probably work better)
[10:08] <AfC> (and, KnitCorrupt ... hm. Does a more modern repo format still give such an error?)
[10:08]  * AfC is out of interesting questions to ask
[10:09] <cjwatson> you might try 'bzr check sftp://path/to/remote/branch' (or 'bzr check /local/path' on the remote machine, faster if possible) to see whether it's the remote branch that's broken or the local checkout
[10:09] <aquarius> I really did bzr checkout. I'm using it like svn...
[10:09] <aquarius> sftp because the remote box is running debian sarge. How cool am I, eh?
[10:10] <aquarius> the repo format needs upgrading. But, it said do "bzr upgrade sftp://wherever" and I did that and it didn't help, so, well, I wasn't sure what to do next :)
[10:10] <cjwatson> rsync branch over, bzr upgrade locally, rsync branch back?
[10:10] <cjwatson> (if all else fails, use brute force)
[10:11] <aquarius> ok, trying bzr check on remote repo
[10:11] <aquarius> heh. I did think about the rsync thing but I'm worried about juggling two copies of my home folder around ;)
[10:11] <cjwatson> you only need to rsync the .bzr bit
[10:12] <aquarius> ah, the remote repo has a .bzr folder, got it. I'd not actually looked in the repo at all; I assumed it was some clever collection of files that mustn't be fiddled with :)
[10:16] <cjwatson> aquarius: the clever collection of files is inside .bzr ;-)
[10:22] <pbor> grazie
[10:22] <pbor> ops, wrong window
[10:30] <AfC> aquarius: for what it's worth, you might want to [manually] install at least bzr 1.5 (and even better yet, manually install >= 1.5 on both local and remote machines). If you are managing your home directory with a VCS I'm not so sure you want to be running an old version of the tool (assuming you were to be doing so).
[10:31]  * aquarius nods. Yeah. This has occurred to me...
[10:36] <aquarius> hrm. bbiab.
[10:46] <awilkins> jam: You're a windows-boy now, yes?
[10:48] <awilkins> markh: Ping?
[10:49] <jonnydee> hi :)
[10:50] <jonnydee> I've got a question: is there any functionality like "svnadmin export REPO" in Bazaar?
[10:50] <Odd_Bloke> jonnydee: What would you anticipate such a command doing?
[10:51] <jonnydee> to export a repository/branch into a repository-neutral format
[10:51] <awilkins> bzr-fast-export  ?
[10:52] <jonnydee> this way I could export a rich-root-pack repository and import the dump into a new one using knits, for example
[10:52] <Odd_Bloke> jonnydee: What version of bzr are you using?
[10:52] <Odd_Bloke> Knits are ooooolde.
[10:52] <awilkins> They're so old, they smell of wee.
[10:52] <lifeless> jonnydee: why do you want to do this?
[10:53] <jonnydee> ooh...there is a bzr-fast-export? I've only read about bzr-fast-import (which does not list bzr as a source)
[10:54] <jonnydee> well, from time to time I get an error "bzr: ERROR: [Errno 22] Invalid argument"
[10:54] <awilkins> Ironically, the only source of it I can find is a git repo :-)
[10:54] <jonnydee> my repository is located on a windows network share
[10:54] <lifeless> jonnydee: if you want to try knits rather than rich-root-pack, just do 'bzr upgrade --rich-root'
[10:55] <lifeless> jonnydee: that willdowngrade the repository to a knit based format
[10:55] <jonnydee> My local working copy is a checkout and after some commits this error occurs. But I don't know the reason, however
[10:55] <lifeless> jonnydee: exporting through fast-export will just destroy your ability to merge with your own history
[10:55] <lifeless> its a bad idea
[10:57] <lifeless> jonnydee: that said, packs are _way_ better than knits at windows friendliness
[10:57] <AfC> heh. You should call it `bzr downgrade --rich-root` [for the case that you're moving backwards]
[10:57] <lifeless> if you're getting errors its almost certain that its coming from the working tree logic
[10:58] <lifeless> and the best way to address that is to ensure there is a bug filed and work with us to fix it
[10:58] <lifeless> jonnydee: ^
[10:58] <jonnydee> I already did a  'bzr upgrade --rich-root' just to see if a downgrade is possible (all other downgrades seem to be unsupported).
[10:59] <jonnydee> I was thinking about filing a bug, but I haven't figured out a pattern which reproduces the mentioned error
[10:59] <jonnydee> yet
[10:59] <lifeless> jonnydee: file the bug
[10:59] <lifeless> jonnydee: if you wait until you know everything about it you may as well just file a patch :) - with a bug, however vague, we can help
[11:00] <jonnydee> ok, I will file a bug. But I have no further information about when the error occurs...not yet, at least.
[11:00] <lifeless> thats fine
[11:01] <lifeless> I take the view that whenever bzr is not ideal there should be a bug filed
[11:01] <lifeless> from there we can talk/discuss/track/analyse the issue
[11:01] <jonnydee> ok, that's a godd view point -- I agree :)
[11:02] <jonnydee> so thank's for your help
[11:02] <jonnydee> cu, bye
[11:09] <awilkins> lifeless: I have a change of yours here that causes errors in test_switch on win32
[11:09] <awilkins> lifeless: robertc@robertcollins.net-20080730095022-4tc7ij34c0tmejb5
[11:09] <awilkins> Should people log bugs for errors that the test suite shows up?
[11:11] <awilkins> lifeless: Reading the diff, it's specifically the bit that removes the osutils.isdir() check
[11:27] <jonnydee> Hi again, I just wanted to let you know about my bug report: https://bugs.launchpad.net/bzr/+bug/255656
[11:28] <jonnydee> oh, sorry. there is a but which reports such reports....didn't know that...
[11:28] <jonnydee> bot
[11:30] <jonnydee> have a nice day / night ;)
[11:35] <sven_> hi! when i get a 'contents conflict' during merge, how do i figure out what type of contents conflict it is?
[11:37] <james_w> jonnydee: it was just responding to you
[11:37] <james_w> jonnydee: thanks for reporting the bug
[11:38] <jonnydee> ahh, ok I see. Well, thank you for your support :)
[11:38] <james_w> jonnydee: it would be really useful to get the backtrace of the problem, could you look in ~/.bzr.log for the problem occuring and attach on of the stazas where it does to the report please?
[11:39] <jonnydee> I'll have a look...just a moment
[11:40] <james_w> thanks
[11:53] <jonnydee> ok, done. I hope it helps...
[11:57] <james_w> jonnydee: thanks, would you say that it was around 10 commits before this happens?
[11:58] <james_w> I imagine it is seeing the backtrace
[11:58] <james_w> there's a problem in the pack logic, and after around 10 commits it will try to autopack
[12:02] <james_w> jonnydee: at a guess this wouldn't happen if it wasn't on a network mounted drive. The operation is probably doing something that isn't liked by that filesystem
[12:03] <james_w> jonnydee: is your project particularly large?
[12:05] <jonnydee> sorry for the late answer:
[12:05] <jonnydee> yes about 10 commits seems reasonable....
[12:06] <ronny> how can i show a revision graph with bzr?
[12:06] <jonnydee> well i hav checked in 3 videos, which are about 90MB each...
[12:06] <jonnydee> ok, i have to go for lunch now... cu later
[12:20] <james_w> rocky: "bzr viz", or "bzr qlog" may be what you want
[12:20] <james_w> rocky: the first is in bzr-gtk, the second in qbzr
[12:20] <rocky> huh?
[12:21] <rocky> james_w: fix your autocompleter :)
[12:21] <james_w> rocky: ah, sorry, I've obviously not woken up yet
[12:21] <james_w> ronny: ^ that was intended for you
[12:22] <sven_> hi! how do i find out which revision a file was removed from the repository?
[12:25] <james_w> sven_: that's pretty tricky at the moment unfortunately
[12:25] <james_w> sven_: there's no simple command to do it
[12:26] <james_w> If you have an idea then I think looking in "bzr log -v" around that area may do it. Otherwise bisect is an option
[12:26] <james_w> It's something we need to improve though
[12:26] <sven_> james_w, ok, thanks
[12:27] <sven_> james_w, yes, that would really be helpful to know!
[12:28] <sven_> james_w, another related issue: would it be possible to give better explanations of 'contents conflicts'? something like "file: removed in THIS, modified in OTHER" or "file: binary file modified concurrently"
[12:29] <james_w> sven_: I'm not sure, I don't know the conflicts code well
[12:29] <sven_> james_w, ok
[12:29] <james_w> sven_: I agree it would be nice to have though, would you file a bug please?
[12:29] <sven_> james_w, will do. thanks!
[12:30] <ronny> james_w: thanks
[12:57] <sven_> james_w, i reported https://bugs.launchpad.net/bzr/+bug/255687 for my first question. about 'contents conflicts', there is already a bug: https://bugs.launchpad.net/bzr/+bug/35015
[12:58] <sven_> james_w, would it be possible to escalate these bugs? they hit us in MySQL quite frequently
[12:59] <james_w> sven_: I'm not the person to ask about that I'm afraid
[12:59] <sven_> james_w, ok. do you know who to ask?
[13:00] <james_w> sven_: I'm not sure how it's supposed to work, you're probably best off asking someone else at mysql how to go about that
[13:00] <sven_> james_w, ok, thanks
[13:22] <awilkins> sven_: A thought ; perhaps if you could get the log based on file_id ?
[13:24] <awilkins> How hard would it be to get a log for a file_id instead of a path?
[13:24] <luks> easy, getting the file_id would be harder
[13:24] <james_w> it would be possible, as that's what the path one does
[13:24] <luks> (or slower, not harder)
[13:24] <james_w> but yeah, luks is right
[13:25] <luks> extracting inventories is expensive, and to find a deleted file you need to extract them a lot
[13:25] <james_w> specifying a path looks up the file id of that path in the current tree, and then gives all revisions that touch that file id
[13:25] <luks> unless it's deleted in the last revision
[13:25] <awilkins> the bug implies that they know a revision from the subset of revisions the file exsinted in, so it's not too bad
[13:25] <luks> if you know the revision, is should be a simple path -> id lookup
[13:27] <sven_> luks, how can i do the path->id lookup?
[13:27] <awilkins> And non-text conflicts do need some usability work ; I have a small patch that adds some options to "conflicts" so you can filter on things other than --text, and use --null separators, but I haven't implemented tests for it yet so I've not submitted it.
[13:27] <luks> sven_: I meant in bzrlib code
[13:27] <sven_> luks, ah, i see
[13:27] <luks> I have a plugin that looks for deleted code somewhere
[13:27] <luks> but I doubt it still works with bzr 1.6
[13:27] <luks> and it's slow as hell
[13:27] <luks> er, I mean it looks for deleted files
[13:28] <james_w> sven_: it's really easy if you have a revision/tree
[13:28] <codeRat> hi. I'm trying to setup bzr on my machines. So the way I want to use it is have a central repository on an ubuntu server. And commiting from two windows machines. I can't get it how the setup the thing :S
[13:29] <codeRat> I have bazaar installed on all three machines..
[13:29] <james_w> if you want to search for a path then you have to traverse history, so it's an O(history) operation
[13:29] <sven_> james_w, yes, i guess i have that: since it's a contents conflict, it still exists in one of the trees
[13:29] <awilkins> Doing a log based on file_id should be simple enough, adding the option to the command would be easy
[13:29] <bob2> codeRat: once you have the repository setup, just 'bzr co sftp://ubuntu/blah' on the windows machines
[13:30] <bob2> (or branch)
[13:31] <awilkins> sven_: If you know a revision where your file exists, you can get the file-id by ``bzr ls --show-ids PATH -r REVISION``
[13:31] <codeRat> I allways get the Connection reset by peer
[13:32] <awilkins> codeRat: i) Is Ubuntu running sshd (it's not part of the default install options)
[13:32] <codeRat> I am using http
[13:32] <awilkins> codeRat: You can't commit over plain HTTP
[13:33] <codeRat> how do I check for sshd?
[13:33] <codeRat> I can ssh to the server..
[13:33] <cody-somerville> I'm having a problem with the push-and-update plugin
[13:33] <awilkins> THen it's running
[13:34] <cody-somerville> On a Windows client, it says:
[13:34] <cody-somerville> running "ssh mba@redcow.ca bzr update "/home/mba/www/cristallandluckett/""
[13:34] <cody-somerville> bzr: ERROR: [Error 2] The system cannot find the file specified
[13:34] <awilkins> codeRat: Ok, first, try opening the URI you are using vaia FileZilla
[13:35] <awilkins> e.g. sftp://ubuntu/~myaccount/mybranch
[13:35] <james_w> cody-somerville: try running with "-Derror" please
[13:35] <cody-somerville> james_w, Okay. I'll get back to you.
[13:35]  * cody-somerville will have to get his co-worker to run that when he gets into the office.
[13:35] <sven_> awilkins, i tried 'bzr ls --show-ids PATH' and 'bzr ls --show-ids PATH -r-1', where PATH exists in the current revision, but it doesn't print anything
[13:36] <james_w> cody-somerville: it might be on the remote side, in which case that probably won't help
[13:37] <james_w> cody-somerville: I'd also check that bzr is installed on the target machine, and is in the mba user's path, and that the directory quoted exists
[13:37] <cody-somerville> james_w, I'm wondering if maybe bzr is erroring because it is trying to execute "ssh" and that binary doesn't exist on windows.
[13:37] <james_w> cody-somerville: I'd also try running the quoted command manually
[13:37] <codeRat> I can sftp to my server
[13:37] <cody-somerville> james_w, ah, good point
[13:37] <bob2> codeRat: did you install bzr using the bzr windows instructions from the website?
[13:37] <james_w> cody-somerville: that could well be it, if there is no ssh on the user's path then it's clearly not going to work
[13:38] <cody-somerville> james_w, Does that mean I'll have to modify the push-and-update plugin manually to use putty? lol
[13:38] <codeRat> bob2, on windows machines yes (I just run the installer :P )
[13:38] <sven_> awilkins, ah, it can't list individual files, only directories.
[13:38] <awilkins> sven_: Yes, it would seem so
[13:38] <james_w> cody-somerville: possibly, there may be some support in bzr for doing this that push-and-update should use
[13:39] <awilkins> sven_: I think that counts as a bug
[13:41] <sven_> awilkins, ok, i'll report it...
[13:44] <abentley> cody-somerville: Bazaar will use paramiko to do ssh if there's no SSH binary.
[13:44] <cody-somerville> abentley, is that instlalled by default on windows?
[13:44] <abentley> cody-somerville: Yes.
[13:45] <sven_> awilkins, reported https://bugs.launchpad.net/bzr/+bug/255705
[13:46] <cody-somerville> so weird.
[13:48] <james_w> cody-somerville: bzr-push-and-update doesn't use paramiko
[13:48] <james_w>     cmd = ['ssh', user+host+port, remote_bzr, 'update', path]
[13:48] <james_w> subprocess.call(cmd)
[13:50] <awilkins> sven_: Ok, I've implemented an extra option for the log command ; we run into our next issue ; it doesn't list the revision where it was deleted
[13:51] <sven_> awilkins, wow, that's fast! thank you :-)
[13:51] <cjwatson> sounds like bzr-push-and-update needs to do the SSHVendorManager.get_vendor thing
[13:52] <sven_> awilkins, so, the extra option lists all revisions where the file was modified or rename or otherwise touched, except the one where it was removed?
[13:52] <awilkins> sven_: It was pretty easy ; the first thing the code does is calculate the file_id from the path so it's not hard to feed it one instead
[13:53] <sven_> awilkins, ok
[13:54] <awilkins> sven_: The reason it leaves it out is that it only allows revisions with text changes to the file through the filter (does it show renames?)
[13:54] <sven_> awilkins, i see
[13:55] <awilkins> Ok, it does show renames
[13:55] <sven_> awilkins, but there is a filter explicitly removing deletions? would it be easy to just update the filter?
[13:56] <awilkins> sven_: That's what I'm looking at
[13:56] <awilkins> sven_: You also have to bear in mind that it would be a change in the behaviour of the command (for the btter, but it might break someones process)
[13:57] <awilkins> sven_: It's not excluding deletions, it's only including modifications
[13:58] <sven_> awilkins, but if it was previously impossible to list deleted files, it ought not to affect the output unless the new option is used?
[13:58] <awilkins> sven_: hmm. Probably true
[14:00] <luks> listing deletions is only possible if you do an equivalent of 'log -v'
[14:00] <luks> that means, loading revision deltas
[14:01] <awilkins> luks: What I've done is implement --file-id for log ; you can now log a file that has been deleted but the filter in  _filter_revisions_touching_file_id doesn't include the deletion
[14:02] <luks> awilkins: yes, because the revision where is was deleted doesn't touch the file
[14:02] <luks> it just disappears from the inventory
[14:03] <awilkins> luks: So do you have to examine the inventory for each revision to see if it contains the file-id?
[14:03] <luks> awilkins: yes
[14:04] <luks> alternatively, calculate the revision delta for each revision and check if it's in delta.deleted
[14:04] <luks> but that's really the same thing
[14:07]  * sven_ has bad luck today... i ran into this: http://pastebin.com/d160d0b7f
[14:08] <luks> that's a very old bug
[14:08] <luks> I sent a patch for it but it was rejected
[14:09] <sven_> luks, ok. do you know a workaround?
[14:09] <luks> sven_: not using -r branch:
[14:10] <luks> you can get the head revision of that branch and use that instead
[14:10] <sven_> luks, i'm running this command because i want to know the gca of the two branches...
[14:10] <luks> sven_: I'm not sure if log will get you that
[14:11] <luks> it's an equivalent of bzr log -r revid:<head of the other branch>
[14:11] <luks> at least I think it is
[14:11] <sven_> luks, ah, right
[14:11] <sven_> luks, i confused branch: with ancestor:
[14:11] <luks> ah
[14:38] <awilkins> How is the project fixed for a win32 test box at the moment?
[14:38] <awilkins> And on the subject, I think the testing could stand to have more organized output
[14:39] <awilkins> Hmm, maybe this is a list hting.
[15:01] <jam> sven_: Just to mention, some of those content conflicts are actually bogus, and I have a patch up for review which should eliminate some of them.
[15:01] <jam> The problem is that your complex history means we have to try harder to track what was actually changed
[15:05] <jam> luks: you can also use "bzr log -r -1:/path/to/branch"
[15:06] <jam> instead of "branch:"
[15:06] <jam> I tried to do a different fix for it as well, and it got reverted.
[15:06] <jam> We would *like* "bzr log -r branch:" to not fetch
[15:06] <jam> but it requires updating a lot of commands to handle when the revisions aren't available in the local branch.
[15:06] <luks> yeah
[15:07] <abentley> jam: Fully agreed.
[15:08] <jam> awilkins: I do work on win32 most of the time, I don't (yet) run the full test suite here.
[15:09] <jam> I would love for "make check" to run cleanly
[15:09] <jam> I just don't feel it is as high a priority as getting stuff like merge working for sven_ :)
[15:09] <abentley> jam: I've wondered about the best way to support that.  Perhaps methods like "def get_two_trees(revision_specs, source_location=None, target_location=None, require_revision_trees=False)"
[15:19] <awilkins> jam: I was thinking that a more strutured test output (something you could upload to a web server with a test viwer like the one the mono project has) would be a boon.
[15:20] <matkor> I have file under bzr control now. I would like to leavie it as it is and make bzr ignore that file.so I do
[15:20] <matkor> bzr ignore app/config/database.php
[15:20] <matkor> Warning: the following files are version controlled and match your ignore pattern:
[15:21] <matkor> How should I do that ?
[15:23] <awilkins> matkor: bzr rm --keep ? (it won't be versioned any more)
[15:23] <james_w> matkor: you mean you want to keep the file versioned, but not commit any changes to it?
[15:24] <matkor> no, I want stop bzr to tracing changes and updating that fiels if changed in repo
[15:25] <hsn_> is bzr+ssh protocol stable enough for everyday use? we are using sftp for now
[15:25] <james_w> matkor: that's not currently possible if I understand your request correctly
[15:25] <beuno> hsn_, oh yes, absolutely
[15:25] <beuno> Launchpad uses it by default with bzr
[15:26] <hsn_> but it needs to have all clients and server at same version?
[15:26] <beuno> hsn_, ideally, but it's not mandatory. They shouldn't be too far away though
[15:27] <matkor> james_w: Prolly I am unable to state it claerly bzr ignore + bzr rm --keep seems good solution to my problem ...
[15:28] <james_w> matkor: ah yeah, that may be it
[15:30] <hsn_> how to configure user database for bzr serve ?
[15:32] <beuno> hsn_, bzr doesn't do user authentication, so you have to do that on the ssh side
[15:34] <awilkins> hsn_: You don't need to run bzr serve for bzr+ssh either
[15:35] <hsn_> bzr push over bzr+ssh updates working tree on server?
[15:35] <beuno> hsn_, no, but there is a plugin that can do that
[15:35] <beuno> push-and-update
[15:36] <beuno> if you *just* want the working tree on the other side, you can use bzr-upload
[15:36] <hsn_> plugin runs on server or client?
[15:36] <beuno> client
[15:39] <hsn_> server side hooks are not done yet?
[15:40] <beuno> I think *some* are, but I don't know for sure, and they're probably in the unreleased 1.6
[15:41] <hsn_> files in absolete_packs needs manual cleaning?
[15:41] <bob2> no, they'll get removed eventually
[15:42] <alex-weej> i'm having trouble mirroring my svn repo... i can use "bzr branch svn://url/trunk" but that only creates a trunk obviously
[15:42] <alex-weej> i tried svn-import, it asks me for my password 3 times and then fails
[15:43] <Jc2k> svn-import is the way to go
[15:43] <Jc2k> you are using the exact same url, without the /trunk ?
[15:44] <Jc2k> have you done an svn co of that url without the /trunk before? (earlier bzr-svn's (not sure when/if it was fixed) couldnt do a co unless svn had been used and it had cached the password before)
[15:45] <Jc2k> alex-weej: ^
[15:45] <alex-weej> yes hang on i will give you the error
[15:46] <awilkins> jelmer: Is this unicode file name meant to be "I squared C" or "I funny-A squared C" ?
[15:48] <awilkins> (funny-a being circumflex-a)
[15:51] <alex-weej> Jc2k: bzr: ERROR: exceptions.AssertionError: 'mirror/$reponame/branches/live' is not a valid path
[15:51] <alex-weej> Jc2k: i don't know where "mirror" is coming from...
[15:51] <alex-weej> that is with bzr svn-import http://svn.example.com/$reponame
[15:55] <Jc2k> hmm
[15:55] <Jc2k> anything interesting in your .bzr.log?
[16:01] <codeRat> I installed python and paramiko but still if I want bzr to use sftp I get Unsupported protocol..any ideas why? (OS: windows xp)
[16:24] <codeRat> I'm trying to setup inetd
[16:25] <codeRat> I have this in the conf file:
[16:25] <codeRat>  server      = /usr/bin/bzr
[16:25] <codeRat>         server_args = /usr/bin/bzr serve --inet --directory=/home/tinesu/bzr-repos
[16:26] <codeRat> Ok, I solved it..Had to delete the bzr command from args
[16:26] <codeRat> this is different in xinetd than inetd :)
[16:27] <beuno> codeRat, are you following a tutorial?
[16:27] <codeRat> I'm trying :)
[16:27] <codeRat> User guide
[16:27] <beuno> if something on bzr's help confused you, it may be interesting to fix it  :)
[16:27] <codeRat> In the userguide there is the line for inetd
[16:28] <codeRat> when you convert it for xinetd ..you have to change what I told before..that's all
[16:36] <jelmer> awilkins, I squared C
[16:37] <awilkins> jelmer: Encoding in Python appears to be confusing then :-(
[16:37] <awilkins> jelmer: I stabbed at it for some minutes without fixing it.
[16:37] <jelmer> awilkins, which file?
[16:38] <awilkins> test_commit_unicode_filename in test_commit.py
[16:38] <jelmer> awilkins, please make sure it's got -*- coding: utf-8 -*- at the top
[16:38] <awilkins> It has
[16:38] <awilkins> The code says "Icircumflex-asuperscript-2C"
[16:39] <awilkins> (sorry, non-unicode IRC client)
[16:40] <awilkins> Ah, ok, vim renders it like that
[16:40] <awilkins> notepad2 is fine with it
[16:40] <awilkins> i(superscript-2)C
[16:41] <awilkins> How is the file named in Linux? Windows write the file in text-base just fine (with unicode filename)
[16:42] <codeRat> I still need some help. I can connect trough bzr:// protocol..but can't with bzr+ssh:// I get this:
[16:42] <codeRat> bzr: ERROR: Connection closed: please check connectivity and permissions
[16:44] <bob2> check ~/.bzr.log
[16:44] <codeRat> on the server or client?
[16:44] <bob2> also, bzr+ssh is unrelated to bzr:// (i.e. you don't need inetd for bzr+ssh to work, but you do need a working ssh account)
[16:45] <alex-weej> Jc2k: 10.068  failed to import pycurl: No module named pycurl
[16:45] <codeRat> I have a working ssh account, but how do I which username to use?
[16:46] <bob2> how do you tell bzr which to use?  bzr branch bzr+ssh://username@host/path/to/branch/
[16:46] <beuno> codeRat, bzr+ssh://username@host/path/to/branch
[16:46] <beuno> hah
[16:46] <bob2> creepy ;)
[16:46] <Jc2k> alex-weej: that shouldnt be fatal..
[16:47] <Jc2k> alex-weej: did it get very far before it errored?
[16:47] <codeRat> still getting the same error :(
[16:47] <jam> awilkins: can you give the line that is the problem?
[16:47] <jam> In general, we don't put UTF-8 into our source code
[16:47] <Jc2k> alex-weej: i presume this is an internal svn repo i'm not going to be able to poke
[16:47] <jam> instead using u'\uAAAA" to define chars
[16:47] <bob2> codeRat: pastebin the last bit of .bzr.log on the client
[16:47] <awilkins> self.build_tree({u'dc/I²C': "data"})
[16:48] <jam> awilkins: is this in bzr or bzr-gtk?
[16:48] <awilkins> bzr-svn
[16:48] <awilkins> Test code
[16:48] <jam> ah, ok
[16:48] <jam> That's Jelmer's realm, and he can do what he wants :)
[16:48] <codeRat> bob2, Where is htis file (on windows )?
[16:48] <jam> I would *recommend* not using UTF-8 literals
[16:48] <jelmer> jam: What's a good alternative?
[16:48] <awilkins> jam: It still fails if you escape it
[16:49] <bob2> codeRat: /Users/username/, I guess
[16:50] <jam> jelmer: Just use the escape code: u'dc/I\xb2C'
[16:50] <jam> that way you don't have to worry about text editors interpreting the chars wrong
[16:50] <jam> I know Vim on Win32 thinks it is latin-1
[16:50] <jam> though I can force it to UTF-8
[16:51] <jam> awilkins: I don't know what "build_tree" Jelmer is using, it doesn't match the TestCaseWithTransport's build_tree
[16:51] <jam> awilkins: You're on win32? Are you on FAT by any chance?
[16:52] <awilkins> jam: Nope, NTFS6 (and FAT32 can use unicode filenames, not sure about FAT16/12)
[16:52] <jam> awilkins: weird, I'm running NTFS on Vista (not sure the exact version) and doing:
[16:52] <jam> open(u'I\xb2C', 'wb').close()
[16:52] <jam> works fine
[16:53] <jam> And Explorer shows the I^2C file
[16:53] <codeRat> bob2, http://pastebin.com/m60287138 here it is
[16:53] <awilkins> jam: That's not the issue
[16:53] <jam> awilkins: are you just saying that the *test* is failing? I thought the build_tree was failing
[16:54] <awilkins> jam: Not sure.. build-tree seems fine, the file is appearing in the SVN working copy with a unicode filename
[16:54] <bob2> codeRat: does 'ssh tinesu@xxx.xxx.xxx.xxx bzr rocks' work?
[16:55] <codeRat> hmm windows doesn't have ssh
[16:55] <codeRat> I mean the command ssh
[16:56] <awilkins> jam: jelmer: think the problem is it being passed ascii/encoded to the SVN client (can that cope with unicode?)
[16:56] <jelmer> awilkins, the svn client only accepts encoded unicode (e.g. utf8)
[16:56] <codeRat> heh, I renamed plink to ssh and the error changed :)
[16:56] <codeRat> bzr: ERROR: [Error 2] The system cannot find the file specified
[16:56] <jam> awilkins: I would assume it has to be UTF8
[16:57] <jam> it sounds like there is a layer doing implicit conversion
[16:57] <jam> (accidentally)
[16:57] <jam> can you paste the traceback?
[16:58] <awilkins> http://pastebin.ubuntu.com/35117/
[17:01] <jam> awilkins: well, I'll give you a quick rundown on the code I have available
[17:01] <jam> It uses:
[17:01] <jam> data = osutils.fingerprint_file(open(self._abspath(relpath)))
[17:01] <jam> And what is happenning
[17:01] <jam> is that self._abspath
[17:01] <jam> does
[17:01] <jam>         return wc.get_pristine_copy_path(self.workingtree.abspath(relpath).encode("utf-8"))
[17:01] <jam> So it seems to be returning a UTF-8 string
[17:02] <jam> which is not valid on Windows
[17:02] <jam> to access local files you *must* use Unicode
[17:02] <jam> I think it works on Linux
[17:02] <jam> because the filesystem is UTF-8
[17:02] <jam> so the UTF-8 str path == Unicode path
[17:02] <jam> If I'm right
[17:02] <jam> the fix would be something like:
[17:02] <awilkins> So utf16 rather than utf8 ?
[17:02] <jam> j        return wc.get_pristine_copy_path(self.workingtree.abspath(relpath).encode("utf-8"))
[17:02] <jam> sorry bad copy
[17:02] <jam>                 osutils.fingerprint_file(open(self._abspath(relpath).decode('utf-8')))
[17:03] <jam> awilkins: if you use the 8-bit apis, it uses OEM encoding
[17:03] <jam> which is usually something slightly random
[17:03] <jam> CP1252 (which is *almost* latin-1, but not really)
[17:03] <jam> So you need to use the Unicode apis
[17:03] <jam> Like you say, something like UTF-16 (though again it is MBCS for windows filesystems, which is very similar, but IIRC not exactly UTF-16)
[17:04] <jam> Basically, passing a 'unicode()' string to open() will use the Windows FooW api
[17:04] <jam> rather than the FooA api
[17:04] <jam> I would also guess that SvnBasisTree._abspath() should really be returning a Unicode string
[17:05]  * awilkins thinks perhaps encoding-specific hungarian var names would be good here.....#
[17:05] <awilkins> jam: That would be my interpretation ; all the paths should be unicode if both OSs support them
[17:05] <jam> awilkins: well, the Bazaar model was that file paths are always Unicode in memory
[17:06] <jam> And that gets serialized/deserialized at the "write bits to disk" or "over the wire" layers
[17:06] <jam> On the other hand
[17:06] <jam> *urls* are always 8-bit strings
[17:06] <jam> (well, technically, always 7-bit strings)
[17:07] <jam> Because *bzr* doesn't have control over all portions of the path
[17:07] <jam> It took us a while to get it right in bzrlib
[17:07] <awilkins> jelmer: Is this down to the pyrex bindings? THe sticking points all seem to be calls into pyrex extensions.
[17:07] <jelmer> awilkins, there's no pyrex remaining anymore :-)
[17:08] <awilkins> jelmer: Pardon, C extensions ?
[17:08] <awilkins> All the places where encodings are occurring for reasons I don't understand are calls into the extensions like client and wc
[17:09] <jelmer> awilkins: The bindings do indeed require encoded strings
[17:09] <jelmer> awilkins, not unicode objects
[17:09] <jelmer> awilkins, I don't understand why that's a problem though
[17:12] <jam> awilkins: I would also mention that doing a bare "open()" like that is a good way to leave a file handle open on windows, causing problems when trying to rm directories :)
[17:13] <Pilky> does anyone know of a way to remove a file completely from your bzr history?
[17:13] <beuno> Pilky, you can't
[17:13] <beuno> once it's versioned, it's there for ever and ever
[17:13] <Pilky> ok
[17:13] <beuno> unless you remove all history after you added it
[17:14] <beuno> or you may be able to break things someway with rebase
[17:14] <Pilky> yeah, I suppose if one really wanted to you could create a branch for every revision back to when you added it, uncommit from the main branch and then just copy the changes over and recommit, but that would be a bit long winded
[17:15] <beuno> it would  :)
[17:16] <meoblast001> how do you insert a line break into a commit message?
[17:17] <beuno> meoblast001, bzr ci
[17:17] <beuno> and it will go into editor mode
[17:17] <meoblast001> ok thanx
[17:17] <beuno> you can do anything you want in there
[17:17] <bob2> or bzr commit -m "something<hitenter>more stuff."
[17:17] <beuno> (ci is an alias for commit, you just avoid the -m"
[17:18] <LeoNerd> Its' actually an alias to "check in", which goes riiiight back to pre-RCS days
[17:18]  * beuno isn't that old   :O
[17:18] <jam> bob2: I will caution that on windows, bzr.bat doesn't seem to pass through line-breaks
[17:18] <jam> I think it is a problem with the .bat functionality itself
[17:19] <bob2> ah, that sucks
[17:19] <jam> I used it for a while
[17:19] <jam> and didn't realize it wasn't working
[17:19] <meoblast001> bzr: ERROR: no changes to commit. use --unchanged to commit anyhow
[17:19] <jam> so I rewrote a .sh wrapper for cygwin
[17:19] <meoblast001> O_o
[17:19] <meoblast001> i made 3 major changes
[17:19] <bob2> meoblast001: did you save them?
[17:19] <meoblast001> yes
[17:19] <meoblast001> hmmm
[17:19] <meoblast001> i guess that bzr ci automatically commited for me
[17:20] <bob2> "bzr ci" will commit after you save and exit the editor it started
[17:21] <meoblast001> yay
[17:25] <codeRat> just one question..I did init on the server and got a branch.I co it from the client..everything went ok..I then add some files..did a commit. But no files are on the server? What is the right way?
[17:26] <LeoNerd> When you say "no files", what do you mean?
[17:26] <bob2> that's fine
[17:26] <bob2> the "working tree" of the remote branch won't be updated
[17:26] <LeoNerd> The branch won't look like it has any files in it, no... those files are the working tree. If there isn't one, it won't appear there
[17:26] <bob2> if you would like it to be, you need a special plugin
[17:26] <LeoNerd> The branch data is all stored within the .bzr subdirectory
[17:27] <bob2> push-and-update plugin
[17:27] <codeRat> but what's the point of having the central repos then
[17:27] <bob2> ?
[17:27] <codeRat> when I try to co from another client I don't get anything..
[17:28] <bob2> the branch data is there, the working copy just isn't updated
[17:28] <bob2> ah, that shouldn't happen
[17:28] <bob2> did you 'bzr co' or 'bzr branch' on the client?
[17:28] <codeRat> co
[17:28] <codeRat> on both clients
[17:28] <beuno> codeRat, you did "bzr add", right?
[17:28] <codeRat> yes
[17:29] <bob2> does 'bzr status' on the client show that everything has been commited (i.e. it should say nothing)
[17:29] <codeRat> it doesn't (say anything)
[17:30] <bob2> what does 'bzr info' say on the client side?
[17:30] <codeRat> I did just "bzr commit" Than it said Committed revision 1. It seems that everything worked fine..
[17:30] <codeRat> Location:
[17:30] <codeRat> Checkout root:.
[17:31] <codeRat> Checkout of branch: bzr://ip/test/
[17:31] <bob2> cool
[17:31] <bob2> then the changes in that commit should be propagated to the central repository
[17:32] <luks> try `bzr log bzr://ip/test/`
[17:32] <codeRat> so now..if I do a bzr co on the other client..should I get thos files I added?
[17:32] <bob2> yup
[17:33] <codeRat> log is fine (I tried on the other client)
[17:33] <luks> then the data are on the server
[17:33] <luks> what does bzr co on the other client says?
[17:35] <codeRat> bzr: ERROR: File exists: u'P:/Bazaar/test/.bzr': [Error 183] Cannot create a file when that file already exists
[17:35] <codeRat> but I got the data
[17:36] <codeRat> can someone explain what is all about with bind/unbind ?
[17:38] <luks> when you do 'bzr co' instead of 'bzr branch', your local branch is bound to the server branch
[17:38] <luks> that means a local commit goes directly also to the server
[17:38] <luks> with 'bzr unbind' you can break that and the branch will become a standalone branch
[17:39] <luks> then you need to use 'bzr push' to upload the data to the server
[17:39] <codeRat> at that time when I do the commit it's saved only locally ?
[17:40] <luks> yes
[17:40] <codeRat> what happen If I do bind ?
[17:40] <luks> I'm not sure what happens with existing local commits, but I guess they will get uploaded next time you commit
[17:41] <codeRat> ok, Thank you very much..
[17:41] <codeRat> All of you for the patience :)
[17:43] <jelmer> awilkins, your patch fails the testsuite:
[17:43] <jelmer> running 13479 tests...
[17:43] <jelmer> ...-workdir/home/+trunk/bzrlib/doc/api/branch.txt)   OK                  92ms
[17:43] <jelmer> ...rkdir/home/+trunk/bzrlib/doc/api/transport.txt)   OK                   1ms
[17:43] <jelmer> ...til.tests.test_bencode.TestBencode.test_bdecode   OK                   0ms
[17:43] <jelmer> ...til.tests.test_bencode.TestBencode.test_bencode   OK                   0ms
[17:43] <jelmer> blackbox.test_add.TestAdd.test_add_control_dir    ERROR                  13ms
[17:43] <jelmer>     'module' object has no attribute 'join'
[17:44] <awilkins> Oh ass
[17:47] <awilkins> It's joinpath, not join. I am an idiot
[17:47] <awilkins> Hmm, ok
[17:47] <luks> nice example of effective code reviewing, it got two approves :)
[17:50] <jelmer> luks, well, the code looked alright, no problem there :-)
[17:53]  * awilkins submits again while hanging head in shame
[17:54] <luks> that's why you should always add a test case, no matter how small the change is :)
[17:55] <bob2> does bzr-svn go through a pqm?
[17:55] <luks> hm, I could swear there were some tests for the test suite
[17:55] <luks> but I can't find them
[17:56] <jelmer> bob2, no
[18:04] <jam> awilkins: Actually, I think the one you want is "pathjoin" yeah, bad naming FTL
[18:04] <jam> joinpath explicitly denies stuff like '..'
[18:04] <jam> pathjoin == os.path.join when appropriate
[18:05] <corporate_cookie> to issue a command like bzr branch lp: launchpad_project_name ..do i need to install a plugin ?
[18:05] <luks> corporate_cookie: the plugin is built-in
[18:05] <corporate_cookie> luks: thanks : )
[18:05] <luks> but its bzr branch lp:launchpad_project_name (no space)
[18:05] <jam> It was my fault for pointing you incorrectly.
[18:06] <corporate_cookie> ah : )
[18:06] <corporate_cookie> stupid spaces
[18:06] <luks> also, where is your nose? :)
[18:06] <corporate_cookie> :^) ?
[18:08] <corporate_cookie> luks: would bzr ERROR: socket.error: (61, 'Connection refused') be indicative of a proxy related issue ?
[18:09] <luks> hmm, could be
[18:09] <corporate_cookie> alas : )
[18:09] <corporate_cookie> thanks for the help
[18:09] <luks> you can just use the full url
[18:10] <luks> the lp: thing seems to use a xml-rpc over https
[18:10] <luks> so if you don't have a https proxy, it won't work
[18:18] <corporate_cookie> that works : )
[18:18] <corporate_cookie> thanks
[19:00] <alex-weej> when i am working with git and i want to work on an orthogonal change, i do "git checkout -b new-work master"
[19:00] <alex-weej> that branches new-work from master and checks it out
[19:00] <alex-weej> i am a bit confused with bazaar... branches are directories?
[19:06] <bob2> yes
[19:06] <bob2> however, bzr also has the concept of repositories and checkouts
[19:06] <cjwatson> alex-weej: you have the choice; it's more usual to have one directory per branch, but you can also use 'bzr switch' to take the git approach
[19:06] <alex-weej> if i use a repository can i branch without having it have to copy my entire working tree?
[19:07] <bob2> alex-weej: yes, make a checkout of one of the branches, then use 'bzr switch /repo/branchname' to switch that checkout between them
[19:09] <cjwatson> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html section 5.5 has some information about this
[19:29] <alex-weej> cjwatson: thanks
[19:33] <pickscrape> mwhudson: I've added a hover style to the breadcrumbs branch. Nice suggestion, it does look a lot better like that.
[19:56] <rockstar> jam, hi
[20:34] <rockstar> beuno, hi
[20:34] <beuno> rockstar, howdy
[20:35] <rockstar> beuno, we've been talking about unifying the loggerhead templates, so that they are more easily skinnable.
[20:36] <beuno> rockstar, unifying?
[20:36] <beuno> LP and LH's trunk?
[20:36] <rockstar> Well, I guess "unifying" is not a good term when applied to trunk.
[20:37] <rockstar> Basically, thumper has other gnome loggerhead stuff, which is slightly different than the ACTUAL loggerhead templates.
[20:38] <beuno> right
[20:38] <jam> rockstar: hey, sorry for the delay, TWiB time, right?
[20:38] <rockstar> I think the gnome stuff has some different needs.
[20:39] <rockstar> jam, I have to run out to Rinchen's house in 20 minutes to help out with their sprint.
[20:39] <rockstar> I'll be there for the rest of the day, but I'm pretty open tomorrow.
[20:39] <beuno> rockstar, so, what's on your mind?  Changing the templates so you can drop in headers?
[20:40] <rockstar> beuno, header and footer first.
[20:40] <rockstar> beuno, then, probably make it so we can drop in a search bar, etc.  At least, that was the brainstorm.
[20:41] <jam> rockstar: well, we'll need to actually *do* it. I skipped last week, and the week before I was late by 5 days or so ... :(
[20:41] <beuno> rockstar, sounds like a good idea. Is someone going to be doing that work, or is that why you're talking to me?
[20:41] <jam> I can't say I'm in the mood, but I know people felt it was helpful
[20:41] <rockstar> jam, yea, and after the good feedback on the mailing list specific to TWiB, I'm really anxious to do it.
[20:42] <rockstar> beuno, I'm actually working on that right now.  I have been all day.
[20:42] <beuno> rockstar, oh, very cool
[20:42] <rockstar> I'm just at a point where I need to let you know what I'm doing, before I can't turn back.
[20:43] <beuno> sure. Do you have a branch somewhere?
[20:43] <pickscrape> How are loggerhead contributions handled (reviewed etc)? Via launchpad?
[20:43] <rockstar> jam, so, should I ping you in the morning tomorrow?
[20:43] <beuno> pickscrape, yeah, for now. Upload a branch, file a merge request
[20:43] <rockstar> beuno, I don't have many changes, but I'll shoot you the branch before I quit tonight.
[20:44] <pickscrape> beuno: I think I already have requested a merge. Do I need to also need to "Request a review"?
[20:45] <beuno> pickscrape, hm, no, that should be enough. Do you have the URL handy?
[20:45] <beuno> rockstar, cool. I love the idea, if that's what you where looking for
[20:45] <pickscrape> https://code.launchpad.net/~pickscrape/loggerhead/breadcrumbs/+merge/664 <- hopefully this is the right URL
[20:45] <cody-somerville> Can someone take a look at this error one of my coworkers is getting?
[20:45] <cody-somerville> http://pastebin.ubuntu.com/35191/
[20:46] <cody-somerville> bzr: ERROR: exceptions.KeyError: 'file:///C:/WebDev/Projects/mba/investfred2/.bzr/repository/upload/r21oxweo2g2wsh2vvcln.pack
[20:46] <beuno> pickscrape, oh, I did see that this morning. It's on my ToDo!
[20:46] <pickscrape> cody-somerville: might want to consider upgrading to 1.5 if that is possible
[20:46] <beuno> I still can't match your nickname you your real name  :)
[20:47] <pickscrape> beuno: cool! No rush, just didn't know how this whole process works yet :)
[20:47] <beuno> pickscrape, you nailed it from the start!
[20:47] <pickscrape> Yeah, weird nickname. I have no imagination. It's a guitar playing technique. :)
[20:47] <luks> the traceback is not the real problem, it just masks it
[20:47] <luks> so it's hard to say what's wrong
[20:47] <cody-somerville> pickscrape, the remote server is running the beta
[20:48] <beuno> cody-somerville, can you make him peak at his ~/.bzr.log to get the traceback?
[20:48] <pickscrape> So is the "Request a review" for when you don't think it's worth merging yet but you want feedback?
[20:49] <beuno> pickscrape, I don't really understand what that's for  :)
[20:49] <cody-somerville> beuno, what would be the equivalent in windows?
[20:49] <beuno> abentley might, I think that's his work
[20:49] <beuno> cody-somerville, oh, windows...  I have no idea  :)
[20:49] <jam> rockstar: yeah, please ping me, I probably won't be ready until post 12 central (11 yours, iirc)
[20:49] <beuno> let's see what launchpad says
[20:50] <beuno> cody-somerville, maybe related to bug #191409 ?
[20:50] <cody-somerville> beuno, this is a branch
[20:50] <abentley> pickscrape: In many projects, you must not merge until you get feedback.
[20:51] <jam> cody-somerville: My Documents\.bzr.log
[20:51] <jam> (it may move in the future)
[20:51] <jam> doing 'bzr --version' will show you where it is
[20:51] <pickscrape> abentley: is the workflow documented anywhere on launchpad?
[20:52] <abentley> pickscrape: Launchpad is meant to support many different workflows.
[20:53] <pickscrape> I found myself wondering if registering a branch with a project that I wasn't involved with would be 'socially acceptable' or not.
[20:53] <rockstar> jam, ack, will do.
[20:53] <beuno> pickscrape, it's encouraged. Although I do agree it doesn't say anywhere
[20:54] <pickscrape> And following that, what the project would expect from my contribution. i.e. standards that I should follow, files that I should edit etc.
[20:54] <jam> pickscrape: I think the feeling (for us at least) is that registering a branch is like posting a patch to their tracker
[20:54] <abentley> pickscrape: most projects will consider it socially acceptable to register a branch.
[20:54] <jam> only in a *more* convenient form
[20:55] <jam> It is a bit different if the project doesn't *use* bzr/lp, but as long as they do, I would guess they would be fine with you posting your own branches.
[20:55] <abentley> pickscrape: We do not dictate how a particular project handles patches.
[20:56] <abentley> pickscrape: Some projects use Launchpad only for bugs.  Others host their code there, but do code reviews elsewhere.
[20:56] <chadmiller> For bzrlib.log.show_log(), what's the least ugly way to make it not emit merged revisions?  Something in the log formatter, I suppose, but I can't place what.
[20:56] <pickscrape> abentley: understood. However, I think lp could have some place where the project can document "contribution guidelines" or something similar to help out new people.
[20:57] <abentley> pickscrape: wouldn't the project web site or source code be a more appropriate place?
[20:58] <pickscrape> Some projects won't have a website other than launchpad. I agree that the code would be a good place to put that, but that requires the user digging about for it. Perhaps allowing links to specific files on the primary branch that appear on the front of the 'code' page?
[20:59] <pickscrape> Would be a good way to make things like 'release notes' accessible too while simultaneously version controlled with the code
[21:00] <abentley> I believe we already allow that.
[21:05] <cody-somerville> beuno, http://pastebin.ubuntu.com/35196/
[21:06] <pickscrape> abentley: I can't see where you can do that
[21:06] <abentley> I believe you can enter any URL you like in the project description.
[21:06] <beuno> cody-somerville, [ 2800] 2008-08-07 14:58:55.887 WARNING: Server is too old for streaming pull, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)
[21:06] <beuno> that should be a pretty good tip on what to do
[21:07] <cody-somerville> beuno, it would be
[21:07] <cody-somerville> beuno, except he is running 1.4
[21:07] <cody-somerville> and the server is running 1.6
[21:07] <beuno> cody-somerville, well, that doesn't seem to be the case
[21:08] <beuno> cody-somerville, can you run "bzr version" on the server?
[21:08] <pickscrape> Isn't this because of an API call that was removed in 1.6, which makes a pre-1.6 client think the server is 1.2?
[21:08] <cody-somerville> Yes.
[21:11] <beuno> cody-somerville, I don't really know then
[21:11] <beuno> spiv?
[21:12] <cody-somerville> spiv?
[21:12]  * cody-somerville will see about getting everyone to upgrade to 1.6 beta :P
[21:14] <beuno> lifeless, I;ve been trying to reproduce bug #248018, but I'm not able to get it to override results.  The javascript should prevent it, and I can't get it to misbehave  :)
[21:14] <jam> beuno: that is a "known bug", the 1.5 client connecting to the 1.6 server
[21:14] <jam> Specifically, there was a verb added in 1.2
[21:15] <jam> which we removed in 1.6
[21:15] <jam> And 1.5 tries it and then thinks you must have an older server
[21:15] <jam> We can't really fix that without: a) Patching 1.5 (which doesn't help clients over just upgrading to 1.6) b) Implementing the verb, which is *hard* to do efficiently and correctly
[21:16] <jam> 1.5 correctly falls back (though it unfortunately also reconnects)
[21:17] <beuno> jam, the bug is it telling that it needs 1.2, not the keyerror thoough, right?
[21:17] <jam> beuno: right the "needs 1.2" is the bug
[21:18] <jam> cody-somerville: the client should still *work* just give a semi-bogus message and reconnect
[21:18] <cody-somerville> jam, it usually does
[21:18] <jam> cody-somerville: Is this consistently failing?
[21:18] <cody-somerville> jam, yes
[21:19] <jam> this actually looks like there is some *other* error which is being triggered, and then this error is covering it up when we cleanup our stack
[21:20] <jam> cody-somerville: check the permissions on .bzr/repository/upload (If you can)
[21:20] <jam> It *feels* like we go to create a new pack, mark it for creation, fail to write to it, get an exception
[21:20] <jam> and then we want to clean up and close the file
[21:20] <jam> but it was never properly opened
[21:21] <jam> cody-somerville: You may try just adding a "try/except: KeyError: pass" around the del line
[21:21] <jam> and see if you don't get a different error
[21:25] <chadmiller> Ah.  I test the revision.merge_depth now, in the log formatter.  That does what I want.
[21:26] <cody-somerville> jam, will I want to do this on remote host or local host?
[21:26] <jam> cody-somerville: the failure is local
[21:26] <jam> So only on the local machine
[21:26]  * cody-somerville goes to see if he can reproduce the error himself.
[21:27] <jam> note that the failure is 4,400 seconds after the process reconnects, which is a bit surprising
[21:27] <jam> You *can* add '-Dhpss' to the bzr branch line
[21:27] <jam> but I have the feeling that is just going to dump a lot of nonuseful information
[21:29] <cody-somerville> :-|
[21:29] <cody-somerville> Does Canonical provide paid support for bazaar?
[21:36] <beuno> cody-somerville, AFAIK, they do
[21:36] <beuno> email poolie
[21:53] <beuno> so, it's official: http://beuno.com.ar/archives/82
[21:56] <pickscrape> Congrats :)
[22:54] <cody-somerville> beuno, you're starting this upcomming Monday?
[22:54] <beuno> cody-somerville, yeap.
[22:55] <cody-somerville> me too!! :)
[22:55] <beuno> cody-somerville, really?  you're joining Canonical?
[22:55] <cody-somerville> Yes sir
[22:55] <Odd_Bloke> beuno: Congrats. :)
[22:56] <beuno> cody-somerville, cool!  what are you going to work on?
[22:56] <beuno> Odd_Bloke, thanks  :)
[22:56]  * mwhudson looks around the channel for people we haven't hired yet
[22:57] <cody-somerville> beuno, Release Engineer for Canonical OEM Solutions Groups
[22:57] <cody-somerville> *Group
[22:57] <beuno> cody-somerville, w00t!  congrats!
[22:57] <beuno> so, we'll meet at some point  :)
[22:57] <beuno> mwhudson, :p
[22:57] <cody-somerville> beuno, For sure! Maybe California?
[22:58] <beuno> cody-somerville, very likely.  I'll know in the following months
[22:58] <cody-somerville> :]
[22:59] <Odd_Bloke> mwhudson: Pick meee!
[23:07] <thumper> Odd_Bloke: :)
[23:35] <jonnydee> lifeless: regarding my bug report (https://bugs.launchpad.net/bzr/+bug/255656): You asked me to do a "bzr pack REPO_PATH"
[23:36] <lifeless> jonnydee: yes, I did
[23:36] <jonnydee> I already tried that and as far as I can remember it faild indeed with the same error
[23:36] <lifeless> jonnydee: please do try it and attach what it puts in the log
[23:37] <lifeless> shouldn't take long
[23:37] <jonnydee> but, unfortunatelly, I'm not at work now and, therfore, I cannot access .bzr.log. But I will have a look to it tomorrow
[23:38] <jonnydee> And I recovered already from the "buggy" repository so I need to wait until I stumble over the "Invalid argument" issue again
[23:39] <jonnydee> I will report information as soon as I can. Thanks for your interesst :)
[23:42] <lifeless> jonnydee: ok; running bzr pack - if it gives us a way to trigger it repeatedly we can move on to determining exactly why it is happening for you without having to wait for it sporadically happening
[23:45] <jonnydee> lifeless: that sounds very good -- I will try it tomorrow. But just to be sure I got your idea: You think "bzr pack REPO" should (or might) always fail, so I don't need to wait until auto pack mechanism is triggered, right?
[23:46] <lifeless> 'bzr pack' and autopack both end up exercising the same code path
[23:47] <lifeless> so doing 'bzr pack' should fail immediately in the same way that autopack is
[23:47] <jonnydee> ok, I understand. Thanks a lot -- I will post feedback tomorrow. So have a nice day/night ;)
[23:47] <jonnydee> CU
[23:48] <lifeless> thanks
[23:51] <jam> Odd_Bloke: Aren't you hired for the summer?
[23:51] <poolie> good morning
[23:51] <jam> morning poolie
[23:52] <poolie> jam, shall we talk here in lieu of a standup?
[23:52] <jam> if you want
[23:52] <jam> spiv is away
[23:52] <jam> and I don't know about igc
[23:53] <jam> poolie: do you want to stay in #bzr?
[23:55] <poolie> sure. i was just going to say i'm going to update the ppa, read some documents for amanda, take my dead video card back to the shop, do the monthly report, hopefully do some reviews and finish at 5
[23:55] <lifeless> I'll believe it when I see it
[23:55] <lifeless> :)
[23:55] <poolie> heh
[23:55] <poolie> it does sound a bit ambitious
[23:55] <lifeless> where is spiv ?
[23:55] <poolie> maybe i should run sudo -b shutdown 17:00 now?
[23:56] <poolie> at the physio
[23:56] <poolie> and i would guess igc is asleep
[23:56] <lifeless> ah yes I remember
[23:58] <poolie> jam, lifeless, how about you?
[23:58] <jam> poolie: so, I'm working on comparing my lazy revno stuff to bzr.dev's merge_sort
[23:58] <jam> And I found a bug in merge_sort as it stands
[23:58] <jam> which I've submitted a simple patch for
[23:59] <lifeless> jam: was this bug in the original merge sort? (You already reimplemented it once I believe?)
[23:59] <jam> lifeless: I believe it is from my change to use simple 3-digit numbers
[23:59] <jam> It is because of a pre versus post increment bug