CODEWITHSUNDEEP
svnvisual-studio-2010perforce
Sakamoto Kazuma
Sakamoto Kazuma

Reputation: 2579

Subversion on Perforce Projects

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.

Upvotes: 1

Views: 172

Answers (3)

randy-wandisco
randy-wandisco

Reputation: 3659

You can find Perforce binaries for most Linux variants. If that's not feasible, you can use something like rsync to transfer builds and patches (your local changes on the build box) back and forth.

If you need a version management system and P4 isn't available, git is probably a better call. You can transfer the git repo by sneaker net, and there is a git-p4 connector that you can use to replay changes into Perforce. Perforce is also developing a better connector but it won't be out until later this year.

Upvotes: 0

haysclark
haysclark

Reputation: 1080

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.

Upvotes: 1

jgritty
jgritty

Reputation: 11915

That would not be my approach. Is it possible to share a drive, or network location between a machine with perforce and this one? Another approach is to contact perforce support and see if they can't get you a working p4 binary.

Adding the source control bindings to svn shouldn't screw them up, but I never tried it.

Upvotes: 0

Related Questions