Working folder

Applies to
ApexSQL Source Control

Summary
This article describes how to use the Working folder feature. In addition, features that are not available when using the Working folder feature, and that are available when using any other supported source control system, are mentioned.

Description

The Working folder feature is intended to be used when you want to try out ApexSQL Source Control without any source control system in place. Simply, choose a local path (or a network one) to be used as a repository, and working through SQL Server Management Studio in the same way as if you are using any source control system. On the other hand, if you already have source control system installed and database version control implemented using any 3^rd party source control client, the Working folder feature can be used to connect the cloned remote repository of the actual source control system with the folder that you set as a working folder using ApexSQL Source Control.

In this way, all the changes committed to the working folder from SQL Server Management Studio using ApexSQL Source Control can be pushed to the remote repository using 3^rd party source control client.

To link a database to a working folder, right click the database in the Object Explorer pane and from the ApexSQL Source Control menu click the Link database to source control option:

This will initiate the Source control wizard. In the Connection type step, select the Working folder option:

Quick tip: Please note that the Working folder feature can be used with either dedicated or shared database development model.

In the next step, choose objects that will be version controlled. Some frequently asked questions about the Object filtering feature are addressed in the Object filtering FAQs.

In the final step, specify the folder on a local machine (or even on a local network) that will be used as a working folder:

Clicking the Finish button will script all database objects included in the Object filtering step, and compare them with the current state of the working folder. When the comparison is done, the results will be shown in the Action center tab:

Exploring the feature without any source control system installed

In case you don’t have any source control system installed, you can use the working folder as a “local repository” where the changes you made through SQL Server Management Studio will be committed.

The main difference between the working folder and the actual source control system is that you won’t be able to review history of changes. Simply, the current state in the working folder can be considered as the “latest version” and you will be able to apply only the latest version and not any of the changes made before that.

Quick tip: Besides Project/object history, Labels aren’t supported when using the Working folder feature.

Using the Working folder feature with installed source control system

If you have a source control client installed and are using it to push/pull changes from a local/network folder (cloned remote repository) to the remote repository and vice versa, the Working folder feature can be integrated into the workflow. In this approach, the local folder (cloned remote repository) can be set as a working folder using ApexSQL Source Control. This enables developers to work on a database and commit changes to the working folder from within SQL Server Management Studio. Later, those changes can be pushed from the working folder to the remote repository using the source control client.

The following are the steps that need to be performed in order to set the cloned repository as a working folder:

• It is assumed that you already have some folder on your local machine where the remote repository was cloned. For the purpose of this article, I’ve cloned the remote repository (called Git1) hosted on github.com to the following location:

  C:\Users\Marko\Desktop\Working folder – test\Git1:

  

• Following the above described steps, link a database to source control using ApexSQL Source Control, and set up the path for the working folder to point to the cloned repository
• Since I’ve cloned a blank repository, all objects included in version control will be shown in the Action center tab.

• After the initial commit of all database objects from the Action center tab:

  

• The working folder and at the same time cloned git repository will have the folder complete structure created and all the scripts placed in the corresponding folders:

  

• After the initial commit to the working folder, the Action center tab shows that the database and the repository (in this case working folder) are synced:

  

• All changes made from now on, either in the database or in the working folder will be shown upon refreshing the Action center tab
• The entire folder structure along with all the scripts can be pushed from the working folder to the remote repository. That is something the source control client application is responsible for and it is out of the scope of this article

Quick tip: Be aware that there is no history of changes between the database and the working folder. The only way to keep the history is to commit each change or a changeset, right after you commit it to the working folder.

Using other features related to the specific database development model

All the features related to a specific database development model work in the same way as they will work in case the database is linked to the repository of any source control system. With that being said, for the dedicated development model you will be able to resolve any conflict that may occur between the version of an object in the database and the working folder.

For the shared development model, the features such as object statuses, check-in and check-out, Database change log, database policies will work in the same way with the working folder feature as with the actual source control system.

Quick tip: When using the Working folder feature with the shared development model, it is mandatory that all the team members link a database using the same/shared location.

Q: Can I use available 3^rd party merging tools in the same way for the working folder as for the actual source control system?

A: Yes, all available merging tools (including the built-in one) can be used when a database is linked to the working folder.

Q: Why I’m still seeing changes already committed by other users?

A: The most likely is that you are not using the same folder as a “working folder”. If this is the case, then being able to see changes already committed by other users is the expected behavior. Make sure you all linked a database to the same folder.

Q: Is it enough to check if the appropriate folder is selected for the shared model, just by checking the object statuses?

A: No, object status will work properly even if someone is not using the unique working folder location.