Antoine Pitrou wrote:
Well, it seems to me that most of these steps are separated by manual intervention (e.g. compile and run the test suite to check that everything works smoothly)
so there's no real point in making a script out of them.
The idea would be to provide scripts for each step that people think should be easier/automated. Like running the provided testcase before and after applying the corresponding patch. Or making sure to build before running tests for a patch that touches C code.
The real issues with svnmerge are its occasional bugs or failures (it forgot some changesets when merging in the io-c branch!)
Who's handling those bugs? Is any of them avoidable/easier to catch/easier to workaround with a script that checks for, e.g., svnmerge version, svnmerge correct usage and completeness of the merge? I think this proposal could help reproducing those issues and fixing/mitigating them until a better solution is available.
Maybe something could be improved in svnmerge, as Martin suggests. Or merging could be made a bit easier, so people would backport their commits themselves more often and the laundry list merges could be a little smaller.
and its limitations (which are really inherent to the SVN model: e.g., if someone commits to the branch you have just started doing an svnmerge to, you have to revert everything and start over with the latest updates).
We have discussed this off-list and I have no answer regarding SVN limitations.
If a svnmerge-on-top-of-hg or svnmerge-on-top-of-bzr script can be used to merge SVN branches with the exact same results of the real svnmerge, only faster and prettier, maybe it should be considered for GSoC too.
If/when the main Python repository moves to a DVCS, scripts that allow people to perform the same steps they currently perform to achieve the same results might help the transition.
I won't mention the bzr-on-top-of-git part :)