Thomas Heller wrote: > - Do I need special rights to call 'svnadmin load' to import this dumpfile > into Python SVN, or are the normal commit rights sufficient?
It's called "svnadmin" for a reason :-) Neal Norwitz or myself will have to do that; we need to do it on the repository machine locally. I would likely take subversion write access offline for the time of the import, so that I can rollback the entire repository in case of an operator mistake. > What exactly is the URL/PATH where it should be imported (some sandbox, > I assume)? My view is that this is the "projects" repository; with ctypes being a project, it should go into the root directory (i.e. as a sibling to python, peps, distutils, stackless, ...). If you prefer to see it in sandbox, this could work as well. > - What about the Python trunk? Should changes from the sandbox be merged > into Modules/_ctypes and Lib/ctypes, or would it be better (or possible at > all) > to use the external mechanism? I would prefer to see two-way merges going on, at least until 2.5 is released (i.e. no changes to Modules/ctypes except for bug fixes). Using svn:external is a risky thing wrt. to branching/tagging: When we tag the Python tree, we want to tag the entire source tree. With svn:external, only the external link would be in the tag, i.e. later changes to the external link would modify old tags. This is undesirable. This problem could be solved with a versioned external link; this would mean that ctypes could not be edited directly, but that one would have to go through the original repository URL to perform modifications, and then update the external link. So I think I still would prefer two-way merges. There are tools to make the merges pretty mechanic. Regards, Martin _______________________________________________ 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
