PFZheng / psutil

Automatically exported from code.google.com/p/psutil
Other
0 stars 0 forks source link

Mercurial migration #233

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
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:
http://code.google.com/p/support/wiki/ChoosingAVersionControlSystem
http://code.google.com/p/support/wiki/ConvertingSvnToHg

Original issue reported on code.google.com by g.rodola on 2 Dec 2011 at 9:33

GoogleCodeExporter commented 9 years ago
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. 

Original comment by jlo...@gmail.com on 2 Dec 2011 at 10:09

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
History should be preserved:
http://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.

Original comment by g.rodola on 3 Dec 2011 at 12:15

GoogleCodeExporter commented 9 years ago
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:
http://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.

Original comment by g.rodola on 6 Dec 2011 at 4:18

GoogleCodeExporter commented 9 years ago
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/afrH3Mqx
dFA

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.

Original comment by g.rodola on 27 Feb 2013 at 9:47

GoogleCodeExporter commented 9 years ago
I migrated the code to Mercurial.
Leaving this open as long as I don't fix the "rXXX" problem.

Original comment by g.rodola on 28 Feb 2013 at 7:30

GoogleCodeExporter commented 9 years ago
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=8eab428dd85111099024b6f450c
b4cfccd441975#
[2] https://code.google.com/p/support/wiki/IssueTrackerAPIPython

Original comment by g.rodola on 2 Mar 2013 at 12:49

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 8 Apr 2013 at 1:21

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 11 Apr 2013 at 9:17

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 12 Apr 2013 at 6:21