June 17, 2011

Resolving Filetypes

Integration
Healthcare

In my last blog post I talked about how the 2011.1 server is going to be able to propagate moves (aka renames) via integrate and resolve, and we got a peek at how 'p4 resolve' is going to be able to handle changes other than those made to content. Today I'll talk a bit about filetypes.

Filetypes and integrate have not historically been the best of friends.  Once a given file's type is set, that type is preserved unless explicitly changed.  Hence, by default, if you were to change a filetype in one branch and integrate into another, the target branch's filetype would stay the same, which loses part of the source's change.  By integrating with the '-t' flag you could force the source's filetype to be copied onto the target, which is sort of a partial fix.  It works pretty well most of the time, so many users always use '-t' as a matter of habit (or policy), but if the filetype of the target has been changed, this policy would cause it to be silently overwritten.  There is also no way under this system to 'ignore' a filetype change as you would a content change.

The new infrastructure in resolve that allows the server to ask the user about changes in filename has allowed us to tackle a number of other old and outstanding problems, integration of filetypes among them.  The default behavior of integrate is now to attach a 'filetype resolve' to the standard content resolve if the source and target filetypes are different.  The filetype resolve uses the same base as the content resolve, and will attempt a three-way merge of the types in cases where the source and target have both changed.  Hence, if a 'text' file has been changed to 'text+k' in one branch and 'text+x' in another, after you have resolved the contents you will be prompted to resolve the filetype, as follows:

Filetype resolve:
at: (text+x)
ay: (text+k)
am: (text+kx)
Accept(a) Skip(s) Help(?) am:

The file will be reopened with whatever filetype is chosen.  The 'p4 resolve -as' and 'p4 resolve -am' commands process non-conflicting filetype resolves exactly the same as they do non-conflicting content resolves, so if a user does a normal integrate and auto-resolve, filetypes will be automatically propagated as appropriate without any user intervention required.

For backwards compatibility purposes, the old 'integrate -t' command still works as it always has to force propagation of filetypes, skipping the resolve step.  As you upgrade to 2011.1, you may wish to review existing scripts and policies that might use that flag and remove it so that you can take advantage of this new resolve behavior.  While you're in there, you might want to get rid of the '-d' flag as well, but I'll talk more about that in my next post.