Hello, our team has installed and configured Team Coding a couple of times, but have never been able to get the workflow to accommodate more than one developer at a time. We have reviewed several videos and articles on installing and configuring, but we run into the same issue.
Currently we have Team Coding (v13.1) installed, but our TOAD is 14.0.75.662. We have been attempting to use Git as our VCS.
The trouble for us is when we set up projects and as each developer creates a new project, the location of the local Git is reset for all the projects. So I come in make a project or two, set the location of the Git repository to a work directory on my workstation (I'll push and pull to Azure DevOps as our remote repo). Later another developer comes along, starts a project, enters a different path to their local repo, and mine is now changed and I will have to steal it back in Team Coding Configuration to keep working.
Obviously we have installed and/or configured TC incorrectly, but we have not found any examples of a set up for several developers using TC.
Following the Quest Getting Started guide, the video and others, a DBA and I installed it on our Oracle server in its own schema. There are many schemas on this server, I only work with a few, other Devs have their own. However, we end up all modifying the same Team Coding Configuration panel and step on each others projects.
Did we miss a step or concept when we installed it? Are there articles out there that explicitly show how to configure for several developers? In general, the Git versioning functionality works well, but we can't figure out the configuration.
Hi Colanut,
My apologies for taking a bit to get back to you on this! Normally in a Team Coding environment, Team Projects follow what schemas are available on the database and are configured once (at the beginning) and not modified afterwards unless new schemas are added or removed. They're also typically configured for schemas that are more persistent on the database than temporary. For example, using the description you mentioned, let's say that the database has four schemas:
- Accounts
- Orders
- Billing
- Support
And let's say developers have their own schemas for development and testing:
- Bob_Schema1
- Sally_Schema2
- Bill_Schema3
Normally, I would expect Team Projects would be set up for the four persistent schemas (Accounts, Orders, Billing, and Support), but probably not for the individual developers' areas as they may be more temporary and used as sandboxes. You could set up Team Projects for each of the schemas, but you'd be saving version history for things that are only temporary in nature.
As for folder organization, to help reduce your local repo changing, I would recommend enabling the option to "Use Subfolders" when configuring your Team Projects so that your repository files are hierarchically structured, but I would probably leave the "Parent Folder" option as either the default (which would be the database name) or a common name. You can also leave it blank. That way, new schemas that are added would simply appear as new subfolders off the main folder in the local repository and you shouldn't have your local repository's root structure changed.
Can you perhaps expand a bit on why developers are creating new Team Projects and how that's changing your local repository? Perhaps I'm not quite following your work scenario. Can you provide an example to help illustrate?
Thanks,
-John
Thanks John, I think we are a similar path. Like your example (which I will stick with) we have a number of schemas for different areas. Since we are just starting out and testing, individual developers were setting up new projects. Also, this is a shared server so different departments (and their devs) manage their own schemas. As an aside this is our ODS warehouse where each major functional area has a team to manage their own schema.
I like the your use of subfolders- each subfolder for a schema, and a parent folder for the whole DB. Some of these distributed teams may or may not use VC, and they may or may not add their schemas, but as you say, their work would not interact with the others.
I suppose then that adding projects should probably be handled by one team, rather than individual developers, so as to not have accidental configuration of other folk's projects. Which we experienced.
I appreciate the organizing strategies.
The next part that tripped us up as configuring the local repository and VCS log-in for Git. In our testing, I set up a project and told TC that my Git repository was in one path, and then other developers didn't know what I did and made theirs in other paths. From your example different devs keep their git in different places:
-
Bob_Schema1 used C:~user\Documents\ODS Versions\Orders , C:~user\Documents\Support
-
Sally_Schema2 used C:~user\Documents\db_work\Accounts
-
Bill_Schema3 used C:~user\dev\ODS\billing
Each time a project is created and the VCS is configured, that path to the local git changes for everybody's projects. So when one developer comes back they have to change it again to get to manage their local repository and the cycle starts again.
Maybe we are not doing the VCS log ins correctly either?
I appreciate your thinking on this. I feel like we are part way there, but I'm missing a step or a concept.
Hi Colanut,
I'm not sure how the local path is changing for everyone's project. The local path is not actually saved with the Team Project's configuration in the database. You can view the configuration settings within the database tables. The configuration settings for Team Coding's global configuration are stored in XML in the TC_OBJ_STORE column of TCX_CONFIG, and the settings for the Team Projects themselves are stored in XML in the PROJECT_CONFIGURATION column of the TCX_PROJECTS table. The local path used for your repository should not be in there as that's a user-specific setting and not a team-level setting.
Instead, you can find the local path in the Git.ini file within Toad's Application Data\User Files directory (Tools -> Options -> General -> Application Data Directory -> click Open Folder -> navigate to User Files). Is your team perhaps all using the same Windows login name and synchronizing your application data folders to the network? If so, I could potentially see that causing an issue as a change one person might make locally could cause another developer's Git.ini file to be overwritten by his/her settings when their folder is synced.
-John
Oh no! Sorry I wasn't clear on that. TC is not moving my actual Git location. Here is a screen of the part where I am configuring the location of the local repository of the Git Log-in:
So this is setting up the Git log in where I can then check-in/check-out. You can see where I've done many tries. (Also, I'd love to clear that list out, because most of those were on my previous workstation.) But when another developer adds a project, for some reason this gets changed in all projects and I can't do the git commands since the location of the log in has been changed. At least that is what we have experienced.
Hi Colanut,
You can clear out the extra entries in that Git.ini file I mentioned previously. All of those saved locations should appear in that file. All you should need to do is edit the file and remove local folders you no longer wish to use from Toad.
I still don't know why other users' local repository folders would be added to your INI file and listed in the Repository dropdown as those aren't saved to the database. As a result, there should be no way for them to be copied from your coworker's machine to your machine and added to your local Git.INI file. Are you perhaps working in a Citrix or Terminal Services environment and all sharing a single machine?
When you go to Toad's Options window, what is showing for your local Application Data folder?
-John
Thank you John for sticking with me on this. Here is my local Application Data folder (yes, colanut is my User ID, I created my email almost 25 years ago and worked on a different campus):
C:\Users\colanut\AppData\Roaming\Quest Software\Toad for Oracle\14.0\
Thanks for the pointer to Git.ini file. I didn't know that existed and now I have a clean VCS log in menu (that itself is gold).
We are not sharing or are in a Citrix environment. But now I am starting to look at the VCS log in procedure as our area of our not understanding. I'm going to have to re-set up my project and then ask a colleague to then do the same. I will get before and after screens of the issue we are (were) seeing. We haven't looked at this effort in a while- our department shifted to Covid monitoring efforts and are now returning to our regular projects.
This will take a couple of days, and I will report my findings. I agree that it would be odd for TOAD/Team Coding to be pulling in other user's Git and reusing them. Sometimes, I doubt I saw it behave that way, but the other Devs experienced it.
