Feedback for Source Control for Oracle git alpha

richardjm

Happy holidays, the Source Control for Oracle git alpha is here.

There is now a version of Source Control for Oracle with very basic git support now available.

Please put feedback on this forum post.

This being an ALPHA it goes without saying that you shouldn't be using this for production source control but we're really keen on getting your feedback.

A few known issues and limitations...

* You can't clone using two-factor-authentication from github
* There is no support for merging branches yet
* If a commit fails then the system may get "confused"
* When linking we perform several full-depth clones of the repository - for large repositories this could be slow
* You can't link to a repository with no commits
* History is deliberately limited to the current active branch and only shows commits of database objects

I'll be on holiday until the 12th of January, I look forward to what you make of it when I get back. How far away from being useful is it?

Want a link the download, just email steve.harris@red-gate.com

Stuporman

Hello. I've had the chance to play with it a bit, and things appear to work mechanically.

The biggest suggestion I can make is to have the tool interact with a local repository rather than the remote. I don't really want SC for Oracle pushing for me.

In traditional VCS systems, checking out and checking in are chores. They're not particularly difficult, but they're very mechanical in nature, and so it makes sense for a tool like this to perform them for you. However, in DVCS systems like git, the functionality and flexibility inherent in the tool means that my use of it is more than just a mechanical chore. By pushing for me, the tool takes away much of that flexibility.

The workflow that SC for Oracle currently follows is necessary if and only if your team develops on a shared development database and you utilize the locking mechanism to ensure that no two developers are working on the same Schema objects simultaneously. Any other scenario would work better the way I've described, but it would probably be best to give us the option.

Stuporman

Let me provide a couple of use cases to clarify.

Setup

I have an existing project in a local git repository located at C:UsersStupormanmy-app. Within this repository is a directory called database which is currently a Schema Compare for Oracle scripts directory. I want Source Control for Oracle to take over management of that Schema Compare for Oracle scripts directory while allowing me to continue to use git as I did before because I am also tracking non-database source files in the same repository.

Operation 1

I am working in my own sandbox database on a long-term project that has its own branch. I am asked to fix a bug in our maintenance branch. I commit what I've done so far so I don't lose the changes, but I do not want to push it because I am planning on amending that commit later when I can finish the work I was doing. I then want to be able to switch to the maintenance branch and have Source Control for Oracle update my database to reflect that branch in one step.

Currently, this would involve issuing 'git checkout maintenance' at git bash or using Source Tree or some other git wrapper to change the repository to reflect the maintenance branch. Then, I must open Schema Compare for Oracle and load the correct project to perform the comparison and then deploy the changes to the sandbox database. If Source Control for Oracle either wrapped or responded to the 'git checkout maintenance' and automagically did the compare and deployment of changes to the sandbox when the 'git checkout' completed, that could save loads of time and hassle as well as reduce the potential for error on the part of the developers.

In this scenario, there is potential danger surrounding changes that have not been brought from the sandbox to the local repository. If the user forgets to commit the changes before switching branches and the changes exist only in the database, then git will not be able to recognize that there are uncommitted changes and will proceed to enable Source Control for Oracle to overwrite those changes with the new branch. Git refuses to checkout until uncommitted changes have been dealt with either by committing, removing, or stashing those changes. For this reason, Source Control for Oracle should synchronize changes from the database into the local repository before performing any git operations. By doing it this way, you do not have to worry about tracking those sorts of things yourself since git will do it for us.

Technical Implementation

I am a big proponent of the DRY principle. I have my own derivative companion principle called DRAEE which stands for Don't Repeat Anyone Else Either. If I were engineering git integration with something like Source Control for Oracle, I would be making liberal use of git hooks (http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) and Oracle Continuous Query Notification (http://docs.oracle.com/cd/E11882_01/app ... m#ADFNS018). In particular, on setup with the repository, I'd latch on to the scripts directory and register a post-checkout hook in the git repository that would update the database from the repository after a successful checkout. I'd also setup a CQN callback to update the repository whenever one of the relevant schema objects has been updated in the database. At that point, the users can minimize the application to the System Tray and never worry about it again since it would operate in the background to keep everything synchronized. This also means that users can continue using git on the command line or from the GitHub app or Source Tree or whatever they want which in turn means you don't have to reimplement all the stuff that they've done a reasonably good job of implementing while still providing tremendous value for end users. They support what they're good at, and you support what you're good at, so I can support what I'm good at.

richardjm

Stuporman wrote:

Hello. I've had the chance to play with it a bit, and things appear to work mechanically.

The biggest suggestion I can make is to have the tool interact with a local repository rather than the remote. I don't really want SC for Oracle pushing for me.

In traditional VCS systems, checking out and checking in are chores. They're not particularly difficult, but they're very mechanical in nature, and so it makes sense for a tool like this to perform them for you. However, in DVCS systems like git, the functionality and flexibility inherent in the tool means that my use of it is more than just a mechanical chore. By pushing for me, the tool takes away much of that flexibility.

The workflow that SC for Oracle currently follows is necessary if and only if your team develops on a shared development database and you utilize the locking mechanism to ensure that no two developers are working on the same Schema objects simultaneously. Any other scenario would work better the way I've described, but it would probably be best to give us the option.

Thanks for that and I apologise for my massive delay in replying.

At your prompting the beta (details here) now has a feature called "working folder" which allows you to connect Source Control for Oracle to a folder on the disk and we save changes and update files from that location giving you total flexibility on how you use your source control system - or even which source control system you use.

I'd be interested to see how you get on with it - the main disadvantage is that there is not way we can get history within the tool as we don't know the commands for history from just a folder.

richardjm

Stuporman wrote:

Let me provide a couple of use cases to clarify.

Setup

I have an existing project in a local git repository located at C:UsersStupormanmy-app. Within this repository is a directory called database which is currently a Schema Compare for Oracle scripts directory. I want Source Control for Oracle to take over management of that Schema Compare for Oracle scripts directory while allowing me to continue to use git as I did before because I am also tracking non-database source files in the same repository.
...

Wow there's a lot of detail there that I'll need time to mull over. For now, as I mentioned above, we've added working folder support which will allow you to link to an arbitrary folder on the disk allowing you full control over how and when to commit.

As for the commit hooks it's something I'll need to investigate, this initial v3 release we're aiming to get basic Git support in place and then expand on it as people request so this is something that is interesting as it's a detailed user workflow which is exactly what we need to understand how people want the tool to work.

If I understand correctly you imagine the tool to always sync changes from the disk to the database whenever a git checkout is detected, and automatically create a commit every time a database object is detected? I think that may work for you but I don't imagine it's going to be something that everybody wants.

Stuporman

Hi Richard,

Sorry for my late reply. I stopped checking on this forum after a while. I'm only just seeing your responses. This means I didn't try out the other beta, but I did just get the latest Deployment Suite for Oracle, so I'll still be able to provide feedback as I use it.

You are correct about updating the database per checkout, but I still want to leave committing in the hands of the user. In other words, I want the tool to update the scripts in my folder automatically in response to changes in the database, but the user is responsible for committing them. It basically just saves the step of manually triggering a sync which could add up to hours of time savings for busy developers.

You wouldn't have to do anything special if the developer decides to discard changes because that is done through a git checkout which would then trigger the database sync.

Thanks for your reply!