Reputation: 21
I have a project coded in python and I use svn for source-control. But now, I have a part of this code I need to commit with Perforce. As the source tree is quite large with lots of files, I don't want to duplicate the files on the different computers. So I want to keep working on SVN and sometimes, push the code on Perforce.
But I have some problems to do that:
when a file is moved or deleted in SVN, submitting the code in Perforce results with an error saying the file is missing and can't be committed. So nothing is committed.
I don't want all my code on Perforce, so I marked only some directories to be added. No problem there. But to retrieve modifications and new files, the thing is to do a Perforce "checkout". And if I do that on the root directory of my development tree, it marks for add all the files in my development tree. So I ended doing a checkout on every directory I previously added, which is quite annoying and time consuming.
If anyone has advice, he/she would become my hero ;-). Thanks!
Upvotes: 2
Views: 1325
Reputation: 207
First of all, you should do everything that is possible to convince whoever setup this system that mixing different source control repositories is very bad for productivity.
Now, your problems arise because you are replicating the overlap between these two repositories at the filesystem level and you didn't set a proper client spec on the Perforce side to filter out unwanted files/folders.
As has been suggested above, you should modify you Perforce client spec to explicitly exclude files and folders you never want to see in the Perforce depot:
-//depot/path/to/SVNfiles/folder-I-dont-want/... //client/local/path/to/folder-I-dont-want/...`
-//depot/path/to/SVNfiles/file-I-dont-want //client/local/path/to/file-I-dont-want`
etc.
As as also been suggested above, run the following Perforce commands (from http://kb.perforce.com/UserTasks/WorkingDisconnected):
p4 diff -sd //myclient/... | p4 -x - delete
p4 diff -se //myclient/... | p4 -x - edit
find . -type f -print | p4 -x - add
Then execute p4 submit
, review manually the list of files added/deleted/edited, remove the ones which shouldn't be there and fix your above list consequently then when you're satisfied validate the submit.
Don't forget to update the client spec as soon as new files/folders are added that you don't want.
But the proper solution is definitely not to do it, you'll run into problems as soon as you start moving files bewteen folders, you will end up having merge problems, etc.
You could work around the merge conflicts by putting the SVN files into their dedicated branch inside the Perforce folder, then integrating/merging the conflicts with their actual destination but this only brings additional work to solve a problem that shouldn't be there in the first place.
Upvotes: 0
Reputation: 53320
It sounds like you have the entire server in your client spec, and are checking things out, perhaps using P4V. Don't do that. Alter your client spec with just the directories you want, in the locations you want. Then use p4 sync to keep them updated with changes other people make.
Your description of the problem is rather woolly. Why do you want some of the files under perforce? Are the files in perforce also in svn?
EDIT:
I suspect that http://kb.perforce.com/UserTasks/WorkingDisconnected may be some use for synchronising changes from svn to perforce.
Setup your perforce workspace/client-spec to map the shared locations to their subversion check out locations.
EDIT2:
From your comment, perhaps what you need is a commit hook on your subversion server, that commits changes to certain files onto the perforce server?
In which case, the subversion server could have a perforce client, and do the proper p4 edit/add/delete calls before submitting the change?
Upvotes: 0
Reputation: 152927
My advice is not to mix workspaces of two different version control tools. That's like playing around with a loaded shotgun pointing at your feet. It will go off, one day.
It's been some years since I last time used Perforce, but I remember it certainly didn't like anyone else messing with its workspaces. Svn doesn't like it either.
Instead, keep the workspaces separate. Disk space is cheap. It's hard to imagine a code base so large that it wouldn't be feasible. Ideally, version stuff in one repository only. If you still need to version files in two places, set up a merge tool to sync changes between the workspaces. In Windows/Linux environment, Beyond Compare is an excellent tool for manual merging. For automatic merges, some scripting may be required to pull patches from one repository and apply them to the other.
Upvotes: 2