Source control with git?

Are there any future plans for this? Looking at Red Gate SQL Source control but looking at SQL Assistant for code completion... If you had support for git too that would be a winning combo and I wouldn't need the red gate product

I believe this is one of the demand based features. If there is a demand, there is a supply. To the best of my knowledge, you are the first one who has ever mentioned git at least here in the support forums. There is basically zero demand for git so far.

Hrmm. Well I am unsure how SA does version control but all the red gate product does is dump the ddl scripts to your working dir and compare them against the real db on startup or on demand(button click) or after saving an object back.

Then it asks if you want to take the changes and overwrites the .sql ddl script in the working dir for that object. You commit them with git when you want to merge the changes from working dir and last commit.

It works well and fast.

How does SA do its version control? Similar fashion of comparing the flat .sql ddl scripts to the current db?

Most source control interfaces work the way you described here, but only to a point. The dumped database files still need to be pushed to the repository, compared against the repository, versioned, etc...etc..., all of that requires source control specific commands or APIs. If you wish, you can use SQL Assistant to synchronize local workspace folder with the database and have it dump DDL scripts, but then from there you would need to run git commands manually to update the repository.

SysOp wrote:

Most source control interfaces work the way you described here, but only to a point. The dumped database files still need to be pushed to the repository, compared against the repository, versioned, etc...etc..., all of that requires source control specific commands or APIs. If you wish, you can use SQL Assistant to synchronize local workspace folder with the database and have it dump DDL scripts, but then from there you would need to run git commands manually to update the repository.

This is easy enough without git API.

Dump to working dir. Commit to git (git commit) will version it etc). If you change anything in the working dir another git commit will see those changes.

The big thing is if I change a table or sproc does SA prompt you to save or discard the changes with the working dir? Or if I pull an old version of something out of git will SA scan the working dir and ask me what to do since that file doesn't match the db version etc?

Well I got a topic notification but it seems to have been deleted?

I added a source control workspace, but when I go to update the workspace from the DB it wants info on my SVN repository which I do not have and I cannot continue from there.

To get it working you would need to get SA connect to some TFS or SVN repository. It doesn't mean you would commit to the repository, you just need the connection to get source control interface loaded.

PS. Commit is only one operation type, there are many others and all of them are source control specific, I'm pretty sure of that.

Consider scheduling nightly workspace updates using SA'sbuilt in method and separately scheduling git command to commit the workspace.

SysOp wrote:

To get it working you would need to get SA connect to some TFS or SVN repository. It doesn't mean you would commit to the repository, you just need the connection to get source control interface loaded.

PS. Commit is only one operation type, there are many others and all of them are source control specific, I'm pretty sure of that.

Consider scheduling nightly workspace updates using SA'sbuilt in method and separately scheduling git command to commit the workspace.

Yes I know commit is only one type of operation, I was just using it as an example.

Is there a way to use the version control module without SVN/TFS just to dump the DDL's to a working dir? If not could that be added in? this way folks can still use S.A's version control and use whatever version control software they desire?

Then S.A can still compare the working dir (latest dump) versus the database. Once you commit the latest dump then GIT would have that version of the document in it's database.. then you can do 'git checkout -- filename' to restore a version of it.. in which S.A would see that the working dir file changed and prompt you to compare and which one to use (either restore old version to the DB, or ignore).. etc

There are many free SVN repos on the web, if you get SA to connect successfully to any of them, for the rest it will do what you want

	SysOp wrote:
	There are many free SVN repos on the web, if you get SA to connect successfully to any of them, for the rest it will do what you want

I guess I can look into a local SVN repo. I don't want my DB schema out on the web.

nevermind.. got it.

I would like to rise up the question.

I believe nowadays, GIT is one of most popular repos.
Is GIT under consideration to be implemented in near future?

Yes, implementing support for GIT is already in the new features list, but I'm not sure about specific implementation time, there is no estimate available yet. We haven't started working on it yet.