dev@glassfish.java.net

Re: Mercurial Migration

From: Jason Lee <jason_at_steeplesoft.com>
Date: Fri, 19 Oct 2007 11:41:37 -0500

That makes sense. I kinda thought java.net might be a limiting factor. In
fact, for a project there I own, I'd like to use hg, but I'd have to host it
somewhere else, which I'm cool with, but I'll have the same issues you're
facing. :)

Thanks for the feedback. It helped a lot. :)

On 10/19/07, Jerome Dochez <Jerome.Dochez_at_sun.com> wrote:
>
> 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
>
>
>


-- 
Jason Lee, SCJP
Software Architect -- Objectstream, Inc.
JSF RI Dev Team
http://blogs.steeplesoft.com