Lightswitch is a fantastic tool but has a MAJOR downside to it – it eats disk space like no-ones business. A simple test project with 1 table, 1 screen & some code on the client side and server side is over 90Mb of space!
If you are a developer you will have some sort of version control system in place and you should be following some best practices in version control. For this post, the one I want to look at is to only check into the repo what actually needs to be in the repo. A polluted and huge repo is not only hard to work with, it puts people off and lowers adoption 
I have been using Mercurial a lot recently and part of a new LS project I took the time to look at how much of the LS project needs to go into the repo – and you know what… it is VERY VERY LITTLE, in fact it is about 0.4%!
Mercurial, for those new to it, has a .hgignore file which uses a regular expression like language to tell it what files to ignore, i.e. don’t commit those files to the repo. Below is what my .hgignore file looks like. That first 4 line group is the LS specific lines while the rest is for general Visual Studio projects:
syntax: glob *.lsproj.user ServiceConfiguration.cscfg */_Pvt_Extensions/* */GeneratedArtifacts/* *.csproj.user *.vbproj.user */[Oo]bj/* */[Bb]in/* *.suo *DXCore.Solution [Tt]humbs.db *.user *.bak.* *.bak *.[Cc]ache */[Pp]ublish/* *.vssscc *.vs10x */[Dd]otfuscated/* [Dd]otfuscated/* *.vsp [Nn][Dd]epend[Oo]ut/* *.licx *.docstates *.cscfg *.csdef
It is important to note that when you pull from the repo (or checkout for TFS/VSS/SVN folk) you’ll get the disk saving, until you open it up that is. Once opened LS will regenerate everything and the size on your machine will be back to the massive 90Mb+, however the repo will remain small, commits will remain small, network traffic will remain small and performance improved – just what we wanted from following those version control best practises.