[12:52] <igc> morning all
[12:54] <Odd_Bloke> Ack, I know I should be in bed when igc shows up. :p
[12:55] <igc> Odd_Bloke: :-)
[01:06] <lifeless> real    2m0.424s
[01:06] <lifeless> user    1m47.271s
[01:06] <lifeless> sys     0m5.912s
[01:06] <lifeless> creeping down
[01:11] <Odd_Bloke> \o/
[01:19] <nvictor> hello all
[01:20] <nvictor> I want to setup bazaar and use it with a friend on a small website project, how do I start?
[01:20] <Odd_Bloke> nvictor: 'bzr init', 'bzr add', 'bzr commit -m "Initial import."' will get you to a Bazaar branch which you can then start using.
[01:21] <Odd_Bloke> nvictor: You then need to decide on what sort of development process you want to use, as Bazaar is able to model several effectively.
[01:21] <nvictor> Odd_Bloke: I'm new to all this
[01:21] <nvictor> Odd_Bloke: just need simple version control for our project
[01:22] <nvictor> with messages mailed to each of us
[01:22] <nvictor> when changes are made
[01:22] <nvictor> with information and all...
[01:24] <Odd_Bloke> nvictor: I'm not at all familiar with using Bazaar in such a distributed manner.
[01:25] <Odd_Bloke> If you hang around, someone better able to help you should pop their head up...
[01:25] <nvictor> Odd_Bloke: tell me how you use it then
[01:25] <lifeless> the bzr email plugin will send emails
[01:26] <nvictor> lifeless: does it require linux?
[01:27] <Odd_Bloke> nvictor: Well, just about everything I use Bazaar for is Free software so there's no problem using Launchpad to serve my branches.  I assume that this is a private website project.
[01:28] <nvictor> yes
[01:28] <nvictor> so I guess that means I can't use launchpad
[01:28] <Odd_Bloke> No, there's no provision for keeping a branch private.
[01:29] <Odd_Bloke> Except possibly for internal Launchpad devlopment, but that obviously doesn't apply. :p
[01:29] <Odd_Bloke> nvictor: I'd look at the email plugin. :)
[01:29] <nvictor> I see
[01:29] <nvictor> yes
[01:29] <nvictor> but I'm under windows
[01:29] <nvictor> we are both
[01:29] <nvictor> but the web server is under a linux machine
[01:30] <nvictor> so I think it would be better to set bazaar there
[01:30] <nvictor> right?
[01:31] <Odd_Bloke> nvictor: Ah, if you have a server then life becomes easier. :)  You will still need Bazaar installed locally though.
[01:31] <Radtoo> If you want a "centralized" sort of repository, ye the server would be the natural place for it.
[01:32] <Radtoo> (or more than one such repositories)
[01:32] <nvictor> ok
[01:32] <Odd_Bloke> nvictor: You're probably better reading through http://bazaar-vcs.org/Workflows than us trying to explain all its content to you.
[01:32] <nvictor> ok
[01:32] <nvictor> thanks guys
[01:34] <nvictor> see you guys
[02:01] <spiv> Good morning.
[02:08] <igc> morning spiv
[02:28] <lifeless> real    1m47.917s
[02:28] <lifeless> user    1m36.566s
[02:28] <lifeless> sys     0m5.336s
[03:04] <lifeless> igc: ^
[03:04] <igc> cool. Bit drop from even 2 hours back .Well done!
[03:04] <igc> s/Bit/Big/
[03:05] <igc> awesome!
[03:06] <igc> lifeless: I'll review your patch later today btw
[03:06] <lifeless> thats bzr.dev + packs + using PlainText rather than annotated texts
[03:06] <lifeless> so a ways to go to get this end user readyt
[03:07] <igc> true. But the point is we now *know* what's required to reach that time - that's a big step regardless
[03:08] <lifeless> oh,I'm not done yet ;)
[03:09] <igc> I know that. :-)
[03:09] <igc> I'm looking forward to this week - should be a good one
[03:15] <lifeless> igc: how much time does your work shave off a packs branch ?
[03:16] <igc> I'd need to remeasure
[03:20] <lifeless> only takes a couple of minutes :)
[03:23] <lifeless> oh, what is 'saving data locally' around ?, I've been meaning to look that up ;)
[03:24] <lifeless> its about 7 seconds long
[06:57] <igc> lifeless: bug in your commit stuff in the pack branch: http://rafb.net/p/Y0R9wG44.html
[07:34] <igc> lifeless: fyi, merging my changes into the pack branch is currently a slight loss performance wise on initial commit of a moz tree. I had expected most of the gain to disappear but not all of them so I'll dig a little and check that I did the merge correctly
[07:37] <lifeless> igc: already fixed
[07:37] <lifeless> thanks for checking the perf results
[07:37] <igc> lifeless: can you push the fix please
[07:46] <abentley> lifeless: I think we are likely to encounter bugs due to badly-split lines in the future if we apply your change.
[07:46] <abentley> I certainly encountered problems when implementing bundle 4.
[07:46] <abentley> In fact, I wouldn't be surprised if the check you found dates to that.
[09:06] <lifeless> abentley: it dates way back, 0.11ish timeframe I think, or before
[09:07] <lifeless> abentley: its a huge performance hit to do all the time, but I could make it an optional check that can be turned on/off if you want to be able to do it
[09:07] <lifeless> while that still costs, it doesn't cost as much
[09:08] <abentley> I'm really torn.  Because I know people will use it wrong, because I used it wrong.
[09:08] <abentley> I don't know how people would know to turn it on.
[09:09] <abentley> And maybe we can't afford to guard against it.
[09:10] <abentley> But I don't think it is widely known that ''.splitlines is bad.
[09:11] <lifeless> I agonised on it too
[09:11] <lifeless> here are some thoughts
[09:11] <lifeless> have it a disablable check, that our code disables
[09:12] <lifeless> or have the test suite turn it on automatically for all knit objects during test execution
[09:12] <lifeless> or allow people enough rope to shoot themselves, and trust that people using the knit api directly will do enough testing to realise they can't get data back out
[09:13] <lifeless> woot
[09:13] <abentley> Turning it on during testing sounds reasonable.
[09:13] <lifeless> pack push is really getting quite slick
[09:13] <lifeless> 2 minutes to push a few commits to people.ubuntu.com via sftp
[09:14] <lifeless> including two ssh connection opens to connect
[09:14] <abentley> But I can easily imagine cases where people don't test knit code thoroughly with LF data.
[09:14] <lifeless> whats the real exposure though
[09:14] <abentley> s/LF/CR
[09:14] <lifeless> foreign branches
[09:14] <lifeless> core code is less of a concern IMO we have solid reviews
[09:15] <lifeless> anyhow, I'm open to mitigating the risk, but its a 5-10 second win to not check every line
[09:15] <abentley> I'm not sure whether Bundle 4 was reviewed.  I tend to think not.
[09:16] <abentley> I've had consistent problems getting things reviewed, so sometimes they get merged without review.
[09:16] <lifeless> well, thats not your fault
[09:16] <lifeless> but I do take the point
[09:17] <lifeless> also more philosophically its really a symptom of api design that we conceptually have to do this check
[09:17] <abentley> Yeah.
[09:17] <lifeless> but
[09:18] <abentley> MPDiff only takes strings as input.  Not sure if that's better API, but at least it's safer.
[09:18] <lifeless> taking other things also has different tradeoffs
[09:18] <lifeless> taking a callback to get the lines is equally breakable
[09:19] <lifeless> take a string means we have to do the split ourselves, with another mem copy of every string
[09:19] <lifeless> taking a call to open a file object will be tricksy for things like mpdiff, you'll end up writing a thunk which is still fallable
[09:20] <lifeless> back later
[09:20] <lifeless> ciao
[09:20] <abentley> l8r.
[09:41] <Drago84> hola
[09:41] <Drago84>  bzr co bazaar.launchpad.net/~awn-core/awn/trunk avant-window-navigator
[09:41] <Drago84> bzr: ERROR: unknown command 'co'
[09:41] <Drago84> help me please?
[09:46] <Drago84>  bzr co bazaar.launchpad.net/~awn-core/awn/trunk avant-window-navigator
[09:46] <Drago84> bzr: ERROR: unknown command 'co'
[09:52] <lifeless> Drago84: 'checkout'
[09:52] <lifeless> Drago84: or 'branch'
[09:52] <lifeless> also your url is invalid - you need a protocol on it
[09:52] <lifeless> 'bzr help' will tell you the commands available
[09:53] <poolie> Drago84, you need either http:// or bzr+ssh:// or sftp:// before the hostname
[12:55] <ubotu> New bug: #138600 in bzr "`bzr mkdir` create new dir before it checks is branch/checkout exists" [Undecided,New]  https://launchpad.net/bugs/138600
[01:14] <matkor> Will bzr 0.14 work with 0.90 repos ? I can not see anything more fresh in mandriva I have to work with ?
[01:15] <AfC> matkor: just install from source. 0.14 is ancient.
[01:15] <AfC> matkor: (or manually bump your package, or whatever)
[01:17] <matkor> AfC: thanks
[03:19] <Odd_Bloke> Using WorkingTree.merge_from_branch doesn't seem to merge tags.  What internals should I use to replace a call to merge that should be transferring tags (in the blackbox testing)?
[06:24] <ignas> how do i change the email that is shown in commit info ? now it is "committer: Ignas Mikalajunas <ignas@my-machine-name>"
[06:24] <ignas> i'd like it to point to my actual email
[06:25] <radix> ignas: bzr whoami "Christopher Armstrong <radix@twistedmatrix.com>"
[06:25] <ignas> radix: thanks
[06:25] <ignas> is it a global setting or a local one?
[06:25] <radix> ignas: global, if I understand your meaning
[06:26] <radix> it's not per-branch
[06:26] <radix> oh
[06:26] <radix> but apparently you *can* set it per-branch
[06:26] <radix> bzr whoami --branch "foo bar etc"
[06:26] <ignas> i see
[06:26] <ignas> thanks
[06:26] <radix> those wacky bzr developers, always adding nifty features ;-)
[08:08] <markvandenborre> I want to recursively remove a directory from a checkout
[08:08] <markvandenborre> but bzr rm --force dir_to_be_deleted
[08:09] <markvandenborre> complains about a non-empty dir
[08:20] <ubotu> New bug: #138716 in bzr "RFE: Smart Server logging" [Undecided,New]  https://launchpad.net/bugs/138716
[08:28] <Enquest> while doing a commit my internet connection was lost...
[08:29] <Enquest> now I want to do the commit again.... however I get something about locked
[08:29] <Enquest> can I remove the file repository/lock ?
[08:29] <luks> `bzr break-lock` is probably a better solution
[08:51] <corporate_cookie> is there an issue with paramiko in python2.5 ?
[09:00] <Peng> Works for me?
[09:01] <corporate_cookie> alas .. i do not seem to be able to import it ...but I an see the bugger in site-packages
[09:02] <corporate_cookie> but im glad to know it works Peng
[09:02] <corporate_cookie> thanks
[09:22] <seanhodges> does anyone here use bzr-svn over HTTPS?
[09:33] <jelmer> seanhodges: yeah
[09:34] <jelmer> seanhodges: 0.4.1 had some issues with http repositories unfortunately, all other releases should be fine
[09:34] <seanhodges> hey jelmer, i'm having trouble getting it to work. I'm getting the 401 authorisation error (getting the error now to paste it here)
[09:35] <seanhodges> i'll check my version whilst i'm at it
[09:35] <jelmer> are you using it against a google hosted project by any chance?
[09:35] <jelmer> or does the repository really require authentication?
[09:35] <seanhodges> no. its hosted by the company i work for
[09:36] <seanhodges> over Apache SSL
[09:36] <jelmer> if it requires authentication, you have to access it using svn itself somehow
[09:36] <jelmer> e.g. 'svn ls <url>' should ask you for that password and store it in the cache
[09:36] <jelmer> which can then be used by bzr-svn
[09:37] <seanhodges> i understand. so if i check out using svn i should be able to use bzr-svn after that - giving it a go
[09:41] <seanhodges> well it didnt fix my immediate problem, but at least i know svn has stored the password permanently now
[09:41] <jelmer> it's still complaining about the 401 ?
[09:41] <seanhodges> yeah:  Unable to handle http code 401: Authorization Required
[09:42] <seanhodges> using this command: bzr co https://svn/svn/nina/trunk
[09:42] <jelmer> that should work if it stored in the password in svn correctly
[09:43] <jelmer> you can try prefixing the url with svn+ so it will bypass the check for the repository type
[09:43] <jelmer> (bzr co svn+https://svn/svn/nina/trunk)
[09:43] <seanhodges> i'll admit now i'm using a pretty old version of bzr-svn... 0.3.2. the reason for this is the bzr-svn website matched that version to my version of bazaar (0.15.0)
[09:44] <seanhodges> that gives me this error: "bzr: ERROR: Unsupported protocol for url "svn+https://svn/svn/nina/trunk""
[09:46] <jelmer> I'd really recommend upgrading, 0.3.2 is really really old
[09:46] <Enquest> I'm doing a commit but bzr always stays stalled at "Uploading data to master branch - Stage 3/5"
[09:46] <Enquest> why would that be...
[09:46] <jelmer> Enquest: it may just be slow, especially in older versions
[09:47] <Enquest> is the latest version
[09:47] <Enquest> how slow would that be... 10 minutes?
[09:47] <Enquest> its only a webproject...
[09:48] <seanhodges> jelmer, i did something stupid: took my svn dir out of ~/bazaar/plugins to try the latest build, but didnt put it back.
[09:48] <seanhodges> i've just recified that and tried the svn+https:// approach again and it looks like it's working
[09:49] <seanhodges> i think saving the password did the trick. thanks a lot for your help. - i'm gonna go shout at myself and make a tea
[09:50] <jelmer> Enquest: bzr+ssh is faster than sftp
[09:50] <jelmer> seanhodges: cool
[09:50] <jelmer> Enquest: what size is the project in ters of number of files / number of revisions?
[09:52] <Enquest> jelmer, with bin some 30 M
[09:52] <Enquest> its a first commit
[09:52] <jelmer> hmm, wouldn't know why it's so slow then, sorry
[09:57] <seanhodges> Enquest have you checked it's not a firewall issue? does it download quickly just downloading the directory using the sftp program?
[09:58] <Enquest> it simple stalles each time... I'm restarting the whole process
[09:58] <Enquest> It is the first time I use bazaar. I used SVN before
[09:59] <luks> don't, it just looks it stalled, it's actually doing something
[09:59] <seanhodges> same here, afraid i was mostly guessing
[09:59] <luks> restarting will not help it :)
[10:00] <seanhodges> thats true, my https download paused for nearly a minute before it started fetching
[10:01] <luks> initial push/pull is always slow, over bzr+ssh it's a bit faster, but not much in the current version of bzr
[10:03] <seanhodges> luks is the delay related to building the bzr repository? just interested
[10:03] <luks> no, it needs to check and upload many files
[10:03] <luks> which causes many roundtrips
[10:03] <seanhodges> ok, cool
[10:03] <luks> so most of the time you spend waiting for connection, not actually uploading
[10:04] <luks> at least that's my understanding of the 'official excuse' :)
[10:05] <fullermd> I blame it on gnomes, personally.
[10:06] <seanhodges> haha makes sense. I'm just waiting for my checkout to complete - does each push back to the svn server have a similar pause? or are the roundtrip checks related to the init?
[10:07] <seanhodges> fullermd, i think thats one excuse i havent seen on bash.org
[10:08] <fullermd> Well, it's sensible.  That's why you haven't seen it there   :p
[10:10] <seanhodges> lol
[10:53] <loswillios> hi guys
[10:54] <loswillios> I can't install the latest bzr on my debian system
[10:54] <loswillios> error in control file: `Files' value not specified at /usr/sbin/install-docs line 701, </usr/share/doc-base/bzr> line 10.
[10:55] <loswillios> ugh, the sources.lst entry has changed. there's -2 out already
[10:56] <fullermd> I'm pretty sure that's a known thing in the packages...
[10:57] <fullermd> Something about being built on a version that didn't need the Files, though other versions do?
[10:57] <loswillios> yeah, 0.90-2 fixed it.
[10:57] <loswillios> I didn't update my sources.lst
[11:00] <dato> fullermd: yeah, something like that
[11:00] <loswillios> thanks guys