I would set EHG_REVISION="default" instead of "tip" by default. "tip" is possibly not on the default branch. Normally one has to set S="${WORKDIR}/${EHG_REPO_URI##*/}". git-2 eclass uses EGIT_SOURCEDIR="${S}" and clones in EGIT_SOURCEDIR, which in the end does the same. Any suggestions?
That is sensible idea. `tip` jumps from one branch to the other in multi-branch repos, and building package from `dev` branch then again from `default` could result in obscure changes for user.
(In reply to comment #1) > That is sensible idea. `tip` jumps from one branch to the other in > multi-branch repos, and building package from `dev` branch then again from > `default` could result in obscure changes for user. That is why, "tip" is not very good default. Many projects have a relatively stable default branch and develop new features on a different even multiple branches, which is why the "tip" is unpredictable as long as this branch is not merged. (git-2.class uses "master" as default branch.)
On the other hand, consider Mercurial workflow: http://mercurial.selenic.com/wiki/TimeBasedReleasePlan Right now, for example, code is freezed for upcoming 2.2 release and there's nothing happening in `default`, all the changes go into `stable`. Using `tip` yields expected behaviour, while `default` would not.
(In reply to comment #3) > On the other hand, consider Mercurial workflow: > http://mercurial.selenic.com/wiki/TimeBasedReleasePlan > Right now, for example, code is freezed for upcoming 2.2 release and there's > nothing happening in `default`, all the changes go into `stable`. Using > `tip` yields expected behaviour, while `default` would not. That is really project specific and also not 100%. Even in Mercurial new features go into default during the freeze from time to time. And then the question is do you want the new feature or the upcoming release. Usually there should be two ebuilds -9999 and -2.1.9999, where the first one is the default branch and the second one is stable. Anyway, I don't like the idea that the ebuild uses tip, which can jump between different branches, so it really depends on what was the last commit and on which branch it was.
(In reply to comment #4) > (In reply to comment #3) > > On the other hand, consider Mercurial workflow: > > http://mercurial.selenic.com/wiki/TimeBasedReleasePlan > > Right now, for example, code is freezed for upcoming 2.2 release and there's > > nothing happening in `default`, all the changes go into `stable`. Using > > `tip` yields expected behaviour, while `default` would not. > > That is really project specific and also not 100%. I agree, mercurial workflow probably shouldn't be regarded as typical/default one. `tip` concept is frowned upon by Matt Mackal, by the way, and could be deprecated in the forseeable future.
I will leave it to the other Christoph to decide. @Krzysztof: Any opinion about that?
Most simple (or semi-complicated) projects will have `tip', for all other cases you can just override EHG_REVISION in the ebuild. I don't think it's possible to have a default that fits all possible cases (thus CANTFIX), it really needs to be looked on case-by-case basis.
Reopen, what about S="${WORKDIR}/${EHG_REPO_URI##*/}" as default?
(In reply to comment #8) > Reopen, what about S="${WORKDIR}/${EHG_REPO_URI##*/}" as default? Do you want to set S in eclass? Or do you mean to clone into ${S}? If the later then it's already done (without introducing another variable) in mercurial_fetch -- look for sourcedir. Also about "normally": only 5 out of 42 ebuilds using mercurial.eclass do this: media-tv/v4l-dvb-hg/v4l-dvb-hg-0.1-r3.ebuild:S="${WORKDIR}/${EHG_REPO_URI##*/}/v4l" media-tv/v4l-dvb-hg/v4l-dvb-hg-0.1-r2.ebuild:S="${WORKDIR}/${EHG_REPO_URI##*/}/v4l" sci-chemistry/votca-csg/votca-csg-1.2.2.ebuild: S="${WORKDIR}/${EHG_REPO_URI##*/}" sci-chemistry/votca-csgapps/votca-csgapps-1.2.2.ebuild: S="${WORKDIR}/${EHG_REPO_URI##*/}" sci-libs/votca-tools/votca-tools-1.2.2.ebuild: S="${WORKDIR}/${EHG_REPO_URI##*/}"
(In reply to comment #7) > Most simple (or semi-complicated) projects will have `tip'... In most cases `tip` would be the same as `default`, but the latter covers nicely more workflows, as described above.
Here's the example: I have mercurial-9999 and tortoisehg-9999 installed. TortoiseHG repo has two branches, stable and default. At the moment only `default` supports Mercurial 2.3 (and therefore live version). `stable` isn't regularly merged back to `default`, so my tortoisehg is regularly broken, depending on where had the last commit landed. A bugfix on `stable`, my @smart-live-rebuild checks it and THG complains about mercurial being too new.
(In reply to comment #11) > Here's the example: I have mercurial-9999 and tortoisehg-9999 installed. > TortoiseHG repo has two branches, stable and default. At the moment only > `default` supports Mercurial 2.3 (and therefore live version). `stable` > isn't regularly merged back to `default`, so my tortoisehg is regularly > broken, depending on where had the last commit landed. A bugfix on `stable`, > my @smart-live-rebuild checks it and THG complains about mercurial being too > new. You should open a bug with the tortoisehg maintainer and ask him to set EHG_REVISION="default" in tortoisehg-9999. Additionally you could ask for a tortoisehg-2.4.9999 ebuild with EHG_REVISION="stable". Krzysztof had reasons to keep the defaults as they are (see comment #7). Anyway, this bug should have be closed as CANTFIX long time ago.
> You should open a bug with the tortoisehg maintainer and ask him to set > EHG_REVISION="default" in tortoisehg-9999. Additionally you could ask for a > tortoisehg-2.4.9999 ebuild with EHG_REVISION="stable". Yep, this is a solution. Of a kind. > Krzysztof had reasons to keep the defaults as they are (see comment #7). His reasoning is a bit strange, as I had already explained. >> Most simple (or semi-complicated) projects will have `tip' So they will have `default` branch as well, won't they? `tip` would work better only in weird and *very* unusual case where repository has no `default` branch at all (never seen such one in real life). In other cases `default` would yield equally (Mercurial or some simple project "without" named branches) or better (THG etc) results. More predictable for user. After all, eclasses are all about common functions and sensible defaults, aren't they? And `default` is clearly better default value due to reasons described. Ah, you've already closed the bug. It's strange to see bug reporter changing his mind without any noticeable reason.
(In reply to comment #13) > Ah, you've already closed the bug. It's strange to see bug reporter changing > his mind without any noticeable reason. Well, I just accept Krzysztof's opinion and as he is the maintainer of the eclass, he has the say. And anyhow also my default suggestions do not have huge advantages. If you want I can reopen this bug, but I made all my ebuilds aware of the way the eclass works a long time ago, so I don't need these changes anymore. @Krzysztof: are you willing to rethink your opinion or at least explain yourself better?
> If you want I can reopen this bug, but I made all my ebuilds aware of the > way the eclass works a long time ago, so I don't need these changes anymore. Well, there's the issue with TortoiseHG at least, and I think that eclass change would be more elegant and cludgeless solution than hacking all the ebuilds. With `default` being the default, ebuild maintainer shouldn't wander how project managers like to merge branches and is `tip` jumping to and fro or not. So I'd like bug to be reopened, yes, and changes to be made.
...and the same goes for Mercurial itself at the moment, curiously enough: [☿:default] mercurial % hg heads changeset: 17419:3ee5d3c372fa branch: stable tag: tip user: Matt Mackall <mpm@selenic.com> date: Sat Sep 01 12:49:43 2012 -0500 summary: Added signature for changeset 072209ae4ddb changeset: 17407:31c123a2f273 user: Leah Xue <leahxue@fb.com> date: Tue Aug 21 16:06:34 2012 -0700 summary: histedit: factored out diff/patch logic `tip` is on `stable` branch now. Of course, it was pointing at `default` prior to 2.3.1 release. Another thing is that any time "most simple (or semi-complicated) projects" (which have only `tip`) could branch and all of a sudden live-users have problems of nature already discussed.
(In reply to comment #16) > ...and the same goes for Mercurial itself at the moment, curiously enough: > > [☿:default] mercurial % hg heads > changeset: 17419:3ee5d3c372fa > branch: stable > tag: tip > user: Matt Mackall <mpm@selenic.com> > date: Sat Sep 01 12:49:43 2012 -0500 > summary: Added signature for changeset 072209ae4ddb > > changeset: 17407:31c123a2f273 > user: Leah Xue <leahxue@fb.com> > date: Tue Aug 21 16:06:34 2012 -0700 > summary: histedit: factored out diff/patch logic > > `tip` is on `stable` branch now. Of course, it was pointing at `default` > prior to 2.3.1 release. > > Another thing is that any time "most simple (or semi-complicated) projects" > (which have only `tip`) could branch and all of a sudden live-users have > problems of nature already discussed. Agreed if the "mother" project does it itself, we should consider this as the default.
@djc: I can help maintaining the mercurial eclass if you like.
Yeah, please take it! I'm a little backlogged at the moment due to my devbox having issues, and I've really never taken much of an interest in the eclass. BTW, I definitely think "default" is a better default than "tip" here.
Do we need to announce that change of the default on gmx-dev?
You mean gentoo-dev? Probably couldn't hurt.
Done and done.
