Best Practices for SVN? VS & SQL RRS feed

  • Question

  • User828583679 posted

    Hi All,

    I travel quite a bit and use both my desktop and laptop. I have a dedicated server with SVN and use it for hosting SVN as well as a production server.

    I use AnkhSVN and Tortoise SVN for my VS projects and keep all my projects on my remote server and a copy locally, on my desktop and laptop.

    I'm wondering if anyone has a suggestion or best practices for SQL db's? Are there any good methods of using SVN with a SQL DB? Do you use Remote DB's and just deal with development being slower? Or do most of you just move databases between laptops and desktops by backing up and restoring?

    Thanks in advance!

    Sunday, September 26, 2010 8:24 AM

All replies

  • User-1179452826 posted

    1. If you move around a lot and need source control, I can't recommend a distributed source control enough. Even if you don't DVCS options are 1000% times better than the archaic SVN. If I were you, I'd switch over to mercurial or git. Mercurial is more user friendly, but git has more options. I personally use mercurial and it is light years ahead of SVN.

    2. For SQL, depends on complexity and what you want. I always have a copy of the main db on my local dev machine to ensure faster dev time and that I don't mess up anything on the central db. If you frequently need to update the schema, then I also create a VS2010 SQL database project. I use that to deploy my local database frequently as it has options to drop and recreate dbs, call external setup procedures, set up test data etc. at a push of a button. When I feel that the changes are good enough to go live, I use the same database project to push the schema and / or data changes to the central server.

    3. I repeat...ditch SVN...move to mercurial (or git). You'll notice a huge perf boost within the first couple of days and will likely not go back. [No more waiting for code to commit to the remote central god server is reason enough for me!]. 

    Sunday, September 26, 2010 8:37 AM