[00:11] good morning spiv, igc, lifeless [00:11] jam, are you still around? [00:14] * Peng_ goes insane. [00:17] Peng_: goes? [00:22] mwhudson: Good point. But now I'm even less sane! [00:23] isn't sanity just a one-trick pony anyway [00:23] Loggerhead is refusing to serve one branch over http. :\ [00:24] Which is kind of annoying when I wanted to use that branch to *test* serving over HTTP. :P [00:24] did bzr push --fixes disappear? [00:24] fullermd: what do you mean by "inability to upgrade from dev formats"? [00:25] Good morning. [00:25] Laney: --fixes is an option on commit, not push. [00:25] Peng_: oh right, tahnks [00:25] thanks [00:32] poolie: % bzr init --development6-rich-root x ; bzr upgrade --development7-rich-root x [00:32] For any permutation of dev6, dev7, 2a in the init/upgrade. [00:32] bzr: ERROR: Cannot convert to format . Does not support nested trees [00:34] I don't know of a filed bug on it. It's come up here and on the ML a few times; I was under the impression that somebody was working on it. [00:34] jelmer, maybe. [00:35] could you search or file one please? [00:36] poolie, fullermd: i think that bug is fixed in bzr.dev, from things i overheard [00:36] Well, the error I just posted is from trying it on my up-to-date bzr.dev... [00:37] (well, OK, I'm missing jam's win32 packaging fix, but I'm guessing that doesn't solve it ;) [00:37] the upgrade bug? [00:37] mwhudson: ping [00:37] Peng_: hi [00:37] mwhudson: Is it just me, or is Loggerhead serving .bzr over HTTP broken? [00:37] Peng_: no idea [00:38] * mwhudson tries [00:38] bzr+http works (I just landed that), but regular old nosmart+http does not. [00:38] Well, nothing in my =bazaar-bugs is jumping out at me, so I guess there isn't one filed... [00:39] Peng_: jelmer said something about the smart server support only working for standalone repositories, i think? [00:39] standalone branches, sigh [00:39] mwhudson: Yeah, thanks to bug #348308, but my issue is HTTP. [00:39] Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308 [00:40] It should be possible for Loggerhead to monkeypatch around that bug, but it's probably a bad idea. [00:40] Peng_: yes, seems .bzr requests are 404ing [00:40] mwhudson: Thanks for confirming it. [00:41] you know what would make loggerhead better? [00:41] tests [00:42] I manually test several different things, but I never run the test suite. :P [00:43] Peng_: [00:43] Invalid url supplied to transport: "readonly+file:///home/mwh/canonical/repos/loggerhead/": local urls must start with file:/// [00:43] lalala [00:43] I was just going to say: NotBranchError: Not a branch: "readonly+file:///trunk/.bzr/branch-format/". === afk is now known as mthaddon [00:44] It's also kinda annoying how upgrade moves everything into backup locations BEFORE blowing up in that case... [00:45] bug 388727 [00:45] Launchpad bug 388727 in bzr "upgrade fails between dev formats" [High,Confirmed] https://launchpad.net/bugs/388727 [00:46] mwhudson: Looks like both get_local_path and check_is_a_branch fail, in different ways. I'll file a bug. === afk is now known as mthaddon [00:53] morning === igc1 is now known as igc [00:54] hello igc [00:54] morning poolie [00:55] * Peng_ goes /away to eat. [01:08] Hi poolie. [01:08] poolie: create_by_apply_delta is only available in CHKInventory [01:09] garyvdm: You can also use Repository.add_inventory_by_delta() [01:10] garyvdm: which works on all repositories [01:10] * garyvdm look [01:10] Hi jelmer [01:10] hi Gary [01:10] I ran into the same problem trying to find what function to use for bzr-svn/bzr-git [01:11] jelmer: I want to create a in memory inventory. [01:12] jelmer: won't Repository.add_inventory_by_delta add an inventory to the repository? [01:12] garyvdm: yeah, it'll write out to disk [01:12] i.e. write it to disk? [01:12] garyvdm: You can steal some of its logic though [01:12] garyvdm: which it uses to apply deltas to non-CHKInventory's [01:13] * garyvdm looks :-) [01:16] There's Inventory.apply_delta - I need to test if that just changes the inventory in memory, or to disk. [01:16] garyvdm: it changes in memory [01:17] jelmer: even WorkingTree.inventory? [01:17] garyvdm: yeah, but you'd probably don't want to change that directly since WorkingTree would just return its own copy [01:18] garyvdm: WorkingTree.inventory.apply_delta() will not directly write out to disk, but will probably cause strnage behaviour [01:18] jelmer: is there a way to create my own copy of the inventory? [01:18] garyvdm: you can make an in-memory copy of WorkingTree.inventory though, and apply the delta to that [01:18] garyvdm: in general no. [01:18] garyvdm: you shouldn't be working with Inventory [01:19] s/working with/mutating or modifying/ [01:19] lifeless: Hi [01:19] the only objects that should modify inventories are implementations of Repository or Tree [01:19] ...I just pulled down 1 revision of bzr.dev. It took 100 seconds, nearly all of which was bzr-search indexing. o_O [01:19] lifeless: even a in-memory copy? [01:19] Sorry, _two_ revisions of bzr.dev. [01:20] garyvdm: an in memory copy of a working tree inventory is shared with the tree and will be saved when write lock is released [01:20] garyvdm: it is the trees /internal/ state [01:20] garyvdm: so no, you should *never* modify an inventory unless your code is part of the implementationof the appropriate Tree or Repository subclasss. [01:21] ...Wait a minute, why did Loggerhead work? Shouldn't the ProgressBarStack thing have broken it? [01:21] lifeless: Is there not a way to create a copy that does not affect the internal state? [01:22] garyvdm: there is but its slow and expensive [01:23] garyvdm: and as previously noted Inventory can't represent the concepts you want like unversioned or ignored files. [01:23] lifeless: ok. [01:23] lifeless: btw - I was wrong about iter_changes returning ignored files. It does. [01:24] :) [01:24] That makes things easier for me :-) [01:27] jml: perhaps this channel works for you?... [01:27] lifeless: would it be safe to set a new instance var on a inventory item? e.g. tree.inventory[fileid].status = "modified" [01:29] they use slots; it won't work. [01:29] ok [01:33] jelmer: what does alioth need [01:33] jelmer: in more precise terms than 'another config file' [01:38] jml, as you probably saw, there are some new bugs targeted to 1.16 [01:47] Pulling another revision of bzr.dev took 45 seconds. Again, almost all bzr-search. :\ [01:48] Are bzr.dev's search indices supposed to be 61 MB? [01:48] indexing is hard [01:49] 18 MB is just from the last 2 days. [01:49] lifeless: ping ^ [01:50] Peng_: yes [01:51] Peng_: can it be shrunk? yes. There are several things that can be done. The index contents can be revisited now we have faster facilities for 'what path is this fileid.revisionid at'. [01:51] We got to bit indices rather than int indices [01:51] we can filter extremely common terms[though this is not necessarily a win] [01:52] I don't really mind the index size. What I mind is that 1/3 of it is from the last 2 days, and indexing during pull is taking 40-45 seconds per revision of bzr.dev. [01:52] Maybe it autopacked? [01:52] Peng_: so it autopacks [01:53] I really doubt that 1/3 is new from 2 days of changes [01:53] further, indexing requires extracting much data and we're not in bbc yet. [01:53] Yeah, you're right. I just checked the obsolete directory. ~4.3 MB from the last week. [01:54] No crisis, then, I guess. :) [01:56] * Peng_ /away! [02:04] do we have a way yet to say "Don't stack" even if the remote server suggests a branch to stack on? [02:04] no [02:04] arse [02:05] not exactly a common use casse [02:05] if the server is misconfigured, fix it :) [02:05] the server isn't misconfigured [02:05] sometimes we want to say this [02:05] sure; like I said its not _common_. [02:10] lifeless: somethin that can run as a system service basically [02:10] jelmer: BZR_HOME=/etc/bazaar [02:11] lifeless: something sustainable, not a quick hack [02:11] jelmer: that is sustainable [02:13] lifeless: at the very least it would be nice if that was more easily accessible, e.g. serve-branches --config=foo would do BZR_HOME=foo under the covers [02:13] jelmer: that would be problematic for me [02:13] because it makes BZR_HOME=foo server-branches --config=foo less clear [02:14] lifeless: also, it's a bit redundant to have every variable in a configuration file prefixed with "http_" [02:16] jelmer: that seems unnecessary and likely inaccurate - public_url's etc should be from the stock bzr information [02:17] lifeless: loggerhead prefixes all its variables with http_ in ~/.bazaar/bazaar.conf at the moment [02:19] lifeless: this specifically is about those variables, not about whatever would usually live in .bzr/branch/branch.conf [02:20] jelmer: well, up to beuno etc. I don't think a specific config file is a good idea though. [02:20] Because using the stock stuff lets you use locations.conf to configure different loggerhead servers [02:20] and if a global config is needed, well there is a bug open on bzr to support /etc configuration already. [02:20] lifeless: I don't see how locations.conf is related here, this isn't about branch-specific settings [02:21] I definitely think BZR_HOME will work reliably for alioth [02:23] poolie, yeah, I haven't had a chance to look at them yet today, but I will [02:24] jml: testresources: review requested. [02:24] poolie, I haven't had a chance to do anything other than _react_ [02:24] lifeless, yeah, I saw the email and flagged it for answer. [02:24] with luck & a spare energon cube I'll get it done tonight. [02:26] all jml, you don't need to look at them now, just making you aware [02:27] poolie, cool :) [02:27] lifeless: alioth wants a backport package with init script etc they can use, but I'd like to see loggerhead settle on something first so I don't have to worry about providing an upgrade path in two months [02:27] I see a lot of conversations in Git projects (cairo being the present instance) saying things like "rebase your work to current master" as a long lived branch gets closer to being considered for acceptance into the project. [02:28] Isn't that just "hey, merge current 'mainline' into your branch, please"? Followed by healthy use of things like `bzr diff -r ancestor:....../mainline` ? [02:29] jelmer: I don't see why BZR_HOME would stop working. [02:29] AfC: in bzr we would just merge yes. because that preserves prior testing etc. [02:30] lifeless: (not to mention not creating new revisions that say exactly the same thing). Ok, that's what I thought. [02:30] AfC: rebasing deletes test results :). If it wasn't long lived, and would just a short lived private branch rebase would matter a lot less. [02:31] lifeless: is it because of their "I want to see individual patches building towards a result which are the only thing I'm [to be] looking at" culture? [02:31] yes [02:31] hm [02:31] which is the history presentation aspect of the RFC I put together [02:32] and it *is* easier to review a series of small patches than a single monolith [02:32] So, while I'm over that, I do wonder what on earth we can do to make Bazaar acceptable to that desired workflow [without needing rebase] [02:32] lifeless: granted [02:32] looms [02:32] hm. Yeah, I guess [02:32] thats what they are designed for [02:32] ah [02:32] implementation bugs and polish aside [02:33] I do think we need rebase as a core polished utility [02:33] but we need to have versioned versions of the same tools for when people are collaborating [02:34] lifeless: so taking a slightly different gloss on this, if individual patch or revision {1,more} cherry picking worked in some way that explicitly and strongly said "this «new» revision came from and essentially is _that_ revision" [02:34] lifeless: then rebasing (hypothetically using that) would be a lot less evil to us. [02:34] s/us/our viewpoint/ [02:34] [right?] [02:36] I realize that "what tree state did you test" is very important... but if we can have a dotted line between "what I'm merging" and "what actually was tested by its author" maybe things would be ok [02:36] dunno [02:36] AfC: I think such cherrypicking would be necessary but not sufficient [02:36] merge is the key [02:36] [I do know that I don't think I'm going to be able to work on any Git based projects ... the DVCS culture I've been taught here is too different from what goes on there] [02:37] lifeless: (well, cherrypick as in `bzr merge ../other_branch/.../filename` [02:37] cherrypick is another brutal overload around here [02:37] AfC: merging *after* the cherrypick for people that had merged the original revision [02:37] up there with history editing ^W commit message fixing [02:37] lifeless: If loggerhead started reading settings from some other file, I wouldn't necessarily expect it to also check http_* in BZR_HOME/bazaar.conf [02:37] mwhudson: ^ can you reassure jelmer [02:37] lifeless: yeah, after [02:38] lifeless: that really is the key, isn't it [02:38] its easy to cherrypick [02:38] its relatively easy to record that you did [02:38] lifeless: this hasn't been my work, i have no real opinions [02:38] lifeless: (I would be impressed if I didn't have to because the tool & it's UIs did said recording for me) [02:38] lifeless: Or to put it in a different way, I wouldn't expect apache to read settings from /root/.apache.conf either by default [02:38] its still freaking-hard to merge the cherrypicked thing accurately without security issues or spurious conflicts [02:39] though i prefer reading http_* options from a bazaar.conf to inventing our own formats and locations [02:39] lifeless: and not have an easily disocverable way to override that [02:39] mwhudson: has there been a release of loggerhead that does [02:39] lifeless: so I gather. [02:39] lifeless: no [02:39] Right. Lunch time rush at this cafe. Time to move. [02:39] * mwhudson is not paying attention here any more, sorry [02:40] send me email if you want a conversation on this [02:50] When pulling, what happens after post_change_branch_tip hooks fire? In other words, if the hook throws an exception, what didn't happen? E.g., it looks like the branch updated correctly, but not the working tree. [02:50] * Peng_ randomly goes /away again. [02:51] right [02:51] update to recover [03:10] if I clone a branch, and that branch is updated after I did a few commits on the clone, what should I do to merge the clone with that branch? [03:12] RenatoSilva: Clone? did you do a checkout, or branch? [03:16] RenatoSilva: if you create a checkout, you can do bzr update. If you did a branch, you can do bzr merge. [03:16] by clone I mean bzr branch [03:19] RenatoSilva: you can bzr pull, if no changes were made to the origin branch in the interim, or you can (bzr merge; bzr commit) [03:19] imagine the original branch is at rev 40, then I copy it and commit 5 revisions (my local branch is now rev 45), but in the meatimeremote branch was updated and is now in rev 43. A merge between the branches woulnd't get confused? [03:19] not at all [03:20] its what bzr merge is meant to be used for [03:20] yeah I can do a bzr pull, but what happens if I don't? [03:20] bzr merge will pull the changes before merging? [03:21] You can't do bzr pull (try it), it will tell you it's can't pull because the branches have diverged. [03:22] So you need to bzr merge, because you changes to merge. It won't get confused, because bzr is not CVS :) [03:22] lol [03:22] s/you changes/you have changes/ [03:27] spiv: ok [03:56] * igc lunch and medical appointment - bbl [04:00] can multiple tags point to the same version? [04:05] yes. technically to a revisionid === timchen1` is now known as nasloc__ [04:11] lifeless: how come item.revision for a item from a WorkingTree.inventory is allways none? [04:12] Could it not tell you the revision from the basis tree? [04:19] jml: I'm working on https://bugs.edge.launchpad.net/bzr/+bug/388675, do you want this fix in 1.16? [04:19] Launchpad bug 388675 in bzr "automatic stacking format upgrade doesn't work over the smart server" [High,In progress] [04:19] jml: I have the issue diagnosed and a quick fix, just making proper patch with tests etc now. [04:24] I typed "bzr branch lp:oah/gst-plugins-base", it starts to download, but it only download a directory containing ".bzr", nothing else. Where is the code? [04:28] garyvdm: the working inventory doesn't have that data [04:28] :-( [04:28] I'll just have to hide the revision columns when showing the wt. [04:28] garyvdm: the basis inventory does (but we're looking at getting rid of most of the basis inventory stored in the tree because we don't need to look at it very often, its largely dead weight) [04:29] [###########/ ] http > 2638KB 3KB/s | Copying content texts:Copied [04:29] It looks like it have download a lot things [04:29] ablmf1: it's building a local bzzr branch. Once it has the history it will build the working tree [04:31] lifeless: Should I wait till all the progress bar reach the end [04:31] or should I give up now? [04:31] ablmf1: wait [04:32] ablmf1: its all working normally [04:32] ablmf1: Why do you want to give up? [04:33] Peng_ : because it has been downloading for 20 m but only give me a .bzr ... Quite slow to access lp from here [04:35] ablmf1: it *only* does a .bzr until right at the very end [04:35] ablmf1: thats normal. [04:35] ablmf1: the .blz contains the whole history [04:35] Hmm, that branch is like 25-30 MB. [04:35] s/blz/.bzr [04:36] Is there any quicker way? [04:36] ablmf1: if you're using http, you probably have a broken http proxy, based on the discussion from yesterday. [04:37] lifeless: No. I am the one discussing proxy with you yesterday. [04:37] Toady I stayed at home for downloading the source code I need [04:37] ablmf1: do you mean yes? [04:37] oh, ok. [04:37] so anyhow [04:38] over http bzr has to do many readv operations [04:38] it shouldn't be *that* slow [04:39] svn has a "svn export" command which do not download the history [04:39] does bzr have one? [04:39] It would be nice to download branches as zip files [04:39] RenatoSilva: loggerhead can do that; its just not enabled on launchpads logerhead [04:39] ablmf1: bzr has one, but it works by downloading the history [04:39] lifeless: good to know [04:40] ablmf1: (svn doesn't download history *ever* anyway, svn export isn't as different as you might think) [04:40] Well, I just merged a directive to a branch, and it opened a file with the commit messages of the patch now that I'm trying to commit the directive changes [04:41] -- This line and the following will be ignored --, what should I do? The command is waiting for the text editor. [04:41] You should type in a commit message above the line [04:41] whatever you want to say about the merge. [04:41] was this caused by an empty bzr commit as I did? [04:42] no [04:42] its normal [04:42] if I did, it would be 2 commit messages then? [04:42] if I put a message I mean [04:43] [04:43] i messed up, but i dont know how much damage i caused [04:43] [###########\ ] http > 6861KB 6KB/s | Copying content texts:Copied [04:43] i have a server with a shared repo with a bunch of related branches in it [04:43] It looks like it has download 6MB [04:44] But I only find 200kb in the working directory [04:44] on a development machine i have another shared repo with copies of those "central" branches, plus a bunch of local branches branched from them [04:44] my mistake was: [04:45] i accidentally pushed one of the development branches from the devel machine to the *repo* dir on the central server without specifying a target branch dir [04:45] RenatoSilva: huh? You'll only get one commit message. [04:45] RenatoSilva: I don't really understand what you're asking. [04:46] ablmf1: you could try stracing the process to see what is happening [04:46] ablmf1: as for how much is in the working directory, there are buffers on whats written to disk and so on; I assure you if you let it finish it will have achieved what you want. [04:47] lifeless: bzr commit -m "message 1", then shows text file, then I type in the file "message 2" [04:47] RenatoSilva: You may find it easier to use bzr qcommit - This shows a gui for commit [04:47] garage_seb: I don't think that should break anything. Has it? [04:48] lifeless: the merge will contain all directive commits? Is it smart enough? [04:48] RenatoSilva: it should not have popped up an editor if you used -m [04:48] lifeless: oh, so...was this caused by an empty bzr commit as I did? [04:48] lifeless: the answer is yes [04:49] you had said no and I get confused :) [04:49] empty can mean 'no message' or 'no changes', I thought you meant the latter. [04:49] lifeless: ok sorry, my mistake then :) [04:49] it all makes sense now :) [04:49] cool [04:50] btw, it will never allow empty message? [04:50] I don't think so [04:50] bzr: ERROR: empty commit message specified [04:50] after I just closed the file [04:51] thats right [04:51] if you're doing a merge [04:51] write a message describing what you are merging. You can skip the details as they will still be present in the commits you are merging. [04:51] ok, then it will deny only for merges [04:51] ablmf1: also, there's some overhead in figuring out what content to transfer before it actually transfers the content. [04:52] ablmf1: especially over a dumb transport like http [04:52] ablmf1: so you may well find that the final size on disk is noticeably smaller than the total network traffic. [04:53] spiv: with readv batching it should be 1-2% no more [04:53] for an initial branch [04:54] lifeless, poolie, jelmer: Thanks for the advice. I have achieved what I wanted to (a browse tree widget, that shows unversioned files and change status) [04:54] I think as they're little changes, it makes more sense to aplly them manually, because I just have to reason to give a bout the merge. The reason is just because they were 2 commits at work, and I couldn't push them there :) [04:54] RenatoSilva: if you haven't made local changes you can just pull from the directive [04:54] s/to reason/no reason [04:54] rather than merging [04:54] humm, nice! [04:55] lifeless, poolie, jelmer: If you are intrested in what I have done, the code it here: http://bazaar.launchpad.net/~garyvdm/qbzr/trees/annotate/head:/lib/treewidget.py [04:55] how do I undo the merge? [04:55] bzr revert? [04:55] RenatoSilva: yes [04:55] 'bzr revert' [04:55] ok [04:59] bzr: ERROR: These branches have diverged. Use the missing command to see how. Use the merge command to reconcile them. [04:59] so you do need to merge [04:59] bzr missing > Using saved parent location: bzr+ssh://bazaar.launchpad.net/~renatosilva/bzr-email/mail-customization/ Branches are up to date.zr+ssh > 0KB 0KB/s | [04:59] I would just merge them with -m "Small fixes from work" or some such [05:00] ok but I'm trying to learn :) [05:00] Hummm let me see... [05:00] The work branch is a branch from bzr-mail! [05:01] My branch here is the mail-customization [05:04] You can skip the details as they will still be present in the commits you are merging. --> actually they're not there :( [05:04] After my last commit comment from lp, the next one is from the merge. [05:05] RenatoSilva: run bzr log -n0 [05:06] it is in rev 41 in lp, there were 2 revs in the merge, but when I commited I'd expect the local branch go to rev 43 [05:06] RenatoSilva: try running qlog [05:06] err - bzr qlog [05:07] RenatoSilva: have you tried running log -n0 [05:07] You should be able to expand rev 41 - under it you will see the revisions that you merged. [05:08] lifeless, any words of wisdom on the situation i reported above, in a previous incarnation when i was known as garage_seb? [05:08] bzr log -r40.. [05:08] RenatoSilva: with "-n0" [05:08] so "bzr log -n0 -r40.. [05:08] " [05:09] seb_: did you see wgrant's question? [05:09] oops no that must have been while my dsl modem blinked out :-( [05:10] seb_: nothing should be broken [05:10] seb_: < wgrant> garage_seb: I don't think that should break anything. Has it? [05:10] oh good :-) [05:10] things seem to be working just fine [05:10] seb_: if you want to get rid of the branch you pushed, you can remove the .bzr/branch directory it will have created [05:10] heh, i just did that and things *still* seem fine [05:10] http://pastie.org/515988, http://pastie.org/515990 [05:10] [but be sure to leave .bzr/repository alone, as that is your shared repo :P] [05:11] ok thanks guys :-) [05:11] yes i didnt remove that one [05:11] RenatoSilva: right, in 515990 you can see the messages [05:12] lifeless: so, the merge revisions become sub-revisions? [05:12] jml, mwhudson (and anyone else interested): https://code.edge.launchpad.net/~spiv/bzr/default-stacking-again/+merge/7601 fixes that stacking bug. [05:13] spiv: is it client side or server side? [05:13] RenatoSilva: yes, thats a reasonable way to think about it [05:13] mwhudson: client [05:13] cool [05:13] lifeless: ok thanks [05:13] this is one of the key, critical diferences vs CVS [05:14] spiv, thanks, I'll take a look at it. [05:14] mwhudson: client [05:15] Oh, I'm too slow today :) [05:15] pushed \o/ [05:15] RenatoSilva: have you tried bzr qlog? [05:15] garyvdm: yes [05:16] RenatoSilva: And? did it help? [05:16] spiv, thanks I'll take a look at it. [05:16] spiv, sorry for the lag -- I needed to have a lunch break afk :) [05:16] jml: I understand :) [05:16] garyvdm: now yes, I didn't note the "+" [05:16] jml: I'm actually planning on doing the same shortly :) [05:17] garyvdm: nice view, thanks! btw, Qt for windows? [05:17] RenatoSilva: qt is multi-platform [05:17] RenatoSilva: used by KDE [05:18] garyvdm: oh I didn't know that, the widgets look pretty native [05:19] garyvdm: it's embedded in bzr installer? [05:19] RenatoSilva: yes [05:19] garyvdm: ok, thank you! [05:26] /quit zzzzz === _thumper_ is now known as thumper [05:29] spiv: thanks for fixing that bug so quickly :) [05:30] mwhudson: once I untangled the particular confusions it wasn't too hard. [05:36] * spiv -> lunch [05:40] Does TortoiseBzr use Qt? [05:47] I'm afraidn to install it, because TortoiseCVS was not working well [06:47] lifeless, spiv, the bug editing collisions were i think bug 28459 [06:47] Launchpad bug 28459 in malone "Handle mid-air collisions in bug reports" [Low,Triaged] https://launchpad.net/bugs/28459 [07:04] poolie: our one wasn't, unless you'd had the bug open for 30 minutes or so... I guess that is possible ;) [07:06] poolie: still, its a nice low bug number ;) [07:07] hi all [07:22] i did have it open [07:22] because, probably someone started talking to me [07:23] also i was wondering what the magic number at the start was [07:23] hello vila [07:23] lifeless, re bug 308403, [07:23] Launchpad bug 308403 in bzr "bzr add should optionally fail if explicitly named files are ignored" [Medium,Confirmed] https://launchpad.net/bugs/308403 [07:23] do you in pracitice commonly add files matching ignore patterns? [07:23] hi poolie [07:24] poolie: Its not that I commonly do it; its a design principle I have. [07:24] poolie: which is that its better to do whats asked and make reverting mistakes easy. [07:24] poolie: and we already have that. [07:27] poolie: I don't object to bzr add having a --strict mode or something for people that prefer to have the command fail. [07:28] mm maybe there should be a global --strict [07:29] Stopping on many little things and forcing things to be re-run is just irritating in my experience. Clippy leads down that road ;) [07:29] some people like being irritated. [07:29]