On 05/04/2009 15:11, Alexandre Vassalotti wrote:
I am not sure if it would be useful to convert the old branches to
Mercurial. The simplest thing to do would be to keep the current svn
repository as a read-only archive. And if people needs to commit to
these branches, they could request the branch to be imported into a
Mercurial branch (or a simple to use script could be provided and
developer could run it directly on the server to create a user
branch).
We should probably not include any branches that haven't been touched in
the last 18 months. Then we also leave out branches that have been pruned.
BTW, tags are also missing from the current conversions. We probably
want to keep all release tags, but not the partial tags (e.g. the
Distutils tags). Are there any other particularly useful tags we should
keep?
An auto-close would be a nice feature, but, as you said, not necessary
for the migration. The main stumbling block to implement an auto-close
feature is to define when an issue should be closed. Maybe we could
add our own meta-data to the commit message. For example:
Fix some nasty bug.
Close-Issue: 4532
When a such commit would arrive in one of the main branches, a commit
hook would close the issue if all the affected releases have been
fixed.
It makes more sense to me to use the syntax already used by Trac et al.,
e.g. "(fix|close)s? (issue|#)\d+" for closing and possibly
"ref(erence)?s? (issue|#)\d+" for creating a link on the issue.
BTW, this would also be a good time to split out the stdlib if that's
still desirable (which I seem to have gleaned from the PyCon videos).
Cheers,
Dirkjan
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
