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.
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
>> Summer of Code student working on the Mercurial -push-> Subversion
>> problem we were talking about:
>> 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
>> to the Mercurial clone back to Subversion. The current technique is
>> 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
>>>>> 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
>>>>> you: http://www.selenic.com/mercurial/wiki/index.cgi/
>>> 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
>> devel mailing list
> Jeff Squyres
> Cisco Systems
> devel mailing list