The python version of simfactory is currently on the branch PYSIM_2010. This should be just PYSIM.
We should fix this before SimFactory 2 becomes the default for the Einstein Toolkit. We could either:
1. Move the Python version to trunk. This would probably cause many people problems, so it probably a bad idea.
2. Create a new branch from the current PYSIM_2010 branch and call it PYSIM.
3. Users are going to be inconvenienced with the switch anyway. Take the opportunity while not many people are using the python version to switch to a better version control system. I like git.
I think it logically makes sense to have SimFactory 2 in a separate repository from SimFactory 1 since they don't share any common files and have essentially independent histories. I think the best thing to do would be to move the PYSIM_2010 branch to a separate repository, bringing the history with it. This can be easily achieved with either svn or git. Whether this new repository is git or svn is a separate issue, although I also like git.
Using /trunk is the "right" solution in the sense that this is what the development version should be anyway. Whoever wants something 'stable' should use another branch: one of the ET branches quite probably. Now, that this might not be the case for a lot of users might be an issue. As far as I can tell, no development happens in trunk right now. So, I propose:
a) Give people a warning that the version in /trunk will be changed to the python version.
The simfactory/Cactus/ET users mailing lists spring to mind.
b) Actually do that after some time (maybe a month)?
After that, version 1 would only be available as old release branches (e.g. old ET branches), and /trunk could again be used for the usual development, removing PYSIM_2010.
I agree with Frank: If we are serious about switching to Python, then we should move the Python version to the trunk, and choose a sensible name for the Perl branch. If we announce things properly, help people with the switch etc. This should work out.
I don't think we need to wait a month. People will ignore such advanced notice and will be surprised anyway -- a few days should suffice.
I agree with Barry that there is really no need for them to be in the same repository, since they share no history. It just leads to confusion. I still think it is best to move the history of the Python version out into a separate repository. The only development that happens in trunk now is fixing of bugs and updating optionlists (this is rare, but we have done it). This has the advantage that people using the Perl version will still be able to do an svn update to get critical fixes etc without having to go through the pain of switching to a new version just for that, or repointing their svn checkouts to a new branch.
What is the argument against moving the Python version history into a new repository?