TeamCoding - custom remote / branches

Could someone please explain the usage of the Custom Remotes option inside Toad Team Project? I havent found anything about this option online. Am I able to do a push to other branch than master? (this will be a very nice feature...).

custom1
custom2

Hi Niko,

Yes, the purpose of this would be to give you the option to push to/pull from a different remote branch. Since Git allows you to push and pull from different remote repositories, this option was added to give you that option as well. Of course, the functionality would still depend on whether Git is able to do a fast-forward merge with that remote, and the remote has to be defined for your local Git repository (see Git's help for the pull and remote commands), but the option is available.

-John

I have additional branches locally and on a remote repo, but I still dont see them inside the Toad. After clicking the pull from remote (custom) or push to remote (custom), I am getting the window to select remote to which to push but in the dropdown I still see only "origin" option...

Hi Niko,

The local repository needs to know about the remote in order to push to it. Toad executes the git remote command in order to obtain information about which remotes are known by the local repository. My suspicion is that if you ran that command within a command prompt, you'd also only see an entry for origin. You can add remotes by using the git remote add command. You can also reference Git's help document on the remote command (git help remote) to see how to add and remove remotes from the local repository.

-John

Hi John,

seems that you misunderstood me (I guess its my mistake), but I am not talking about additional remotes. I am talking about additional branches inside the remote. This is something necessary for us because we have several developers in here. Idea is that each of them upon getting the task create new branch based on that task and work on it. Upon finishing, they should push the changes to that branch and create a merge request with test branch. Jenkins should then compile the changes on a test database (we already made this to work).

We are gonna have test and master (production) branches + branches based on developer's tasks so we need "few more buttons" so that we can (from toad) create new branch, switch to it, push/pull from it.... I hope you understand our need for this. Thank you

I found this as an answer from May 2018:

There’s no current plans to implement branching or merging in Team Coding since databases don’t support them. It’d be too easy for two people working in different branches to overwrite each other’s database code, or for multiple code branches to get out of sync with database objects. Team Coding was designed to work directly in the trunk for all version control providers, whether centralized or distributed.
Git Branches - #2 by jbowman

Regarding overwriting the code, object is being locked after checking out so this is really helping a lot. Also, GIT is holding every change in its history so it can be easily reverted back if needed.

I understand your concern but I dont see nothing bad in giving us option and let us try. Reading the forum, its obvious that there are people who also need this.

What I have tried is to create a new branch and switch to it via Git Bash and then check in and push object changes via Toad. I got what I wanted, Toad pushed changes to that new branch so this could work, I would just like to have all in one place.

I hope you will reconsider this feature. Thanks

Hi Niko,

Sorry for the delayed response. The problem is not really rooted in branching perse, but in the switching of branches and merging that happens fairly regularly in distributed version control systems like Git and Mercurial, and the possibility that changes within those branches may not get reflected in the master repository is a good bit higher.

In distributed environments, switching between branches can happen pretty regularly during the course of a work week. The concept in distributed version control systems is that you can work in your own isolated version of the repository without affecting anyone else and then simply merge your changes in when you're done. If you need to change direction due to an immediate fix or if your current changes aren't working, you can simply create a new branch and optionally throw your existing one away. During that process, the version control client will rebuild the entire local repository to match the condition of the known head revision of the specified branch to which you're switching.

Databases, however, don't support such a mechanism as all code is live and shared between all users. It operates in a centralized version control manner. As a result, the database code can't be changed to synchronize with a random branch switch from the VCS client -- nor really should it. Doing so could cause significant damage to the database code, and could potentially overwrite code on which another developer is working. As a result of a branch switch, your local repository (and everyone else's) is now out of sync with the database code.

As an example, let's say you're a developer working on a new database feature. In a typical Git environment, you would create a local branch and start working in your branch. You make a few changes to the database code. In the meantime, another developer is working on their new feature in their repository. They can see in Team Coding that objects are being changed (if they have "prompt user on differences" enabled); they can also see when you're currently changing certain objects because those objects are being locked in Team Coding; and they can see when objects were last changed in the Object Summary window; however if you haven't pushed your changes yet to the central repository, they can't yet see the VCS history of those changes. If you decided to go a different direction with your code and decided to throw away your current branch, it's fairly easy to throw away a branch in Git, but those changes have already been made to the database and it may not be as simple to identify and back out those changes.

Similarly, let's say while implementing your feature, you get a high priority bug that needs fixing or a higher-priority feature that needs implementing. In Git, you'd normally switch branches back to the last known stable branch and create a new one to make your change. During that time, there's no simple way to revert the changes you made in your branch from the database in favor of the new changes you need to make. If the new direction goes on a while, your original branched code will still be in the database even though your local branch has been shelved. Meanwhile, the other developer sees the database object as different from what's in both their's and the central repository's source.

Branching and merging is a complicated topic when it comes to database code with a much greater risk of database code corruption. That's why it's generally recommended to not use branches with database code when using distributed version control systems such as Git and Mercurial. It's not to say you can't use branches within Team Coding; but for now we're leaving branch management to the user as a process which requires manual intervention. It's something that we are continuing to consider, however, but always want to make sure we always consider database code consistency in doing so.

-John

Hi John,

Thank you for very detailed response. Your arguments are on place, I understand the "cons" and I agree with you, database is a centralized system and thats just how it is.

Why I believe that we can work with branches without issues is because one of our team is in charge only for reports, so in 99%, 1 guy is in charge for 1 report (1 procedure), so nobody else is going to mess with his work...

If all of them are working on the same (master) branch, merging changes within Test branch is in no use because all changes will have to go to test server, even if some projects are not finished yet... I hope you see the problem we are facing with... Solution is to go with branches OR not to commit anything till the project is fully done, but in this case changes will be inside the db but not on git so this is also not a good practice...

Regards