Hi Jason
good question.
the principal reason for not moving to Mercurial immediately is
infrastructure. We have a lot of problems associated with the fact
java.net does not support mercurial yet. That would mean that not only
we would need to host and manage the mercurial server (ok we are sun,
hardware is cheap here) but also find ways to authenticate users using
their java.net ids and so on. Unfortunetely, java.net does not provide
an API to do authentication nor does it allow to export the projects
users list and password). So the infrastructure support was becoming a
resource sink rapidly
Some other factor tickled in like the absence of IDEs integration
which is likely to have impact on developer productivity plus good
learning material on the web to get to know how to use mercurial.
So we are basically buying time for those reasons.
We have run some experiments on the svn -> hg migration and Paul Sterk
can give you more details but basically they were successful, far
better than cvs->hg which we neven managed to make work. So in a
sense, if you don't have infrastructure issues, and you only use
netbeans which is the only IDE supporting mercurial so far (Intellij
has an early plugin, not sure about eclpse), then I think that a quick
turnaround from svn to hg is entirely possible.
HTH, jerome
On Oct 19, 2007, at 8:45 AM, Jason Lee wrote:
> I have a question about the proposed/planned Mercurial migration.
> From the traffic I've seen, it appears that the migration will be
> slow, due to the nature/maturity of the CVS->Hg migration tools,
> thus requiring a sojourn in the land of Subversion, which is
> understandable. What I *don't* understand though (and I'm hoping
> someone can explain to me) is why the migration path is CVS-
> >Subversion->Wait a while->Mercurial? Why the long delay under
> svn? Not having analyzed things as closely as I'm sure Those in
> Charge have, it would seem that one could simply migrate the repo to
> svn, then turn right around and migrate THAT to hg, thus avoiding
> requiring devs to learn a "temporary" tool.
>
> I ask, as I MIGHT be able to get my organization to consider making
> an identical move, so I've been watching GlassFish's efforts (and
> OpenJDK's to a lesser extent) to see what gotchas will be discovered.
>
> Thanks!
>
> --
> Jason Lee, SCJP
> Software Architect -- Objectstream, Inc.
> JSF RI Dev Team
> http://blogs.steeplesoft.com