Hi Eric, Despite the fact that internal hg repositories are used, the idea is NOT to use them as development repositories - but ONLY push releases to the ToolShed. In the interests of reproducibility (other people might use your ToolShed entry in a workflow, or as a dependency), you should not be able to ever rewrite history or delete commits - something you can do with a git or hg repository but should generally avoid. i.e. Being allowed to "cleapup and start again" is blocked by the Galaxy goal of reproducibility. I personally prefer git to hg, and therefore use that for development tracking of my own ToolShed releases - but if you like hg then I would suggest using a BitBucket.org hosted hg repository for developing your tool. You can see examples here - many of these tools do have explicit dependencies on other tools/packages in the ToolShed (either my own, or from 3rd parties): https://github.com/peterjc/galaxy_blast https://github.com/peterjc/pico_galaxy Regards, Peter On Tue, Jun 24, 2014 at 1:15 PM, Eric Kuyt <eric.kuijt@wur.nl> wrote:
Hi All,
I am playing around with putting a tool in testtoolshed. Now when changes to dependency versions are detected, the toolshed detects a new version and a dropdown is created.
but sometimes I do not want this behavior when the first version was erroneous for example. I tried hg strip on the repository and pushing it back to the testtoolshed but sadly it didn't result in a clean repository but a multi-headered mess.
Is there a way to cleanup the remote repository and start over. And what would be a cleaner way to develop tools on a toolshed still making use of repository dependencies?
Thanks,
Eric