Should I submit unchanged files to Perforce?

T

3

6

I'm using Perforce to integrate two codelines. In the resulting changelist, there are files which are marked as opened for integration, but have not actually changed.

Should I submit these unchanged files or should I revert them?

I want to revert them because I don't want these unchanged files to pollute the changelist.

But, if I submit them, I have a feeling that Perforce might have a use of this "fact" (that the files have been integrated) for future integration.

Trine answered 26/1, 2011 at 2:4 Comment(0)

E

4

Yes, you should submit them. This will create the integration record to record that the changes have been "integrated" (which may not mean actual changes occurred on the target).

Emilio answered 26/1, 2011 at 19:24 Comment(7)

Thanks, Jason. I noticed that, if I don't submit these diff-less files, another invocation of p4 integrate will again try to merge these diff-less files. So, submit them I shall. Again, thanks! – Trine 26/1, 2011 at 23:56

You are mistaken. There is no need to submit unchanged files. Perforce will not attempt to integrate files that have not changed, (i.e., were opened and then reverted). There is no need to "...create the integration record to record that they changes have been "integrated"..." because no changes have been made. – Aircrewman 27/1, 2011 at 13:50

I guess they meant files with no difference, e.g. because the same change has already been made by hand on both side of the integrated file. – Gwendolyn 28/1, 2011 at 13:3

@raven, no, the edit revision on the other branch will show up for integration until you check-in a merge change of some kind from that revision. There is no other way for Perforce to know what changelists should and should not be integrated. – Emilio 28/1, 2011 at 21:44

@pascal: You mean branch a file, check it out on both trunk and branch, make the same change to both files, check in the file on the trunk, check in the file on the branch, and then integrate the file on the branch back into the trunk? That would be a silly thing to do. – Aircrewman 28/1, 2011 at 23:30

@Jason: I didn't understand your last comment. What I do know is this. If you branch a file, check out the file on the branch, but make no changes to it, there is no reason to submit it and integrate it back into the trunk. Just revert it. – Aircrewman 28/1, 2011 at 23:30

There are more reasons that an integration can result in no differences against a target file. For example, you may fix a bug in a current release, but due to changes the bug doesn't exist on the Trunk (and you have a policy of merge nags like my work does). Or refactoring on the Trunk means you can't do an automatic merge. This is a common enough situation that Perforce identifies it with a unique graphic in the revision graph (Ignore). – Emilio 31/1, 2011 at 17:27

A

5

There is no need to submit unchanged files. I can't even understand why the option exists. Perforce only needs to know about changes you make to files. The fact that you checked a file out, but did nothing to it, is irrelevant. Revert unchanged files. As you said, don't pollute the revision history.

Aircrewman answered 27/1, 2011 at 13:50 Comment(1)

One reason is a metadata change, like changing the perforce file type or line endings. Other than that it is total madness – Edgebone 30/3, 2015 at 15:47

E

4

Yes, you should submit them. This will create the integration record to record that the changes have been "integrated" (which may not mean actual changes occurred on the target).

Emilio answered 26/1, 2011 at 19:24 Comment(7)

Thanks, Jason. I noticed that, if I don't submit these diff-less files, another invocation of p4 integrate will again try to merge these diff-less files. So, submit them I shall. Again, thanks! – Trine 26/1, 2011 at 23:56

You are mistaken. There is no need to submit unchanged files. Perforce will not attempt to integrate files that have not changed, (i.e., were opened and then reverted). There is no need to "...create the integration record to record that they changes have been "integrated"..." because no changes have been made. – Aircrewman 27/1, 2011 at 13:50

I guess they meant files with no difference, e.g. because the same change has already been made by hand on both side of the integrated file. – Gwendolyn 28/1, 2011 at 13:3

@raven, no, the edit revision on the other branch will show up for integration until you check-in a merge change of some kind from that revision. There is no other way for Perforce to know what changelists should and should not be integrated. – Emilio 28/1, 2011 at 21:44

@pascal: You mean branch a file, check it out on both trunk and branch, make the same change to both files, check in the file on the trunk, check in the file on the branch, and then integrate the file on the branch back into the trunk? That would be a silly thing to do. – Aircrewman 28/1, 2011 at 23:30

@Jason: I didn't understand your last comment. What I do know is this. If you branch a file, check out the file on the branch, but make no changes to it, there is no reason to submit it and integrate it back into the trunk. Just revert it. – Aircrewman 28/1, 2011 at 23:30

There are more reasons that an integration can result in no differences against a target file. For example, you may fix a bug in a current release, but due to changes the bug doesn't exist on the Trunk (and you have a policy of merge nags like my work does). Or refactoring on the Trunk means you can't do an automatic merge. This is a common enough situation that Perforce identifies it with a unique graphic in the revision graph (Ignore). – Emilio 31/1, 2011 at 17:27

A

2

I always reverted unchanged files in my changelists. I can't remember any wrong consequences.

(Fortunately, now we switched to git.)

Alcahest answered 26/1, 2011 at 2:49 Comment(1)

Well, git doesn't really give you a choice on this matter since it handles branching differently. – Emilio 28/1, 2011 at 21:59

Recommended topics

Hot tags