|[eclipse.org-architecture-council] [Bug 249745] Eclipse Repository Best Practices|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=249745 Product/Component: Community / Architecture Council Dave Orme <djo@xxxxxxxxxxxxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |djo@coconut-palm- | |software.com --- Comment #3 from Dave Orme <djo@xxxxxxxxxxxxxxxxxxxxxxxxx> 2008-10-06 10:02:49 -0400 --- A year and a bit ago, I contracted with a company that does not allow SSH through the firewall. So I was in the market for something that: * Allows version control over HTTP. * Has a decent Eclipse plugin. * Has traction, particularly in the Java community. * Is well-supported on all platforms Java developers use, particularly Windows. * Is *not* Subversion, for all the reasons already documented in the mailing list thread. It turns out that with only minor caveats, Mercurial fits all of these qualities today for the work that I do and seems to be a reasonable candidate going forward. === Version control over HTTP === Mercurial can expose a repository through a regular HTTP web page using CGI or Fast-CGI. It uses regular old HTTP post, so if the site is accessible, version control Just Works. The same web site that exposes version control also automatically doubles as a ViewVC-style web interface to the repository. Sweet. This makes server-side security really easy too, since you can use HTTPS and Apache authentication to secure the repository and don't have to give out full SSH logins to people you barely know. === Has a decent Eclipse plugin === When I started, Mercurial's plugin was usable, but barely so. Today, it is fully featured, but needs another 3 months of hard usage in the wild to get all the last niggling bugs out. Particularly, when cloning repositories the plugin sometimes doesn't get it right. But all the day-to-day commit/push/pull/merge operations work well now. But I've been amazed at how quickly the Mercurial Eclipse plugin has progressed. It's really a nice piece of software already and will soon be even better. === Has traction, particularly in the Java community === Mercurial is the only distributed version control system to be widely used for large Java projects. In particular, the large Sun Microsystems open source projects like OpenJDK and NetBeans now use Mercurial. Outside of the Java space, Mozilla.org has standardized on Mercurial for their version control. With large customers like these, we can be assured that Mercurial will be well-supported for years to come. === Is well supported across all Java developers' OSs === Mercurial is one of the few distributed version control systems that runs as well on Windows as on Unix-based operating systems. Since the vast majority of Eclipse users run Windows, this is important. === How has it gone? === Over the past 6-9 months, I've been using Mercurial more and more exclusively for new development. * Initially, the Eclipse tooling was a bear to work with. But the Eclipse tooling has now stabilized and has become (mostly) a joy to use. * As mentioned above, Mercurial has been a joy to work with on the server side. * On the client side, I've gotten addicted to always having instantaneous access to my full repository history even when I'm on an airplane, because it's always on my local hard drive. * As everyone says, branching and merging is much easier than with CVS or SVNâ¦ * I love how Mercurial doesn't spatter .cvs or .svn-like folders all over my repository. Rather, there's one .hg folder in the root of the repository. This makes searching my repository from the command-line or Windows Explorer easy again. === Conclusion === Someone will ask, âWhy not Git, or some other DVCS?â The answer is simple: 1. To my knowledge, Mercurial is the only DVCS with a mature Eclipse plugin. 2. Mercurial is the only DVCS used widely on very large Java open-source projects. For this developer, Mercurial has proven to be everything I've wanted in the near term. From what I've seen so far, I could also imagine it being a good choice for Eclipse in the long term. -- Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
Back to the top