Re: [gentoo-dev] bzr.eclass
On 17:19 Sat 14 Feb , Jorge Manuel B. S. Vicetto wrote:
> # @ECLASS-VARIABLE: EBZR_DIFFSTAT_CMD
> # @DESCRIPTION:
> -# The bzr command to get the diffstat output.
> -EBZR_DIFFSTAT_CMD="bzr diff"
> +# The bzr command to get the diff output.
> +EBZR_DIFF_CMD="bzr diff"
> + ${EBZR_DIFF_CMD} | diffstat
Why does this need to happen? Please add a comment.
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpZMN9UThynW.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Harring wrote: > On Wed, Feb 11, 2009 at 02:01:24AM -0800, Zac Medico wrote: >> Brian Harring wrote: >>> On Tue, Feb 10, 2009 at 12:55:51PM -0800, Zac Medico wrote: Brian Harring wrote: > Frankly, forget compatibility- the current format could stand to die. > The repository format is an ever growing mess- leave it as is and > work on cutting over to something sane. Changing the repository layout is a pretty radical thing to do. You're welcome to start a new subject for that if you'd like but I'd prefer to keep the scope of this thread focussed on the cache format for the existing repository layout. >> I don't intend to repeal the cache mtime requirement, at least >> (especially) not on gentoo's rsync tree. However, I wouldn't say >> that it's something that necessarily needs to be a requirement for >> other repositories or overlays, moving forward (assuming that an >> alternative validation framework is in place). > > So... you want a subset of repositories to have cache algo x, while > the rest have the old algo. And since the repo w/ algo x isn't > marked in some fashion, all managers will have to use new algo x for > compatibility reasons. Right... Clients using either validation mechanism can consume the same cache. If the client recognizes DIGESTS data and it's available in a given cache entry, naturally the client should prefer the DIGESTS validation mechanism because it's more reliable. >>> I reiterate, this belongs in a seperate repository format, along w/ >>> the rest of the unversioned repository changes you've been pushing in >>> (profile package.mask breaking all non portage PMs is a perfect >>> example). >> The package.mask thing is a separate discussion. Let's do that in a >> separate thread. > > Package.mask is relevant purely as a demonstration of why unversioned > changes to the repository formats *needs* to stop. Generally speaking > it's pretty shitty behaviour to embrace/extend a format when others > rely on it for interop. I agree that it's a poor practice to change the format in ways that are not inter-operable. However, as said above, introduction of the DIGESTS data is inter-operable. > The annoying thing about this thread is that *no where* am I saying > you shouldn't be free to experiment. All I'm stating is that the end > result isn't a compatible repo- it *is* a new format (version even) > thus mark it in some way so that the rest of us can start properly > handling it rather then having to cut last minute releases since we're > PMS compliant but portage treats PMS as a subset of it's format rules. As said, the end result of introducing the DIGESTS data _is_ a compatible repo. > Pretty simple request, and not something that shouuld require argument > as far as I'm concerned. >>> The daft thing about this is that w/ effectively atomic sync (if the >>> sync fails then mark the repo as screwed up till a sync completes), >>> the current cache format can *still* do validation- no clue if >>> paludis has it, but at least pkgcore and portage can handle this via >>> awareness of the eclass stacking. >> I want to have a more fault-tolerant solution than that. > > I understand your reasoning, and frankly I used to view the rsync > issue in the same way- it's a naive view however since it implicitly > is assuming that the resultant repo is *usable*, iow that the actual > ebuild/eclass/profile data is valid, just that the updating bailed > during metadata transfer. There is zero gurantee as to where the > rsync bailed- meaning you can be missing patches, have trashed > manifests, etc. > > Well aware it's not friendly to require people to force a completed > sync before being able to use the repo, but it really is the only > *safe* option- as such the fault tolerant counterarg is a non > arguement. Problems aren't only triggered by sync issues. For example, suppose that the user has locally modified an eclass in a way that results in a metadata change. The DIGESTS data will provide enough information to detect cases such as this. Without this data, the user may be left scratching their head, wondering why their eclass change hasn't been accounted for. >>> Note that proper PM implementations *still* have to set the cache >>> entries mtime for backwards compatibility w/ older PMs that don't >>> support this new unversioned change thus muddying the implementation >>> even further. >> As said above, I wasn't intending that, at least (especially) not >> for gentoo's rsync tree. I guess you got that idea from the mention >> of bug 139134, but you don't need to worry about it. > > Implicitly it's required; if pkgcore is to generate cache entries for > repo x, it has to do exactly as I said so that any any pre > cache-modified-managers are still able to use the cache. That's > assuming the $PM cares about compatibility... As said, clients using either va
Re: [gentoo-dev] bzr.eclass
Hi.
Christian Faulhammer wrote:
> Hi,
>
> a user maintained a Bazaar overlay for some time now and introduced
> some changes to bzr eclass, I would like to introduce into the tree.
> Please review the attached patch.
>
> V-Li
I'm attaching a revised patch that tries to improve some issues in the
current version in the tree, incorporates your changes and Peter
Volkov's (pva) patch about sftp URIs.
--
Regards,
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
Index: bzr.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/bzr.eclass,v
retrieving revision 1.1
diff -u -b -B -r1.1 bzr.eclass
--- bzr.eclass 25 Oct 2008 12:17:23 - 1.1
+++ bzr.eclass 14 Feb 2009 18:03:39 -
@@ -6,6 +6,8 @@
# @MAINTAINER:
# Jorge Manuel B. S. Vicetto ,
# Ulrich Mueller ,
+# Christian Faulhammer
+# Mark Lee ,
# and anyone who wants to help
# @BLURB: This eclass provides support to use the Bazaar DSCM
# @DESCRIPTION:
@@ -25,7 +27,8 @@
HOMEPAGE="http://bazaar-vcs.org/";
DESCRIPTION="Based on the ${EBZR} eclass"
-DEPEND=">=dev-util/bzr-1.5"
+DEPEND=">=dev-util/bzr-1.5
+ dev-util/diffstat"
# @ECLASS-VARIABLE: EBZR_STORE_DIR
# @DESCRIPTION:
@@ -35,17 +38,17 @@
# @ECLASS-VARIABLE: EBZR_FETCH_CMD
# @DESCRIPTION:
# The bzr command to fetch the sources.
-EBZR_FETCH_CMD="bzr branch"
+EBZR_FETCH_CMD="bzr checkout --lightweight"
# @ECLASS-VARIABLE: EBZR_UPDATE_CMD
# @DESCRIPTION:
# The bzr command to update the sources.
-EBZR_UPDATE_CMD="bzr pull"
+EBZR_UPDATE_CMD="bzr update"
# @ECLASS-VARIABLE: EBZR_DIFFSTAT_CMD
# @DESCRIPTION:
-# The bzr command to get the diffstat output.
-EBZR_DIFFSTAT_CMD="bzr diff"
+# The bzr command to get the diff output.
+EBZR_DIFF_CMD="bzr diff"
# @ECLASS-VARIABLE: EBZR_EXPORT_CMD
# @DESCRIPTION:
@@ -72,10 +75,10 @@
# - https://
# - sftp://
# - rsync://
-# - lp://
+# - lp:
# @CODE
#
-# Note: lp = https://launchpad.net
+# Note: lp: seems to be an alias to https://launchpad.net
EBZR_REPO_URI="${EBZR_REPO_URI:-}"
# @ECLASS-VARIABLE: EBZR_BOOTSTRAP
@@ -112,12 +115,55 @@
# default: ${PN}
EBZR_CACHE_DIR="${EBZR_CACHE_DIR:-${PN}}"
+# @FUNCTION: bzr_initial_fetch
+# @DESCRIPTION:
+# Retrieves the source code from a repository for the first time, via
+# ${EBZR_FETCH_CMD}.
+bzr_initial_fetch() {
+ local repository="${1}";
+ local branch_dir="${2}";
+
+ # fetch branch
+ einfo "bzr fetch start -->"
+ einfo " repository: ${repository} => ${branch_dir}"
+
+ ${EBZR_FETCH_CMD} ${EBZR_OPTIONS} "${repository}" "${branch_dir}" \
+ || die "${EBZR}: can't branch from ${repository}."
+}
+
+# @FUNCTION: bzr_update
+# @DESCRIPTION:
+# Updates the source code from a repository, via ${EBZR_FETCH_CMD}.
+bzr_update() {
+ local repository="${1}";
+ local branch_dir="${2}";
+ local repo_type=$(bzr info "${EBZR_BRANCH_DIR}" | head -n 1 | cut -d '(' -f 1)
+
+ if [[ "${repo_type}" != "Lightweight checkout " ]]; then
+
+ einfo "Re-fetching the branch to save space..."
+ rm -rf "${EBZR_BRANCH_DIR}"
+ bzr_initial_fetch "${repository}" "${EBZR_BRANCH_DIR}"
+ else
+
+ # update branch
+ einfo "bzr update start -->"
+ einfo " repository: ${repository}"
+
+ pushd "${EBZR_BRANCH_DIR}"
+ ${EBZR_UPDATE_CMD} ${EBZR_OPTIONS} \
+ || die "${EBZR}: can't update from ${repository}."
+ ${EBZR_DIFF_CMD} | diffstat
+ popd
+ fi
+}
+
# @FUNCTION: bzr_fetch
# @DESCRIPTION:
# Wrapper function to fetch sources from bazaar via bzr fetch or bzr update,
# depending on whether there is an existing working copy in ${EBZR_BRANCH_DIR}.
bzr_fetch() {
- local EBZR_BRANCH_DIR
+ local EBZR_BRANCH_DIR repository
# EBZR_REPO_URI is empty.
[[ ${EBZR_REPO_URI} ]] || die "${EBZR}: EBZR_REPO_URI is empty."
@@ -125,8 +171,15 @@
# check for the protocol or pull from a local repo.
if [[ -z ${EBZR_REPO_URI%%:*} ]] ; then
case ${EBZR_REPO_URI%%:*} in
- # lp:// is https://launchpad.net
- http|https|rsync|sftp|lp)
+ # lp: seems to be an alias to https://launchpad.net
+ http|https|rsync|lp)
+;;
+ sftp)
+if ! built_with_use dev-util/bzr sftp; then
+ eerror "To fetch sources from ${EBZR_REPO_URI} you need sftp"
+ eerror "support in dev-util/bzr."
+ die "Please, rebuild dev-util/bzr with the sftp USE flag enabled."
+fi
;;
*)
die "${EBZR}: fetch from ${EBZR_REPO_URI%:*} is not yet implemented."
@@ -142,7 +195,7 @@
export SANDBOX_WRITE="${SANDBOX_WRITE%%:/}"
fi
- cd -P "${EBZR_STORE_DIR}" || die "${EBZR}: can't chdir to ${EBZR_STORE_DIR}"
+ pushd "${EBZR_STORE_DIR}" || die "${EBZR}: can't chdir to ${EBZR_STORE_DIR}"
EBZR_BRANCH_DIR="${EBZR_STORE_DIR}/${EBZR_CACHE_DIR}"
@@ -151,31 +204,18 @@
debug-print "${FUNCNAME}: EBZR_OPTIONS = ${EBZR_OPTIONS}"
- local repository
-
if [[ ${EBZR_REPO_URI} == */* ]]; then
- repository="${EBZR_REPO_URI}${EBZR_BRANCH}"
+ repository="${EBZR_REPO_URI}/${EBZR_BRANCH}"
+ elif [[ -n ${EB
[gentoo-dev] Re: bzr.eclass
Hi,
Ulrich Mueller :
> > On Sat, 14 Feb 2009, Christian Faulhammer wrote:
>
> > Please review the attached patch.
>
> + local repo_type=3D$(bzr info "${EBZR_BRANCH_DIR}" |
> head -n 1 | cut -d '= (' -f 1)
> + if [[ "${repo_type}" !=3D "Lightweight checkout
> " ]]; then
>
> This test looks very fragile to me. Could it be replaced by something
> else?
The refetching of old full checkouts is not needed, just a neat
feature. After looking at the repository structure a different test
could be the existence of .bzr/repository...lightweight checkouts don't
have it.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://www.faulhammer.org/>
signature.asc
Description: PGP signature
Re: [gentoo-dev] bzr.eclass
> On Sat, 14 Feb 2009, Christian Faulhammer wrote:
> Please review the attached patch.
+ local repo_type=3D$(bzr info "${EBZR_BRANCH_DIR}" | head -n 1 |
cut -d '=
(' -f 1)
+ if [[ "${repo_type}" !=3D "Lightweight checkout " ]]; then
This test looks very fragile to me. Could it be replaced by something
else?
Ulrich
Re: [gentoo-dev] Re: Live source based ebuild proposals
Ciaran McCreesh wrote: No. Really. Again. You've been steadily talking nonsense on this whole issue. Please step back, start again and clearly and concisely explain in coherent English how you solve the simple example I gave earlier in the thread. I am far from the only person who hasn't managed to work out your explanation of this simple case so far. Let try to clarify: main problem: - have the possibility to track upstream w/out having to take a manual snapshot of their sources, but having portage automatically fetch them from their tree. current situation: - we have some eclasses that on unpack phase fetch the sources from the upstream server, prepare them and then the usual ebuild process follows. - in order to make an ebuild using those eclasses be valued as the highest possible, the simplest solution had been give it a version "high enough", namely -. That makes simple track a single tree per package. - The same could be done with any version component in order to try to track multiple instances, so to track what will be the next 1.5 version, somebody could create an ebuild as 1.4. or 1.5_pre, being an arbitrary big number. -scm proposal: - use a component version that makes whatever before it valued as "the highest within that component", likely -r or _p do, that includes the case "the highest version in absolute" in order to arbitrary decide an "high enough" value, namely -. - from what you can find in the glep, the change is apparently purely cosmetic beside the hinted but not expressed possibilities having portage fully aware those ebuild manage something "live" could give. live-properity proposal: - have a property to make portage aware that the ebuild is using live sources. - it doesn't add components to the ebuild version but just marks the ebuild. So this proposal aims to improve portage internal management but doesn't add or detract anything regarding version resolution. live-template proposal: - you still have a new version component, in this case either ".live" or "_live", but in the template. - it isn't used directly in resolution but it generates automatically a normal version that get resolved as usual. - tries to make sure there is a way to get reproducible results regarding installed packages by embedding the informations to get again the same sources. So you can also re-emerge the very same package again you emerged it once since it has a defined version number. - tries to give developers willing to track upstream and then provide snapshots the ability to do that automatically. I hope that is what the various proponents meant with their proposals and that's clear enough. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: Live source based ebuild proposals
Ryan Hill wrote: I'm sorry, Luca, but I can't do what I want to do with your proposal. I'd like to know what you want to do. With the -scm suffix I can. Good to know, once you state what it is Actually I thought this was settled. What exactly is the issue holding GLEP 54 back that we need more discussion and different proposals? - the glep 54 draft was deem unspecified and about 6 month ago. Peper was asked by the council to add more details on why and how it is useful. Nobody did anything and now he isn't even more acting as proxy to Ciaranm requests. - since apparently some people even disliked that proposal basically because in their eyes it didn't add any to - in term of functionality people suggested to use a specific property to mark ebuilds as "live" and have portage act accordingly. - in addition some people (me being the main writer) started discussing what really they needed that - doesn't give already, focus being the ability to track live sources installed and possibly the ability to get from an ebuild using live sources to an ebuild using a snapshot automatically. Thus the half baked document I put in my devspace got in. If there weren't people quite vocal against -scm the council wouldn't have been involved. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
On Wed, Feb 11, 2009 at 02:01:24AM -0800, Zac Medico wrote: > Brian Harring wrote: > > On Tue, Feb 10, 2009 at 12:55:51PM -0800, Zac Medico wrote: > >> Brian Harring wrote: > >>> Frankly, forget compatibility- the current format could stand to die. > >>> The repository format is an ever growing mess- leave it as is and > >>> work on cutting over to something sane. > >> Changing the repository layout is a pretty radical thing to do. > >> You're welcome to start a new subject for that if you'd like but I'd > >> prefer to keep the scope of this thread focussed on the cache format > >> for the existing repository layout. > > I don't intend to repeal the cache mtime requirement, at least > (especially) not on gentoo's rsync tree. However, I wouldn't say > that it's something that necessarily needs to be a requirement for > other repositories or overlays, moving forward (assuming that an > alternative validation framework is in place). So... you want a subset of repositories to have cache algo x, while the rest have the old algo. And since the repo w/ algo x isn't marked in some fashion, all managers will have to use new algo x for compatibility reasons. Right... > > I reiterate, this belongs in a seperate repository format, along w/ > > the rest of the unversioned repository changes you've been pushing in > > (profile package.mask breaking all non portage PMs is a perfect > > example). > > The package.mask thing is a separate discussion. Let's do that in a > separate thread. Package.mask is relevant purely as a demonstration of why unversioned changes to the repository formats *needs* to stop. Generally speaking it's pretty shitty behaviour to embrace/extend a format when others rely on it for interop. The annoying thing about this thread is that *no where* am I saying you shouldn't be free to experiment. All I'm stating is that the end result isn't a compatible repo- it *is* a new format (version even) thus mark it in some way so that the rest of us can start properly handling it rather then having to cut last minute releases since we're PMS compliant but portage treats PMS as a subset of it's format rules. Pretty simple request, and not something that shouuld require argument as far as I'm concerned. > > The daft thing about this is that w/ effectively atomic sync (if the > > sync fails then mark the repo as screwed up till a sync completes), > > the current cache format can *still* do validation- no clue if > > paludis has it, but at least pkgcore and portage can handle this via > > awareness of the eclass stacking. > > I want to have a more fault-tolerant solution than that. I understand your reasoning, and frankly I used to view the rsync issue in the same way- it's a naive view however since it implicitly is assuming that the resultant repo is *usable*, iow that the actual ebuild/eclass/profile data is valid, just that the updating bailed during metadata transfer. There is zero gurantee as to where the rsync bailed- meaning you can be missing patches, have trashed manifests, etc. Well aware it's not friendly to require people to force a completed sync before being able to use the repo, but it really is the only *safe* option- as such the fault tolerant counterarg is a non arguement. > > Note that proper PM implementations *still* have to set the cache > > entries mtime for backwards compatibility w/ older PMs that don't > > support this new unversioned change thus muddying the implementation > > even further. > > As said above, I wasn't intending that, at least (especially) not > for gentoo's rsync tree. I guess you got that idea from the mention > of bug 139134, but you don't need to worry about it. Implicitly it's required; if pkgcore is to generate cache entries for repo x, it has to do exactly as I said so that any any pre cache-modified-managers are still able to use the cache. That's assuming the $PM cares about compatibility... ~harring pgpirUW2WrBOd.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/doc/de: lvm2.xml
Hi, "Michael MAnch (micm)" : Du hast einen Tippfehler in LDAP. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] bzr.eclass
Hi,
a user maintained a Bazaar overlay for some time now and introduced
some changes to bzr eclass, I would like to introduce into the tree.
Please review the attached patch.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
http://www.faulhammer.org/>
--- /usr/portage/eclass/bzr.eclass 2008-10-25 14:17:23.0 +0200
+++ eclass/bzr.eclass 2009-02-13 22:54:39.0 +0100
@@ -6,6 +6,8 @@
# @MAINTAINER:
# Jorge Manuel B. S. Vicetto ,
# Ulrich Mueller ,
+# Christian Faulhammer
+# Mark Lee ,
# and anyone who wants to help
# @BLURB: This eclass provides support to use the Bazaar DSCM
# @DESCRIPTION:
@@ -25,7 +27,8 @@
HOMEPAGE="http://bazaar-vcs.org/";
DESCRIPTION="Based on the ${EBZR} eclass"
-DEPEND=">=dev-util/bzr-1.5"
+DEPEND=">=dev-util/bzr-1.5
+ dev-util/diffstat"
# @ECLASS-VARIABLE: EBZR_STORE_DIR
# @DESCRIPTION:
@@ -35,17 +38,17 @@
# @ECLASS-VARIABLE: EBZR_FETCH_CMD
# @DESCRIPTION:
# The bzr command to fetch the sources.
-EBZR_FETCH_CMD="bzr branch"
+EBZR_FETCH_CMD="bzr checkout --lightweight"
# @ECLASS-VARIABLE: EBZR_UPDATE_CMD
# @DESCRIPTION:
# The bzr command to update the sources.
-EBZR_UPDATE_CMD="bzr pull"
+EBZR_UPDATE_CMD="bzr update"
# @ECLASS-VARIABLE: EBZR_DIFFSTAT_CMD
# @DESCRIPTION:
-# The bzr command to get the diffstat output.
-EBZR_DIFFSTAT_CMD="bzr diff"
+# The bzr command to get the diff output.
+EBZR_DIFF_CMD="bzr diff"
# @ECLASS-VARIABLE: EBZR_EXPORT_CMD
# @DESCRIPTION:
@@ -112,12 +115,27 @@
# default: ${PN}
EBZR_CACHE_DIR="${EBZR_CACHE_DIR:-${PN}}"
+# @FUNCTION: bzr_initial_fetch
+# @DESCRIPTION:
+# Retrieves the source code from a repository for the first time, via
+# ${EBZR_FETCH_CMD}.
+bzr_initial_fetch() {
+ local repository="${1}";
+ local branch_dir="${2}";
+ # fetch branch
+ einfo "bzr fetch start -->"
+ einfo " repository: ${repository} => ${branch_dir}"
+
+ ${EBZR_FETCH_CMD} ${EBZR_OPTIONS} "${repository}" "${branch_dir}" \
+ || die "${EBZR}: can't branch from ${repository}."
+}
+
# @FUNCTION: bzr_fetch
# @DESCRIPTION:
# Wrapper function to fetch sources from bazaar via bzr fetch or bzr update,
# depending on whether there is an existing working copy in ${EBZR_BRANCH_DIR}.
bzr_fetch() {
- local EBZR_BRANCH_DIR
+ local EBZR_BRANCH_DIR repository
# EBZR_REPO_URI is empty.
[[ ${EBZR_REPO_URI} ]] || die "${EBZR}: EBZR_REPO_URI is empty."
@@ -151,31 +169,32 @@
debug-print "${FUNCNAME}: EBZR_OPTIONS = ${EBZR_OPTIONS}"
- local repository
-
if [[ ${EBZR_REPO_URI} == */* ]]; then
- repository="${EBZR_REPO_URI}${EBZR_BRANCH}"
+ repository="${EBZR_REPO_URI}/${EBZR_BRANCH}"
+ elif [[ -n ${EBZR_BRANCH} ]] ; then
+ repository="${EBZR_REPO_URI}/${EBZR_BRANCH}"
else
repository="${EBZR_REPO_URI}"
fi
if [[ ! -d ${EBZR_BRANCH_DIR} ]] ; then
- # fetch branch
- einfo "bzr branch start -->"
- einfo " repository: ${repository} => ${EBZR_BRANCH_DIR}"
-
- ${EBZR_FETCH_CMD} ${EBZR_OPTIONS} "${repository}" "${EBZR_BRANCH_DIR}" \
- || die "${EBZR}: can't branch from ${repository}."
-
+ bzr_initial_fetch "${repository}" "${EBZR_BRANCH_DIR}"
else
- # update branch
- einfo "bzr pull start -->"
- einfo " repository: ${repository}"
-
- cd "${EBZR_BRANCH_DIR}"
- ${EBZR_UPDATE_CMD} ${EBZR_OPTIONS} "${repository}" \
- || die "${EBZR}: can't merge from ${repository}."
- ${EBZR_DIFFSTAT_CMD}
+ local repo_type=$(bzr info "${EBZR_BRANCH_DIR}" | head -n 1 | cut -d '(' -f 1)
+ if [[ "${repo_type}" != "Lightweight checkout " ]]; then
+ einfo "Re-fetching the branch to save space..."
+ rm -rf "${EBZR_BRANCH_DIR}"
+ bzr_initial_fetch "${repository}" "${EBZR_BRANCH_DIR}"
+ else
+ # update branch
+ einfo "bzr update start -->"
+ einfo " repository: ${repository}"
+
+ cd "${EBZR_BRANCH_DIR}"
+ ${EBZR_UPDATE_CMD} ${EBZR_OPTIONS} \
+|| die "${EBZR}: can't update from ${repository}."
+ ${EBZR_DIFF_CMD} | diffstat
+ fi
fi
cd "${EBZR_BRANCH_DIR}"
signature.asc
Description: PGP signature
