I'm trying to use subversion.eclass in a context where unconditionally failing out when ESVN_REPO_URI changes is problematic. Something akin to the following logic might be more appropriate: - After a checkout or successful update, retrieve and store the repository root and UUID. - When attempting to do an update and the repository URI is different... - If the UUID has changed, delete the tree and do a new checkout. - If the UUID has not changed but the repository root has changed, do a "svn switch --relocate ${OLD_REPOSITORY_ROOT} ${NEW_REPOSITORY_ROOT}". - If the UUID has not changed and the repository root has not changed (or the repository root has changed and a switch --relocate to update the base URIs has not completely resolved the issue), do a "svn switch ${ESVN_REPO_URI}". Does this logic make sense? If so, would you accept a patch implementing it, were I to develop one, or would you prefer to write such a patch yourself? (I'm moderately handy with shell, but not familiar with the conventions associated with building an eclass). Thank you!
Just attach the patch if you have one. :)
I don't have a patch yet -- trying to determine if I need to make the effort, at this point. I'm inexperienced enough with building code for use in eclasses that someone more experienced could get a better job done faster (I don't know the local conventions for finding an appropriate place to store state, for instance) -- but if me doing it is the way it'll get done, me doing it it'll be.
*** Bug 200052 has been marked as a duplicate of this bug. ***
Created attachment 136995 [details, diff] Patch implementing previously-discussed logic All use cases excepting the fall-through failure case (where URIs don't match even after relocation efforts) have been tested.
[a-z][A-Z] sucks, locale-specific thing. You should use tr '[:lower:]' '[:upper:]' instead...
Created attachment 140996 [details, diff] Patch implementing previously-discussed logic, revised Changed tr usage, not only in subversion__to_varname, but also in subversion__to_upper_case() [a previously-existing function from which it was derived].
(In reply to comment #5) > [a-z][A-Z] sucks, locale-specific thing. You should use tr '[:lower:]' > '[:upper:]' instead... It won't work for tr_TR. http://en.wikipedia.org/wiki/Turkish_dotted_and_dotless_I $ LC_ALL="tr_TR.UTF-8" $ [[ "REVISION" == "$(echo revision | tr [:lower:] [:upper:])" ]] && echo TRUE $
*** Bug 188081 has been marked as a duplicate of this bug. ***
The only thing I don't like about the patch is that it totally nukes the previous checkout. It should probably move it. I think a better solution altogether is to somehow incorporate the ESVN_WC_URL (or a hash, as you like) into the local WC, so like 0.20.2_p15634 might checkout to "${DISTDIR}/svn-src/mythtv/release-0-20-fixes/mythtv" and 0.21_pre15718 would checkout to "${DISTDIR}/svn-src/mythtv/trunk/mythtv" That would allow us to program the eclass to dynamically choose the appropriate name for whatever path comes out of the svn info URL variable. That way it could never be a mismatch. (In reply to comment #7) > $ LC_ALL="tr_TR.UTF-8" > $ [[ "REVISION" == "$(echo revision | tr [:lower:] [:upper:])" ]] && echo TRUE $ [[ "REVISION" == "$(echo revision | tr [:lower:] [:upper:])" ]] && echo TRUE TRUE One of us has another bug to report...
I personally think this whole eclass is overly complicated and tries to do too much stuff for no good reason.
(In reply to comment #10) > I personally think this whole eclass is overly complicated Exactly where?
(In reply to comment #11) > (In reply to comment #10) > > I personally think this whole eclass is overly complicated > > Exactly where? > It duplicates the functionality of epatch in eutils.eclass unnecessarily. It's trying to provide one huge src_unpack() to rule them all, that needs to be trimmed down.
subversion__to_upper_case() is gone completely. Basic svn switch support is there. but no svn switch --reloate.
Hello all, I think there is a little bug in the subversion.eclass. I have a little ebuild which uses subversion to install. The variable ESVN_REPO_URI is set. Yesterday, the ebuild was working, but today it doesn't work anymore. Sorry, if I post to the wrong Bug, but maybe the issue is related to this one, because of the ESVN_REPO_URI. This is the output of emerge: >>> Merging net-firewall/gateway-5.1.0 to /root/gateway/rootfs/ * * ERROR: net-firewall/gateway-5.1.0 failed. * Call stack: * ebuild.sh, line 49: Called pkg_preinst * environment, line 1910: Called subversion_pkg_preinst * environment, line 2281: Called subversion_wc_info * environment, line 2302: Called subversion__get_repository_uri 'pkg_preinst' * environment, line 2124: Called die * The specific snippet of code: * die "${ESVN}: ESVN_REPO_URI (or specified URI) is empty."; * The die message: * subversion: ESVN_REPO_URI (or specified URI) is empty. * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/net-firewall/gateway-5.1.0/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-firewall/gateway-5.1.0/temp/environment'. There seems to be a missing argument in the function _pkg_preinst: subversion_wc_info() { local repo_uri="$(subversion__get_repository_uri "${1}")" local wc_path="$(subversion__get_wc_path "${repo_uri}")" ... ... subversion_pkg_preinst() { local pkgdate=$(date "+%Y%m%d %H:%M:%S") subversion_wc_info ^^^^^ ${1} in subversion_wc_info would be empty in this case. Best regards Elmar
(In reply to comment #14) > Sorry, if I post to the wrong Bug, but maybe the issue is related to this > one, because of the ESVN_REPO_URI. It is the wrong bug but nonetheless thanks for reporting. It should be fixed now.
*** Bug 269771 has been marked as a duplicate of this bug. ***
Created attachment 204402 [details, diff] simpler: just add relocate option, maybe as first step to committing the previously attached patch
(In reply to comment #17) > Created an attachment (id=204402) [details] > simpler: just add relocate option, maybe as first step to committing the > previously attached patch Has anyone reviewed this? It's very simple and should not break anything - can't this be just committed, saving zillions of Bytes being uselessly retransmitted because fellow gento0ers don't know about --relocate nor how to patch subversion.eclass with it so they end up deleting the full repo and redownloading it?
