Beta 13.0.0.60 TFS-TFVC interface allows linking to a subfolder of a linked project?

Toad for Oracle - Beta
1

In the TFS-TFVC window I wasn’t allowed to use $/BanTest in two different Team Coding projects. However, it did allow me to use a subfolder of BanTest in the second project. Is it supposed to work that way?

2

Hi dwmosman,

It is supposed to work that way, yes. You can’t map two different Team Projects to the same folder, and I would highly recommend against mapping a second Team Project to a subfolder of the first Team Project. What exactly are you trying to accomplish? Perhaps there’s an easier way to accomplish what you’re trying to do.

-John

3

Well, this report was more accidental. I was just looking at some improvements from 12.12 and tried it for curiosity’s sake. Then, since it was Beta and all, it seemed like I ought to report it in case it was a glitch.

But I sure wouldn’t turn down helpful advice. We’re trying to set up pilots of TOAD with Git and TOAD with TFS TFVC to decide which approach to take. Our immediate goal is to add version control to our Oracle programming, long term, we’d like to expand version control to our other code-bases as well. I’m working on setting up the TFVC pilot while my associate is working on Git. This is kind of a challenge since I haven’t done anything with TFS-TFVC before so I don’t know how either TFS or Toad really wants to work.

So any recommendations on how best to organize projects and folders would be welcome. A lot of my questions are being generated just from trying to reset and start over to learn what’s possible.

For what its worth, we’re a small to medium sized shop. Heavy on vendor systems, lots of PL/SQL, with a smattering of other stuff mixed in. The work is mostly small development projects, integration, vendor package mods and base data structures for a central reporting group. TOAD is our primary IDE, used by DBA and dedicated PL/SQL programmers. A few others with limited touches use SQL developer or similar when they need to.

One challenge is that our vendor code base is huge but we will only modify a small percent of it. I’ve been thinking about going with a single project so we all don’t have to download 40,000 objects we’ll never use. But I don’t really like that, isn’t it better to group by application or by schema?

4

Hey Douglas,

Not a problem at all. A good portion of what you choose will ultimately depend on cost, what features you need, as well as which VCS you’re most comfortable working with. There is no magic bullet with VCS providers. Each has its own advantages and disadvantages from a usability standpoint. From Toad’s perspective, here are a few differences to consider:

  • Clients
    • Toad’s internal TFS client consumes TFS web service endpoints, so there’s no client to install. All you need to do is enter your server name and go.
    • Toad’s Git support requires a command-line Git client installed on your computer.
  • Working model
    • TFS is a centralized version control system, so all changes are made directly to the server.
    • Git operates in a distributed fashion. All changes are made to your local repository. As a result, you’ll have extra steps to synchronize between your local and remote repositories.
  • Work-item tracking
    • TFS supports tracking work items (essentially “to-do” tasks), and you can link those work items to check-ins.
    • Git doesn’t have native support for work-item tracking, so this would not be an option in Toad.
  • Revisions
    • TFS uses sequential revision numbers
    • Git uses hashes for revision numbers
  • Forced revisions
    • TFS supports forcing a revision of unchanged DDL code
    • Git doesn’t support forcing a revision of unchanged code
      As mentioned in your other post, Toad’s Team Coding needs to work in the master trunk of the VCS. It does not support branching or merging, as that’s a very easy way to cause issues in the database. When working with database objects, I would steer clear of branching and merging techniques. For that reason, I might recommend having separate project areas in the VCS for database code vs non-database code. In Toad, you can follow the Getting Started guide, which can be accessed by a tool button in the Team Coding Configuration window in Toad for Oracle 13. For Toad 12.12 or earlier, you can find it here:

https://community.toadworld.com/members/john-pocknell/blogs#post-15929

As for how to structure your projects, there are a couple of different ways you could do it. You mentioned that you have over 40,000 objects, most of which will never be changed. You also mentioned that your shop is heavy on vendor systems and small development projects. In that scenario, breaking it apart may have some benefits so each user doesn’t have to download everything. Assuming that each development project accesses its own set of database schemas, and development projects are different than vendor mods, you could break it up into groups, like the following:

VCS Root: $/DatabaseCode/ (TFS) or C:\DatabaseCode<DatabaseName> (Git)

  • Team Project 1: Name = Vendor Code, VCS Project: Vendors, Parent Folder = , Database Objects: Schemas for vendor products

  • Team Project 2: Name = Dev Projects, VCS Project: Projects, Parent Folder = , Database Objects: Schemas for dev projects

  • Team Project 3: Name = Reporting, VCS Project: Reporting, Parent Folder = , Database Objects: Schemas for central reporting
    You could then leave “Subfolder Structure” setting in Team Coding as the default "Schema / Object Type / ", and your VCS would be organized:

  • $/DatabaseCode/

    • Vendors
      • Schema(s)
        • Object Type(s)
          • File(s)
    • Projects
      • Schema(s)
        • Object Type(s)
          • File(s)
    • Reporting
      • Schema(s)
        • Object Type(s)
          • File(s)
            If you needed to break them out by individual vendor or project (provided there aren’t too many), you could use something like this:

VCS Root: $/DatabaseCode/ (TFS) or C:\DatabaseCode<DatabaseName> (Git)

  • Team Project 1: Name = Vendor1, VCS Project: Vendors/Vendor1, Parent Folder = , Database Objects: Schemas for that vendor’s products

  • Team Project 2: Name = Vendor2, VCS Project: Vendors/Vendor2, Parent Folder = , Database Objects: Schemas for that vendor’s products

  • Team Project 3: Name = Vendor3, VCS Project: Vendors/Vendor3, Parent Folder = , Database Objects: Schemas for that vendor’s products

  • Team Project 4: Name = Vendor4, VCS Project: Vendors/Vendor4, Parent Folder = , Database Objects: Schemas for that vendor’s products

  • Team Project 5: Name = Vendor5, VCS Project: Vendors/Vendor5, Parent Folder = , Database Objects: Schemas for that vendor’s products

  • … etc …

  • Team Project n: Name = DevProject1, VCS Project: Projects/DevProject1, Parent Folder = , Database Objects: Schemas for that project

  • Team Project n+1: Name = DevProject2, VCS Project: Projects/DevProject2, Parent Folder = , Database Objects: Schemas for that project

  • Team Project n+2: Name = DevProject3, VCS Project: Projects/DevProject3, Parent Folder = , Database Objects: Schemas for that project

  • … etc …

  • Team Project x: Name = Reporting1, VCS Project: Reporting/Reporting1, Parent Folder = , Database Objects: Schemas for central reporting
    You could then leave “Subfolder Structure” setting in Team Coding as the default "Schema / Object Type / ", and your VCS would be organized:

  • $/DatabaseCode/

    • Vendors
      • Vendor1
        • Schema(s)
          • Object Type(s)
            • File(s)
      • Vendor2
        • Same as Vendor1
      • Vendor3
        • Same as Vendor1
      • Vendor4
    • Projects
      • DevProject1
      • DevProject2
      • DevProject3
    • Reporting
      • Reporting1
        Then, in Team Coding, you can freeze the vendor code projects (in the toolbar of the Team Coding Configuration window) that shouldn’t get changed to prevent developers from making modifications to them.

In Git, using this methodology may be a bit more complex since cloning a remote repository copies all files, folders, and complete revision history to the local machine (which could get quite large). In that case, you could:

  1. Use shallow cloning whenever possible (see Git’s “clone” documentation on that), or
  2. When starting a new project, clone only that project’s folder into a new local folder when logging in via Toad.
  3. ex: Assuming you have a central repository at http:///git:
  4. You could clone http:///git/DatabaseCode//Projects/DevProject1 to c:\work\projects\DevProject1.
  5. If you needed to switch to DevProject2, re-log into Git and clone http:///git/DatabaseCode//Projects/DevProject2 to c:\work\projects\DevProject2.
    I hope this helps provide some direction. If you have any other questions, or there’s anything else I can do, feel free to ask!

-John

5

This is very helpful. However, past development projects have not maintained separate schemas and many included mods to existing apps so cross-schema has been more the rule than the exception.

Also, our primary vendor, a large school ERP system, chose to organize by general purpose rather than specific functions. As a result, the bulk of code is in three schemas:

General - 2100 objects general purpose tables, objects and reference tables

Base - 13,000 objects most packages, functions and procedures

Student - 6,000 objects the primary student application

So, even for a small ticket request, its not uncommon to need to access all three of those large schemas. I’ll try setting up projects for each one today or Monday and give it a bit of a go. Unless you have other suggestions?

I do have a couple of other questions.

How to I get rid of old TFS Workspaces? I’d like to clear out the old local folders and start over but I don’t see any delete. Do I need to install Visual Studio or Eclipse to manage those?

Also, on new work - When creating a new script or object, it says the file has to be “saved” before being added to the VCS. Does it need to be saved into its proper place in the local repository? Does Team Coding or the VCS lock into the original save location in some way. If not, then after adding the object to VCS, should the original saved version be deleted?

6

Hey Douglas,

My apologies it took me this long to get back to you on this post! I never got notified of your response in this thread. I came across it while answering your other posts.

Well, that many objects in only three schemas will present a challenge for management, to be sure. Team Coding should be able to handle it, but you may experience a bit of delay in loading, and you may need to scroll through a lot of objects in the Team Coding Manager. In this case, I might recommend setting up the projects and using the Schema Browser instead of the Team Coding Manager. It'll be a matter of personal preference based on performance and user interface.

How to I get rid of old TFS Workspaces?

TFS Workspaces themselves need to be deleted from within Visual Studio Team Explorer. However, you can edit existing workspaces and remove or remap folder links by clicking the "Edit" button on the TFS login window in Toad.

As for the question about saving scripts, I think we covered that in another one of your posts. If we didn't, feel free to ask again!

-John

7

Oops… I spoke too soon. You don’t need to delete TFS workspaces within Visual Studio Team Explorer. You can do that within Toad by clicking on the “Remove” button on the TFS login window. That will remove a workspace from TFS so you can create a new one. Again, clicking the “Edit” button will allow you to remap folder links in an existing workspace.

-John

8

It seemed to me that the remove button just removed the selectced link but the workspace would continue to hang around and show up on the dropdown even after all links were removed?