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):




On Tue, Jun 24, 2014 at 1:15 PM, Eric Kuyt <eric.ku...@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
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:

Reply via email to