Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] [Bug 249745] Eclipse Repository Best Practices  
Product/Component: Community / Architecture Council

Dave Orme <djo@xxxxxxxxxxxxxxxxxxxxxxxxx> changed:

           What    |Removed                     |Added
                 CC|                            |djo@coconut-palm-
                   |                            |

--- 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
    * 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

=== 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, 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
    * 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
    * 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

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:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Back to the top