Version Control interface: Mercury for Unity (First release)

Announcing Mercury for Unity, a unified interface for a common set of version control commands. Add, commit, push, pull, check the logs, forget files, access the command line, and more, all without leaving the comfort and convenience of the Unity editor. Mercury for Unity was developed by our studio, and is used in our studio projects.

Mercury for Unity in the Asset Store

Useful notes:

* Mercury for Unity is a version control interface. It is not version control software. You will first need to install appropriate version control software to use Mercury for Unity.

* Mercury for Unity will use any "hgignore.txt" file in the default Mercury for Unity install folder as the repositories' ignore file. A default "hgignore.txt" file is provided, and is used in our projects.

* In addition, any "hgrc.txt" file in the default Mercury for Unity install folder will be used as a configuration file for the local repository. We provide the same "hgrc example.txt" that we use to template our projects. Simply rename this file to "hgrc.txt" and fill in the details as desired. Our default "hgignore.txt" is set up to take into account the renamed file.

* Mercury for Unity will use the username given in an appropriate "hgrc.txt" file as the username for commit commands. Simply type in an appropriate message, leave the username blank, and commit.

* Mercury for Unity will automatically initialize an appropriate repository in your solution folder if one is not already present. If an appropriate repository is already present, then that repository will be used for all operations.

* Every single line of every single script file contained in the Mercury for Unity download can be checked to ensure that we are being open, above-board, and honest. We simply ask that if you find any security holes or problems in our code, you tell us first, so we have a fair chance to patch them.

* Mercury for Unity is used in our own projects, and is developed based on the commands we use most often. And, of course, we are open for feedback, and eager to improve this tool. After all, we use it too.

* Mercury for Unity will unfortunately not make you a cheese sandwich.

 

New release bug: New repository initialization was not proceeding correctly. This has been fixed, and the fix submitted to the Asset Store. In the meantime, Mercury for Unity may experience problems properly initializing the ".hg" folder.

We apologize for the inconvenience, and are working to ensure no further difficulties.

 

Update: Initialization bug fix update has been accepted to the Asset Store.

 

It has become clear that, at this point, it is time to ask for community feedback.

If you investigated the plugin, and decided not to purchase it, what motivated your decision?
If you simply don't find it interesting, what could or would have to change for you to find it interesting?
Is the explanation too vague? (certain names were left out, out of legal concerns. I Am Not A Lawyer)

Or, if you are planning to purchase the plugin, but have left purchase for later, what improvements, additions or changes could make the plugin better meet your needs?

 

As the Description is short I can only orientate at the screenshot provided in the AssetStore page. To me it seems each command has a monobehavior script and thus must be attached to a gameobject. If so thats "weird" to me since I would expect some kind of menu command or window and not an object in a scene.
There is no acces to the documentation. People like to know what they purchase upfront. Also a video on how to use it would help to see what it actually does (better than command line).
I hesitate to change the versioning scheme during a project since it may break something. Can your plugin hook up this case and be used without worries?
The versioning software is "mercurial" and i guess people can't find your plugin "mercury" (planet?) when they search for it.
There already is a mercurial plugin in the AS which shows branches, resolves conflicts etc and IS NOT JUST a wrapper for the commands. And it costs less than yours.

Thats what immediately comes to my mind.

 

You do have valid points, and a price adjustment is indicated. Taking your points in turn,

The scripts themselves work through the editor, and the two GameObjects which contain the "client-facing" scripts are contained in the project folder "Mercury for Unity". Nothing needs to be added to the scene.

I had thought that .pdfs would be visible in the store, but it seems not - Something I should have checked. Is there a preferred format for documentation that you know of? I didn't find any in the FAQs, myself. .txt would probably be visible.

If there's an existing .hg folder in the solution folder, Mercury for Unity will just use that. It's intended primarily to automate common tasks I found myself having to drop out of the editor or use the command line script for.

I'm unsure how much, if anything, I can use the actual version software's name in relation to my thin client interface. Which presents problems, to say the least. I'm hesitant to sink more money into what has been, so far, a money sink. I have heard there's free legal advice sites, so perhaps I should investigate those...

That would be a primary motivation to reduce the cost. I set its cost by the table given, and received no feedback otherwise, so I had assumed that the cost was viable. I will take greater care in the future.

Thank you for your feedback. I appreciate it. Expect an update soon, and if anyone is planning on purchasing it, wait until the price drop.

 

If you make the included pdf documentation available for download separately would be a good start.

I also have no clues about this legal stuff but this way your product can hardly be found if someone searches for it. instead of asking a lawyer (money) try to ask the mercurial people first. since its open source i doubt they will block you like proprietary software vendors would do. Also other software products (plugins, community patches, skins etc) refer to the name of the software they are for. so i guess it can't be completetly forbidden as long as you make sure you don't own the name/product but just extend it in some way.

you are welcome.

and don't forget to make a short usage video. imo these help alot to decide if one likes a product or not.

 

Update: Had to re-install Windows recently. Still trying to find/recover all my files, including this project.

In the mean time, would you happen to know if there's a place to adjust a store package on the website?

 

Do you actually mean that you were not using source control for your own source control plug-in?

 

Of course I am. The first thing I did with it was commit itself to source control.

I also didn't push after adding the publisher tools, but before Windows decided to start going crazy.

Yes. Irony.

I do, however, have a continuous backup of my entire computer, updated just a few hours before I re-installed Windows. However, on my last attempt to download from the web server, it glitched.

I'll be taking another crack at it tonight.

Edit: On further thought, this post may sound angry. That is not my intent.

 

A massive price reduction and update to 4.6 has been submitted.

Would it be better to build it in an earlier version, say 3.5? That seems like something that may allow more people to use it.

 

Massive price reduction and update accepted; there is now a .txt documentation.

In addition, updates are being planned that will see this turned into a much more viable product.