reporegistory: disable Open for deleted repository, add re-clone from remote
Created originally on Bitbucket by tin-pot (Martin Hofmann)
See https://bitbucket.org/tortoisehg/thg/issues/4313/#comment-22280927
Original text:
The Repository Registry pane in the Workbench of TortoiseHg is a really nice way to keep track of one's Hg repositories, alleviating the need to remember where they all are, or to manually seek for these repositories in the file system, using eg Windows Explorer.
Consider however the following (IMO rather typical) scenario:
A developer wants to make some changes to a repository of her, which is hosted on a remote server (think Bitbucket et al). She gets a clone down from the host to the local filesystem to start working on the code.
When finished, she commits her changes, pushes them back to the remote repository, and - because there's no more need for the local clone - wipes the working repository from the disk.
Now the Repository Registry in fact does remember there was this local repository long after it's gone, and shows it in its pane.
However: All the items in the pane look the same. The only way to detect if a repository actually still exists (in the file system) is to try one of the commands provided eg in the context menu: Explore, Open, etc. If there is no actual repository, the effect depends on the command: Open gives an appropriate error message box, Explore just does nothing, etc.
I'd like to think that improvements like the following would be really useful:
-
Wouldn't it be nice if one could see at first glance which of the repositories listed in the Repostory Registry do still exist in the file system? For example, the hint could be a different icon, or a greyed-out item, or an italic font etc.
-
Wouldn't it be nice if the Repository Registry would offer only these commands (ie enable them in the context menu) which are applicable to a non-existing repository? I think that would be Copy Path, Rename, and Remove from Registry.
-
Wouldn't it be nice if the Repository Registry would also remember where a repository was cloned from, even beyond that repositories lifetime? In the scenario above, if the developer wants to work on the remote repostitory again the next time, the URL to clone from (pointing to the remote host) would still be there right in the Repository Registry
So the Workbench could scan (in the file system) for non-existing repositories listed in the Repository Registry and mark them appropriately, adapting the enabled commands in the context menu or elsewhere for the missing ones. The Clone item would probably be better enabled, because the subsequent Clone dialog box would be the perfect place to fill in the remembered remote URL, if there is one. So re-cloning a "remembered" repository would only require hitting Clone in that dialog.
Looking for a handful of directories in the local files system should
be really quick, unless a remembered repository path points to a drive
that is no longer mounted (a USB stick, say), which could take longer
to detect - I'm not sure. Restricting the scan for directories to file
systems that are fast and available from the start should avoid problems
in this area (eg do not search on a A:
floppy disk drive ;-).
Depending on the amount of information the Repository Registry keeps about each repository, a Properties dialog box might also be helpful, because the only way -as far as I can tell - to see the path to a "registered" repository now is to either try and access it (Open/Explore/Terminal) or to invoke Copy Path and paste the path somewhere in order to read it. A remembered URL would lead to similar questions.
What do you think about this?