How do l handle making a sample project that needs to be Strongly Typed, but not the master branch?

I am in the process of preparing all my projects that were on CodePlex to be moved to GitHub (Azure DevOps + GitHub actually), and I don’t know much (anything as long as potential clients aren’t reading this) about branches.

My project is called DataTier.Net. It was called RAD Studio Code Generation Toolkit on CodePlex, but the domain DataTier.Net recently became available so I bought it. DataTier.Net is 100% stored procedure driven alternative to Entity Framework.

Since I added about a bunch of new features for this release, I thought an interesting sample project to come with the program is an idea for Visual Studio Tool Window (like Solution Explorer) called VSNotes, a to do list program that might even pull in work items from the repo in a later version. 

From my previous adventures into VS Package development, I learned you have to have strongly typed projects for anything COM related. 

Now to my question, and this is why I can’t use Twitter as it takes me 2,000 characters to get to ‘Hello’.

What is the easiest way to handle this so that the projects in the Master are not strongly typed, but still keep one code base so I don’t have to maintain two branches?

Is this something an automated build should handle? (another buzz word I have heard of, but that is about all).

And last question if anyone has the time to read all this, and sorry if this is not the right place to ask this:

Is there a place on this site I can ask if any Git volunteer(s) wouldn’t mind adivising me on how to do some things while the projects* are currently in a private repo on Azure DevOps, 

* currently the repo is one very large repo containing all of my open source projects, because the explanation given here about sub projects was far outside of my understanding and Git abilities. 

I expect the 3 projects listed below will be very popular, and there are about 15 others that are sitting on my hard drive and might benefit someone.

DataTier.Net - Create 100% stored procedure driven data tiers. 

DBCompare w/ Remote Compare

Compare two SQL Server database. Either from two connection strings, or export the database schema to XML and compare the schema against a connection string for comparing SQL databases on private VM’s.

XML Mirror

Xml Made Simple. The Remote Compare features of DB Compare were made with XML Mirror.

Thanks. If this was a work project I could hire someone and bill the client, but from my previous experience open source doesn’t pay very well.

I like GitHub Azure / Azure DevOps so much better than CodePlex, as being able to view the code before you download it is so valuable, but CodePlex let me upload a zip file and it was easy as far as releasing something, but not updating.

I am trying to catch up to this century.

I hope I’m understanding your question. It sounds like you have a code base that you’d like to keep both an untyped and a typed version of in Git, for example a code base in TypeScript, one without types and the other with. And you’re asking if using branches is the correct way to handle this?

If my understanding is correct, I would have to give a, possibly infuriating, “it depends”. For example, if the code base is complete and you’re not going to change it very much or at all in the future other than to add these types, then yes, that would be a fine use of branches. But if you’re going to be continually updating and maintaining the code base, things get complicated quickly. It gets complicated based on how much those two code bases are going to diverge and how much and which direction changes are going to be interchanged between them. If you’re only going to add changes to the untyped code and then merge those changes over to the typed code base in that one direction, then it could be reasonable. If you’re going to make changes to either and swap changes back and forth, I fear that things will become hard to handle rather quickly.

The simplest branching model is having one main branch and many short-lived “change” branches that are split from the main branch, some work is done, and then merged back in to the main branch. The next simplest is having two “main” branches, “development” and “release”, many short-lived “change” branches that get merged into “development”, and then changes in “development” get merged to “release” when you’re ready to release the next version. There are more complicated scenarios above that, but I hope you see the pattern here, managing branch complexity is best done by keeping changes flowing one direction.

I hope that helps!

1 Like

Yes it helps, as any where to start asking the right questions points me in the right direction.

To answer your question, I would only be updating the non-strongly typed version. I just hate to make the main code base strongly typed for compatiblitiy with other libraries, ease of use, etc.

Now for the ‘How to’ part since you said this scenario is probably possible. Do I have to manually pull changes for the other branch, or are there ways to force this happen when I sync a checkin?


I don’t have to do a Visual Studio package as a sample project, I just thought it would be a fun and useful demonstration since everyone using the product will have Visual Studio.

This might be a later released sample since the strongly typed branch adds a lot of complexity.