A feature like this would be useful for a large project to stage the
transition from SVN to HG such that it does not occur abruptly. I
don't know if it would be useful or not as a permanent solution, but
something to consider.
It is certainly something interesting to watch.
-- Josh
On May 5, 2008, at 10:18 AM, Jeff Squyres wrote:
Depending on how that works, it could be quite interesting -- it opens
up the possibility of leaving SVN as the "back-end" repository, but
also fully supporting HG as well. I don't know if that's really
sensible / useful (i.e., why not fully convert to HG if we're going to
do HG), but it's an option...
On May 5, 2008, at 10:13 AM, Josh Hursey wrote:
Per our conversation in Chicago - It looks like Mercurial has a
Google
Summer of Code student working on the Mercurial -push-> Subversion
problem we were talking about:
http://code.google.com/soc/2008/hg/appinfo.html?
csaid=2757CDDD2156F1A7
For those not at the meeting this has to do with interoperability
between Subversion and Mercurial. Mercurial has decent tools for
making a read only copy of a Subversion repository (exactly like we
have just setup for Open MPI), but the problem is pushing changes
made
to the Mercurial clone back to Subversion. The current technique is
to
create a patch from Mercurial and apply it by hand to the Subversion
repository. Maybe this will be improved this summer.
-- Josh
On May 5, 2008, at 8:04 AM, Jeff Squyres wrote:
On May 5, 2008, at 7:49 AM, Terry Dontje wrote:
Mercurial is a fully distributed system. So instead of thinking
of /tmp
branch, you should think of publishing your repository, which has
your
commits in it. As I understand it, open-mpi.org is not set up for
publishing other repositories yet, but it is quite easy to set
up a
mercurial server; there are also several places that will host one
for
you: http://www.selenic.com/mercurial/wiki/index.cgi/
MercurialHosting
FWIW, our goal is to be able to have the OMPI developers be able to
use their same SVN username/password to be able to publish hg trees
on www.open-mpi.org
(or hg.open-mpi.org). But using an outside hosting service is also
a possibility.
It's not a high priority issue at the moment, but we'll be looking
into it in the not-distant future.
--
Jeff Squyres
Cisco Systems
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
Cisco Systems
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
