How to recover Perforce history on a moved directory
I have a branch on Perforce, where I changes the directory structure of the project using Rename/Move command.
During merging back to the mainstream, Something went wrong that caused Perforce to think of the new structure as a whole-new directories.
Subsequently, the history of the files in the new directory structure is totally unrelated to the history of the same files before changing the structure.
Is there anyway to recover this situation ? Or ask Perforce to append the old history with the new history ?
version-control perforce
asked Nov 19 '18 at 11:36
Ahmed AdelAhmed Adel
10738
add a comment |
I have a branch on Perforce, where I changes the directory structure of the project using Rename/Move command.
During merging back to the mainstream, Something went wrong that caused Perforce to think of the new structure as a whole-new directories.
Subsequently, the history of the files in the new directory structure is totally unrelated to the history of the same files before changing the structure.
Is there anyway to recover this situation ? Or ask Perforce to append the old history with the new history ?
version-control perforce
asked Nov 19 '18 at 11:36
Ahmed AdelAhmed Adel
10738
add a comment |
I have a branch on Perforce, where I changes the directory structure of the project using Rename/Move command.
During merging back to the mainstream, Something went wrong that caused Perforce to think of the new structure as a whole-new directories.
Subsequently, the history of the files in the new directory structure is totally unrelated to the history of the same files before changing the structure.
Is there anyway to recover this situation ? Or ask Perforce to append the old history with the new history ?
version-control perforce
asked Nov 19 '18 at 11:36
Ahmed AdelAhmed Adel
10738
I have a branch on Perforce, where I changes the directory structure of the project using Rename/Move command.
During merging back to the mainstream, Something went wrong that caused Perforce to think of the new structure as a whole-new directories.
Subsequently, the history of the files in the new directory structure is totally unrelated to the history of the same files before changing the structure.
Is there anyway to recover this situation ? Or ask Perforce to append the old history with the new history ?
version-control perforce
version-control perforce
asked Nov 19 '18 at 11:36
Ahmed AdelAhmed Adel
10738
asked Nov 19 '18 at 11:36
Ahmed AdelAhmed Adel
10738
asked Nov 19 '18 at 11:36
Ahmed AdelAhmed Adel
10738
asked Nov 19 '18 at 11:36
Ahmed AdelAhmed Adel
10738
asked Nov 19 '18 at 11:36
Ahmed AdelAhmed Adel
10738
10738
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Something went wrong that caused Perforce to think of the new structure as a whole-new directories.
Usually if this happens it means someone didn't use the "rename/move" command and used some other method to rename instead (i.e. they did something that adds the new directory as a new set of files independent of the originals rather than an atomic rename of an existing set of files). It's impossible for me to say how to "recover" without seeing what the history of the files looks like now so I can reverse-engineer what the "something went wrong" was.
I'd recommend either posting on the Perforce forums or contacting Perforce technical support so that somebody with expertise can wheedle the necessary data out of you (I can intuit that this will require an amount of back and forth that stackoverflow frowns on -- "what were the branches you were merging from and to", "okay, now run THIS command to see the history of that branch and send me the output," "okay, which of these five merge operations I can see in the history is the one you're talking about,") and propose a solution.
From another answer:
So, for a file a/b/c, you can look at the by using the -i option where appropriate. For example, p4 filelog -li a/b/c.
This is not necessary if files are renamed via the "move/rename" command, so if you need to use "filelog -i" to see file history, the files were definitely renamed by some other method. (The "p4 move" command was added in 2009 so long-time Perforce users will sometimes use other workflows.)
answered Nov 19 '18 at 15:49
Sam StaffordSam Stafford
12.1k819
2
Thanks for the pointer on the "move/rename" integration history details. I've been using Perforce since 2000, and still dop4 integratefollowed byp4 delete.
– janm
Nov 19 '18 at 16:34
Caught out! :D Yeah, the new "move" command has a bunch of special semantics designed to prevent a lot of the historic problems with Perforce "losing" history of renamed files. Check out the "remapping renamed files" section of this white paper, which talks about how "moved" files implicitly modify branch mappings to make sure changes merge correctly: swarm.workshop.perforce.com/files/guest/sam_stafford/doc/…
– Sam Stafford
Nov 19 '18 at 17:11
Thanks for the link. I will read it in detail later but a quick scan reminded me of some old interactions with Perforce support, and a look through my email history found an interaction with you on this subject from 2005!
– janm
Nov 19 '18 at 17:36
If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
– Sam Stafford
Nov 19 '18 at 18:15
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',
autoActivateHeartbeat: false,
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%2f53373811%2fhow-to-recover-perforce-history-on-a-moved-directory%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Something went wrong that caused Perforce to think of the new structure as a whole-new directories.
Usually if this happens it means someone didn't use the "rename/move" command and used some other method to rename instead (i.e. they did something that adds the new directory as a new set of files independent of the originals rather than an atomic rename of an existing set of files). It's impossible for me to say how to "recover" without seeing what the history of the files looks like now so I can reverse-engineer what the "something went wrong" was.
I'd recommend either posting on the Perforce forums or contacting Perforce technical support so that somebody with expertise can wheedle the necessary data out of you (I can intuit that this will require an amount of back and forth that stackoverflow frowns on -- "what were the branches you were merging from and to", "okay, now run THIS command to see the history of that branch and send me the output," "okay, which of these five merge operations I can see in the history is the one you're talking about,") and propose a solution.
From another answer:
So, for a file a/b/c, you can look at the by using the -i option where appropriate. For example, p4 filelog -li a/b/c.
This is not necessary if files are renamed via the "move/rename" command, so if you need to use "filelog -i" to see file history, the files were definitely renamed by some other method. (The "p4 move" command was added in 2009 so long-time Perforce users will sometimes use other workflows.)
answered Nov 19 '18 at 15:49
Sam StaffordSam Stafford
12.1k819
2
Thanks for the pointer on the "move/rename" integration history details. I've been using Perforce since 2000, and still dop4 integratefollowed byp4 delete.
– janm
Nov 19 '18 at 16:34
Caught out! :D Yeah, the new "move" command has a bunch of special semantics designed to prevent a lot of the historic problems with Perforce "losing" history of renamed files. Check out the "remapping renamed files" section of this white paper, which talks about how "moved" files implicitly modify branch mappings to make sure changes merge correctly: swarm.workshop.perforce.com/files/guest/sam_stafford/doc/…
– Sam Stafford
Nov 19 '18 at 17:11
Thanks for the link. I will read it in detail later but a quick scan reminded me of some old interactions with Perforce support, and a look through my email history found an interaction with you on this subject from 2005!
– janm
Nov 19 '18 at 17:36
If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
– Sam Stafford
Nov 19 '18 at 18:15
add a comment |
Something went wrong that caused Perforce to think of the new structure as a whole-new directories.
Usually if this happens it means someone didn't use the "rename/move" command and used some other method to rename instead (i.e. they did something that adds the new directory as a new set of files independent of the originals rather than an atomic rename of an existing set of files). It's impossible for me to say how to "recover" without seeing what the history of the files looks like now so I can reverse-engineer what the "something went wrong" was.
I'd recommend either posting on the Perforce forums or contacting Perforce technical support so that somebody with expertise can wheedle the necessary data out of you (I can intuit that this will require an amount of back and forth that stackoverflow frowns on -- "what were the branches you were merging from and to", "okay, now run THIS command to see the history of that branch and send me the output," "okay, which of these five merge operations I can see in the history is the one you're talking about,") and propose a solution.
From another answer:
So, for a file a/b/c, you can look at the by using the -i option where appropriate. For example, p4 filelog -li a/b/c.
This is not necessary if files are renamed via the "move/rename" command, so if you need to use "filelog -i" to see file history, the files were definitely renamed by some other method. (The "p4 move" command was added in 2009 so long-time Perforce users will sometimes use other workflows.)
answered Nov 19 '18 at 15:49
Sam StaffordSam Stafford
12.1k819
2
Thanks for the pointer on the "move/rename" integration history details. I've been using Perforce since 2000, and still dop4 integratefollowed byp4 delete.
– janm
Nov 19 '18 at 16:34
Caught out! :D Yeah, the new "move" command has a bunch of special semantics designed to prevent a lot of the historic problems with Perforce "losing" history of renamed files. Check out the "remapping renamed files" section of this white paper, which talks about how "moved" files implicitly modify branch mappings to make sure changes merge correctly: swarm.workshop.perforce.com/files/guest/sam_stafford/doc/…
– Sam Stafford
Nov 19 '18 at 17:11
Thanks for the link. I will read it in detail later but a quick scan reminded me of some old interactions with Perforce support, and a look through my email history found an interaction with you on this subject from 2005!
– janm
Nov 19 '18 at 17:36
If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
– Sam Stafford
Nov 19 '18 at 18:15
add a comment |
Something went wrong that caused Perforce to think of the new structure as a whole-new directories.
Usually if this happens it means someone didn't use the "rename/move" command and used some other method to rename instead (i.e. they did something that adds the new directory as a new set of files independent of the originals rather than an atomic rename of an existing set of files). It's impossible for me to say how to "recover" without seeing what the history of the files looks like now so I can reverse-engineer what the "something went wrong" was.
I'd recommend either posting on the Perforce forums or contacting Perforce technical support so that somebody with expertise can wheedle the necessary data out of you (I can intuit that this will require an amount of back and forth that stackoverflow frowns on -- "what were the branches you were merging from and to", "okay, now run THIS command to see the history of that branch and send me the output," "okay, which of these five merge operations I can see in the history is the one you're talking about,") and propose a solution.
From another answer:
So, for a file a/b/c, you can look at the by using the -i option where appropriate. For example, p4 filelog -li a/b/c.
This is not necessary if files are renamed via the "move/rename" command, so if you need to use "filelog -i" to see file history, the files were definitely renamed by some other method. (The "p4 move" command was added in 2009 so long-time Perforce users will sometimes use other workflows.)
answered Nov 19 '18 at 15:49
Sam StaffordSam Stafford
12.1k819
Something went wrong that caused Perforce to think of the new structure as a whole-new directories.
Usually if this happens it means someone didn't use the "rename/move" command and used some other method to rename instead (i.e. they did something that adds the new directory as a new set of files independent of the originals rather than an atomic rename of an existing set of files). It's impossible for me to say how to "recover" without seeing what the history of the files looks like now so I can reverse-engineer what the "something went wrong" was.
I'd recommend either posting on the Perforce forums or contacting Perforce technical support so that somebody with expertise can wheedle the necessary data out of you (I can intuit that this will require an amount of back and forth that stackoverflow frowns on -- "what were the branches you were merging from and to", "okay, now run THIS command to see the history of that branch and send me the output," "okay, which of these five merge operations I can see in the history is the one you're talking about,") and propose a solution.
From another answer:
So, for a file a/b/c, you can look at the by using the -i option where appropriate. For example, p4 filelog -li a/b/c.
This is not necessary if files are renamed via the "move/rename" command, so if you need to use "filelog -i" to see file history, the files were definitely renamed by some other method. (The "p4 move" command was added in 2009 so long-time Perforce users will sometimes use other workflows.)
answered Nov 19 '18 at 15:49
Sam StaffordSam Stafford
12.1k819
edited Nov 21 '18 at 4:17
answered Nov 19 '18 at 15:49
Sam StaffordSam Stafford
12.1k819
answered Nov 19 '18 at 15:49
Sam StaffordSam Stafford
12.1k819
answered Nov 19 '18 at 15:49
Sam StaffordSam Stafford
12.1k819
12.1k819
2
Thanks for the pointer on the "move/rename" integration history details. I've been using Perforce since 2000, and still dop4 integratefollowed byp4 delete.
– janm
Nov 19 '18 at 16:34
Caught out! :D Yeah, the new "move" command has a bunch of special semantics designed to prevent a lot of the historic problems with Perforce "losing" history of renamed files. Check out the "remapping renamed files" section of this white paper, which talks about how "moved" files implicitly modify branch mappings to make sure changes merge correctly: swarm.workshop.perforce.com/files/guest/sam_stafford/doc/…
– Sam Stafford
Nov 19 '18 at 17:11
Thanks for the link. I will read it in detail later but a quick scan reminded me of some old interactions with Perforce support, and a look through my email history found an interaction with you on this subject from 2005!
– janm
Nov 19 '18 at 17:36
If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
– Sam Stafford
Nov 19 '18 at 18:15
add a comment |
2
Thanks for the pointer on the "move/rename" integration history details. I've been using Perforce since 2000, and still dop4 integratefollowed byp4 delete.
– janm
Nov 19 '18 at 16:34
Caught out! :D Yeah, the new "move" command has a bunch of special semantics designed to prevent a lot of the historic problems with Perforce "losing" history of renamed files. Check out the "remapping renamed files" section of this white paper, which talks about how "moved" files implicitly modify branch mappings to make sure changes merge correctly: swarm.workshop.perforce.com/files/guest/sam_stafford/doc/…
– Sam Stafford
Nov 19 '18 at 17:11
Thanks for the link. I will read it in detail later but a quick scan reminded me of some old interactions with Perforce support, and a look through my email history found an interaction with you on this subject from 2005!
– janm
Nov 19 '18 at 17:36
If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
– Sam Stafford
Nov 19 '18 at 18:15
2
2
Thanks for the pointer on the "move/rename" integration history details. I've been using Perforce since 2000, and still do
p4 integrate followed by p4 delete.– janm
Nov 19 '18 at 16:34
Thanks for the pointer on the "move/rename" integration history details. I've been using Perforce since 2000, and still do
p4 integrate followed by p4 delete.– janm
Nov 19 '18 at 16:34
Caught out! :D Yeah, the new "move" command has a bunch of special semantics designed to prevent a lot of the historic problems with Perforce "losing" history of renamed files. Check out the "remapping renamed files" section of this white paper, which talks about how "moved" files implicitly modify branch mappings to make sure changes merge correctly: swarm.workshop.perforce.com/files/guest/sam_stafford/doc/…
– Sam Stafford
Nov 19 '18 at 17:11
Caught out! :D Yeah, the new "move" command has a bunch of special semantics designed to prevent a lot of the historic problems with Perforce "losing" history of renamed files. Check out the "remapping renamed files" section of this white paper, which talks about how "moved" files implicitly modify branch mappings to make sure changes merge correctly: swarm.workshop.perforce.com/files/guest/sam_stafford/doc/…
– Sam Stafford
Nov 19 '18 at 17:11
Thanks for the link. I will read it in detail later but a quick scan reminded me of some old interactions with Perforce support, and a look through my email history found an interaction with you on this subject from 2005!
– janm
Nov 19 '18 at 17:36
Thanks for the link. I will read it in detail later but a quick scan reminded me of some old interactions with Perforce support, and a look through my email history found an interaction with you on this subject from 2005!
– janm
Nov 19 '18 at 17:36
If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
– Sam Stafford
Nov 19 '18 at 18:15
If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
– Sam Stafford
Nov 19 '18 at 18:15
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.
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%2f53373811%2fhow-to-recover-perforce-history-on-a-moved-directory%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
