Can I use git repo in old format and vscode in new source format?
Clash Royale CLAN TAG#URR8PPP
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.
- Project exists in old format.
- Create new project in vscode and choose the option create project from manifest file.
- Make changes in vscode.
- 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. - 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
add a comment |
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.
- Project exists in old format.
- Create new project in vscode and choose the option create project from manifest file.
- Make changes in vscode.
- 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. - 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
add a comment |
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.
- Project exists in old format.
- Create new project in vscode and choose the option create project from manifest file.
- Make changes in vscode.
- 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. - 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
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.
- Project exists in old format.
- Create new project in vscode and choose the option create project from manifest file.
- Make changes in vscode.
- 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. - 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
salesforcedx git vs-code
asked Jan 29 at 20:57
javanoobjavanoob
3,90352472
3,90352472
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
1
Transitioning slowly into DX seems like a good idea. Also, thanks for suggestinggit mv
command, I am going to explore on this. Thanks!
– javanoob
Jan 29 at 21:41
add a comment |
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
);
);
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%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
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.
1
Transitioning slowly into DX seems like a good idea. Also, thanks for suggestinggit mv
command, I am going to explore on this. Thanks!
– javanoob
Jan 29 at 21:41
add a comment |
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.
1
Transitioning slowly into DX seems like a good idea. Also, thanks for suggestinggit mv
command, I am going to explore on this. Thanks!
– javanoob
Jan 29 at 21:41
add a comment |
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.
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.
answered Jan 29 at 21:28
sfdcfoxsfdcfox
256k11201441
256k11201441
1
Transitioning slowly into DX seems like a good idea. Also, thanks for suggestinggit mv
command, I am going to explore on this. Thanks!
– javanoob
Jan 29 at 21:41
add a comment |
1
Transitioning slowly into DX seems like a good idea. Also, thanks for suggestinggit 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
add a comment |
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.
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%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
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