I have a project that’s currently in a Perforce repository. Unfortunately, due to some testing restrictions, I have a test machine (private build of something that resembles linux) that, for whatever reason, does not run Perforce, but is able to run subversion. Is it possible, or a good idea, to load everything into subversion while it is still tied into Perforce?
This is a VS2010 project, and I know that VS2010 will see the source control bindings that Perforce has. Will putting this into subversion screw this up?
Yes I know for testing all I have to do is copy the compiled build, however we are also looking at making changes on the fly, so we do want to do some code editing on the target machine as well.
I would start by saying that you don’t need a 2nd source control system for just moving file from one system to another. Wouldn’t you be better off just using RSync to move the files from one computer that has p4 running to the other machine?
If I were to shoe-horn a solution that uses two version control systems then I would use Git over SVN because SVN is going to litter your sub-folders with .svn files which could pollute your Perforce repo. If you use Git you can more easily overlay the two repos with minimal issues. In the end, if your not using the versioning in SVN then your going to have other issues over time, such as the repo slowly filling up and deleting the .svn files.
I actually utilize git with Perforce where all the binaries are stored in Perforce so that we can ‘lock’ the files. Once the artist check-in files into Perforce our Jenkin’s CI server see’s the update, it gets the latest assets in P4, copies the check-in notes and then commit’s the assets to GIT into and ‘art’ branch. The dev’s then and merge the ‘art’ branch into the master branch or specific feature branches. It’s also a nice way to keep costs down because you only need enough seats of P4 for the artist and the Jenkins box, the dev’s all can use GIT which is free.