=== Ursinha is now known as Ursinha-afk
[01:40] <_habnabit> http://www.habnabit.org/bzr-graph3.png <- out of curiosity, why is it that most of the merged revisions are numbered 85.[1-5].X? Merging from trunk (which is what it's clustered around) doesn't seem to reset it.
[01:40] <_habnabit> I'm unclear on how revision numbers are assigned from a merge.
[01:45] <_habnabit> (My guess it it's using the earliest shared parent revision contained in the branch.)
[01:47] <maxb> _habnabit: <mainline revno branched from>.<sequential numbering of branches off that mainline point>.<position on that branch>
[01:48] <_habnabit> maxb, so the only way to reset the first number is to make a new branch?
[01:48] <maxb> yes.... though it's just an arbitrary number, does it matter?
[01:48] <_habnabit> I'm just curious.
[01:48] <_habnabit> I don't care about it.
[01:50] <lifeless> _habnabit: if you pull from trunk, it will reset all your local revnos to be identical to those in trunk
[01:50] <_habnabit> Aha.
[01:50] <lifeless> but you can only do that after trunk has merged from you
[01:50] <_habnabit> Right.
[01:56] <maxb> wtf, we have an intermittent test failure in bzr 2.3b4 in bzr-beta-ppa :-(
[01:56] <spiv> maxb: :(
[02:02] <maxb> list emailed
[02:02] <maxb> I'm baffled
[03:25] <jubei__> is there a way to check if there are changes to a repository before running bzr pull ?
[03:26] <bob2> bzr missing
[03:33] <jubei__> awesome, thanks
[03:58] <rocky> is it possible to create branch X from a subdir in mybranc?  say mybranch has subdirs sd1 and sd2 and i want to produce a branch that only consists of sd1 stuff...
[03:59] <bob2> you can branch, delete, move.  or there's the split stuff, but I don't know how usable that is atm
[04:08] <spiv> maxb: replied; known issue, fixed upstream and workaround just landed in lp:bzr
[04:12] <maxb> gosh
[04:12] <maxb> how obscure
[04:14] <spiv> maxb: on the plus side, it wasn't our fault ;)
[07:22] <vila> hi all
[07:31] <vila> poolie: hey ! the poolie_droid sounded like a definitive SSD failure :-}
[07:33] <vila> maxb: fix landed, I filed bug #686008 as soon as I saw the daily builds failures, sorry I didn't think to warn you explicitly
[07:33] <ubot5> Launchpad bug 686008 in Bazaar "TypeError: 'member_descriptor' object is not callable" [Medium,In progress] https://launchpad.net/bugs/686008
[07:35] <vila> maxb: ... obscure it not fair for this, it's far worse than that (and my English is not good enough to find the fait word there ;)
[07:35] <vila> s/fait/fair/
[07:37] <vila> maxb: even knowing what was happening and why I couldn't write a *reliable* reproducing test :-/ See https://code.edge.launchpad.net/~vila/bzr/686008-spurious-https-failure/+merge/42969 for details
[07:59] <vila> poolie: ping
[08:01] <poolie> hi vila
[08:02] <vila> poolie: was your _droid suffix related to your SSD issues ? :-}
[08:02] <poolie> haha
[08:02] <poolie> not right at the moment
[08:29] <fullermd> vila: (brief moment of lucidity) I pulled in your changes and did somsethingorother yesterday.
[08:30] <vila> fullermd: yup, I saw that ! Thanks ! Take care
[08:30]  * fullermd tries to get another 2 hour block of sleep...
[09:24] <ronny> hi
[09:24] <ronny> where is bzrlib.bzrdir gone?
[09:26] <vila> ronny: it seems to be present in all my bzr branches, may be you can be more specific ?
[09:29] <ronny> vila: im testing agains what is pip/easy_install-able
[09:29] <ronny> it recently broke
[09:29] <ronny> its quite annoying that bzr breaks the anyvc builds every few weeks in such unexpected ways
[09:30] <vila> I can understand your frustration but I still have no idea what failure you're talking about
[09:31] <vila> bzrlib/bzrdir.py is quite a significant piece and it won't disappear without notice
[09:32] <ronny> vila: the testing process currently download whatever bzr version is pip installable, and tests agaist that
[09:32] <ronny> (there is no way to sanely link to older ones)
[09:33] <vila> I have no idea what pip installable means but I can give you links for many bzr versions including the stable ones
[09:33] <ronny> vila: its quite useless if pip install bzr==version does not work
[09:33] <vila> ...
[09:34] <vila> you're talking chinese as far as I'm concerned
[09:34] <mgz> it's one of those setuptools based html scraping things.
[09:35] <mgz> because installing stuff from random bits downloaded over http is always such a great idea.
[09:35] <vila> ronny: are you telling that you don't have a bzrlib/bzrdir.py file ?
[09:36] <vila> ronny: if that's the case, the way you acquire bzr is seriously broken
[09:37] <vila> ronny: being the bzr release manager these days, I can assure you that *all* recently releases version *includes* this file
[09:37] <ronny> hmm, it actually exists
[09:37] <vila> ha, we're making progress
[09:37] <ronny> vila: well, why the hell is NONE of them propperly availiable on pypi
[09:37] <ronny> pretty much everything else i use just does that, and i can just get any version i want by package==version
[09:38] <ronny> only bzr makes me work extra
[09:38] <ronny> like always
[09:38] <vila> may be we can focus on concrete problems and how to solve them rather than ranting ?
[09:38] <ronny> ok, sorry
[09:40]  * ronny finishes the local reproducing
[09:40] <vila> what OS are you using ? I maintain quite a few flavours but *NONE* of them requires to use easy_install and I'm not familiar with how this works
[09:41] <ronny> vila: im using tox to create virtualenvs with all requirements for the test runs
[09:41] <ronny> its using pip to grab the requirements
[09:41] <ronny> (and falls back to easy_install if necessary)
[09:41] <vila> what is pip and what is tox ?
[09:41] <vila> bah, nvm
[09:42] <vila> where are you getting bzr and in which form ? tar.gz ? .deb ?
[09:42] <ronny> tarball, installing it in a virtualenv after all
[09:43] <vila> where is this tarball coming from ?
[09:43] <vila> and what OS are you using (no, really) ?
[09:44] <ronny> im on the latest ubuntu, the test box is on a gentoo, its all linux
[09:44] <ronny> the thing pip currenly grabs is  bzr-2.3b4.tar.gz
[09:44] <vila> so both of them provides stable releases AFAIK
[09:44] <mgz> vila, as I was saying, it scrapes html, and has broken in the past from <https://launchpad.net/bzr/+download> changing format.
[09:45] <vila> ronny: if you're using betas instead, then you are *expected* to encounter problems and give us feedback, that's the point of betas
[09:45] <ronny> vila: well, the issue for me is simple - bzr cannot propperly be installed by the python package installer
[09:46] <vila> ronny: this is as useful as bug reports saying: 'Does not work'
[09:46] <mgz> it just gets the first likely link on that page.
[09:47] <ronny> vila: i requested pushing all releases to pypi as well some times now
[09:47] <vila> ronny: afaik the python installer is used in Ubuntu and there is even *daily* builds exercising it, so surely you encounter something more specifi
[09:47] <vila> ronny: right, may be you teach us how to do that then
[09:48] <ronny> vila: python package installers are pip and easy_install
[09:48] <spiv> ronny: python package installers are "python setup.py install", really.
[09:48] <vila> ronny: don't they rely on setup.py ?
[09:48] <ronny> vila: yes, but they have to grab the package from soemwhere first
[09:48] <ronny> and in bzr's case, the only link they ever can get is the latest tarball out
[09:49] <spiv> Or did pip/easy_install get integrated into the standard Python distribution since I last checked?
[09:49] <vila> ronny: is there a way to fix that on http://pypi.python.org/pypi/bzr ?
[09:49] <ronny> the usual way is to just push the tarballs there
[09:49] <spiv> (I agree it would be nice to work well with pip etc, though)
[09:49] <ronny> usually people upload after a sdist
[09:50] <vila> ronny: as far as I know, the instructions say: 'python setup.py register' which I did for 2.2.2
[09:50] <mgz> I'm not even sure that's enough, because bzr has build dependencies that it doesn't declare using the setuptools machinary.
[09:50] <ronny> vila: that only tells pypy there is a project with that version
[09:51] <mgz> so virtualenv installs may break even if tarballs get uploaded.
[09:51] <vila> ronny: that's why I mention it, what should be done is what I'm asking
[09:51] <ronny> mgz: tarballs ship with c files, dont they?
[09:51] <mgz> ah, so they do.
[09:51] <ronny> vila: upload after sdist
[09:51] <vila> upload
[09:51] <vila> -bash: upload: command not found
[09:51] <mgz> and I guess you don't care about running selftest.
[09:52] <ronny> vila: its a distutils command
[09:52] <vila> distutils upload
[09:52] <vila> -bash: distutils: command not found
[09:53] <mgz> as in setup.py vila.
[09:54] <vila> python setup.py upload
[09:54] <vila> running upload
[09:54] <vila> error: No dist file created in earlier command
[09:54] <mgz> +setuptools specifc.
[09:54] <vila> and yes, I'm in the right directory from which 2.2.2 was released
[09:55] <mgz> basically, the problem is we don't use setuptools.
[09:55] <mgz> which I think isn't something we want to change.
[09:55] <vila> ronny: here it goes ^
[09:56] <ronny> vila: doesnt matter
[09:56] <vila> ronny: if you care about it, a patch against bzr making your life easier will certainly be considered, failing that, may be you should think of a better way to select your bzr source
[09:56] <ronny> vila: pip/easy_install force setuptools on any setup.py
[09:57] <ronny> vila: just upload the dam tarballs to pypi
[09:57] <ronny> pip/easy_install will do the rest
[09:59] <vila> ronny: one last time: I don't know how to do that nor do I have the time to investigate, you obviously know better and are certainly in a better position to propose a patch which can be as little as explaining which commands need to be run when
[10:01] <ronny> vila: python setup.py sdist upload
[10:01] <spiv> ronny: i.e. a patch to our doc/developers/releasing.txt
[10:01] <spiv> Anyway, this really doesn't sound like the cause of your bzrlib.bzrdir problem.
[10:01] <spiv> Can you give more details about that?
[10:03] <vila> ronny: done. test and feedback welcome and for an additional bonuses a merge proposal updating the document spiv mentioned above
[10:03] <spiv> Because there's nothing about grabbing the 2.3b4 tarball rather than the 2.2.2 tarball that seems relevant to that.
[10:05] <ronny> hmm, seems likepip still prefers the latest ones, but i think i can fix that
[10:05] <mgz> I'm curious about that too spiv, but reckoned setuptools was just breaking something else.
[10:07] <mgz> vila: I think one upshot of putting a tarball up there is breaking anyone on windows trying to easy_install bzr (if it worked before, that is)
[10:07] <vila> hmm and this command doesn't seem to include the generated C files, so most likely the result will not be the expected one
[10:07] <vila> nor the docs ones
[10:08] <vila> ronny: and how do we remove this broken tarball now ?
[10:08] <ronny> vila: pypi has a web ui for that
[10:09] <vila> done
[10:10] <mgz> I'm failing to find any documentation on how to actually interface with pypi to upload stuff we want from our build scripts.
[10:10] <vila> the web page allowing removing the tarball seems to allow manual upload too
[10:10] <ronny> mgz: distutils includes a uploader
[10:10] <mgz> no, ronny, no, it doesn't.
[10:10] <mgz> *setuptools* does.
[10:10] <vila> ronny: which produces the bogus behaviour above
[10:11] <mgz> which as vila just found, is broken.
[10:12] <ronny> mgz: distutils includes one for sure, setuptools is not required
[10:14] <mgz> hm, ported across in some version.
[10:15] <ronny> starting with 2.5
[10:17] <vila> ronny: I've update the Download URL at pypi, can you try again ?
[10:17] <vila> s/update/updated/
[10:20] <ronny> pip tries http://launchpad.net/bzr/2.2/2.2.2/+download/bzr-2.2.2.tar.gz, gets a http 404, then grabs the rest of the download list and grabs the latest one
[10:21] <vila> it shouldn't get a 404 since that's the url *all* packagers are using
[10:23] <ronny> it would be appreciated if the redirect target wouldnt trick browsers into display as text
[10:23] <vila> https://edge.launchpad.net/bzr/+download clearly states that 662 people succeeded to download it with this link
[10:25] <vila> ronny: file a bug
[10:26] <vila> ronny: but try to focus on your actual problem, we've been at it for an hour now and you still haven't explained what the problem was about bzrlib.bzrdir
[10:27] <ronny> it missing was in part caused by the venv getting messed up
[10:28] <ronny> i did a messy fox for the build issue, to get it propper i need to kill the problems with grabing specific bzr versions as source tarballs
[10:30] <vila> ronny: does this means updating the Download URL on pypi doesn't address your problem then ?
[10:31] <vila> mgz: does the proper tarball on pypi address your concern about windows people ?
[10:31] <ronny> it should, right now pip/easy_install still select thr wrong one for reasons unknown to me
[10:31] <ronny> (weird stuff only happens for stuff thats not propperly uploaded to pypi)
[10:32] <vila> ronny: we're back to 'does not work' being useless to make progress
[10:33] <ronny> vila: im trying t figure why pip fails to take the download link into account, but i cant exactly give a detailed description i dont have
[10:34] <vila> ronny: right, that's exactly my point: there is nothing we can't fix if we don't know what we do wrong
[10:36] <ronny> vila: im working on the details, but the basics are your tarballs are at locations that are awfully inaccessible for pip/easy_install
[10:36] <vila> s/awfully/standard http but/
[10:39] <vila> ronny: why you insist on getting around packaged versions provided by the OSes you use while not wanting to use a source *branch* despite working with DVCS tools is a bit behind my understanding though...
[10:39] <vila> But that probably explain why you're the first one to report such problems...
[10:40] <vila> ronny: gentoo for example backported a patch from our trunk to the 2.2.2 stable branch which you will never get by working with tarballs
[10:41] <vila> ronny: if you're using python-2.7 (targeted  by the backported patch) you're on your own
[10:45] <vila> mgz: did I mention I uninstalled launchpadlib from the 10.6 babune slave ? Leading to 3 remaining failures
[10:45] <ronny> vila: these day thats the common way to set up isolated python envs for test runs
[10:48] <vila> ronny: GIGO (garbage in, garbage out), if your test inputs are wrong, so do your tests outputs
[10:49] <vila> ronny: if you're interested about how bzr is tested: http://babune.ladeuil.net:24842/
[10:49] <vila> this is a hudson setup that use the bzr trunk on various platforms
[10:58] <ronny> time to drop the bzr variation of my CI i guess
=== Ursinha is now known as Ursinha-brb
=== oubiwann is now known as oubiwann_
=== oubiwann_ is now known as oubiwann
=== vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3b4 is officially out ! (rm vila)
[14:43] <didrocks> hey
[14:44] <didrocks> so, I'm trying to merge between two branches, I have conflicts. (a lot of them). When trying to bzr resolve --take-others --all, I get:
[14:44] <didrocks> bzr: ERROR: Tree transform is malformed [('duplicate id', 'new-74', 'new-1')]
[15:06] <jelmer> didrocks: hi
[15:06] <jelmer> didrocks: I believe there's an open bug about that
[15:06] <vila> didrocks: bzr version ?
[15:07] <vila> jelmer: hey :)
[15:07] <vila> jelmer: remind where I should check in debian to see if bzr-2.3b4 is there ?
[15:07] <vila> s//me/ !
[15:07] <jelmer> vila: Good arvo
[15:08] <jelmer> vila: http://qa.debian.org/bzr
[15:08] <jelmer> sorry, http://packages.qa.debian.org/bzr
[15:08] <jelmer> I haven't packaged/uploaded b4 yet
[15:08] <didrocks> vila: Bazaar (bzr) 2.3b3
[15:08] <didrocks> jelmer: is it fixed in trunk? I can't do the unity release because of it right now
[15:09] <vila> bug #646691
[15:09] <ubot5> Launchpad bug 646691 in Mahara "Blog account settings still available when blog disabled" [Low,Confirmed] https://launchpad.net/bugs/646691
[15:09] <vila> bug #646961
[15:09] <ubot5> Launchpad bug 646961 in Bazaar 2.2 "resolve --take-other produces AttributeError" [High,Fix released] https://launchpad.net/bugs/646961
[15:09] <didrocks> I found that weird, right :)
[15:10] <vila> hmm
[15:10] <didrocks> ok, fixed in trunk then
[15:10] <vila> not sure it's the same one but...
[15:10] <didrocks> oh right, doesn't seem
[15:10] <vila> didrocks: where did you get your bzr ? ppa ?
[15:11] <didrocks> vila: lp:~unity-team/nux/nux and lp:~unity-team/nux/packaging
[15:11] <didrocks> vila: you can try without merge-upstream, just merge nux in packaging. We get a whole bunch of conflicts
[15:12] <didrocks> (not sure why btw… It's just a one-line change in most of files)
[15:12] <vila> didrocks: I meant where is your bzr-2.3b3 coming from ? source ? ppa ?
[15:12] <didrocks> I assume there was something with merge-upstream and missing file in tarball
[15:12] <didrocks> vila: oh, from natty
[15:15] <vila> didrocks: #638451
[15:15] <vila> bug #638451
[15:15] <ubot5> Launchpad bug 638451 in Bazaar " bzr resolve --take-other bzr: ERROR: Tree transform is malformed [('duplicate', None, 'new-1', None)] " [High,Fix released] https://launchpad.net/bugs/638451
[15:16] <vila> didrocks: more like it no ?
[15:16] <didrocks> vila: exactly :) so I should definitively pull trunk
[15:16] <didrocks> vila: do I have to mess up with PYTHON_LIBRARY path?
[15:16] <vila> didrocks: feedback *highly* appreciated there
[15:17] <vila> didrocks: not sure what you mean, but if you run the right *bzr* script, the right bzrlib should be selected (or file a bug)
[15:17] <didrocks> vila: ok, let's see how it goes
[15:17] <vila> didrocks: if you run from source, don't forget to run 'make' first
[15:18] <vila> didrocks: note that you're using a quite recent addition there that will handle the *text* conflicts by *forcing* the OTHER version (with --take-other)
[15:19] <vila> didrocks: i.e. all changes that could be otherwise merged cleanly are thrown away
[15:19] <jelmer> didrocks: alternatively you can use the nightly builds
[15:19] <vila> didrocks: make sure you read 'bzr help conflict-types' there
[15:20] <vila> jelmer: I read the emails related to the failures, but not always the associated logs, is there a place which summarizes the status of the builds ?
[15:21] <jelmer> vila: https://code.launchpad.net/~bzr/+recipes has a list of all the recipes, each recipe has an overview of the resulting builds
[15:21] <vila> jelmer: ha, 2.3b4 not yet packaged, ok
[15:21] <jelmer> vila: there's also https://code.launchpad.net/~bzr/+archive/daily/+packages
[15:23] <vila> jelmer: thanks, I keep forgetting +packages
[15:23] <vila> meh, didrocks, don't leave without feedback !!!
[15:23] <vila> . o O (reboot did he ?)
[15:30] <vila> jelmer: should https://code.launchpad.net/~bzr/+recipe/bzr-daily mention beta5 instead of beta4 ?
[15:31] <jelmer> vila: no, as we're using "beta4+bzr" - note the + which means this version comes /after/ beta4
[15:31] <vila> jelmer: %-} ooook
[15:31] <jelmer> vila: Alternatively we could use beta5~bzr if we knew we were going to do a beta5
[15:31] <jelmer> (~ sorts before empty string, + sorts after empty string)
[15:32] <vila> right, so you did this change at freeze or at release time ?
[15:32] <jelmer> vila: yep
[15:32] <vila> a or b: yes... :D
[15:33] <vila> any ?
[15:33] <vila> yeah, any, sorry, thinking aloud ;D
[15:34] <vila> haaa, he's back :D
[15:34] <vila> didrocks: so ?
[15:34] <didrocks> vila: sorry, seeems that I was disconnected :/
[15:34] <didrocks> 16:25:42 didrocks | vila: are you sure it's taking the right bzrlib? like if I try ~/sandbox/bzr/bzr resolve --all --take-other (~/sandbox/bzr is where I branched bzr from)
[15:34] <didrocks> 16:26:23 didrocks | oh right   bzrlib: /home/didrocks/sandbox/bzr/bzrlib
[15:34] <didrocks> 16:26:32 didrocks | so ok… it's not fixed :/
[15:34] <didrocks> I have 2.3.0dev5 from --version
[15:35] <vila> file a bug
[15:36] <didrocks> vila: what do you need as needed info in addition to the branch and the error output?
[15:36] <jelmer> vila: Sorry :-) I changed it after the release
[15:36] <vila> didrocks: reproducing recipe
[15:36] <didrocks> vila: can I workaround in some way (downgrade or such)? I think that I can't delay the unity release anymore :)
[15:37] <vila> didrocks: try resolving in several steps
[15:37] <didrocks> there are 50 conflicts… will write a shell script then
[15:38] <vila> didrocks: meh, is that a private branch ?
[15:38] <didrocks> vila: it's not, you can't check it out?
[15:38] <vila> no, got not a branch
[15:39] <didrocks> let me check, I maybe made a typo
[15:39] <vila> s!/nux!/trunk! ?
[15:39] <didrocks> vila: oh sorry, the trunk is at trunk, right
[15:40] <didrocks> or lp:nux
[15:40] <vila> yup, better
[15:40] <didrocks> the packaging branch is good :)
[15:41] <vila> ouch, 62 conflict
[15:41] <vila> ouch, 62 conflicts
[15:41] <didrocks> vila: yeah, I'm not sure why there are there… upstream just changed the email in every files
[15:41] <didrocks> vila: so I think something happened between bzr merge-upstream / the tarball / trunk
[15:42] <didrocks> well, we try to ship every files in the tarball to avoid conflicts as we had at some point
[15:42] <vila> no, there are a bunch of content conflicts which means different file-ids probably so parallel import ?
[15:42] <didrocks> vila: weird, bzr merge-upstream did that?
[15:42] <vila> no idea
[15:42] <didrocks> like it added other file ids?
[15:46] <didrocks> filed as bug #688101
[15:47] <vila> didrocks: I'm digging the history of both branches
[15:47] <ubot5> Launchpad bug 688101 in Bazaar "bzr: ERROR: Tree transform is malformed [('duplicate id', 'new-74', 'new-1')]" [Undecided,New] https://launchpad.net/bugs/688101
[15:47] <didrocks> vila: thanks, it will be way easier for you I guess to find what happened than I ;)
[15:48] <vila> didrocks: hopefully :-}
[15:49] <didrocks> (I was the CSM administrator in my previous company, so I digged a lot in that to support developers, I don't want to do that anymore :p)
[15:49] <vila> didrocks: so far the only suspicious bit is revno 138 (New upstream release _ cherry pick latest commit)
[15:50] <vila> didrocks: di you change your workflow somehow between now and then ?
[15:51] <didrocks> vila: I've already done that in the past for unity itself. I just bzr merge from trunk what's interested
[15:51] <didrocks> so it should pick upstream file-id if there are new, isn't it?
[15:51] <vila> didrocks:  if you started your packaging branch from trunk ,yes
[15:52] <didrocks> vila: right, it is started from trunk
[15:52] <vila> and that seems to be the case (revno 113)
[15:52] <didrocks> that's all the benefit of merge-upstream and this workflow, cherry-picks :)
[15:52] <didrocks> (no more debian/patches/…)
[15:53] <didrocks> and it went well in the past in bamf/unity/dee… (I'm used to do that since May I would say)
[15:56] <vila> right, so comparing the inventories on both tips, sounds fine, all common files have the same file-ids, but it seems the conflicting ones are new in trunk... weird
[15:58] <didrocks> vila: not only the new ones (it can't add the directory it seems), but also ones where the email name was changed, isn't it?
[16:04] <vila> didrocks: hmm, doing 'bzr qlog trunk packaging' shows that you *never* merged since 0.9.1
[16:05] <vila> no wrong
[16:05] <didrocks> vila: is that what bzr log trunk packaging tells me?
=== beuno is now known as beuno-lunch
[16:06] <didrocks> bzr: ERROR: Path "/home/didrocks/work/unity/nux/ubuntu" is not a child of path "/home/didrocks/work/unity/nux/nux"
[16:06] <vila> of course you never merge packaging in trunk, you do the opposite, sorry
[16:06] <didrocks> right :)
[16:06] <vila> *q*log
[16:06] <didrocks> didn't know that command, it's coming from which package/plugin?
[16:06] <vila> qbzr
[16:07] <didrocks> no gtk equivalent? ;)
[16:07] <vila> best way to look at branch histories (especially to see how they interact)
[16:07] <vila> bzr viz, but I don't remember if it accepts multiple branches
[16:07] <didrocks> I've always used with once, let's see how it work with 2
[16:08] <vila> well, yes it does, but it still lacks the ability to hide merges
[16:08] <vila> a good chunk of the qlog backend is in a mp for bzr, once it lands, viz could reuse it
[16:08] <didrocks> oh nice, yeah, it's easier to see the history this way
[16:13] <vila> didrocks: eeerk, never ever use 'resolve --all' all this does is deleting the conflicts file
[16:13] <vila> didrocks: on the other hand, I just did that and that may be shortcut you're after...
[16:13] <didrocks> vila: well, I haven't done that. I just noticed it this time
[16:14] <didrocks> vila: on bzr resolve --all --take-other should take all .OTHER, isn't it?
[16:14] <vila> didrocks: no, that's a bug, --all and --take-other shouldn't be allowed together
[16:14] <didrocks> vila: oh ok :)
[16:15] <vila> didrocks: try 'bzr resolve --all' alone and look at the result but don't commit !
[16:15] <fullermd> Yeah, 'resolve --all' is a "mark that things are done", "--take-whatever" is a "do things".  Kinda a wart that one command does both.
[16:15] <didrocks> fullermd: oh right!
[16:15] <didrocks> vila: yeah, confirmed
[16:15] <vila> didrocks: if you're happy with the result: do 'bzr revert --forget-merges' and then and only then commit
[16:16] <vila> didrocks: if you weren't in a hurry I won't recommend that *at all*
[16:17] <vila> ha, bah, no good, bunch of .OTHER all over the place
[16:17] <didrocks> vila: hum, so what should I use? bzr merge && bzr revert --forget-merges? but that will prevent me taking new upstream version, isn't it?
[16:17] <vila> didrocks: no, that would be a huge cherry-pick
[16:17] <vila> didrocks: but forget it, bad idea
[16:18] <didrocks> vila: ok, I still have some time :)
[16:19] <vila> jam: ping
[16:20] <vila> jam: I don't have news from gary and we still haven't installers for bzr-2.2.2, can you help ?
=== zyga is now known as zyga-food
[16:26] <LeoNerd> bzr add   silently adds container directories. This is helpful.   bzr mv    doesn't add new path containers, gets upset. Possibly it should?
[16:26] <LeoNerd> Well, not silently. Automatically.
[16:27] <LeoNerd> Strikes me if 'add' does it, so should 'mv'
[16:28] <fullermd> Devil's advocate: You call mv to move a file from one place to another; having it also add stuff is unexpected.
[16:28] <LeoNerd> Devil's Counter-advocate; You call add to include one new file; having it also add other stuff is unexpected.
[16:29] <vila> didrocks: ok, the problems started at revno 139 in trunk
[16:29] <LeoNerd> Or make it non-default?  bzr mv --add-parents oldname newname
[16:29] <vila> LeoNerd, fullermd: very good, put that in a bug !
[16:29] <LeoNerd> Then people who want it can just alias
[16:29] <didrocks> vila: looking
[16:29] <fullermd> Perhaps, but it's at worst "do more than expected", not "do something else too".  I'd be shocked at 'add' moving stuff around; perhaps less so, but still somewhat, at 'mv' adding stuff.
[16:30] <fullermd> We're not ready for a bug, we're still rehearsing!
[16:30] <LeoNerd> Well.. currently it complains and dies
[16:30]  * Torne is more surprised by mv failing just because he didn't add the directory
[16:31] <didrocks> vila: weird, it's modified but the whole file content is removed and then added
[16:31] <didrocks> vila: oh "fix end of line" -> \r\n -> \n ?
[16:32] <vila> yeah, so the file-ids shouldn't be modified then
[16:33] <didrocks> right
[16:34] <Torne> fullermd: bzr add adds the parent directories because otherwise the operation would have to fail, and failing an operation with a perfectly logical intent would be silly. I don't think that mv is different just because "mv" and "add" are different commands.
[16:36] <jam> hi vila, I might be able to dig something out, but I honestly haven't worked closely with Garyvdm on the last couple of builds
[16:36] <vila> jam: :-/ do you know if he at least pushed its last related branches ?
[16:37] <jam> he should have, but no, I don't know that for sure
[16:56] <didrocks> vila: so, do you have any suggestion? I can drop the packaging branch and setup one again… but that will be a pity :/
[16:57] <vila> didrocks: whatever works for you :-/ I'm still digging and won't have a fix shortly sry :-/
[16:57] <didrocks> vila: ok, can you keep the branch somewhere? I'll surely --overwrite
[16:57] <vila> didrocks: but my feeling is that the prolem is in merge not in resolve, the later being a symptom
[16:58] <vila> didrocks: I have both branches there
[16:58] <didrocks> vila: ok, I'll maybe scratch them then. Hope that the use case can be solvable for you :)
[16:59] <vila> me too
=== deryck is now known as deryck[lunch]
[17:21] <vila> didrocks: that's the first time you're using 'bzr resolve --take-other' right ?
[17:22] <vila> didrocks: there seems to be mutiple bugs there when the same file is involved in several conflicts
[17:23] <vila> didrocks: the workaround seem to be to resolve the conflicts manually
[17:23] <didrocks> vila: I never used it before, right
[17:23] <vila> didrocks: I'm halfway
[17:23] <vila> didrocks: ha good, so I think it will not have give you the expected result
[17:23] <vila> didrocks: is  NuxGraphics/GraphicsDisplayWin.h windows specific ?
[17:24] <didrocks> vila: yeah, Nux is multi-plateform
[17:24] <vila> didrocks: and you deleted it from the packaging branch. Using --take-other means take it again
[17:25] <didrocks> vila: no, it was not disted in make dist tarball
[17:25] <didrocks> vila: so bzr merge-upstream deleted it
[17:26] <vila> didrocks: meh, I didn't use merge-upstream
[17:29] <didrocks> vila: I mean, that's why some files were deleted there in some commits
[17:31] <vila> didrocks: right, anyway, that's why you have Content Conflicts (one side deleted, the other modified)
[17:32] <didrocks> vila: yes, just a pity there is no way to solve that in one command :)
[17:32] <vila> didrocks: indeed
[17:33] <vila> didrocks: but your specific use case here is tricky, you want a mix of --take-this and --take-other
[17:34] <vila> well, not even, you don't want --take-other, you want to keep your deletions and cleanly merge the rest I think
[17:34] <didrocks> vila: exactly :/ in any case, there are some workflow issues with merge-upstream for such cases
[17:34] <didrocks> right
[17:34] <vila> didrocks: any way, summary:
[17:35] <vila> - thanks for the bug, I should fix it,
[17:35] <vila> - --take-other is not what you want: you need to resolve them in smaller chunks but not at all once, one by one in the worst case
[17:36] <vila> - merging more often will help, as usual :D
[17:36] <didrocks> vila: I'm merging once a week :)
[17:37] <didrocks> vila: but yeah, this use-case is an issue with merge-upstream workflow
[17:37] <didrocks> at least, we know why there are conflicts, which is good
[17:41] <vila> didrocks: well, more often can also mean merging less revisions (which is what I'm doing)
=== beuno-lunch is now known as beuno
[17:45] <vila> didrocks: I'm lost now, revno 144 produces 58 conflicts and I have no clue about how to resolve them
[17:45] <didrocks> vila: right, but with 25 upstream branch without making a release… once a week is already a lot :)
[17:46] <vila> didrocks: of course, that's a bug, I'm only talking about workarounds here, the last item had a smiley ;D
[17:46] <didrocks> right :)
[17:47] <vila> and when I say one.. probably several
[17:50] <vila> didrocks: bactracking to your ', it was not disted in make dist tarball' where is this defined ?
[17:59] <didrocks> vila: sorry, I'm currently on the unity release, hard to be responsive :)
[17:59] <vila> didrocks: no worries, am I right if I guess from Mafile.am files ?
[17:59] <didrocks> vila: this is definied in the dist target of all the Makefile.am
[17:59] <didrocks> yeah
[17:59] <didrocks> (there are multiple)
[18:00] <vila> to yeah, this is taking shape, you're suddenly confronted with a bunch of conflicts (deleted/modified), so what you really want is some way to attach merge options to files or directories
[18:01] <vila> and this became more obvious *because* a change was made to *all* files
=== deryck[lunch] is now known as deryck
=== Meths_ is now known as Meths
=== zyga-food is now known as zyga
=== Ursinha is now known as Ursinha-brb
[20:56] <poolie> hi jam
[22:10] <spiv> Good morning.
[23:09] <poolie> hi spiv
=== zyga is now known as zyga-afk
=== Ursinha-brb is now known as Ursinha