Community
Participate
Working Groups
I'd like Eclipse to be aware of and able to see a Mercurial repository clone, when branching (i.e. 'hg clone'). It should also be possible to switch between different branches without the back-end hassle. The problem is, that Mercurial copies the project folder, which is not visible in Eclipse. Furthermore depending projects will not automatically use the new project after importing it Eclipse. My suggestion would be to have more meta information for the project, which should contain a directory pointer to the 'active' sub-folder system to be used. Example: Project name: my-project trunk workspace folder: my-project/tip a branch/clone workspace folder: my-project/named-clone another clone workspace folder: my-project/another-named-clone If 'my-project' is selected, then the trunk workspace folder is used - and is the only visible project in the Eclipse Package Explorer. When a clone is created the workspace folder will be created and used as the Eclipse source folder for that project - any projects depending on 'my-project' will - transparently - be using the built classes from 'my-project/named-clone' instead, of course, it should be possible to see this information ('tip' or 'named-clone') in the Eclipse Package Explorer. Why I chose to propose Mercurial over Bazaar and git: git - is to my knowledge linux + mac only with the possibility of using cygwin for Windows, which is an awful shame, but if it isn't truly multi platform, then it simply scores lower otherwise it would most likely be my choice. Bazaar - I haven't tried this one, but according to this unscientific and semi-old blog: http://sayspy.blogspot.com/2006/11/bazaar-vs-mercurial-unscientific.html it is slower than Mercurial, which some would see as a problem. (see Linus Torvalds' Google Talk on 'git' http://www.youtube.com/watch?v=4XpnKHJAok8 ). References: Mercurial - http://www.selenic.com/mercurial/wiki/ Bazaar - http://bazaar-vcs.org/ git - http://git.or.cz/ -- Per Holst
The Eclipse Platform team just doesn't have the resources to implement additional repository providers. Contributions are welcome but, when talking about an implementation of this size, a better approach is probably to start a separate Eclipse project as Subversive did for Subversion support.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
