Saving sync projects and putting them under source control

Ben Mills

I already sent a support email about this, but I wanted to put my opinion on the forum to see if anyone else agrees (or disagrees).

I'm upgrading from version 3.4 to 5.0 and I don't like the way I can't save the comparison projects to a specified location. I've always saved these files with my other source code and put them under source control. That way, I could be the SQL Compare "expert" and the other developers could just checkout the latest copy of the sync project and run it. Now, the other developers will have to build there own sync projects.

Maybe I should just build scripts to automate the comparisons. I guess, this works, but it's sometimes nice for the other developers to see the results of the comparison in the UI before commiting the changes.

Dominick Reed

Hi Ben,

If you right click one of your projects in the list, you can choose "Locate on disk..." That will give you access to the project file that you can share with your colleagues. They will need to drop it into the same location on their computers for SQL Compare to see it.

Projects can save people a lot of time, but we found that they were rarely being used - with most people just creating a new comparison each time. The effort of saving a project, giving it a meaningful name and specifying a location is more than the effort needed to start anew each time. The new approach should ensure that more of our users will take advantage of them, whilst still allowing them access to the underlying files.

Hope that helps.



Dom

Brian Donahue

Hi Guys,

You should still be able to use the project files with the command-line version of SQL Compare and the Toolkit API after you've located the files on disk like Dom says.

Ben Mills

I see what you are saying up to a point. The changes you have made make sense as a default behaviour for people who don't have many projects, but for enterprise users, *I think* that there should be an option to save files in other locations and be able to double click on those files to open the project.

These Red Gate tools are great products and are a critical part of our development environment. For large enterprise use, everything has to be under source control and version 5 makes that hard.

Anyway, that was my 2 cents. I'm going to create command line scripts instead and put them under source control.

Thanks,
Ben