At Thu, 24 Oct 2013 10:03:14 -0400, Greg Von Kuster wrote:
Hello Simon,
On Oct 23, 2013, at 5:01 PM, Simon Guest <simon.guest@agresearch.co.nz> wrote:
We've noticed a funny about resetting repository metadata from the toolshed web interface.
My understanding is that this is used to get the toolshed back in sync with the underlying mercurial repo, for example after pushing updates from hg on the command line.
This is not quite correct. When committing a new changeset to a repository (either via hg push from the command line or by using any feature in the Tool Shed's upload component), metadata is reset on the repository automatically, but only back to the previous installable changeset revision if one exists. So for those repositories that have multiple changeset revisions, not all of the repository changelog is inspected with a new commit.
The "Reset all repository metadata" feature, however, does inspect the complete repository changelog and resets metadata from revision 0 through the repository tip. In addition to being useful for the current repository itself, it can also be useful for all other repositories that have a dependency relationship to it. See http://wiki.galaxyproject.org/RepositoryRevisions#Resetting_metadata_on_your....
In general, it is not necessary to use this feature.
Hi Greg, Thanks for the explanation, and the link to that helpful Wiki page. And also that code update 11114:71c35dbde130 which will help our tool test/development cycle. I have a remaining question, though, about the recommended working practices for developing a toolshed tool. I didn't find this described on the Wiki. There is obviously a cycle of development to go through, making updates, installing to a test galaxy instance, etc. It seems to us that the only sensible way to handle this is within a local test toolshed, essentially using the repo in the test toolshed as a development repo (despite the warnings not use the toolshed as a source code repo on the Wiki!). During such an iterative process, we don't want to keep bumping the tool version. Therefore it seems necessary to reset the repository meta data after every push, in order to install the just-updated-for-testing tool. Once the tool is working, the files can be uploaded into a clean repo on a production toolshed, so we don't keep all the intermediate development versions. Or is there a better way to do this? cheers, Simon