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.gu...@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
> In general, it is not necessary to use this feature.
Thanks for the explanation, and the link to that helpful Wiki page.
And also that code update 11114:71c35dbde130 which will help our tool
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?
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
To search Galaxy mailing lists use the unified search at: