Bonjour,
On 06/08/11 03:23 AM, René Dudfield wrote:
Hey,
On Fri, Aug 5, 2011 at 9:31 PM, Lenard Lindstrom <le...@telus.net
<mailto:le...@telus.net>> wrote:
Hello,
Before moving anything do some hg configuration, such as enabling
the eol extension
(http://mercurial.selenic.com/wiki/EolExtension). There is a PEP
on the Python migration: http://www.python.org/dev/peps/pep-0385.
From reading about the eol extension... it seems one issue with the
eol extension is that everyone needs to enable it otherwise it doesn't
work correctly. Is that correct? I don't remember any other project
using this extension. Maybe we don't really need it. It seems python
uses a hook to reject commits with wrong line endings based on the eol
extension. Maybe we can have one of these hooks in place.
Yes, if Bitbucket allows custom hooks on its repository, then a filter
to reject, or even convert, the wrong kind of line ending would be enough.
* what to do with branches, and trunk?
Most branches are closed. I just merged msvc64 back into trunk. It
has be removed. The msi, testtools, and trackmod branches can be
omitted as well.
ok, cool. I can't figure out how to omit branches with the _hg
convert_ extension so far. I'm sure there's some way to prune things
though.
Here's the pruning dead branches docs.
http://mercurial.selenic.com/wiki/PruningDeadBranches
Maybe the _hg strip_ command is what we're looking for. If want want
to wipe them and their history.
* instead of a trunk the root should be the trunk.
I think the trunk would become the tip. We may have to rethink how
we commit changes. I admit I have used the Pygame SVN repository
branches as an off site backup system while making changes. I
don't know what the equivalent is with hg, if any. Maybe patches
posted to the issue tracker can serve the purpose.
Lenard Lindstrom
Yeah, we can keep the tip as something like the trunk now I guess. hg
makes branches are way easier than svn branches. The pull request is
functionality is good too. You fork the repo on your own account, and
when ready send a pull request to the main branch.
I'll send some measurements of the converted repository size later
today, once it's done converting.
There is some thing called a permanent branch. Maybe this can represent
formal releases. There is also a patch queue, which may work for off
site backups and to make experimental changes widely available without
messing up the tip at Bitbucket. The way development is handled with a
distributed version control system sure differs from SVN. No centralized
experimental branches should be needed. Only bug fixes and firm feature
changes should be pushed to the Bitbucket repository. Anything else can
be done locally and submitted as a patch. We can also also make Pygame
versions with experimental features available as separate downloads from
Bitbucket.
Lenard Lindstrom