[00:30] <jelmer> w00t, got "bzr builddeb <remote-url>" working :-)
[03:12] <alecwh> ﻿Hello! I want my bzr repository to be something that any user can just clone for the latest version possible of the software. The only problem is, I have a "config.php" file that needs to be changed after a clone, because a variable needs to be set to "$installed = 'no';". However, my local copy has it to 'yes' because that's what I use for myself. So, is there any way that bzr can just "ignore" that config.php to any changes, and just leave 
[03:12] <bob2> have a seperate branch
[03:13] <bob2> although then you can only merge one way
[03:16] <alecwh> oh, so just merge branches whenever I make a change?
[03:16] <alecwh> but that will merge the config.php's (and probably have a merge conflict), because they are different, correct?
[03:20] <jelmer> alecwh: alternatively, you may just want to include a file "local-config.php" from your config.php that isn't versioned
[03:21] <jelmer> perhaps only if it exists, and set "$installed = 'yes'" if it doesn't
[03:22] <alecwh> jelmer: good idea actually... but if bzr doesn't recognize it, then it won't be uploaded with the repository.
[03:22] <jelmer> alecwh: yes, but you would be the only one who would have to have that file
[03:23] <jelmer> users who wouldn't have it would just get the default configuration
[03:23] <alecwh> oh okay. I'll try that out, thanks jelmer.
[03:23] <alecwh> =)
[03:23] <alecwh> wait - what does bzr ignore do?
[03:23] <bob2> stop bzr status complaining about files being unknown and 'bzr add .' from adding them
[03:29] <alecwh> oh, ok.
[03:30] <bob2> (you can still add them by giving their specific name)
[03:51] <nekohayo> ugh, for some reason I am still not able to rebase with bzr 1.5, getting tracebacks, can anyone help me figure out if it's me doing something wrong or if it's a bug?
[05:01] <jearl> cspam
[06:25] <alecwh> I'm trying to get bazaar to work with http://cia.vc to send my commits to IRC channels, but I'm stuck. Does anybody know how to do this?
[06:57] <bob2> you're using the bzr cia thing?
[06:59] <gour> is this "Another possible use for a checkout is to use it with a treeless repository containing your branches, where you maintain only one working tree by switching the master branch that the checkout points to when you want to work on a different branch." common 'bzr-idiom' when for local development?
[06:59] <gour> s/when for/for
[08:38] <gour> my xdg_email is empty...anyone use Gnus with bzr?
[09:03] <vila> gour: I use bzr and I use Gnus, what is your question :)
[09:04] <bob2> I don't even have a xdg_mail
[09:05] <vila> gour: no need for a Gnus mail client, just add 'mail_client = emacsclient' in ~/.bazaar/bazaar.conf and add (server-start) to your ~/.gnus
[09:05] <vila> gour: I said ^ a few days ago, did you read it ?
[09:06] <gour> thanks
[09:06] <gour> vila: no, i missed it
[09:07] <vila> gour: hmm, yeah, re-reading logs, you left just before I posted it :) Sorry, I missed that detail :-/
[09:08] <gour> ta
[09:08] <vila> gour: what exactly means 'ta'
[09:09] <vila> I understand the 't' is for thanks but the 'a' ?
[09:10] <gour> 'alot'
[09:10] <spiv> "ta" is just a short way to say "thanks".
[09:10] <gour> :-)
[09:10] <vila> spiv: hi !
[09:11] <spiv> vila: good evening
[09:11] <vila> I'm looking at bug #230223, but I feel out of my league :-/
[09:12] <spiv> vila: sorry, I'm just passing through...
[09:12] <vila> my understanding so far is that smart server probing is not prepared to receive a 403
[09:12] <vila> spiv: ok, no worries
[09:12]  * spiv -> dinner
[11:39] <alefteris> i upgraded my local branch to rich-root-pack, then I'm trying to do the same with the launchpad.net hosted branch, but I get this: "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format."
[11:40] <alefteris> when i try to do bzr info at the launchpad branch i get "Standalone branch (format: unnamed)". What am I doing wrong?
[12:00] <lifeless> alefteris: for the launchpad branch you need to upgrade using sftp; that should work
[12:07] <alefteris> lifeless, thanks, I had to install paramiko as well and all went fine :)
[12:37] <jelmer> nekohayo, please file a bug report
[12:46] <lifeless> jelmer: bzr pull from bzr-svn - is it mainly slow cause of bzr ?
[12:47] <jelmer> lifeless: yes
[12:49] <jelmer> lifeless, there are some minor bits that can be improved in the fetch code of bzr-svn but it's mainly in the bzr-side of things
[12:50] <jelmer> lifeless, are you doing a pull that appears to be too slow?
[12:52] <bob2> did the bzr-gtk trunk get rebased?
[12:53] <jelmer> bob2
[12:53] <jelmer> no
[12:57] <lifeless> jelmer: I was showing ted gould from inkscape
[12:57] <lifeless> jelmer: and it was doing a revision every 30-40 seconds ot so
[12:57] <lifeless> which is rather appalling :P
[12:58] <bob2> oh, bah, ~bzr/bzr-gtk got killed 6 months ago and I didn't notice
[12:58] <jelmer> lifeless: Wow, ok. Worst I've seen is once every couple of seconds
[12:59] <jelmer> lifeless: Any idea what is being so slow?
[13:01] <jelmer> lifeless, are you trying this with a local svn repository?
[13:02] <jelmer> sourceforge can be really slow sometimes
[13:05] <jelmer> lifeless: I'm just trying it as well now, and it's taking 2 seconds to reply to each request
[13:06] <jelmer> lifeless: so, when are shallow branches going to land ? :-P
[13:18] <lifeless> jelmer: argh, 2 second latency on the server is explainable :)
[13:19] <lifeless> jelmer: could we show that in thhe ui/log file somehow ?
[13:19] <jelmer> lifeless: we are, but the progress bar is sometimes hidden for some unexplainable reason
[13:20] <jelmer> there are progress bars being displayed from inside bzr-svn
[13:20] <jelmer> s/displayed/created
[13:20] <hsn_> zr: ERROR: No such file: 'http://bazaar-vcs.org/bzr/bzr.dev/.bzr/repository/indices/b072a80d0242839227870cba3a3e0f9b.rix'
[13:20] <hsn_> repo moved?
[13:22] <lifeless> hsn_: probably a push going through at the time you were reading
[13:22] <lifeless> hsn_: just try again
[13:23] <lifeless> hsn_: there is a bug open - this is something we should retry on
[13:29] <hsn_> lifeless: it works now
[13:56] <jelmer> lifeless: inkscape isn't exactly fast here either; does about one revision every two or three seconds
[13:57] <jelmer> lifeless: seriously though - what's still left for shallwo branches?
[13:58] <lifeless> jelmer: thats faster than we were seeing
[13:58] <lifeless> jelmer: well the prototype branch is there for testing; you should be able to do bzr-svn work for it now
[13:58] <lifeless> jelmer: I'm working on optimisations now - inpartcular exposing historic texts on all repositories
[14:00] <jelmer> lifeless: where's the branch?
[14:11] <lifeless> jelmer: mumbke shallow-branch or somthing
[14:11] <lifeless> http://www.google.com/search?q=bzr+shallow+branch&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a
[14:11] <lifeless> its in that list :)
[14:12]  * jelmer wished he could do "lp list-branches bzr | grep shallow"
[14:17] <jelmer> lifeless: how stable is that API supposed to be, and what are the chances it's going to be in 1.6 ?
[14:17]  * jelmer doesn't want to go through similar issues as rich roots
[14:21] <lifeless> jelmer: hopefully the external API is done
[14:21] <lifeless> I would like it if you worked with me on a beta-bzr-svn branch to use it
[14:22] <lifeless> jelmer: that would be better than waiting for me to be 'done' and then findingout its missing/bad for you
[14:22] <lifeless> jelmer: just don't offer it to 'users'.
[14:28] <jelmer> lifeless: I'm happy to work on "beta" support in bzr-svn, I'm just trying to avoid participating in the process too early
[14:29] <jelmer> and having to maintain a bzr-svn branch through API changes and months of bzr releases
[14:31] <acuster> hey jelmer! Any chance you'd be willing to flesh out your answer to the last FAQ: http://samba.org/~jelmer/bzr-svn/FAQ.html ?
[14:31] <jelmer> acuster: What specifically?
[14:31] <acuster> it bit me enough that I'm being pushed towards mercurial but I suspect bzr handles svn copy better than hg
[14:32] <acuster> I did a push back to svn, possibly with an --overwrite I don't remember, and the operation deleted the whole trunk and pushed us back to where I had converted from
[14:33] <acuster> so I gather I deeply misunderstood how bzr and svn go together
[14:33] <acuster> so specifically
[14:33] <acuster> that and it are vague
[14:33] <acuster> I'd like a recepie possibly with why
[14:34] <lifeless> jelmer: I would help maintain such a branch
[14:34] <lifeless> jelmer: work goes >> when many hands
[14:34] <jelmer> acuster: I updated the FAQ
[14:34] <acuster> thanks
[14:35] <jelmer> lifeless: Thanks, that'd help
[14:35] <acuster> I'll try to get a better grip on my question when I can use 1.5 on this hardy
[14:42] <lifeless> jelmer: have you seen my status mails ?
[15:03] <jelmer> lifeless: no, I haven't - a quick search for "shallow" in my bzr mailbox doesn't list anything
[15:04] <jelmer> lifeless: also, the only "shallow" branch from you on launchpad is 11 weeks was last changed in february
[15:04] <bob2> it's on p.u.c
[15:06] <jelmer> http://people.ubuntu.com/~robertc/baz2.0/shallow-branch/ ? that's the one that hasn't hcanged since feb
[15:07] <nekohayo> jelmer: hey, it seems it stopped giving me tracebacks! http://pastebin.ca/1021882 but I get a bunch of conflicts. should bzr replay be done with -r2.. (revision 2 is identical in contents) or the revision that followed?
[15:09] <jelmer> nekohayo: the branches probably have different file ids
[15:09] <nekohayo> jelmer: well, I assume so, they were different branches... what do I do?
[15:10] <jelmer> the maptree stuff should be able to help there (it makes rebase/replay use paths rather than file ids) but that's not hooked up to the rebase ui yet (only used by svn-upgrade)
[15:11] <jelmer> so it's not really possible to use rebase/replay in this case
[15:11] <nekohayo> >_<?!
[15:12] <nekohayo> I don't exactly see what's so unusual with my case :|
[15:12] <jelmer> different file ids
[15:17] <nekohayo> jelmer: what is a fileid actually? and how could branches that were not historically connected ever have matching file ids?
[15:17] <jelmer> nekohayo: a file id is a unique string that identifies a file. It's generated when it is first added to bzr
[15:17] <jelmer> nekohayo: there's no way for historically not connected branches to have the same file ids
[15:19] <nekohayo> so there's no way to go further now? solving the conflicts wouldn't do it?
[15:20] <jelmer> nekohayo: you can use diff + patch manually to replay each commit so you end up using the file ids from the branch you're building on rather than the branch you're replaying
[15:22] <nekohayo> basically recommitting everything by hand
[15:22] <jelmer> yes
[15:22] <jelmer> I'm not aware of any bzr plugins at that can do that for you
[15:23] <jelmer> rebase/replay could do it if you hooked up the maptree stuff
[15:23] <nekohayo> how hard is that?
[15:25] <jelmer> should be a matter of adding a call to MapTree() in the function that replays a delta in rebase
[15:26] <lifeless> jelmer: yes, thats right - I've been working on 'VersionedFiles' the consolidation of knits etc
[15:26] <lifeless> jelmer: that will let me loosen the constraint on version locking in shallow-ranch, and also get good performance for checkout() over the network.
[15:27] <nekohayo> rebase.py:410:def replay_delta_workingtree(wt, oldrevid, newrevid, newparents,
[15:31] <nekohayo> jelmer: I see that there is a file bzr-rebase/site-packages/bzrlib/plugins/rebase/test_maptree.py
[15:32] <nekohayo> but I don't understand it
[15:32] <jelmer> nekohayo: you'd need the code in maptree.py
[15:34] <jelmer> and wrap the other tree specified to merge in replay_delta_workingtree() with MapTree()
[15:40] <nekohayo> x_x beyond my skillset I guess
[15:40] <nekohayo> or is there a bug/blueprint I can subscribe to for rebase to support maptree?
[15:41] <jelmer> no, though you could file one
[15:54] <Verterok> Hi
[15:54] <Verterok> nekohayo, jelmer: maybe using fastexport/fastimport to replay the commit?
[15:54] <Verterok> s/commit/commits/
[15:55] <lifeless> jelmer: so look for those mails :)
[15:56] <lifeless> vila: isn't your new POST bug a dupe?
[15:57] <vila> lifeless: I was unsure and wanted a reference to put in my merge request for #230223
[15:57] <vila> lifeless: bug #231649 is for the *test* servers
[15:58] <lifeless> vila: anyhow, do you have time to look at http vs sftp pull performance?
[15:59] <vila> ghaaa, still trying to clean up my plate, I think I shoudl decline :-/
[16:00] <vila> I really really really want to write that use-a-real-server-for-tests plugin now
[16:01] <vila> lifeless: wait a minute, what are you talking about ? http vs sftp ? Care to help me page in ?
[16:04] <lifeless> vila: couple days ago
[16:04] <lifeless> vila: kinnison was saying 'pull never utilises full bandwidth'
[16:04] <lifeless> vila: I said 'try sftp'; he did and it maxed his link out
[16:05] <lifeless> vila: he had been pulling over http
[16:09] <vila> so sftp utilizes full bandwidth but http not ? If it's with urllib, that's a regression from the time I rewrote the streaming part.
[16:12] <vila> trying.
[16:15] <vila> branch uses full bandwidth AFAICS, or not ? Seems like many pack files are involved.
[16:16] <vila> sftp doing asynchronous IO thanks to paramiko may explain a bit of difference
[16:17] <nekohayo> jelmer: think that could work?
[16:18] <jelmer> nekohayo, not familiar enough with fastexport/fastimport
[16:18] <nekohayo> Verterok: never tried them, any pointers how to go about it?
[16:19] <vila> lifeless: indeed, pull seems worst than branch for bandwith (did a test with bzr branch -r 3300 bzr.dev tests; cd test; bzr pull bzr.dev
[16:19] <jelmer> lifeless, any chance you can merge bzr.dev in your shallow branch branch?
[16:19] <Verterok> nekohayo: I'm not an expert, but played a bit with it :)
[16:20] <Verterok> nekohayo: first do an fastexport of the branch, then you can write your own  processor to filter whatever you need to
[16:21] <Verterok> and do a fastimport, using the your custom proccessor
[16:27] <lifeless> jelmer: I will, once I have all tests passing with no repository._revision_store
[16:27] <lifeless> jelmer: e.g. probably tomorrow
[16:27] <jelmer> lifeless, ok
[17:08] <vila> lifeless: bzr: ERROR: Not a branch: "sftp://vila@bazaar.launchpad.net/~bzr/bzr/trunk/ ???
[17:09] <bob2> are you a member of the bzr group?
[17:10] <vila> bob2: I hope so :)
[17:11] <bob2> hehe
[17:24] <lifeless> vila: ?
[17:25] <vila> lifeless: shouldn't there be a branch there ?
[17:25] <lifeless> interesting
[17:26] <lifeless> vila: no
[17:26] <lifeless> vila: its not hosted on launchpad
[17:26] <lifeless> vila: its mirrored there only
[17:26] <vila> simple, clear. Thanks lifeless :)
[18:05] <abentley> vila: We are hoping to make our sftp and bzr+ssh services behave the same.  So that branch might be available on sftp after the next launchpad release.
[18:07] <abentley> vila: I worked on that with jml.  It was rather tricky because the sftp server is twisted, and bzr+ssh is synchronous.
[18:09] <vila> abentley: thanks for the info, what I was searching for was a branch that I can access with http and sftp with the same network context cot ompare respective performances, I totally forgot that I was accessing different hosts on lp, so...
[18:09] <vila> s/cot/to/
[18:12] <abentley> vila: I think the host is the same in both cases.  The problem is really that there are two different areas on launchpad; the hosted area and the mirrored area.  http gives access only to the mirrored area (which contains copies of hosted branches).  sftp gives access only to the hosted area.
[18:12] <abentley> bzr+ssh gives access to both, preferring hosted.
[18:14] <vila> abentley: thks.
[18:15] <abentley> np
[18:22] <vila> grr, what is the difference between code.lp.net and bazaar.lp.net ? bazaar is giving me a 502 Bad Gateway after a 215s timeout where code seems to issue a redirection (triggering a bug in the nosmart+ decorator by the way) 8-(
[18:24] <beuno> vila, I think code.lp is used for the web app, and bazaar.lp is for actual branches
[18:24] <beuno> morning  :)
[18:24] <vila> beuno: hi :)
[18:49] <vila> !paste
[19:00] <lifeless> see you all tomorrow
[21:24] <MachinShin> hey guys, getting this error, what can i do to fix it? ->bzr: ERROR: Unsupported protocol for url "sftp://<censored>/trunk": Unable to import paramiko (required for sftp support): No module named paramiko"
[21:24] <mwhudson> beuno: damn loggerhead -- i bounced it
[21:24] <jelmer> MachinShin, install paramiko
[21:30] <MachinShin> thanks jelmer
[21:50] <Peng> Ok, this is weird. I'm reading Ben Finney's posts on the mailing list while watching the Star Trek TOS episode about Lt. Cmdr. Ben Finney.
[21:51] <pickscrape> Maybe they used bzr for source control when programming the LCARS system?
[22:21] <thumper> morning
[22:21] <thumper> jelmer: are you available for a few questions?
[22:21] <jelmer> thumper, hi
[22:21] <jelmer> thumper, sure
[22:22] <thumper> jelmer: There are two branches on launchpad that are causing many errors right now
[22:22] <thumper> jelmer: and both are bzr-svn branches
[22:22] <thumper> jelmer: one is yours, and one is a friends
[22:22] <thumper> jelmer: LP is failing to scan them properly as it is failing some basic integrity checks on revisions
[22:22] <thumper> jelmer: one thing we do is to check the revisions to make sure that the parentage hasn't changed
[22:23] <thumper> jelmer: but for these two branches it appears that between scans, the parents of some revisions did change
[22:23] <thumper> jelmer: I was under the impression that bzr revisions didn't change once they were created
[22:23] <jelmer> thumper, that's correct
[22:23] <thumper> s/didn't/shouldn't/ ?
[22:23] <jelmer> which branches are these?
[22:24] <thumper> https://code.launchpad.net/~jelmer/python/trunk is one
[22:24] <thumper> RevisionModifiedError: parent svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:55872 was added since last scan
[22:24] <thumper> jelmer: that is the error I am seeing
[22:25] <jelmer> to which revision was that parent added?
[22:26] <thumper> jelmer: unfortunately I don't think I have that information easily to hand
[22:26] <thumper> jelmer: what can I provide in order to help track this down?
[22:26] <jelmer> thumper: details about which revision apparently changed parents
[22:26] <thumper> ok
[22:26] <thumper> is that all?
[22:27] <jelmer> thumper: Also, is this integrity checking done across branches?
[22:27] <thumper> jelmer: yes
[22:27] <thumper> that may be the underlying problem
[22:27] <thumper> we store a copy of the revisions in the database
[22:27] <jelmer> in that case it's probably that one of the branches was created using an experimental version of bzr-svn
[22:27] <thumper> which includes parentage
[22:28] <thumper> hmm...
[22:28] <thumper> this is an interesting problem to solve then
[22:29] <jelmer> thumper: I think one of the branches just has to be thrashed
[22:29] <thumper> jelmer: is there any way to determine which branch is the one created with the experimental bzr-svn?
[22:30] <jelmer> well, recreating that branch using a stable version of bzr-svn
[22:31] <thumper> jelmer: ok, thanks
[22:41] <xif> How, and how well, does bzr support the following development process:
[22:41] <xif> The project has the following root directories: /linux, /osx, and /osx-diffs. Each time a developer commits /linux/foo.conf, the SCM applies the /osx-diffs/foo.conf.diff to it, and then commits it /osx/foo.conf.
[22:41] <xif> (commits it as the file /osx/foo.conf)
[22:43] <thumper> xif: sounds like a candidate for looms
[22:43] <thumper> xif: as long as you didn't have bidirectional diff application
[22:44] <thumper> xif: you could have /linux as the base thread
[22:44] <thumper> xif: and /osx os the next thread
[22:44] <thumper> xif: and the difference between them is effectively the /osx-diffs
[22:45] <thumper> xif: there is an export-loom command that can create branches for each thread
[22:45] <xif> thumper: very cool... I'm looking at this right now
[22:45] <thumper> xif: you would commit on /linux
[22:45] <thumper> xif: then switch up to /osx
[22:45] <thumper> xif: and merge, resolve and commit
[22:45] <thumper> at least that is how I think it would work
[22:46] <xif> yeah, it definitely looks interesting...
[22:46] <xif> I'm reading about it right now: http://blogs.gnome.org/jamesh/2008/04/01/bzr-loom/
[22:46] <xif> thumper: thanks for the recommendation :)
[22:46] <thumper> xif: np
[23:13] <Peng> Wouldn't branches work too?
[23:28] <xif> Peng: how, exactly?
[23:32] <Peng> I dunno.
[23:32] <Peng> I have very little experience with looms, but how are looms better than branches for this? Avoiding lots of merge revisions?
[23:36] <awilkins> I have a feeling I should have used looms for one of my projects after reading that page
[23:37] <awilkins> My example is patches to a set of model files (written as Java) ; one set of patches that was compatible with the old model, one that was for the new software and wasn't
[23:37] <awilkins> I was managing that as two branches ; and I was making compatible changes in one branch and merging up to the other, but it sounds like I should have made a loom and had a compatible thread and an incompatible thread
[23:38] <awilkins> It would at least have beem more conveneient
[23:38]  * awilkins is tired and his fingers are slipping
[23:40] <awilkins> I still don't think it easily addresses what to do when you are making changes and one part of them should be in a thread lower than you are on... I think you might have to shelve the bits that go in the higher thread, jump down a thread, commit, jump up adnd unshelve and commit
[23:41] <awilkins> Anyhow, gnight.
[23:59] <igc> morning