Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 343355

Summary: bzr.eclass: export current revision after the checkout
Product: Gentoo Linux Reporter: Michał Górny <mgorny>
Component: EclassesAssignee: bazaar+obsolete
Status: RESOLVED FIXED    
Severity: enhancement CC: qnikst, ulm
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
URL: https://bugs.launchpad.net/bzr/+bug/672330
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 311101    
Attachments: A patch exporting CRC32 of dirstate file

Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-10-30 10:19:07 UTC
I'd appreciate if bzr.eclass exported the current code revision after doing the checkout. This will allow programs to grab it from environment.bz2 and know which revision the package was built against.

A similar feature is already provided by git (EGIT_VERSION), hg (HG_REV_ID), subversion (ESVN_WC_REVISION) and even cvs (ECVS_VERSION and ESCM_VERSION).
Comment 1 Alexander Vershilov (RETIRED) gentoo-dev 2010-10-30 17:43:30 UTC
I don't know darcs very well but next chain:
darcs show repo | grep "Num Patches" | sed 's/ *//' | cut -s -d' ' -f3
will return current 'version'

It can be done because of meaning of num patches is similar to git version and hg revision. 
Comment 2 Alexander Vershilov (RETIRED) gentoo-dev 2010-10-30 17:44:45 UTC
sorry i've missed that this is bzr.eclass problem not darcs :(
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-10-31 14:24:50 UTC
It seems that a good command to get this is 'bzr revno --tree'. The '--tree' option is quite important here as otherwise bzr tends to grab the revno of remote repository.

On the other hand, the 'bzr testament' output could be safer. However, I don't know how to pass an equivalent of '--tree' there, and chaining one with the other seems even more pointless.
Comment 4 Ulrich Müller gentoo-dev 2010-11-01 09:10:16 UTC
Even with the --tree option, bzr revno still fetches about half a megabyte here. And it is slooow:

   emacs-trunk # time bzr revno --tree
   102048

   real    0m7.911s
   user    0m0.499s
   sys     0m0.056s

"bzr update" shows the revision when finished, maybe its output could be parsed?
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-11-01 12:19:29 UTC
Ah, I see... I'll try to find some way...

And if we're unable to find any sane way, we could still manually grep crc32 from .bzr/checkout/dirstate as some kind of solution.
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-11-01 12:41:04 UTC
Created attachment 252793 [details, diff]
A patch exporting CRC32 of dirstate file

This seems relatively safe, doesn't require any network interaction and is quite simple to implement.
Comment 7 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-11-01 16:16:52 UTC
Fauli, the CRC32 solution I've attached is enough for my needs and works fine. Could you state whether it could be applied so I could proceed with updating the code of smart-live-rebuild? Thank you.
Comment 8 Christian Faulhammer (RETIRED) gentoo-dev 2010-11-04 13:10:30 UTC
(In reply to comment #7)
> Fauli, the CRC32 solution I've attached is enough for my needs and works fine.
> Could you state whether it could be applied so I could proceed with updating
> the code of smart-live-rebuild? Thank you.

 I am not too happy with it, as it exports some kind of random value.  Maybe a upstream request to not access the remote tree for the revno would be great.
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-11-04 19:20:26 UTC
(In reply to comment #8)
>  I am not too happy with it, as it exports some kind of random value.  Maybe a
> upstream request to not access the remote tree for the revno would be great.

Well, that's not that random and it could be used to quickly check whether the checkout has changed or not. I don't mind brining a better solution in the future but this little thing would be of much use to me and I'd appreciate it very much.
Comment 10 Ulrich Müller gentoo-dev 2010-11-06 15:23:35 UTC
(In reply to comment #8)
>  I am not too happy with it, as it exports some kind of random value.
> Maybe a upstream request to not access the remote tree for the revno would
> be great.

For a non-lightweight checkout the revision is stored in .bzr/branch/last-revision which is a tiny file, one line of text only. Maybe upstream could be convinced to add it for lightweight checkouts too?

In the meantime, why not use the checksum solution? It's only a variable which doesn't hurt anyone.
Comment 11 Christian Faulhammer (RETIRED) gentoo-dev 2010-11-07 22:51:30 UTC
Applied.  Thanks for the cooperation.  I reported upstream (see URL field) and maybe we can simplify this block of code, too, then.

 if [[ -z ${EBZR_REVISION} ]]; then
                rsync -rlpgo --exclude=".bzr/" . "${WORKDIR}/${P}" \
                        || die "${EBZR}: export failed"
        else
                # revisions of a lightweight checkout are only available when online
                [[ -z ${EBZR_OFFLINE} || -d ${EBZR_BRANCH_DIR}/.bzr/repository ]] \
                        || die "${EBZR}: No support for revisions when off-line"
                ${EBZR_EXPORT_CMD} -r "${EBZR_REVISION}" "${WORKDIR}/${P}" \
                        || die "${EBZR}: export failed"
        fi
Comment 12 Ulrich Müller gentoo-dev 2011-02-06 23:37:02 UTC
The foreseen update of bzr.eclass (posted to gentoo-dev ML today) will use branches instead of checkouts. That means that the .bzr/checkout/dirstate file where the checksum was taken from will no longer exist.

The updated eclass will "export EBZR_REVNO=$(${EBZR_REVNO_CMD})". Is this variable name o.k.?

Any tools that are currently using EBZR_TREE_CRC32 will have to be updated to use the new variable. Therefore reopening.
Comment 13 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-02-08 15:35:40 UTC
(In reply to comment #12)
> The foreseen update of bzr.eclass (posted to gentoo-dev ML today) will use
> branches instead of checkouts. That means that the .bzr/checkout/dirstate file
> where the checksum was taken from will no longer exist.
> 
> The updated eclass will "export EBZR_REVNO=$(${EBZR_REVNO_CMD})". Is this
> variable name o.k.?

Sounds fine.

> Any tools that are currently using EBZR_TREE_CRC32 will have to be updated to
> use the new variable. Therefore reopening.

Thanks. AFAICS checkout path creation method has changed too, so I'll need to update that one too.
Comment 14 Ulrich Müller gentoo-dev 2011-02-08 15:46:10 UTC
(In reply to comment #13)
> Thanks. AFAICS checkout path creation method has changed too, so I'll need to
> update that one too.

Yes. And the latest version of the eclass exports EBZR_WC_PATH, which should hopefully simplify it.
<http://overlays.gentoo.org/proj/emacs/browser/emacs-overlay/eclass/bzr.eclass?rev=1612>
Comment 15 Ulrich Müller gentoo-dev 2011-02-10 22:25:12 UTC
New bzr.eclass committed to portage tree. smart-live-rebuild-0.7 seems to work fine with it.

Anything else that is still using EBZR_TREE_CRC32 and needs to be fixed?
Comment 16 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-02-11 08:34:49 UTC
(In reply to comment #15)
> New bzr.eclass committed to portage tree. smart-live-rebuild-0.7 seems to work
> fine with it.

Thanks for testing.

> Anything else that is still using EBZR_TREE_CRC32 and needs to be fixed?

Don't think so. I'll close it for you :).