How to recover Perforce history on a moved directory












1















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



























    1















    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

























      1












      1








      1








      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














      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













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 19 '18 at 11:36









      Ahmed AdelAhmed Adel

      10738




      10738
























          1 Answer
          1






          active

          oldest

          votes


















          2















          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





















          • 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











          • 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











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


          }
          });














          draft saved

          draft discarded


















          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









          2















          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





















          • 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











          • 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















          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





















          • 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











          • 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








          2








          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
















          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














          share|improve this answer



          share|improve this answer








          edited Nov 21 '18 at 4:17

























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











          • 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





            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











          • 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




















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          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





















































          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







          -

          這個網誌中的熱門文章

          Xamarin.form Move up view when keyboard appear

          圖片
          .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box; } 0 I'm trying to build a Chat app UI, the idea of the Layout was pretty simple: When the input bar is focused, keyboard show up and "push" up the chat bar, as it's a grid, the ListView will resize to fit the screen: I update the input bar's margin to "push" it up: NSValue result = (NSValue)args.Notification.UserInfo.ObjectForKey(new NSString(UIKeyboard.FrameEndUserInfoKey)); CGSize keyboardSize = result.RectangleFValue.Size; if (Element != null){ Element.Margin = new Thickness(0, 0, 0,keyboardSize.Height); //push the entry up to keyboard height when keyboard is activated } And this is ...
          閱讀完整內容

          Post-Redirect-Get with Spring WebFlux and Thymeleaf

          圖片
          .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box; } 2 Can someone explain to me how to implement the post-redirect-get pattern in Spring WebFlux and Thymeleaf? What subscribes on the database save method? @GetMapping("/register") public String showRegisterForm(Model model) { model.addAttribute("user", new User()); return "register"; } @PostMapping public String processRegisterForm(@Valid User user, BindingResult bindingResult) { if (bindingResult.hasErrors()) { return "register"; } else { userRepository.save(user); //what subscribes on this? //how to redirect on e.g. "/login"? ...
          閱讀完整內容

          Anylogic : not able to use stopDelay()

          圖片
          -2 I am building a railway station model. I want a train to depart when I click a button. I want to call stopDelay() for that but I am not sure how to do that and from which place. anylogic share | improve this question asked Nov 23 '18 at 10:12 Anupam Singh Anupam Singh 1 Hi Anupam, welcome to SOF. Please check how to ask good questions, see link below. Your question is...
          閱讀完整內容