Mercurial migration

[giampaolo]

From g.rodola on December 02, 2011 22:33:46

Main problem with our current development strategy is that every time we are 
going to add a new feature, this has to be replicated on 4 different platforms 
(windows, linux, osx and freebsd) and *every time* we do this our code base 
becomes inevitably unstable.

By "unstable" I mean that for a certain period of time we'll have tests which 
usually fail and one who might want to use latest SVN version because, say, it 
fixes a certain bug, is forced to use a code base containing partially 
implemented features and which is generally unstable.

To say an example, we are in this exact situation right now because:
- we started issue 229 (psutil.get_users()) which goes back to nov 9
- we stopped working on it
- we fixed issue 232 A solution to this problem is starting to use branches.
Every time we're going to implement a new feature we can start developing into 
a separate branch, implement the feature across all 4 platforms and when we're 
done merge everything back into the trunk.
At the same time, we are free to commit bug fixes against the trunk, which will 
remain "stable".

SVN support what described above but... well... it sucks. =)
The "branching" consists in creating a separate copy of the trunk into another 
directory. 
From then on, the two directories will have a separate history (and this is 
terrible). The subsequent merge is also something I recall being pretty painful.

On the other hand, mercurial provides "named branches": 
http://www.python.org/dev/peps/pep-0385/#branch-strategy With this, each change 
set we do against a branch belongs to the same repository/directory as the 
"tip" (the trunk), the history is centralized into a single point, and skipping 
between "tip" (the trunk) and the branch is very easy (and fast).

I've been using this strategy at work for a year now and I basically got addicted.

Some links: 
https://code.google.com/p/support/wiki/ChoosingAVersionControlSystem 
https://code.google.com/p/support/wiki/ConvertingSvnToHg

Original issue: http://code.google.com/p/psutil/issues/detail?id=233

[giampaolo]

From [email protected] on December 02, 2011 14:09:54

Can we migrate the existing logs and information to Mercurial? How smooth would 
the migration be in terms of preserving history and such? I dislike moving to a 
new VCS in midstream though I do agree we could be making better use of 
branching and merging in SVN.

[giampaolo]

From g.rodola on December 03, 2011 04:15:19

History should be preserved: 
https://code.google.com/p/support/wiki/ConvertingSvnToHg My only concern is 
what's going to happen to the revision links provided in our issue tracker (I 
mean "rXXX", where XXX is a number).
I asked support on gcode mailing list.

[giampaolo]

From g.rodola on December 06, 2011 08:18:39

As I imagined, bug tracker's "rXXX" links are not automatically converted.
Since we've been making a massive use of them since day 1, and there's no way 
to edit issues, I'm not willing to make the conversion.
FWIW, I've filed an issue on google code bug tracker: 
https://code.google.com/p/support/issues/detail?id=6071 ...but knowing their 
time schedule it's unlikely we'll be able to do this soon.
I'm closing this out for now.

Status: WontFix

[giampaolo]

From g.rodola on February 27, 2013 13:47:04

Reopening this.
I asked support on gcode mailing list and it seems they're not willing to fix 
this "rXXX" link problem: 
https://groups.google.com/forum/?fromgroups=#!topic/google-code-hosting/afrH3MqxdFA
 That said, I think that keep post poning this migration is only worse.
As explained in my first comment, using named branches will make my life 
easier, especially now that I'm willing to restart working on Solaris support 
and issue 250 .

As for "rXXX" links, after the repository is migrated, I will manually go 
through all issues and add a comment reporting the new Mercurial cset in which 
a certain issue has been fixed.

Status: ReOpened

[giampaolo]

From g.rodola on February 28, 2013 11:30:29

I migrated the code to Mercurial.
Leaving this open as long as I don't fix the "rXXX" problem.

Status: Started
Labels: Usability

[giampaolo]

From g.rodola on March 02, 2013 04:49:33

It took me 2 days and a serie of automated scripts using selenium [1] because 
the damn gcode's issue tracker's API [2] is broken, but I finally made it.

Code has been successfully migrated to Mercurial (including branches) and all 
the issues filed so far reports the new converted csets.

Closing.

[1] 
https://code.google.com/p/billiejoex/source/detail?r=8eab428dd85111099024b6f450cb4cfccd441975#
 [2] https://code.google.com/p/support/wiki/IssueTrackerAPIPython

Status: FixedInSVN
Labels: Milestone-0.6.2

[giampaolo]

From g.rodola on April 07, 2013 18:21:49

Status: FixedInHG

[giampaolo]

From g.rodola on April 11, 2013 02:17:39

Labels: -Milestone-0.6.2 Milestone-0.7.0

[giampaolo]

From g.rodola on April 12, 2013 11:21:26

Status: Fixed