[00:01] <jfroy> No. I'm speaking about providing a port number when none was explicitly given in the URL to credential stores and for the authentication section matching process.
[00:01] <jfroy> using the system's services database is not an ideal solution
[00:01] <jfroy> allowing the transport handlers to provide it a reliable solution
[00:02] <jfroy> ultimately, somewhere, something will open a socket to a specific IP address using a specific transport layer on a specific port. That information should always be available.
[00:02] <vila> jfroy: no, you were talking about making transport convert port=None to the /etc/services one, which mwhudson is referring as *bad* because it will not respect .ssh/config
[00:02] <jfroy> Now, granted, if the transport layer is an external process, it gets messy.
[00:03] <vila> and that's only one case, I don't remember the specifics but there were other
[00:03] <jfroy> vila: I agree with that
[00:03] <psynaptic> just thought I'd let you guys know.. restarting terminal fixed my problem
[00:07] <vila> jfroy: look at "bzr log -m 'default port'" for previous attempt and when it was abandoned (with references to bugs that may provides better information than my failing memory :)
[00:08] <jfroy> vila: yeah I intend to. Pragmatically speaking, I wrote a patch way back when for the http transport handlers to provide a port number.
[00:08] <jfroy> And since the credential stores are ignored the the ssh transport layer, that may be a pragmatic approach to fix part of the problem.
[00:09] <jfroy> Or I may just move the fallback to the keychain store and tell people to not specify a port for default port http sections.
[00:09] <jfroy> *are ignored for the ssh transport layer
[00:11] <vila> jfroy: http is different from other protocols regarding authentication as it's the only one where the socket is opened *before* authentication is attempted, but for the general case you can as well, use getservbyname in your wrapper when port==None
[00:11] <jfroy> vila: yes, but it's highly unlikely the keychain store would be useful for anything else than http.
[00:12] <jfroy> I'm interested in covering the 90% case :p
[00:13] <vila> jfroy, then better do that without requiring a bzr modification :-P
[00:14] <jfroy> *grumbles*
[00:14] <jfroy> I don't disagree there :p
[00:15] <jfroy> But, if a simple patch can allow other people to benefit, why not?
[00:15] <jfroy> (assuming it ends up being a simple patch)
[00:43] <rocky> jelmer: ever seen  a sha1knitcorrupt error ? :(
[00:49] <jelmer> rocky, yeah
[00:52] <rocky> jelmer: i'm getting that on one of my branches that came from a bzr-svn branch
[00:53] <jelmer> rocky, created with lp:bzr-svn ?
[00:53] <rocky> not sure
[00:53] <rocky> could have been
[01:03] <rocky> jelmer: i'm running a script i found that is supposed to clean up some sha1 corrupt issues but it's reporting not being able to find an inventory.kndx ... ever seen that?
[01:03] <jelmer> rocky, that looks like a bzrlib issue
[01:04] <rocky> right now i'm just trying to salvage a few important revs but even bzr diff is failing
[01:05] <jelmer> it sounds like a clean "bzr clone" would fix it
[01:06] <rocky> so what's the diff between "bzr branch" and "bzr clone" then?
[01:09] <luks> there is no difference
[01:11] <rocky> i branched into a new repo and there's still no inventory.kndx ...
[01:24] <lifeless> rocky: current formats do not use kndx files
[01:25] <rocky> lifeless: ah
[01:25] <rocky> jelmer: when i run "bzr check -v" on a repo i get "7 inconsistent parents" is that typical?
[01:25] <rocky> that repo works fine btw
[01:26] <rocky> actually i'm getting 1 ghost revision, 1 revision missing parents in ancestry, and 7 inconsistent parents
[01:28] <rocky> jelmer: this is on a fresh new repo and checking out svn+https://dev.serverzen.com/svn/cluemapper/ClueBzrServer/trunk   :(
[01:28] <rocky> jelmer: i guess that svn repo has legacy corrupted bzr trunk problems ;(
[01:29] <jelmer> rocky, the check results you mentioned aren't problems
[01:29] <rocky> jelmer: bzr reconcile blows up
[01:29] <jelmer> rocky, how?
[01:31] <rocky> jelmer: http://paste.plone.org/26841
[01:33] <lifeless> mwhudson: try bbc again, with updated branches; should be faster still
[01:33] <jelmer> rocky, you've hit bug 336749
[01:33] <rocky> jelmer: looks related to bug #336749
[01:33] <rocky> lol yeah
[01:46] <SamB> jelmer: I would have to build baz myself, I think ... that is, it isn't in Debian anymore.
[01:48] <SamB> jelmer: anyway, I doubt I have room to do a full arch->git conversion of emacs myself, so I guess the point is moot ;-)
[01:56] <jfroy> vila: thanks for the review, I can address some of those.
[02:03] <vila> jfroy: np
[02:05] <jfroy> I didn't update the netrc plug-in tests because I considered them outside the scope of the patch.
[02:05]  * SamB wonders how jelmer will deal with bug 340195
[02:05] <jfroy> I dislike "grab bag" patches that change a bunch of unrelated things.
[02:06] <jelmer> SamB, already fixed :-)
[02:06] <SamB> oh
[02:07] <SamB> what did you decide to do about it?
[02:07] <jelmer> it was a one-line patch
[02:07] <SamB> (I assume that readme.txt was being moved into a branch?)
[02:08] <jelmer> SamB, no, it was just a file appearing in a place where bzr-svn expected a branch
[02:08] <SamB> oh, was that all ?
[02:08] <SamB> then why did it fail a few revisions later than 249 ?
[02:08]  * SamB puzzled
[02:08] <jelmer> because it was a bug :-)
[02:09] <jelmer> bzr-svn was only some of those cases
[02:14] <jelmer> lifeless, what does your latest patch fix?
[02:15] <SamB> jelmer: oh, when does the tag import happen?
[02:18] <jelmer> SamB, at the end
[02:19] <SamB> jelmer: does only svn-import do it ?
[02:19] <jelmer> SamB, bzr branch / bzr pull too
[02:20] <lifeless> jelmer: more specifics please
[02:21] <jelmer> lifeless, exactly
[02:21] <SamB> jelmer: oh, and I think you don't emphasize enough that `bzr svn-import' creates the same kind of branches as `bzr branch'
[02:23] <lifeless> jelmer: I don't know what my latest patch is
[02:23] <jelmer> lifeless, The one with the few details :-)
[02:23] <jelmer> lifeless, "Tada!"
[02:23] <SamB> hah
[02:24] <jelmer> SamB, I'm not sure, branches are branches
[02:25] <SamB> jelmer: well, you make it sound too much like a static conversion tool, I guess
[02:26] <jelmer> lifeless, did you see my reply to your comment about default-rich-root
[02:26] <SamB> might just be the name
[02:27] <SamB> but, well, the wikipage is so sparse that there isn't much else to gather information from
[02:28] <lifeless> jelmer: it does what the subject said :)
[02:28] <lifeless> jelmer: subjects are often displayed by mail clients:)
[02:28]  * SamB wishes the SVN protocol weren't so danged slow for imports
[02:28] <lifeless> jelmer: I don't think I saw your comment, no
[02:28] <jelmer> SamB, which bzr-svn version are you using?
[02:29] <jelmer> lifeless, I guess I should rephrase
[02:29] <SamB> jelmer: I pulled it a few minutes ago from lp:bzr-svn
[02:29] <jelmer> lifeless, what things does it fix?
[02:29] <SamB> the SVN protocol just wasn't designed for streaming revision history, that's all
[02:30] <SamB> (well, especially not over HTTP, I guess ...)
[02:30] <lifeless> jelmer: it makes the flag on the format be accurate
[02:31] <jelmer> lifeless, it doesn't e.g. help with texts with ghost parents in pack repos?
[02:31] <lifeless> jelmer: no idea; it was inconsistent, I'm fixing it
[02:31] <jelmer> lifeless: ah, thanks
[02:38] <jelmer> lifeless, I was hoping it fixed the text ghost parent issue
[02:49]  * SamB wonders why bzr tags needs a branch
[02:51] <spiv> SamB: because tags are stored on a branch
[03:10]  * SamB wonders why he isn't seeing any tags in his putty import
[03:58] <lifeless> mwhudson: ping
[03:58] <mwhudson> lifeless: hi
[04:00] <mwhudson> lifeless: log -v --short is much quicker in this bzr-gc-chk255 branch now :)_
[04:02] <mwhudson> lifeless: like maybe twice as fast as --1.9
[04:17] <mwhudson> mm, a bit less than twice as fast
[04:17] <mwhudson> but a lot faster :)
[04:22] <lifeless> mwhudson: so how is loggerhead
[04:23] <mwhudson> lifeless: i haven't tested it specifically yet, been hacking on it in other ways today
[04:37] <mwhudson> today, i will mostly be stabbing firefox
[04:37] <gotgenes> How can I tell what files Bazaar *is* tracking?
[04:37] <Peng_> gotgenes: "bzr inventory", I guess
[04:38] <gotgenes> Peng_: Yep, that works. Thanks.
[04:38] <mwhudson> gotgenes: also ls --versioned
[04:42] <gotgenes> mwhudson: that works too. thanks
[04:42] <mwhudson> (i think commands like inventory, ignored, unknowns are gently deprecated in favour of ls --option)
[04:43] <mwhudson> gotgenes: i'd be lost without my "bzr ls --versioned --null | xargs -0 grep dsadas" commands :)
[04:49] <lifeless> mwhudson: 'bzr search'
[05:32] <lifeless> mwhudson: I think I have your conversion issues fixed
[05:32] <lifeless> mwhudson: pushing soon, once this test completes
[05:38] <mwhudson> lifeless: cool
[05:42] <gotgenes> Is there a way to get colorized output from bzr commands?
[05:42] <bob2> bzrtools has cdiff
[05:42] <bob2> in general no
[05:45] <gotgenes> bob2: fair enough
[05:48] <elben> I want to share my dot-files (.vimrc, etc) across all my machines. what do you think the best way of doing this is?
[05:49] <bob2> bzr!
[05:51] <gotgenes> elben: That's what I do.
[05:51] <gotgenes> Create symbolic links from your home directory to a branch directory
[05:51] <elben> you just set up a repo with your home folder being the root folder?
[05:52] <gotgenes> elben: naw
[05:52] <gotgenes> that gets messy
[05:52] <elben> @gotgenes: hah that just came to mind!
[05:52] <bob2> it doesn't get very messy
[05:52] <gotgenes> bob2: bzr status gets messy
[05:52] <bob2> I've been doing that for 4 years or so
[05:53] <elben> hum.. the machines at my univ doesn't have bzr installed =(
[05:53] <gotgenes> elben: if they have Python, you should be fine
[05:59] <elben>   alright, i'll try it out
[05:59] <elben> thanks for the tips
[06:00] <lifeless> mwhudson: pull groupcompress
[06:01] <lifeless> mwhudson: it plus the preior fix I gave  you (with a curret bbc branch) will probably be enough
[06:01] <mwhudson> lifeless: do i need to scrap my half-done branch, or can i pull on top of that?
[06:01] <lifeless> mwhudson: scrap it
[06:04] <mwhudson> lifeless: what was the fix you gave me again?
[06:04] <mwhudson> or at least, which file was it in\
[06:04] <lifeless> repository.py
[06:05] <mwhudson> hm
[06:05] <mwhudson> can you pastebin the diff?
[06:05] <mwhudson> or tell me the line number
[06:06] <lifeless> actually that fix is not relevant now, you need:
[06:07] <poolie> james_w: could you land my patch in https://bugs.edge.launchpad.net/ubuntu/+source/python-crypto/+bug/337073 or prod it along?
[06:08] <james_w> poolie: I can't land it, but I can make sure it is in the correct place
[06:10] <lifeless> http://paste.ubuntu.com/129110/
[06:14] <lifeless> mwhudson: you probably want to pull 1000 revisions at a time
[06:14] <lifeless> mwhudson: we're uhm, a little too efficient at the moment :P
[06:21] <lifeless> jam: http://paste.ubuntu.com/129110/
[06:29] <BasicOSX> Hello #bzr, looknig for guidance on where to push the 1.13rc1 for release? I'm "stuck" on step #7, submitting changes to PQM. Any help?
[06:30] <james_w> BasicOSX: hey, there is no branch yet, Robert is on it
[06:30] <james_w> BasicOSX: however, it's a bit more tricky as your key isn't known to PQM
[06:30] <james_w> BasicOSX: if you make your branch available somewhere I will submit it on your behalf
[06:31] <BasicOSX> Let me push it to my local area, back in a couple
[06:35] <BasicOSX> james_w:  ok, push underway, will /poke you when complete
[06:43] <schmichael> does bzr have an "outgoing" type command to see what commits would be applied in a push?
[06:43] <spiv> schmichael: "bzr missing --mine-only"
[06:44] <schmichael> spiv: perfect!  thanks!
[06:54] <BasicOSX> james_w:  prepare-1.13 here => http://bazaar.frostmage.org/prepare-1.13/
[06:55] <james_w> thanks
[06:56] <BasicOSX> Shall I continue with the announcement or should I wait for PQM ?
[06:57] <james_w> I'll submit now, but it may take some time, so you can work on other things in the meantime
[06:59] <mwhudson> lifeless: global name 'key' is not defined :(
[07:00]  * mwhudson changes it to 'keys'
[07:00] <mwhudson> and finally 'chunks'
[07:10] <lifeless> mwhudson: diff please
[07:13] <devilsadvocate> hi, I´m trying to get rid of this ¨Server does not support bazaar protocol 3, reconnecting¨. I´m using the latest bzr in the Debian Lenny repo. Is there any sane way I can either upgrade the server or force clients into Protocol < 3 so that the password doesnt have to be entered twice? (*very annoying)
[07:14] <Peng_> Are there up-to-date debs for Debian? The Ubuntu ones would probably work, but..
[07:15] <devilsadvocate> i have no idea. which bzr version did network protocol 3 come in?
[07:15]  * devilsadvocate is not sure if its a configuration issue
[07:16] <devilsadvocate> i have 1.5-1.1
[07:17] <devilsadvocate> which is probably bzr 1.5
[07:17] <devilsadvocate> hm
[07:18] <lifeless> devilsadvocate: 1.6 will solve this.
[07:18] <lifeless> 1.12 is current, 1.13 is entering rc as we speak :)
[07:19]  * devilsadvocate grumbles about debian stable
[07:19] <devilsadvocate> lifeless, thanks
[07:19] <devilsadvocate> i´ll look into trying to install it manuall
[07:19] <devilsadvocate> manually*
[07:19] <spiv> devilsadvocate: also, using an SSH key agent will save you typing in your password so often.
[07:20] <spiv> devilsadvocate: but I believe the bzr PPA has packages that should work on debian stable.
[07:20] <devilsadvocate> spiv, i use ssh keys, but i´ve got 60 people who dont know the first thing about version control and ssh keys to train, so..
[07:21] <devilsadvocate> spiv, is it possible to use ssh keys from windows? im using the bzr+ssh transport and the windows binary installer for bzr
[07:21] <lifeless> mwhudson: ping
[07:21] <spiv> devilsadvocate: there's a key agent for putty IIRC.  "pagent"?
[07:23] <devilsadvocate> spiv, hm. I´m not sure what ssh agent is being used. let me find a vanilla windows install and try that out. I dont think putty is being used anywhere... installing bzr + tortoise seemed to have installed some ssh agent as well
[07:24] <mwhudson> lifeless: hi
[07:25] <lifeless> mwhudson: pastebin the changes you made?
[07:25] <mwhudson> lifeless: 'key' only appears once in _inventory_xml_lines_for_keys
[07:26] <lifeless> mwhudson: got that, and fixed
[07:26] <mwhudson> that's all the changes i made
[07:26] <mwhudson> pull -r 1000 worked
[07:26] <lifeless> oh chunks comment was unrelated?
[07:26] <mwhudson> pull -r 2000 is still grinding away
[07:26] <mwhudson> lifeless: i changed key to chunks
[07:26] <mwhudson> as the other things i tried didn't work
[07:27] <lifeless> mwhudson: I need to see a diff
[07:27] <lifeless> mwhudson: as I don't understand
[07:27] <mwhudson> lifeless: http://pastebin.ubuntu.com/129129/
[07:28] <mwhudson> ah, -r 2000 completed
[07:28]  * mwhudson kicks off -r 3000
[07:28] <mwhudson> grar
[07:28] <lifeless> oh
[07:28] <lifeless> right, yes, record.key[-1]is the right incantaiton
[07:29] <lifeless> mwhudson: after it finishes, do 'bzr pack'
[07:30] <mwhudson> bzr: ERROR: Revision {('dirstate.py-20060728012006-d6mvoihjb3je9peu-1', 'mbp@sourcefrog.net-20070401013825-zggofbeun985u2ri')} not present in "<bzrlib.plugins.groupcompress.groupcompress.GroupCompressVersionedFiles object at 0x2fbddd0>".
[07:30] <mwhudson> again :/
[07:31] <mwhudson> oh, didn't pack first
[07:32] <lifeless> mwhudson: thats odd and shouldn't have happened
[07:37] <BasicOSX> Can someone with ops please update the topic to '1.13rc1 released 10 Mar'
[07:38] <mwhudson> lifeless: maybe you should try it :)
[07:39] <lifeless> mwhudson: I am
[07:39] <lifeless> 2.4G of output so far
[07:40] <mwhudson> hum
[07:40] <mwhudson> maybe i did something wrong then
[07:40] <james_w> lifeless: I have submitted the changes to the 1.13 branch and PQM seems to have ignored it. I got no email, and there is no new revision, and nothing in its queue apparently. Is there any way to debug this?
[07:40] <lifeless> mwhudson: did you delete the repository you were fetching into?
[07:40] <mwhudson> many times
[07:40] <mwhudson> i don't know if i did this very last time
[07:40] <lifeless> james_w: you probably haven't managed to get the mail out of your laptop
[07:40] <james_w> I have
[07:44] <poolie> woo way to go BasicOSX!
[07:47] <BasicOSX> Attempting to update pypi and "Server response (403): You are not allowed to store 'bzr' package information" anyone have auth to give me privs to update?
[07:47] <james_w> BasicOSX: http://pqm.bazaar-vcs.org/ <- merging now, sorry for the delay
[07:48] <BasicOSX> james_w:  np, ever sit on hold with a "normal" commercial software vendor? Service here is amazing!
[07:48] <james_w> heh :-)
[07:49] <spiv> BasicOSX: topic updated
[07:50] <BasicOSX> spiv:  ty
[07:50] <Peng_> Congrats on the release (candidate), BasicOSX & everyone. :)
[07:51] <BasicOSX> 1.13 should go smoother as now my feet are wet and I did not drown on my first attempt :-)
[08:11] <d-b> hi is there a good gui for bzr ?
[08:16] <AfC> d-b: there are several.
[08:17] <d-b> yes ?
[08:17] <d-b> any that i can use to link into konqueror / nautilus gui ?
[08:26] <spiv> d-b: there's a qbzr plugin (which tortoise-bzr on windows uses, I believe), and bzr-gtk has optional nautilus integration.
[08:27] <d-b> i have got bzr-gtk ... i wanted a gui manager ^^
[08:33] <spiv> d-b: try the nautilus integration bzr-gtk.  There's a readme about it in the source.
[08:53] <poolie> i'm craving a quick review of https://code.edge.launchpad.net/~mbp/bzr-email/335332-starttls/+merge/4331
[08:53] <poolie> hm needs diffs
[08:54] <poolie> lifeless: ^^ diffs added, really easy
[08:59] <lifeless> mwhudson: it converted for me
[08:59] <lifeless> 37MB total
[09:01] <nags> my friend tries bazaar from windows and getting this error message
[09:01] <nags> any clues ?
[09:01] <mwhudson> lifeless: i don't know what i'm doing wrong then
[09:01] <nags> C:\Python25\Scripts\racetrack1.0>bzr launchpad-login jwgreen
[09:01] <nags> bzr: ERROR: Connection error: curl connection error (SSL certificate problem, ve
[09:01] <nags> rify that the CA cert is OK. Details:
[09:01] <nags> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify faile
[09:01] <nags> d)
[09:01] <nags> on https://launchpad.net/%7Ejwgreen/%2Bsshkeys
[09:01] <mwhudson> lifeless: can you upload it to rookery or something?
[09:01] <lifeless> mwhudson: sure
[09:28] <lifeless> mwhudson: upload bandwidth sucky, will upload overnight
[09:28] <lifeless> mwhudson: 37MB is 27MB
[09:29] <lifeless> bah, 3  in the second part :P
[09:29] <lifeless> ciao
[09:29] <mwhudson> lifeless: cool, it's not like i'm going to do anything tonight :)
[11:26] <johnf> anyone working on 13rc1 packages for bzr-beta-ppa yet? If not I'll start
[11:52] <shled> hello
[11:52] <lifeless> johnf: doit
[11:53] <shled> beginners question: is it safe to remove a branch's directory after merging it into the main line?
[11:55] <beuno> shled, yeap, should be
[11:55] <shled> beuno: thanks!
[11:56]  * beuno waves at lifeless from Cape Town
[11:56]  * shled happily frees some disk space
[12:04] <thecookie> New to bzr. I just set up a master branch on a server, I branched it locally. Doing some code changes, commit it. Now it's commited to my local main branch, right? So to push it back to the master branch I do a push?
[12:05] <thecookie> After I've done a push, the master branch server needs to do an update to get the changes. That's why there is a push-and-update plugin, right? Is there any other way of doing it, or is that "the" way of doing it?
[12:07] <lifeless> beuno: nice
[12:08] <lifeless> thecookie: generally you don't need to have a up to date tree on the master for other people to pull from it
[12:09] <thecookie> lifeless: Well, the project I'm working with is a web page, and the same server hosting it is also hosting the page via http. That's why I want to update it. Maybe the post commit hook is triggerd on a push?
[12:10] <lifeless> thecookie: for that, most folk use the 'bzr-upload' plugin I think
[12:10] <lifeless> thecookie: the post-tip-branch-change hook is fired on the server after a push if you are using bzr+ssh
[12:12] <thecookie> I'm using bzr+ssh, yeah. But it seems to be a bit of overhead. First I push changes to the server, then I upload them too?
[12:14] <thecookie> I didn't read up on the upload plugin tho. Maybe I should :)
[12:15] <johnf> lifeless: At some stage I'll need write access to the lp:~bzr/bzr/packaging-hardy is it possible to get access to those as a bzr-beta member? Or should I just create my own branches and propose merges?
[12:15] <thecookie> Yeah, seems to work like I thought. Seems stupid to upload the changes twice
[12:16] <thecookie> I guess push-and-update fits me thetter then, just wanted to check if there was a "correct" way to do it
[12:18] <Jc2k> wg /8
[12:18] <Jc2k> grr
[12:21] <lifeless> thecookie: in general update can fail because of local edits; bzr-upload kind of fits the model better; anyhow - as long as you're happy thats great
[12:22] <lifeless> johnf: we can fix permissions on tha tbranch - move it to ~bzr-beta-ppa or whatever
[12:22] <lifeless> johnf: let me know tomorrow ;P
[12:22] <johnf> lifeless: ok cool
[12:22] <lifeless> Jc2k: :)
[12:22] <thecookie> lifeless: The master server will never have local edits
[12:23] <thecookie> It's pretty much just the "main branch" hosted for others
[12:51] <OllieR> is it possible to cancel a pending merge?
[12:51] <OllieR> on this branch it looks like someone has done a local ci and then done an up
[12:51] <OllieR> so the changes are showing as pending merge but I just want to remove them
[12:52] <OllieR> Whats the best way to do this?
[12:52] <jelmer> OllieR, bzr revert
[12:54] <OllieR> jelmer: thanks
[13:19] <johnf> can someone test http://inodes.org/johnf/debs/bzr_1.13~rc1-1~bazaar1~intrepid1_i386.deb before I upload to the beta ppa?
[13:45] <rocky> if i merge from branch A into branch B ... and later on i merge from branch B into branch C ... how does the history on branch C reflect the original changes from branch A ?
[13:46] <rocky> i mean does it show up as a merge commit coming from A ?
[14:04] <rocky> lifeless: don't suppose you know if the streaming feature for bzr push to a bzr url works over bzr+http:// as well?
[14:21]  * SamB wonders why jelmer did a release of bzr-svn that depends on an unreleased version of bzr
[14:22] <rocky> SamB: latest release of bzr-svn should work with released bzr-1.13rc1 no ?
[14:22] <SamB> rocky: oh, that's a release ?
[14:22] <rocky> bazaar release notes says it is
[14:22] <rocky> i haven't actually downloaded it tho
[14:22] <SamB> nevermind then
[14:42] <saulus> hi, how do I change the "parent branch", this one is deleted and I want to set the parent branch to the submit branch
[14:43] <saulus> funny - as soon as i send my request it works 0o
[16:03] <jelmer> SamB, the API is frozen now there's a RC out
[16:03] <jelmer> SamB, that's always a good moment to release bzr-svn, otherwise people need to wait for one after 1.13 is released
[16:48] <KangOl> Hi
[16:48] <KangOl> How to clean the history of a branch after doing a "bzr split" ??
[16:49] <KangOl> I want to strip out all unrelated log history
[17:18] <nathanhammond> Hokay, so. I'm in both this and Mercurial's room and am asking the same question in both places. Why should I choose Bazaar over Hg at this point in time for new projects?
[17:19] <nathanhammond> (With the continued improvements I've seen on both sides, the BzrVsHg comparison is out of date.)
[17:19] <nathanhammond> I've been using Git for a while now, but in a mixed environment (Windows) it is hard(/impossible) to justify using it.
[17:36] <eferraiuolo> I'm wondering if there is a command to remove all *.~1~ backup files that got created on accident? I forgot to add the --no-backup argument to the bzr revert command
[17:39] <Tak> I personally chose bzr over other DVCSs because: I know it will run anywhere python will run, it has good support for a lot of different workflows, bzr devs are constantly working on better merging and more efficient storage, and support by ubuntu/launchpad
[17:40] <maxb> eferraiuolo: bzr clean-tree might help. Or, there's always plain old find.
[17:40] <Tak> find . -regex '.*\.~[0-9]+~$' -execdir rm {} \;
[17:40] <Tak> ;-)
[17:40] <nathanhammond> Tak: thanks for your comments. Is there any particular workflow that stands out?
[17:41] <nathanhammond> (I'm coming from Git, needing something that runs as a non-second-class citizen on Windows)
[17:41] <Tak> for me, no particular one by itself, but every project has its own workflow
[17:41] <maxb> I think the point about workflow is that if you want to pretend you're still using a centralized SCM, you can?
[17:41] <Tak> and I've yet to find one that is uncomfortable with bzr
[17:42] <nathanhammond> I am trying to train centralized out of the rest of the team in baby steps.
[17:43] <eferraiuolo> maxb: thanks
[17:44] <jelmer> KangOl, History isn't really changable.
[17:45] <Pieter> Tak: heavy rebasing / cherry-picking doesn't work very well with bzr
[17:45] <Tak> ok
[17:46] <devilsadvocate> Tak, there are loads of them
[17:46]  * Tak shrug
[17:46] <devilsadvocate> nathanhammond, best of luck doing that
[17:46] <Tak> "I haven't found any" != "They don't exist" ;-)
[17:47] <devilsadvocate> Tak, nathanhammond : theres always _some_ part of the team thats wants to do thing "the other way"
[17:47] <Tak> it's true
[17:48] <Tak> I've spent years migrating my dept from (vault||nothing) => svn
[17:48] <nathanhammond> devilsadvocate, Tak: fortunately, there are two camps they're coming from: svn locally, and the "copy a folder, edit" approach
[17:48] <nathanhammond> globally there isn't anything
[17:48] <nathanhammond> and that is one of my responsibilities
[17:48] <Tak> is it too late to murder the copy/edit group?
[17:48] <jelmer> Pieter, Cherrypicking only works well with darcs unfortunately :-/
[17:49] <devilsadvocate> Tak, you'd be killing off half your team, if not more
[17:49] <nathanhammond> be nice! web developers, the lot of 'em.
[17:50] <nathanhammond> SCM-managed websites seems to be a kinda new thing
[17:50] <devilsadvocate> nathanhammond, you and i have a very unenviable job. the hope is that the univers shall one day repay us
[17:51] <nathanhammond> devilsadvocate: I'm simply hoping that things aren't so entrenched that it is possible to get people to buy in
[17:52] <nathanhammond> the problem is that the team actually has decent incremental hourly backups that has been serving as their version control.
[17:52] <nathanhammond> "why do I need SCM when..."
[17:53] <nathanhammond> in any case, I'll figure it out.
[17:53] <devilsadvocate> nathanhammond, its not so much entrenched in a different camp, its more of a "is this really worth my time and effort as this really great effort"
[17:54] <devilsadvocate> *really gread programmer"
[17:54] <devilsadvocate> great*
[17:54]  * devilsadvocate really needs sleep
[17:54] <nathanhammond> heh
[17:55] <devilsadvocate> if you ask me, the easier way would be to let it bite them in the face one day and let take it up voluntarily
[17:55] <nathanhammond> that worked at the last job
[17:56] <nathanhammond> rm -rf is not a friend
[17:56] <devilsadvocate> :D
[17:56] <devilsadvocate> rm -rf is the lesser of devils
[17:57] <devilsadvocate> a simple backup will do the job, you dont need version control
[17:57] <nathanhammond> old job: no backups
[17:57] <nathanhammond> git's distributed SCM to the rescue on 3 of 4 projects (since I set them up)
[17:57] <devilsadvocate> no, the fun time comes when its time to deliver and you realize different parts of the groups were working on different code, as in, different checkouts from a no-exisiting tree and that they all dont work together
[17:58] <nathanhammond> fourth project lost a week, since that was the last time it got pushed live
[17:58] <nathanhammond> ouch. no thanks.
[18:22] <alefteris> hi all! are symlinks added in the bzr repo? if they are how can I remove them, I tried with bzr remove but that didn't work
[18:30] <kfogel> sanity check: bzr versions directories as first-class objects, right?  I mean, that's how it's always appeared to me, but I want to make sure I'm not missing any gotchas.
[18:30] <luks> yes
[18:30] <kfogel> luks: thanks
[18:30] <luks> directories are just a different kind of 'inventory items'
[18:37] <clemente> alefteris: yes, they are added. There is some trouble in removing them; for instance see: https://bugs.launchpad.net/bzr/+bug/236149   . I have added there a link to a workaround
[18:44] <alefteris> clemente, thanks. another thing: with the symlink added, will I be able to check out to a windows machine?
[18:58] <clemente> alefteris: I don't know that; I suppose yes, you can, but I don't know what will be checked out. Maybe the same file twice?
[19:01] <clemente> (however, some messages in the Internet speak about getting just an error...)
[19:05] <alefteris> clemente, ok thanks a lot
[19:44] <eferraiuolo> I got the following message when doing a checkout of a branch on over HTTP:
[19:44] <eferraiuolo> Got a 200 response when asking for multiple ranges, does your server at localhost:8080 support range requests?
[19:45] <eferraiuolo> Will bzr still function if the server doesn't support multiple range requests?
[19:45] <eferraiuolo> i.e. will my branch be fine even though bzr wrote that message during the checkout?
[19:48] <mwhudson> yes
[19:48] <mwhudson> it's a performance thing, not a correctness thing
[19:48] <eferraiuolo> mwhudson: thanks for the insight
[19:50] <pgega> hello
[19:50] <mwhudson> reboot, brb
[19:55] <pgega> I am working on the bazaar-based audit script that watches some various dirs for changes and commits the to the repo.
[19:56] <pgega> Is there any way tor relocate repository (.bzr) from working dir using bzrlib ?
[19:57] <Spaz> hello
[19:57] <Spaz> does bzr have a command to copy files?
[19:59] <bob2> no
[20:04] <Spaz> :(
[20:05] <bob2> afaik only svn does
[20:05] <Spaz> hg does too
[20:06] <LarstiQ> what are the semantics in hg?
[20:06] <LarstiQ> for merge, and log?
[20:06] <LarstiQ> Spaz: does a copy get updated with changes on the copied from?
[20:06] <Spaz> not in hg.
[20:06] <Spaz> you can make a symlink though
[20:07] <Spaz> which effectively does the same thing.
[20:07] <bob2> what's the point then? :)
[20:08] <LarstiQ> Spaz: iirc, afaik, the semantics of copy never became crystal clear
[20:08] <Spaz> bob2, https://bugs.launchpad.net/bzr/+bug/269095
[20:09] <LarstiQ> Spaz: and implementing it halfbaked would give false promises and trouble etc
[20:09] <Spaz> eh.
[20:09] <Spaz> copy should copy the file along with its revision history
[20:09] <LarstiQ> Spaz: but the developers aren't opposed to copy, if someone does the work :)
[20:09] <LarstiQ> Spaz: that's only one part of it.
[20:09] <LarstiQ> Spaz: how does it interact with the rest of the tool?
[20:10] <LarstiQ> this is all my recollection from the past
[20:10] <Spaz> ahh. i see.
[20:10] <Spaz> i would do this but i'm not familiar enough with bzr's internals.
[20:10]  * LarstiQ doesn't know if there is a different current status
[20:11] <LarstiQ> Spaz: that we can help with
[20:13]  * Spaz will give this a shot since he has so much free time today
[20:14] <Spaz> although this will certainly take a few days.
[20:14] <Spaz> probably a week. :p
[20:32] <LarstiQ> Spaz: I'd be impressed if you get it done in that time :)
[20:32] <LarstiQ> Spaz: will buy you a beverage of your choice when we meet :)
[20:36] <LarstiQ> jelmer: will you upload 0.5.3 to ppas, or ok if I do that?
[20:36] <jelmer> LarstiQ, go for it :-)
[20:37] <jelmer> LarstiQ, and thanks (-:
[20:37] <LarstiQ> jelmer: you'll have to wait till tomorrow though
[20:40] <Spaz> LarstiQ, i wrote 900 LOC this week. :p
[20:40] <Spaz> (according to sloccount)
[20:45] <LarstiQ> Spaz: I'm afraid that's not where the problem is going to lie
[20:45] <LarstiQ> Spaz: but don't let me be pessimistic, I should cheer you on \o/
[20:46] <Spaz> LarstiQ, trust me, much of this code wasn't trivial :p
[20:46] <Spaz> i'm just insane though.
[20:56] <LarstiQ> Spaz: cool :)
[21:40] <mwhudson> mm, multiply_tests looks a lot nicer than what we do in lp today :)
[22:06] <OllieR> Hey I am setting up a bzr repo for centralised workflow. I have done mkdir /src/bzr/ I was then planning on doing bzr init-repo -treeless /srv/bzr and creating subdirs such as applications and websites which I would do bzr init in e.g. bzr init /srv/bzr/websites/example.com/main/
[22:07] <OllieR> What I guess thought it is it best to just do bzr init-repo on the dir /srv/bzr or should i do it on the specific project branches
[22:07] <OllieR> e.g. bzr repo-init /srv/bzr/websites/example.com/
[22:08] <OllieR> I am going to need to give write/read access on various dirs/branches to various people. Wondering if having a repo for each project would help me do this or whether I have missed something/got confused
[22:09] <verterok> OllieR: if you create a repo in /src/bzr/ all users must have write access in that dir
[22:14] <OllieR> verterok: which means all users could write to all branches
[22:14] <bob2> yes
[22:14] <OllieR> which is not really what i want so i will do a bzr init-repo for each project
[22:17] <OllieR> need to also look into giving public access via http
[22:18] <OllieR> i guess i can just add an apache vhost and let users checkout via http://
[22:18] <OllieR> then write access doesn't come into it
[22:34] <johnf> lifeless: So I have bzr 1.13rc1 packages ready to upload. But there isn't a new bzrtools yet so I'm hesitant to upload it. Since this was one of my biggest issues ie the packages in the ppa being out of sync
[22:35] <lifeless> johnf: thats fair enough.. perhaps abentley: can do a release today; though we are sprinting :)
[22:39] <kousu> What does diverge mean to bzr?
[22:40] <kousu> I was able to pull a branch and have it merge changes, but now I keep getting "branches have diverged".
[22:42] <bob2> pure bzr or does it involve svn?
[22:43] <jml> radix: regarding bug 152008
[22:43] <kousu> pure bzr
[22:44] <jml> radix: I was wondering, do the Twisted community _really_ need that? You could probably hack buildbot up to do a PQM-style "only land if tests pass" thing.
[22:48] <mwhudson> lifeless: lp:bzr-search was broken by the removal of adapt_tests
[22:50] <radix> yeaaaah well
[22:51] <radix> that's another thing to do
[22:51] <radix> jml: but it still doesn't solve the problem
[22:51] <jml> radix: it might make it less pressing.
[22:51] <radix> jml: I mean, it's pretty easy to introduce tests which spuriously fail
[22:51] <radix> yeah, true
[22:51] <radix> we could do the lose-history hack
[22:51] <radix> when we really need to revert
[22:52] <mwhudson> i wonder if you could have the reverting process insert a revprop
[22:52] <jml> radix: so, we do revert revisions from time to time from the Launchpad tree.
[22:52] <radix> jml: well, and the other thing is that we still can't switch to an "only land if the tests pass" because of *current* sporadic tests
[22:52] <mwhudson> that merge would notice when you merge trunk into the feature branch
[22:52] <radix> mwhudson: that's how I was imagining the solution would look
[22:53] <jml> radix: right. there are things you can do there, but they mostly require either fixing the tests or policy changes.
[22:54] <mwhudson> AssertionError: Failed doctest test for bzrlib.branchbuilder.BranchBuilder
[22:54] <mwhudson> because i didn't let it have my passphrase :(
[22:55] <jml> radix: sporadic tests could be marked todo, for example
[22:55] <jml> radix: but still, there's a bzr bug, and we should fix it :)
[22:56] <lifeless> mwhudson: yes, I have a fix just need to upload it :P
[22:56] <mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/321320
[22:56] <mwhudson> lifeless: oh good
[22:56] <lifeless> mwhudson: give the bzr.dev.chk copy a spin, you'll want to rsync
[22:56] <lifeless> -> sprint now
[22:57] <mwhudson> lifeless: other priorities right now, but will do
[22:57] <mwhudson> oh, i have a bazaar branch i want landing in a sec :)
[23:10] <lifeless> mwhudson: ok
[23:11] <mwhudson> lifeless: http://pastebin.ubuntu.com/129561/
[23:11] <mwhudson> lifeless: it just extracts the creation of the branch format scenarios out of load_tests
[23:24] <lifeless> mwhudson: looks fine to me
[23:24] <mwhudson> lifeless: cool, i sent a bundle off, but it doesn't seem to have made it to the list yet
[23:25] <lifeless> JFDI
[23:29] <lifeless> you chave commit rights yeha?
[23:29] <mwhudson> nope
[23:30] <lifeless> oh
[23:31] <mwhudson> though of course i can't change launchpad to use this until after i land bzr.dev into sourcecode
[23:31] <mwhudson> but well
[23:33] <mwhudson> lifeless: the branch is at https://code.edge.launchpad.net/~mwhudson/bzr/extract-make-branch-scenarios fwiw
[23:35] <mwhudson> and the bundle here: http://people.ubuntu.com/~mwh/extract-make-branch-scenarios-4109.patch
[23:35] <spiv> Apparently calling fsync is more important under ext4: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54
[23:45] <blueyed> Is there a better way to get a revisions log message than $(bzr log -r $rev --long | grep '^  ' | sed 's/^  //') ?
[23:46] <kousu> blueyed: what's wrong with bzr log -r $rev?
[23:47] <blueyed> kousu: I only want the message (for a script).
[23:47] <kousu> ooh
[23:47] <blueyed> ok, the "--long" is not required (since it's default).. but anyway..
[23:51] <kousu> You could bzr log -r $rev --short | tail -n +2 but that's not much better
[23:51] <kousu> Or you could write a bzr plugin that gives you just the log messages
[23:51] <kousu> But what you've got already is probably as good as either of those
[23:52] <blueyed> ok, thanks, kousu. It would break however when the amount of spaces changes.. :/
[23:53] <kousu> So give up on shell and write it in python? str.strip for the win
[23:54] <blueyed> well, sure. I could strip it in shell, too - but it's used for detecting the message, too. therefore "--short"/tail is an improvement already.