The facts:
- Sun and many other organizations have started considering moves to Mercurial. In Sun's case, it's a mandate for all Sun-managed OSS projects (OpenSolaris, OpenJDK, etc).
- Moving projects to Mercurial frequently (usually?) requires IDE/tool support.
- Sun's IDE/tools and those of many other organizations are Java-based (NetBeans, Eclipse, and so on).
- Mercurial is written in Python.
- Jython is an implementation of Python for the JVM.
Put simply: if you want to become an OSS rockstar tomorrow, get Mercurial running on Jython.
(credit for this idea goes to OpenJDK ambassador Tom Marble...I'm just trying to needle the OSS world into making it happen)
4 comments:
Excellent stratgizing! And timely too since Jython 2.2 is in its final release candidate stage.
PushToTest is releasing TestMaker 5 this coming week. We had planned to migrate to Subversion from CVS. Perhaps we should migrate to Mercurial?
Is there a migration guide to go from CVS to Mercurial? And is there some sort of comparitive guide explaining the advantages of Mercurial to Subversion?
-Frank
fcohen: I don't have any offhand, but I've seen some very convincing presentations on Hg and I know there are scads of articles out there comparing and presenting migration options. I'd expect they're largely Python scripts to import your CVS repository, but I'd also expect they probably work well.
The largest obvious advantage to Mercurial is that you have the entire repository available to you offline, so you can version, branch, revert, and commit without pushing anything to a common repository. Then when you're happy with what you've got, you can choose to do that push (the details here are a bit fuzzy to me).
The largest obvious disadvantage to Mercurial is that you have the entire repository available to you offline. In the case of a large project, that could be a lot of data you don't need. But I believe a future (or current) version of Hg supports partial repository pulls. Again, details a bit fuzzy for me here.
Famous last words, but a Jython implementation of mercurial would seem to be some while away. I had a quick look (quick == one lunchtime + a couple of excessively long compile cycles) and there are rather too many dependencies on libraries that just aren't available in Jython (BZ2, and heapq/itertools spring immediately to mind). Integrating shared libraries would be a non-trivial exercise, so one would be left with re-implementing those libraries in Jython or Java. For example, providing an interface to Apache Commons Compress that looks like the bz2 Python module. In itself, not particularly difficult, but not the ideal solution.
So much for my starry eyed dreams of OSS rockstar fame: "here's an implementation I prepared in my lunchbreak..." ;-)
Also looked into it. The snag I hit was the bdiff.py module. I didn't find an equivalent Java library for it.
Post a Comment