Salesforce, Python, SQL, & other ways to put your data where you need it

Need event music? 🎸

Live and recorded jazz, pop, and meditative music for your virtual conference / Zoom wedding / yoga class / private party with quality sound and a smooth technical experience

Migrating my Salesforce org backups from Eclipse to VSCode without messing up Git

07 Nov 2019 🔖 salesforce vscode eclipse
💬 EN

Here’s how I migrated all my “Salesforce configuration metadata backups” from Eclipse to VSCode without my 5-year-old Git history really caring.

This is a bit of a quick-and-dirty low-quality post; sorry. Publishing it on the blog in case I forgot an org and need it again myself. 😆

Note that this only worked because I didn’t need to convert mdapi-style metadata files to sfdx-style metadata files (I didn’t have any objects in src).

Need help getting VSCode installed and set up? Try these steps on a brand new dev org to get your bearings.

  1. Back up the whole Eclipse folder to some directory far, far away in case I majorly mess up.
  2. Delete every folder but src (which is a sub-folder of the tracking folder) and .git; stage & commit & push in Git with SourceTree.
    • Everything else is just stuff that has to do with Eclipse.
  3. Delete cruft from src; stage & commit & push in Git with SourceTree.
    • If I have src things I don’t want in my new environment, like artifacts from packages, get rid of them now.
    • They just get in the way of Git successfully tracking renames in the next step (it has limits of how many file renames it can track at a time).
  4. Rename src to default.
    • Then create a new folder main at the same level of the filesystem as default; drag default inside of main.
    • Then create a new folder force-app at the same level of the filesystem as main; drag main inside of force-app.
    • Then stage in Git with SourceTree.
  5. Hopefully I have a “yay, the renames worked!” moment.
    • If so, commit & push in Git with SourceTree.
    • If not, troubleshoot (e.g. try staging smaller batches for multiple commits; make sure “rename tolerance” settings are all the way up in my Git installation; etc.).
  6. In VSCode, SFDX: Create Project with Manifest name_it_whatever (don’t use spaces or VSCode will yell at you) in C:\Users\myusername\Documents\Repos\wrapper_folder_name
  7. Close the folder in VSCode
  8. In File Explorer, rename C:\Users\myusername\Documents\Repos\wrapper_folder_name\name_it_whatever\ to C:\Users\myusername\Documents\Repos\wrapper_folder_name\Meaningful Name\
  9. Open C:\Users\myusername\Documents\Repos\wrapper_folder_name\Meaningful Name\ in VSCode
  10. Connect this project to the Salesforce org it represents with SFDX: Authorize an Org.
    • No need to actually retrieve any metadata from the server yet (although it certainly might, so maybe set the package.xml minimal?)
  11. Delete the C:\Users\myusername\Documents\Repos\wrapper_folder_name\Meaningful Name\force-app folder
  12. Copy over force-app and .git from the org I’ve been tearing apart into the new folder C:\Users\myusername\Documents\Repos\wrapper_folder_name\Meaningful Name.
  13. Rename the old folder so SourceTree can’t find it and prompts me for the new folder; choose the new folder.
    • If it doesn’t prompt, close SourceTree hand-edit C:\Users\myusername\AppData\Local\Atlassian\SourceTree\bookmarks.xml.
    • But I probably just forgot to do the whole “renaming the old folder” bit, honestly.
      SourceTree won’t prompt if I just leave it empty of a .git sub-folder; it’ll merely act up.
  14. Set up C:\Users\myusername\Documents\Repos\wrapper_folder_name\Meaningful Name\.gitignore the way I like it.
    • e.g. before #Salesforce cache add the chunk below these instructions.
  15. Test:
    • Delete a file; make sure it ends up in Git potential changes.
    • Retrieve from package and make sure it comes back onto the filesystem and disappears from Git potential changes.)
  16. PROFIT.
# Other
.sfdx/orgs/[email protected]/metadataTypeInfos.json

Related Reading: Note that the links below ended up being overkill for me, since I didn’t have object folders in src anyway. Still, I thought it was worth noting their existence – for example, I learned about setting my Git rename tolerance up higher.

The process I didn’t end up following, which came from those links, was:

  1. SFDX: Create Project with Manifest: My Prod_TEMP in C:\Users\myusername\Documents\Repos\prod_temp
  2. C:\Users\myusername\Documents\Repos\prod_temp\My Prod_TEMP> : sfdx force:mdapi:convert --rootdir C:\Users\myusername\Documents\Repos\oldprod\src --outputdir C:\Users\myusername\Documents\Repos\prod_temp\src
  3. Now I have a bunch of folders like classes and triggers in C:\Users\myusername\Documents\Repos\prod_temp\src\main\default
  4. … “Oh, nevermind; I have another idea.”
--- ---