How to recover Perforce history on a moved directory

up vote
1
down vote

favorite

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

share|improve this question

asked Nov 19 at 11:36

Ahmed Adel

10738

add a comment | 

up vote
1
down vote

favorite

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

share|improve this question

asked Nov 19 at 11:36

Ahmed Adel

10738

add a comment | 

up vote
1
down vote

favorite

up vote
1
down vote

favorite

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

share|improve this question

asked Nov 19 at 11:36

Ahmed 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

share|improve this question

asked Nov 19 at 11:36

Ahmed Adel

10738

share|improve this question

asked Nov 19 at 11:36

Ahmed Adel

10738

share|improve this question

share|improve this question

asked Nov 19 at 11:36

Ahmed Adel

10738

asked Nov 19 at 11:36

Ahmed Adel

10738

asked Nov 19 at 11:36

Ahmed Adel

10738

10738

add a comment | 

add a comment | 

1 Answer
1

active

oldest

votes

up vote
2
down vote

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.)

share|improve this answer

edited yesterday

answered 2 days ago

Sam Stafford

11.5k719

• 
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
  – Sam Stafford
  2 days ago
  

  
  
  
  

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
});


}
});

 

draft saved

draft discarded

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

Name

Email

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

Name

Email

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
2
down vote

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.)

share|improve this answer

edited yesterday

answered 2 days ago

Sam Stafford

11.5k719

• 
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
  – Sam Stafford
  2 days ago
  

  
  
  
  

add a comment | 

up vote
2
down vote

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.)

share|improve this answer

edited yesterday

answered 2 days ago

Sam Stafford

11.5k719

• 
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
  – Sam Stafford
  2 days ago
  

  
  
  
  

add a comment | 

up vote
2
down vote

up vote
2
down vote

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.)

share|improve this answer

edited yesterday

answered 2 days ago

Sam Stafford

11.5k719

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.)

share|improve this answer

edited yesterday

answered 2 days ago

Sam Stafford

11.5k719

share|improve this answer

share|improve this answer

edited yesterday

edited yesterday

edited yesterday

answered 2 days ago

Sam Stafford

11.5k719

answered 2 days ago

Sam Stafford

11.5k719

answered 2 days ago

Sam Stafford

11.5k719

11.5k719

• 
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
  – Sam Stafford
  2 days ago
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  2 days ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
  – Sam Stafford
  2 days ago
  

  
  
  
  

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
2 days ago

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
2 days ago

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
2 days ago

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
2 days ago

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
2 days ago

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
2 days ago

If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
– Sam Stafford
2 days ago

If you talked to Perforce support about branching/merging at any point between 2000 and 2010 you probably talked to me. ;)
– Sam Stafford
2 days ago

add a comment | 

 

draft saved

draft discarded

 

draft saved

draft discarded

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

Name

Email

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

Name

Email

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

Name

Email

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

Name

Email

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

Name

Email

Required, but never shown

Name

Name

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Name

Name

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

This page is only for reference, If you need detailed information, please check here