Switching from SVN to Mercurial

[GoogleCodeExporter]

Kurt (kwmsmith) has suggested to switch f2py svn repository to mercurial 
repository. Googlecode provides instructions for that

http://code.google.com/p/support/wiki/ConvertingSvnToHg

Now I have the following questions:

  1) Does anyone have any objections for the switch? It would be nice if all f2py commiters could give a short answer whether they agree or disagree with the switch.

  2) Do we want to keep full log history?

Original issue reported on code.google.com by pearu.peterson on 25 Jul 2010 at 5:56

[GoogleCodeExporter]

Now I recalled that f2py setup.py scripts create __svn_version__.py
file using the svnrevision program. Is there any equivalent hg command
that would produce a revision number that would be usable in version strings?

Original comment by pearu.peterson on 25 Jul 2010 at 6:18

[GoogleCodeExporter]

Is there any reason to switch to mercurial? I mean, I wouldn't mind switching, 
but if there is no real reason to do the switch, then why the effort? Would we 
or the project benefit from using mercurial instead?

Original comment by omar.aw...@gmail.com on 26 Jul 2010 at 5:11

[GoogleCodeExporter]

CC'ing to Kurt.

This is a good question. Google gives many documents that compare
mercurial and subversion (and other) systems. Personally I am satisfied
with using subversion for the f2py project. Currently its development
is not too rapid and I don't see reasons for creating branches
(in which mercurial is much better than subversion).

On the other hand, I can understand and I would take advantage of mercurial 
features such as using local repository for rapid development and then the main 
repository when development has stabilized. 

Also, since Kurt has created a personal fparser hg repository for working with 
experimental features (such as using logger for outputting fparser messages), 
then
I don't mind switching to mercurial when it helps the project to evolve further 
with the tools that the project developers are more used to or think that these 
tools would ease the development cycle.

Btw, switching to mercurial is not a big effort when ignoring history (see 
googlecode instructions). Moreover, the current svn repository will still be 
available after the switch, that is, the commit history is not really lost.
So, I think that the effort to switch is minimal and the real question is 
whether
using mercurial will help the development of the project, will it ease the life
of developers or will it make it harder for someone.

Original comment by pearu.peterson on 26 Jul 2010 at 8:01

[GoogleCodeExporter]

Kyle Mandli and I worked on fparser a bit during the Scipy 2010 conference.  We 
put a mercurial repository of fparser up on bitbucket, and it makes it *much* 
easier to try out experimental branches, etc. like Pearu mentions. I'll be 
pushing the improvements to svn soon.  The Cython project uses mercurial, and 
doing merges between branches and other repos is a nice experience, something I 
couldn't imagine even trying with svn.  If the switch to mercurial doesn't take 
too much effort then I'm all for it, although that's easy for me to say :-)  
Since there isn't much history in fparser on googlecode I certainly don't mind 
restarting the repo at the svn HEAD, especially since the original history is 
still there.

It's possible to work with a remote svn repo with mercurial locally, but it is 
somewhat kludgy, and I think there are definite benefits to using a DVCS for 
everyone involved.  It takes a bit getting used to, though.

I'll take a look at the __svn_version__.py script and figure out the mercurial 
equivalent.

And to be clear: If it isn't too hard, keeping log history would be great, but 
it's up to Pearu or whoever does the conversion.  There isn't that much history 
in the googlecode svn repo.

Original comment by kwmsmith@gmail.com on 26 Jul 2010 at 9:06

[GoogleCodeExporter]

So the 'equivalent' of svnversion is:

$ hg identify --id
f4596fa7a3b9

Which gives the global revision id for the working copy (the currently 
checked-out revision).  There are other options to fine-tune what is output, 
see:

$ hg help identify

If there are uncommitted changes, it looks like:

$ hg identify --id
f4596fa7a3b9+

(a '+' is appended...)

Original comment by kwmsmith@gmail.com on 26 Jul 2010 at 9:23

[GoogleCodeExporter]

OK, sounds good! I've never used mercurial before, but as it seems to help with 
development and give the developers more freedom trying out stuff in a local 
repository (which is actually something I missed in svn when playing with the 
f2py code), I'm in! Let me know if I can help with migrating to the new repo.

Original comment by omar.aw...@gmail.com on 27 Jul 2010 at 8:14

[GoogleCodeExporter]

Ok, I shall prepare the repository for the switch (introducing 
__hg_version__.py)
and do the conversion hopefully within couple of hours. Kurt, if you cannot 
making
the push sooner then it's ok, the improvements can be pushed also to a new
repository.

Original comment by pearu.peterson on 27 Jul 2010 at 9:24

[GoogleCodeExporter]

The switch to Mercurial with complete history is now done (it was very easy).

Creating source distribution of f2py requires numpy revision 8527 or newer
that has now __hg_version__.py file generation support. For all other
tasks you may still use your favorite numpy version.

Anyone can create a clone of f2py in

  http://code.google.com/p/f2py/source/checkout

For suggested work flow, read also

  http://code.google.com/p/support/wiki/MercurialFAQ#Why_should_I_create_a_server-side_clone?

Original comment by pearu.peterson on 27 Jul 2010 at 11:34

[GoogleCodeExporter]

Thanks, Pearu!

Original comment by omar.aw...@gmail.com on 28 Jul 2010 at 8:52

[GoogleCodeExporter]

Original comment by pearu.peterson on 28 Jul 2010 at 8:31

• Changed state: Done