Summary: | bzr.eclass: export current revision after the checkout | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
Component: | Eclasses | Assignee: | 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
2010-10-30 10:19:07 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. sorry i've missed that this is bzr.eclass problem not darcs :( 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. 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? 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. 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.
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. (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. (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. (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. 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 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. (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. (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> 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? (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 :). |