views:

329

answers:

3

Say I created a branch in perforce of our codebase. Here is the branch spec:

//depot/code/main/... //depot/code/branch/...

Then, in the branch, say I move the branched file a.txt -> b.txt using

p4 integrate //depot/code/branch/a.txt //depot/code/branch/b.txt
p4 delete //depot/code/branch/a.txt

Now, let's say some changes are made to a.txt in main which I would like to have integrated into b.txt in the branch

When I try to integrate using the original branch spec, it doesn't reflect the changes made to a.txt in main onto b.txt - is there any way to have the changes made in main show up in the renamed file?

The branch spec is rather large (hundreds of changes) and quite a few files were renamed in the branch, so I'd like to have an automated way to do this. Let me know if I can clarify anything here -- it would help to have a whiteboard ;)

Thanks! Sam

+1  A: 

I don't believe so. Since there is no direct p4 rename, you have to integrate and delete - once you've done that, integrates from another branch no longer go to the right file. At least that's been my experience.

Graeme Perrow
Thanks - Updated to show what commands were actually issued - in reality I used p4v to do it.
SamBeran
I believe 2009.1 adds proper renames - which doesn't help with history
Douglas Leeder
+2  A: 

Perforce 2009.1 has proper renames, which might help with this - probably, and in any case only for future renames. See Perforce 2009.1 release notes, in particular:

#177023 * **
    The new 'p4 move' command allows for better support for
    renaming files.  A file must be already opened for 'edit'
    or 'add' in order to be moved.  Moved files can be synced,
    resolved and diffed against the repository just like files
    opened for 'edit'.  See 'p4 help move' for more info.

You can add the rename into the branch spec. Then at least the integrations will be automatic - even if the branch spec will be even longer and more complicated.

Douglas Leeder
As far as I understand it, the *only* benefits of p4 move are that you can cleanly move and edit a file in a single atomic changelist, and until you check in that changelist further syncs will propagate changes from the source to the target . *After* you've checked it in, it behaves just the same as a branch, an edit and a delete action except that they are inseparable. It does not help with integrating moves from one branch to another. It is not what is called "first class renames" in other source control systems.
Weeble
I think you might be right - it looks that way - although, with the meta-data recorded in the database, Perforce might add proper handling in future? Previously it was impossible to differentiate branch from rename.
Douglas Leeder
+3  A: 

The only way I know of to have Perforce handle this for you is to use the branch spec to map the old file in the original to the new file in the branch. Perhaps that has changed with the new move command in the recent Perforce versions, but not that I've experienced.

Caleb Huitt - cjhuitt