What does “tampered with before resolve” mean on file resolve?
up vote
6
down vote
favorite
I'm trying to merge main stream to development stream and some files need to be resolved. On resolve I have an error:
filepath tampered with before resolve - edit or revert.
I tried to solve it as described here, but without success.
This is what verify command shows me:
for the target
filepath - branch change 9070 (text) A3269695246A89D21F341D8A5BB70B5B
for the source
filepath - edit change 22793 (text) 171BA2F3E0FFCEF3F7A34FDB7A2CEF69
filepath - add change 9049 (text) A3269695246A89D21F341D8A5BB70B5B
What do branch change, edit change, add change mean? Why is the MD5 identical but I still have an error? How to solve?
perforce
add a comment |
up vote
6
down vote
favorite
I'm trying to merge main stream to development stream and some files need to be resolved. On resolve I have an error:
filepath tampered with before resolve - edit or revert.
I tried to solve it as described here, but without success.
This is what verify command shows me:
for the target
filepath - branch change 9070 (text) A3269695246A89D21F341D8A5BB70B5B
for the source
filepath - edit change 22793 (text) 171BA2F3E0FFCEF3F7A34FDB7A2CEF69
filepath - add change 9049 (text) A3269695246A89D21F341D8A5BB70B5B
What do branch change, edit change, add change mean? Why is the MD5 identical but I still have an error? How to solve?
perforce
add a comment |
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I'm trying to merge main stream to development stream and some files need to be resolved. On resolve I have an error:
filepath tampered with before resolve - edit or revert.
I tried to solve it as described here, but without success.
This is what verify command shows me:
for the target
filepath - branch change 9070 (text) A3269695246A89D21F341D8A5BB70B5B
for the source
filepath - edit change 22793 (text) 171BA2F3E0FFCEF3F7A34FDB7A2CEF69
filepath - add change 9049 (text) A3269695246A89D21F341D8A5BB70B5B
What do branch change, edit change, add change mean? Why is the MD5 identical but I still have an error? How to solve?
perforce
I'm trying to merge main stream to development stream and some files need to be resolved. On resolve I have an error:
filepath tampered with before resolve - edit or revert.
I tried to solve it as described here, but without success.
This is what verify command shows me:
for the target
filepath - branch change 9070 (text) A3269695246A89D21F341D8A5BB70B5B
for the source
filepath - edit change 22793 (text) 171BA2F3E0FFCEF3F7A34FDB7A2CEF69
filepath - add change 9049 (text) A3269695246A89D21F341D8A5BB70B5B
What do branch change, edit change, add change mean? Why is the MD5 identical but I still have an error? How to solve?
perforce
perforce
edited Dec 16 '15 at 0:04
Chad
581421
581421
asked Oct 21 '15 at 7:50
nikitablack
1,69611331
1,69611331
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
up vote
11
down vote
accepted
Perforce's client-server architecture is confusing you a bit here: the 'verify' command is reporting on the state of the files on the server, but the 'tampered with before resolve' message from 'p4 resolve' is alerting you to a problem with the state of the files on your client.
It appears, from the little bit of information that you provided, that:
- Change 9049 added the source file, with digest A3269...
- Change 9070 branched that source file to the target. Of course, the digest is the same for source and target, since the branch was a perfect copy of the file.
- Change 22793 modified the source file, and hence its digest changed
- You are then trying to integrate change 22793 from the source to the target.
This integration would be a straightforward "safe resolve" in most cases, because the file was changed only in the source, and the target was a perfect copy of the previous revision of the source.
However, the resolve command looked on your actual workstation copy of the target file, and discovered that the file that you have there is not a file with digest A3269...
Since the 'resolve' command was just about to replace your copy of the target file on your workstation with the merged result, it doesn't want to do that if there is a possibility that you made changes to that file (without opening the file for edit) that you don't want to lose.
So 'resolve' is trying to tell you to have a look at the copy of the target file that is currently on your workstation (using your text editor, e.g.), and see if you actually made changes to that file.
If you did, and you want to save those changes, then you can't perform this integration at this time; you need to instead open the file for edit (using 'edit -k' to retain your modified copy of the file, of course) so that Perforce can merge your edited copy with the changes from change 22793.
If you didn't make changes to the target file, or if you made changes but you don't want them, then you need to discard those changes explicitly, for example by:
- reverting the pending integration to the target file
- Running 'p4 sync -f target-file'
This is the sort of information that 'resolve' is trying to communicate in that very terse
filepath tampered with before resolve - edit or revert.
Thank you, good answer. It explained me a lot. And I solved the problem with replacing.
– nikitablack
Oct 22 '15 at 10:38
add a comment |
up vote
0
down vote
I also have faced this issue while executing p4 resolve -am for some file. the solution is to do p4 edit <filename> and then execute p4 resolve -am for that file.
add a comment |
up vote
0
down vote
It means that your local was edited without the app knowing about it (e.g., you forgot to do "p4 edit" first). I believe I've seen this when doing an integrate then changing the file before submitting it, too.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f33253733%2fwhat-does-tampered-with-before-resolve-mean-on-file-resolve%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
11
down vote
accepted
Perforce's client-server architecture is confusing you a bit here: the 'verify' command is reporting on the state of the files on the server, but the 'tampered with before resolve' message from 'p4 resolve' is alerting you to a problem with the state of the files on your client.
It appears, from the little bit of information that you provided, that:
- Change 9049 added the source file, with digest A3269...
- Change 9070 branched that source file to the target. Of course, the digest is the same for source and target, since the branch was a perfect copy of the file.
- Change 22793 modified the source file, and hence its digest changed
- You are then trying to integrate change 22793 from the source to the target.
This integration would be a straightforward "safe resolve" in most cases, because the file was changed only in the source, and the target was a perfect copy of the previous revision of the source.
However, the resolve command looked on your actual workstation copy of the target file, and discovered that the file that you have there is not a file with digest A3269...
Since the 'resolve' command was just about to replace your copy of the target file on your workstation with the merged result, it doesn't want to do that if there is a possibility that you made changes to that file (without opening the file for edit) that you don't want to lose.
So 'resolve' is trying to tell you to have a look at the copy of the target file that is currently on your workstation (using your text editor, e.g.), and see if you actually made changes to that file.
If you did, and you want to save those changes, then you can't perform this integration at this time; you need to instead open the file for edit (using 'edit -k' to retain your modified copy of the file, of course) so that Perforce can merge your edited copy with the changes from change 22793.
If you didn't make changes to the target file, or if you made changes but you don't want them, then you need to discard those changes explicitly, for example by:
- reverting the pending integration to the target file
- Running 'p4 sync -f target-file'
This is the sort of information that 'resolve' is trying to communicate in that very terse
filepath tampered with before resolve - edit or revert.
Thank you, good answer. It explained me a lot. And I solved the problem with replacing.
– nikitablack
Oct 22 '15 at 10:38
add a comment |
up vote
11
down vote
accepted
Perforce's client-server architecture is confusing you a bit here: the 'verify' command is reporting on the state of the files on the server, but the 'tampered with before resolve' message from 'p4 resolve' is alerting you to a problem with the state of the files on your client.
It appears, from the little bit of information that you provided, that:
- Change 9049 added the source file, with digest A3269...
- Change 9070 branched that source file to the target. Of course, the digest is the same for source and target, since the branch was a perfect copy of the file.
- Change 22793 modified the source file, and hence its digest changed
- You are then trying to integrate change 22793 from the source to the target.
This integration would be a straightforward "safe resolve" in most cases, because the file was changed only in the source, and the target was a perfect copy of the previous revision of the source.
However, the resolve command looked on your actual workstation copy of the target file, and discovered that the file that you have there is not a file with digest A3269...
Since the 'resolve' command was just about to replace your copy of the target file on your workstation with the merged result, it doesn't want to do that if there is a possibility that you made changes to that file (without opening the file for edit) that you don't want to lose.
So 'resolve' is trying to tell you to have a look at the copy of the target file that is currently on your workstation (using your text editor, e.g.), and see if you actually made changes to that file.
If you did, and you want to save those changes, then you can't perform this integration at this time; you need to instead open the file for edit (using 'edit -k' to retain your modified copy of the file, of course) so that Perforce can merge your edited copy with the changes from change 22793.
If you didn't make changes to the target file, or if you made changes but you don't want them, then you need to discard those changes explicitly, for example by:
- reverting the pending integration to the target file
- Running 'p4 sync -f target-file'
This is the sort of information that 'resolve' is trying to communicate in that very terse
filepath tampered with before resolve - edit or revert.
Thank you, good answer. It explained me a lot. And I solved the problem with replacing.
– nikitablack
Oct 22 '15 at 10:38
add a comment |
up vote
11
down vote
accepted
up vote
11
down vote
accepted
Perforce's client-server architecture is confusing you a bit here: the 'verify' command is reporting on the state of the files on the server, but the 'tampered with before resolve' message from 'p4 resolve' is alerting you to a problem with the state of the files on your client.
It appears, from the little bit of information that you provided, that:
- Change 9049 added the source file, with digest A3269...
- Change 9070 branched that source file to the target. Of course, the digest is the same for source and target, since the branch was a perfect copy of the file.
- Change 22793 modified the source file, and hence its digest changed
- You are then trying to integrate change 22793 from the source to the target.
This integration would be a straightforward "safe resolve" in most cases, because the file was changed only in the source, and the target was a perfect copy of the previous revision of the source.
However, the resolve command looked on your actual workstation copy of the target file, and discovered that the file that you have there is not a file with digest A3269...
Since the 'resolve' command was just about to replace your copy of the target file on your workstation with the merged result, it doesn't want to do that if there is a possibility that you made changes to that file (without opening the file for edit) that you don't want to lose.
So 'resolve' is trying to tell you to have a look at the copy of the target file that is currently on your workstation (using your text editor, e.g.), and see if you actually made changes to that file.
If you did, and you want to save those changes, then you can't perform this integration at this time; you need to instead open the file for edit (using 'edit -k' to retain your modified copy of the file, of course) so that Perforce can merge your edited copy with the changes from change 22793.
If you didn't make changes to the target file, or if you made changes but you don't want them, then you need to discard those changes explicitly, for example by:
- reverting the pending integration to the target file
- Running 'p4 sync -f target-file'
This is the sort of information that 'resolve' is trying to communicate in that very terse
filepath tampered with before resolve - edit or revert.
Perforce's client-server architecture is confusing you a bit here: the 'verify' command is reporting on the state of the files on the server, but the 'tampered with before resolve' message from 'p4 resolve' is alerting you to a problem with the state of the files on your client.
It appears, from the little bit of information that you provided, that:
- Change 9049 added the source file, with digest A3269...
- Change 9070 branched that source file to the target. Of course, the digest is the same for source and target, since the branch was a perfect copy of the file.
- Change 22793 modified the source file, and hence its digest changed
- You are then trying to integrate change 22793 from the source to the target.
This integration would be a straightforward "safe resolve" in most cases, because the file was changed only in the source, and the target was a perfect copy of the previous revision of the source.
However, the resolve command looked on your actual workstation copy of the target file, and discovered that the file that you have there is not a file with digest A3269...
Since the 'resolve' command was just about to replace your copy of the target file on your workstation with the merged result, it doesn't want to do that if there is a possibility that you made changes to that file (without opening the file for edit) that you don't want to lose.
So 'resolve' is trying to tell you to have a look at the copy of the target file that is currently on your workstation (using your text editor, e.g.), and see if you actually made changes to that file.
If you did, and you want to save those changes, then you can't perform this integration at this time; you need to instead open the file for edit (using 'edit -k' to retain your modified copy of the file, of course) so that Perforce can merge your edited copy with the changes from change 22793.
If you didn't make changes to the target file, or if you made changes but you don't want them, then you need to discard those changes explicitly, for example by:
- reverting the pending integration to the target file
- Running 'p4 sync -f target-file'
This is the sort of information that 'resolve' is trying to communicate in that very terse
filepath tampered with before resolve - edit or revert.
answered Oct 21 '15 at 13:46
Bryan Pendleton
13.9k32539
13.9k32539
Thank you, good answer. It explained me a lot. And I solved the problem with replacing.
– nikitablack
Oct 22 '15 at 10:38
add a comment |
Thank you, good answer. It explained me a lot. And I solved the problem with replacing.
– nikitablack
Oct 22 '15 at 10:38
Thank you, good answer. It explained me a lot. And I solved the problem with replacing.
– nikitablack
Oct 22 '15 at 10:38
Thank you, good answer. It explained me a lot. And I solved the problem with replacing.
– nikitablack
Oct 22 '15 at 10:38
add a comment |
up vote
0
down vote
I also have faced this issue while executing p4 resolve -am for some file. the solution is to do p4 edit <filename> and then execute p4 resolve -am for that file.
add a comment |
up vote
0
down vote
I also have faced this issue while executing p4 resolve -am for some file. the solution is to do p4 edit <filename> and then execute p4 resolve -am for that file.
add a comment |
up vote
0
down vote
up vote
0
down vote
I also have faced this issue while executing p4 resolve -am for some file. the solution is to do p4 edit <filename> and then execute p4 resolve -am for that file.
I also have faced this issue while executing p4 resolve -am for some file. the solution is to do p4 edit <filename> and then execute p4 resolve -am for that file.
edited Nov 12 at 5:57
Ratul Sharker
2,69711526
2,69711526
answered Nov 12 at 5:52
Sandeep Varshney
1
1
add a comment |
add a comment |
up vote
0
down vote
It means that your local was edited without the app knowing about it (e.g., you forgot to do "p4 edit" first). I believe I've seen this when doing an integrate then changing the file before submitting it, too.
add a comment |
up vote
0
down vote
It means that your local was edited without the app knowing about it (e.g., you forgot to do "p4 edit" first). I believe I've seen this when doing an integrate then changing the file before submitting it, too.
add a comment |
up vote
0
down vote
up vote
0
down vote
It means that your local was edited without the app knowing about it (e.g., you forgot to do "p4 edit" first). I believe I've seen this when doing an integrate then changing the file before submitting it, too.
It means that your local was edited without the app knowing about it (e.g., you forgot to do "p4 edit" first). I believe I've seen this when doing an integrate then changing the file before submitting it, too.
answered Nov 12 at 22:36
tkosinski
1,022710
1,022710
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f33253733%2fwhat-does-tampered-with-before-resolve-mean-on-file-resolve%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown