Can I use git repo in old format and vscode in new source format?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












4















We want to switch to vscode but our git repo uses old source format and we don't want to convert this to new source format yet.This article talks about how to convert existing projects to new source format without losing git repo history but we don't want to do this, atleast, for sometime.



Here is what we are thinking of and need input from others if there will be any issues with this approach.



  1. Project exists in old format.

  2. Create new project in vscode and choose the option create project from manifest file.

  3. Make changes in vscode.

  4. When ready to commit, convert the new source structure to old structure with command sfdx force:source:convert. I played around with this command we can convert only the component that we touched and don't need to convert entire project.

  5. Go to folder(old source format) and commit from there.

If we are working on metadata type that did not change in new source format, we don't need to convert and simply copy file from new Project to Old Project and commit from there and no need to use command sfdx force:source:convert.










share|improve this question


























    4















    We want to switch to vscode but our git repo uses old source format and we don't want to convert this to new source format yet.This article talks about how to convert existing projects to new source format without losing git repo history but we don't want to do this, atleast, for sometime.



    Here is what we are thinking of and need input from others if there will be any issues with this approach.



    1. Project exists in old format.

    2. Create new project in vscode and choose the option create project from manifest file.

    3. Make changes in vscode.

    4. When ready to commit, convert the new source structure to old structure with command sfdx force:source:convert. I played around with this command we can convert only the component that we touched and don't need to convert entire project.

    5. Go to folder(old source format) and commit from there.

    If we are working on metadata type that did not change in new source format, we don't need to convert and simply copy file from new Project to Old Project and commit from there and no need to use command sfdx force:source:convert.










    share|improve this question
























      4












      4








      4


      1






      We want to switch to vscode but our git repo uses old source format and we don't want to convert this to new source format yet.This article talks about how to convert existing projects to new source format without losing git repo history but we don't want to do this, atleast, for sometime.



      Here is what we are thinking of and need input from others if there will be any issues with this approach.



      1. Project exists in old format.

      2. Create new project in vscode and choose the option create project from manifest file.

      3. Make changes in vscode.

      4. When ready to commit, convert the new source structure to old structure with command sfdx force:source:convert. I played around with this command we can convert only the component that we touched and don't need to convert entire project.

      5. Go to folder(old source format) and commit from there.

      If we are working on metadata type that did not change in new source format, we don't need to convert and simply copy file from new Project to Old Project and commit from there and no need to use command sfdx force:source:convert.










      share|improve this question














      We want to switch to vscode but our git repo uses old source format and we don't want to convert this to new source format yet.This article talks about how to convert existing projects to new source format without losing git repo history but we don't want to do this, atleast, for sometime.



      Here is what we are thinking of and need input from others if there will be any issues with this approach.



      1. Project exists in old format.

      2. Create new project in vscode and choose the option create project from manifest file.

      3. Make changes in vscode.

      4. When ready to commit, convert the new source structure to old structure with command sfdx force:source:convert. I played around with this command we can convert only the component that we touched and don't need to convert entire project.

      5. Go to folder(old source format) and commit from there.

      If we are working on metadata type that did not change in new source format, we don't need to convert and simply copy file from new Project to Old Project and commit from there and no need to use command sfdx force:source:convert.







      salesforcedx git vs-code






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Jan 29 at 20:57









      javanoobjavanoob

      3,90352472




      3,90352472




















          1 Answer
          1






          active

          oldest

          votes


















          3














          That's similar to what we do now and... no, it doesn't work, at least not well. If you do this, you will continue to make more work for yourself, and you will likely "never" get in to DX format. Conversion on any non-trivial project "all-at-once" is not trivial and not recommended. I tried once in our org and lost a month worth of work-hours trying to do this, while other developers were actively using "src" metadata format files, etc. Also, I should add that this is a lot more work over time than necessary.



          If your goal is to use DX, the entire team needs to start at once and commit to it (no pun intended, I think). Create an empty DX structure and commit it to your repo. When you need to change a file, use git mv to move it to the appropriate DX folder(s), commit those changes, do work in VS Code, commit, and then deploy from DX. Lather, rinse, repeat until you're fully converted.



          Once you start, everyone should use force:source:deploy/force:package*/etc to deploy. If you have a CI/CD, have it deploy metadata first, then DX afterwards. As you move your metadata over, you can eventually just turn off the mdapi deployments and strictly use DX deploy or package installs. Changing over time will eliminate the stress of trying to convert all at once and ease the transition.






          share|improve this answer


















          • 1





            Transitioning slowly into DX seems like a good idea. Also, thanks for suggesting git mv command, I am going to explore on this. Thanks!

            – javanoob
            Jan 29 at 21:41










          Your Answer








          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "459"
          ;
          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: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          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%2fsalesforce.stackexchange.com%2fquestions%2f248400%2fcan-i-use-git-repo-in-old-format-and-vscode-in-new-source-format%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









          3














          That's similar to what we do now and... no, it doesn't work, at least not well. If you do this, you will continue to make more work for yourself, and you will likely "never" get in to DX format. Conversion on any non-trivial project "all-at-once" is not trivial and not recommended. I tried once in our org and lost a month worth of work-hours trying to do this, while other developers were actively using "src" metadata format files, etc. Also, I should add that this is a lot more work over time than necessary.



          If your goal is to use DX, the entire team needs to start at once and commit to it (no pun intended, I think). Create an empty DX structure and commit it to your repo. When you need to change a file, use git mv to move it to the appropriate DX folder(s), commit those changes, do work in VS Code, commit, and then deploy from DX. Lather, rinse, repeat until you're fully converted.



          Once you start, everyone should use force:source:deploy/force:package*/etc to deploy. If you have a CI/CD, have it deploy metadata first, then DX afterwards. As you move your metadata over, you can eventually just turn off the mdapi deployments and strictly use DX deploy or package installs. Changing over time will eliminate the stress of trying to convert all at once and ease the transition.






          share|improve this answer


















          • 1





            Transitioning slowly into DX seems like a good idea. Also, thanks for suggesting git mv command, I am going to explore on this. Thanks!

            – javanoob
            Jan 29 at 21:41















          3














          That's similar to what we do now and... no, it doesn't work, at least not well. If you do this, you will continue to make more work for yourself, and you will likely "never" get in to DX format. Conversion on any non-trivial project "all-at-once" is not trivial and not recommended. I tried once in our org and lost a month worth of work-hours trying to do this, while other developers were actively using "src" metadata format files, etc. Also, I should add that this is a lot more work over time than necessary.



          If your goal is to use DX, the entire team needs to start at once and commit to it (no pun intended, I think). Create an empty DX structure and commit it to your repo. When you need to change a file, use git mv to move it to the appropriate DX folder(s), commit those changes, do work in VS Code, commit, and then deploy from DX. Lather, rinse, repeat until you're fully converted.



          Once you start, everyone should use force:source:deploy/force:package*/etc to deploy. If you have a CI/CD, have it deploy metadata first, then DX afterwards. As you move your metadata over, you can eventually just turn off the mdapi deployments and strictly use DX deploy or package installs. Changing over time will eliminate the stress of trying to convert all at once and ease the transition.






          share|improve this answer


















          • 1





            Transitioning slowly into DX seems like a good idea. Also, thanks for suggesting git mv command, I am going to explore on this. Thanks!

            – javanoob
            Jan 29 at 21:41













          3












          3








          3







          That's similar to what we do now and... no, it doesn't work, at least not well. If you do this, you will continue to make more work for yourself, and you will likely "never" get in to DX format. Conversion on any non-trivial project "all-at-once" is not trivial and not recommended. I tried once in our org and lost a month worth of work-hours trying to do this, while other developers were actively using "src" metadata format files, etc. Also, I should add that this is a lot more work over time than necessary.



          If your goal is to use DX, the entire team needs to start at once and commit to it (no pun intended, I think). Create an empty DX structure and commit it to your repo. When you need to change a file, use git mv to move it to the appropriate DX folder(s), commit those changes, do work in VS Code, commit, and then deploy from DX. Lather, rinse, repeat until you're fully converted.



          Once you start, everyone should use force:source:deploy/force:package*/etc to deploy. If you have a CI/CD, have it deploy metadata first, then DX afterwards. As you move your metadata over, you can eventually just turn off the mdapi deployments and strictly use DX deploy or package installs. Changing over time will eliminate the stress of trying to convert all at once and ease the transition.






          share|improve this answer













          That's similar to what we do now and... no, it doesn't work, at least not well. If you do this, you will continue to make more work for yourself, and you will likely "never" get in to DX format. Conversion on any non-trivial project "all-at-once" is not trivial and not recommended. I tried once in our org and lost a month worth of work-hours trying to do this, while other developers were actively using "src" metadata format files, etc. Also, I should add that this is a lot more work over time than necessary.



          If your goal is to use DX, the entire team needs to start at once and commit to it (no pun intended, I think). Create an empty DX structure and commit it to your repo. When you need to change a file, use git mv to move it to the appropriate DX folder(s), commit those changes, do work in VS Code, commit, and then deploy from DX. Lather, rinse, repeat until you're fully converted.



          Once you start, everyone should use force:source:deploy/force:package*/etc to deploy. If you have a CI/CD, have it deploy metadata first, then DX afterwards. As you move your metadata over, you can eventually just turn off the mdapi deployments and strictly use DX deploy or package installs. Changing over time will eliminate the stress of trying to convert all at once and ease the transition.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 29 at 21:28









          sfdcfoxsfdcfox

          256k11201441




          256k11201441







          • 1





            Transitioning slowly into DX seems like a good idea. Also, thanks for suggesting git mv command, I am going to explore on this. Thanks!

            – javanoob
            Jan 29 at 21:41












          • 1





            Transitioning slowly into DX seems like a good idea. Also, thanks for suggesting git mv command, I am going to explore on this. Thanks!

            – javanoob
            Jan 29 at 21:41







          1




          1





          Transitioning slowly into DX seems like a good idea. Also, thanks for suggesting git mv command, I am going to explore on this. Thanks!

          – javanoob
          Jan 29 at 21:41





          Transitioning slowly into DX seems like a good idea. Also, thanks for suggesting git mv command, I am going to explore on this. Thanks!

          – javanoob
          Jan 29 at 21:41

















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Salesforce Stack Exchange!


          • 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%2fsalesforce.stackexchange.com%2fquestions%2f248400%2fcan-i-use-git-repo-in-old-format-and-vscode-in-new-source-format%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






          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Bahrain

          Postfix configuration issue with fips on centos 7; mailgun relay