Reputation: 107
As a new perforce user I had to made a decision, that was very probably wrong.
My customer has the following depot structure:
//depot/dir_a
//depot/dir_b etc.
dir_a and dir_b describe no branches, they are pure directories. The whole project simply populates //depot.
I had to create a branch from this and tried to set up something like a SVN or git standard tree:
//depot/master/dir_a
//depot/master/dir_b
//depot/branches/1.0/dir_a
//depot/branches/1.0/dir_b
At the specific moment I wasn't allowed to change the old structure, but only to add things. So, I have been ending up with
//depot/dir_a
//depot/dir_b
//depot/branches/1.0/dir_a
//depot/branches/1.0/dir_b
Now, I am recognizing some pitfalls here: For example, it seems non-trivial to merge between //depot and //depot/branches/1.0 (the later being a sub-directory and probably some kind of 'part' of the informal pre-existing 'root' branch).
How can I fix this (provided that I'm now allowed to create a 'master' and moving the old stuff into it)?
Upvotes: 1
Views: 244
Reputation: 71562
If you haven't started creating "master" and "branches" etc yet, I'd just do:
p4 integ //depot/... //depot/master/...
p4 delete //depot/...
p4 submit
Now everything is in "master" and you can move forward (just ignore all the deleted files outside of your new directory structure).
If you've already put things into "master" and "branches" then you'll have to work around them, which isn't that hard but requires a little bit of thought so you don't end up creating "master/master" etc. Something like:
p4 delete //depot/...
p4 revert //depot/master/... //depot/branches/...
p4 integ //depot/... //depot/master/...
p4 revert //depot/master/master/... //depot/master/branches/...
p4 submit
In any case, you want to move your work into the "master" directory because as you've noted it's going to be easier to merge between "master" and "branches/whatever" than it is to merge from the root to something underneath of it.
Upvotes: 2