[00:30] w00t, got "bzr builddeb " working :-) [03:12] 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] have a seperate branch [03:13] although then you can only merge one way [03:16] oh, so just merge branches whenever I make a change? [03:16] but that will merge the config.php's (and probably have a merge conflict), because they are different, correct? [03:20] alecwh: alternatively, you may just want to include a file "local-config.php" from your config.php that isn't versioned [03:21] perhaps only if it exists, and set "$installed = 'yes'" if it doesn't [03:22] jelmer: good idea actually... but if bzr doesn't recognize it, then it won't be uploaded with the repository. [03:22] alecwh: yes, but you would be the only one who would have to have that file [03:23] users who wouldn't have it would just get the default configuration [03:23] oh okay. I'll try that out, thanks jelmer. [03:23] =) [03:23] wait - what does bzr ignore do? [03:23] stop bzr status complaining about files being unknown and 'bzr add .' from adding them [03:29] oh, ok. [03:30] (you can still add them by giving their specific name) [03:51] 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] cspam === mwhudson_ is now known as mwhudson [06:25] 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] you're using the bzr cia thing? [06:59] 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] s/when for/for [08:38] my xdg_email is empty...anyone use Gnus with bzr? [09:03] gour: I use bzr and I use Gnus, what is your question :) [09:04] I don't even have a xdg_mail [09:05] 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] gour: I said ^ a few days ago, did you read it ? [09:06] thanks [09:06] vila: no, i missed it [09:07] gour: hmm, yeah, re-reading logs, you left just before I posted it :) Sorry, I missed that detail :-/ [09:08] ta [09:08] gour: what exactly means 'ta' [09:09] I understand the 't' is for thanks but the 'a' ? [09:10] 'alot' [09:10] "ta" is just a short way to say "thanks". [09:10] :-) [09:10] spiv: hi ! [09:11] vila: good evening [09:11] I'm looking at bug #230223, but I feel out of my league :-/ [09:11] Launchpad bug 230223 in bzr "smart server probing in 1.4 breaks check outs of short bus http repositories [regression]" [High,Confirmed] https://launchpad.net/bugs/230223 [09:12] vila: sorry, I'm just passing through... [09:12] my understanding so far is that smart server probing is not prepared to receive a 403 [09:12] spiv: ok, no worries [09:12] * spiv -> dinner [11:39] 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] when i try to do bzr info at the launchpad branch i get "Standalone branch (format: unnamed)". What am I doing wrong? === brilliantnut is now known as brilliantout [12:00] alefteris: for the launchpad branch you need to upgrade using sftp; that should work [12:07] lifeless, thanks, I had to install paramiko as well and all went fine :) [12:37] nekohayo, please file a bug report [12:46] jelmer: bzr pull from bzr-svn - is it mainly slow cause of bzr ? [12:47] lifeless: yes [12:49] 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] lifeless, are you doing a pull that appears to be too slow? [12:52] did the bzr-gtk trunk get rebased? [12:53] bob2 [12:53] no [12:57] jelmer: I was showing ted gould from inkscape [12:57] jelmer: and it was doing a revision every 30-40 seconds ot so [12:57] which is rather appalling :P [12:58] oh, bah, ~bzr/bzr-gtk got killed 6 months ago and I didn't notice [12:58] lifeless: Wow, ok. Worst I've seen is once every couple of seconds [12:59] lifeless: Any idea what is being so slow? [13:01] lifeless, are you trying this with a local svn repository? [13:02] sourceforge can be really slow sometimes [13:05] lifeless: I'm just trying it as well now, and it's taking 2 seconds to reply to each request [13:06] lifeless: so, when are shallow branches going to land ? :-P [13:18] jelmer: argh, 2 second latency on the server is explainable :) [13:19] jelmer: could we show that in thhe ui/log file somehow ? [13:19] lifeless: we are, but the progress bar is sometimes hidden for some unexplainable reason [13:20] there are progress bars being displayed from inside bzr-svn [13:20] s/displayed/created [13:20] zr: ERROR: No such file: 'http://bazaar-vcs.org/bzr/bzr.dev/.bzr/repository/indices/b072a80d0242839227870cba3a3e0f9b.rix' [13:20] repo moved? [13:22] hsn_: probably a push going through at the time you were reading [13:22] hsn_: just try again [13:23] hsn_: there is a bug open - this is something we should retry on [13:29] lifeless: it works now [13:56] lifeless: inkscape isn't exactly fast here either; does about one revision every two or three seconds [13:57] lifeless: seriously though - what's still left for shallwo branches? [13:58] jelmer: thats faster than we were seeing [13:58] jelmer: well the prototype branch is there for testing; you should be able to do bzr-svn work for it now [13:58] jelmer: I'm working on optimisations now - inpartcular exposing historic texts on all repositories [14:00] lifeless: where's the branch? [14:11] jelmer: mumbke shallow-branch or somthing [14:11] 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] its in that list :) [14:12] * jelmer wished he could do "lp list-branches bzr | grep shallow" [14:17] 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] jelmer: hopefully the external API is done [14:21] I would like it if you worked with me on a beta-bzr-svn branch to use it [14:22] jelmer: that would be better than waiting for me to be 'done' and then findingout its missing/bad for you [14:22] jelmer: just don't offer it to 'users'. [14:28] 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] and having to maintain a bzr-svn branch through API changes and months of bzr releases [14:31] 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] acuster: What specifically? [14:31] it bit me enough that I'm being pushed towards mercurial but I suspect bzr handles svn copy better than hg [14:32] 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] so I gather I deeply misunderstood how bzr and svn go together [14:33] so specifically [14:33] that and it are vague [14:33] I'd like a recepie possibly with why [14:34] jelmer: I would help maintain such a branch [14:34] jelmer: work goes >> when many hands [14:34] acuster: I updated the FAQ [14:34] thanks [14:35] lifeless: Thanks, that'd help [14:35] I'll try to get a better grip on my question when I can use 1.5 on this hardy [14:42] jelmer: have you seen my status mails ? [15:03] lifeless: no, I haven't - a quick search for "shallow" in my bzr mailbox doesn't list anything [15:04] lifeless: also, the only "shallow" branch from you on launchpad is 11 weeks was last changed in february [15:04] it's on p.u.c [15:06] http://people.ubuntu.com/~robertc/baz2.0/shallow-branch/ ? that's the one that hasn't hcanged since feb [15:07] 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] nekohayo: the branches probably have different file ids [15:09] jelmer: well, I assume so, they were different branches... what do I do? [15:10] 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] so it's not really possible to use rebase/replay in this case [15:11] >_ I don't exactly see what's so unusual with my case :| [15:12] different file ids [15:17] jelmer: what is a fileid actually? and how could branches that were not historically connected ever have matching file ids? [15:17] nekohayo: a file id is a unique string that identifies a file. It's generated when it is first added to bzr [15:17] nekohayo: there's no way for historically not connected branches to have the same file ids [15:19] so there's no way to go further now? solving the conflicts wouldn't do it? [15:20] 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] basically recommitting everything by hand [15:22] yes [15:22] I'm not aware of any bzr plugins at that can do that for you [15:23] rebase/replay could do it if you hooked up the maptree stuff [15:23] how hard is that? [15:25] should be a matter of adding a call to MapTree() in the function that replays a delta in rebase [15:26] jelmer: yes, thats right - I've been working on 'VersionedFiles' the consolidation of knits etc [15:26] 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] rebase.py:410:def replay_delta_workingtree(wt, oldrevid, newrevid, newparents, [15:31] jelmer: I see that there is a file bzr-rebase/site-packages/bzrlib/plugins/rebase/test_maptree.py [15:32] but I don't understand it [15:32] nekohayo: you'd need the code in maptree.py [15:34] and wrap the other tree specified to merge in replay_delta_workingtree() with MapTree() [15:40] x_x beyond my skillset I guess [15:40] or is there a bug/blueprint I can subscribe to for rebase to support maptree? [15:41] no, though you could file one [15:54] Hi [15:54] nekohayo, jelmer: maybe using fastexport/fastimport to replay the commit? [15:54] s/commit/commits/ [15:55] jelmer: so look for those mails :) [15:56] vila: isn't your new POST bug a dupe? [15:57] lifeless: I was unsure and wanted a reference to put in my merge request for #230223 [15:57] lifeless: bug #231649 is for the *test* servers [15:57] Launchpad bug 231649 in bzr "http test server can't handle POST" [Undecided,Confirmed] https://launchpad.net/bugs/231649 [15:58] vila: anyhow, do you have time to look at http vs sftp pull performance? [15:59] ghaaa, still trying to clean up my plate, I think I shoudl decline :-/ [16:00] I really really really want to write that use-a-real-server-for-tests plugin now [16:01] lifeless: wait a minute, what are you talking about ? http vs sftp ? Care to help me page in ? [16:04] vila: couple days ago [16:04] vila: kinnison was saying 'pull never utilises full bandwidth' [16:04] vila: I said 'try sftp'; he did and it maxed his link out [16:05] vila: he had been pulling over http [16:09] 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] trying. [16:15] branch uses full bandwidth AFAICS, or not ? Seems like many pack files are involved. [16:16] sftp doing asynchronous IO thanks to paramiko may explain a bit of difference [16:17] jelmer: think that could work? [16:18] nekohayo, not familiar enough with fastexport/fastimport [16:18] Verterok: never tried them, any pointers how to go about it? [16:19] 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] lifeless, any chance you can merge bzr.dev in your shallow branch branch? [16:19] nekohayo: I'm not an expert, but played a bit with it :) [16:20] nekohayo: first do an fastexport of the branch, then you can write your own processor to filter whatever you need to [16:21] and do a fastimport, using the your custom proccessor [16:27] jelmer: I will, once I have all tests passing with no repository._revision_store [16:27] jelmer: e.g. probably tomorrow [16:27] lifeless, ok [17:08] lifeless: bzr: ERROR: Not a branch: "sftp://vila@bazaar.launchpad.net/~bzr/bzr/trunk/ ??? [17:09] are you a member of the bzr group? [17:10] bob2: I hope so :) [17:11] hehe [17:24] vila: ? [17:25] lifeless: shouldn't there be a branch there ? [17:25] interesting [17:26] vila: no [17:26] vila: its not hosted on launchpad [17:26] vila: its mirrored there only [17:26] simple, clear. Thanks lifeless :) === emgent is now known as emgent`UDS === emgent`UDS is now known as emgent [18:05] 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] vila: I worked on that with jml. It was rather tricky because the sftp server is twisted, and bzr+ssh is synchronous. [18:09] 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] s/cot/to/ [18:12] 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] bzr+ssh gives access to both, preferring hosted. [18:14] abentley: thks. [18:15] np [18:22] 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] vila, I think code.lp is used for the web app, and bazaar.lp is for actual branches [18:24] morning :) [18:24] beuno: hi :) === brilliantout is now known as brilliantnut [18:49] !paste [18:49] pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) [19:00] see you all tomorrow === weigon_ is now known as weigon === emgent is now known as emgent`UDS === emgent`UDS is now known as emgent === mwhudson_ is now known as mwhudson [21:24] hey guys, getting this error, what can i do to fix it? ->bzr: ERROR: Unsupported protocol for url "sftp:///trunk": Unable to import paramiko (required for sftp support): No module named paramiko" [21:24] beuno: damn loggerhead -- i bounced it [21:24] MachinShin, install paramiko [21:30] thanks jelmer [21:50] 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] Maybe they used bzr for source control when programming the LCARS system? [22:21] morning [22:21] jelmer: are you available for a few questions? [22:21] thumper, hi [22:21] thumper, sure [22:22] jelmer: There are two branches on launchpad that are causing many errors right now [22:22] jelmer: and both are bzr-svn branches [22:22] jelmer: one is yours, and one is a friends [22:22] jelmer: LP is failing to scan them properly as it is failing some basic integrity checks on revisions [22:22] jelmer: one thing we do is to check the revisions to make sure that the parentage hasn't changed [22:23] jelmer: but for these two branches it appears that between scans, the parents of some revisions did change [22:23] jelmer: I was under the impression that bzr revisions didn't change once they were created [22:23] thumper, that's correct [22:23] s/didn't/shouldn't/ ? [22:23] which branches are these? [22:24] https://code.launchpad.net/~jelmer/python/trunk is one [22:24] RevisionModifiedError: parent svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:55872 was added since last scan [22:24] jelmer: that is the error I am seeing [22:25] to which revision was that parent added? [22:26] jelmer: unfortunately I don't think I have that information easily to hand [22:26] jelmer: what can I provide in order to help track this down? [22:26] thumper: details about which revision apparently changed parents [22:26] ok [22:26] is that all? [22:27] thumper: Also, is this integrity checking done across branches? [22:27] jelmer: yes [22:27] that may be the underlying problem [22:27] we store a copy of the revisions in the database [22:27] in that case it's probably that one of the branches was created using an experimental version of bzr-svn [22:27] which includes parentage [22:28] hmm... [22:28] this is an interesting problem to solve then [22:29] thumper: I think one of the branches just has to be thrashed [22:29] jelmer: is there any way to determine which branch is the one created with the experimental bzr-svn? [22:30] well, recreating that branch using a stable version of bzr-svn [22:31] jelmer: ok, thanks [22:41] How, and how well, does bzr support the following development process: [22:41] 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] (commits it as the file /osx/foo.conf) [22:43] xif: sounds like a candidate for looms [22:43] xif: as long as you didn't have bidirectional diff application [22:44] xif: you could have /linux as the base thread [22:44] xif: and /osx os the next thread [22:44] xif: and the difference between them is effectively the /osx-diffs [22:45] xif: there is an export-loom command that can create branches for each thread [22:45] thumper: very cool... I'm looking at this right now [22:45] xif: you would commit on /linux [22:45] xif: then switch up to /osx [22:45] xif: and merge, resolve and commit [22:45] at least that is how I think it would work [22:46] yeah, it definitely looks interesting... [22:46] I'm reading about it right now: http://blogs.gnome.org/jamesh/2008/04/01/bzr-loom/ [22:46] thumper: thanks for the recommendation :) [22:46] xif: np [23:13] Wouldn't branches work too? [23:28] Peng: how, exactly? [23:32] I dunno. [23:32] I have very little experience with looms, but how are looms better than branches for this? Avoiding lots of merge revisions? [23:36] I have a feeling I should have used looms for one of my projects after reading that page [23:37] 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] 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] It would at least have beem more conveneient [23:38] * awilkins is tired and his fingers are slipping [23:40] 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] Anyhow, gnight. [23:59] morning