More source control questions: shared projects

[robert]

Karl,
What I read is that Dick has 2 folder structures:
C:CSharp
C:XSharp

and wants to manage these under Git at the same time
I think that this is not possible.
To manage code at the same time there has to be a common folder.
You can do this in 2 separate Git repositories, but I do not really understand what the use is to group projects by development language.
Most customers that I have worked with/for use a different folder structure.
Something like:

C:ProjectsProject1
C:ProjectsProject1Library1
C:ProjectsProject1MainExe
C:ProjectsProject2
C:ProjectsProject2Library2
C:ProjectsProject2Library3
C:ProjectsProject2MainExe
C:ProjectsSharedCode
C:ProjectsSharedCodeSharedLibrary1
C:ProjectsSharedCodeSharedLibrary2

In this layout I would create a Git Repo at the levels Project1, Project2 and SharedCode
Even in this layout it will be difficult to checkin Shared Code and Project specific code, but at least you are then following the common logic that the whole world uses.

Robert

[TerryB1]

Hi Karl
You’re right – probably nothing, just an aside.
I was trying to give a possible reason for the error messages Dick was getting when trying to do what I understood him to be doing.
Terry

[MathiasHakansson]

It all boils down to the question;

In which Git-Project does the shared code reside?

If the shared code resides in several different Git-Projects at the same time you would not be able to version control your code. Which Git-Project holds the latest code change? Merging simultanious changes will not be possible.
If you branch your code you will get a new solution folder on your disk. This folder will contain the full solution. What happens to your shared code then?
Read more on branching strategies on https://www.javacodegeeks.com/2015/11/g ... egies.html

One way to (sort of) do what Dick wants is to have all applications in the same solution. This way of doing things has several disadvantages. The applications may not have the same life span, release dates or developers. Compiling will take a long time. It's much better to divide your solution into smaller parts and treat your shared code like a third party component. Update in each project when convenient, either manually or with nuget.

/Mathias

[ic2]

Thanks, all for the comments. @Terry, it looks like the error is a problem in the Git Credential Manager which reoccurs every time again. See this link "Can't login to GitHub" https://github.com/github/VisualStudio/issues/949 which started 16 month ago and has new comments up 'til today. Someone suggested the hashtag #MicrosoftShouldNotMakeSuchStupidMistakesInTheFirstPlaceBecauseWhatIsTestingForAndTls1.2ExistsSinceALongLongTime and I can only agree with that. It's really frustrating that the life span of once working setups with everything with and around Visual Studio is sometimes not more than a few days after which one can spend hours to get it working again .

And it's X#/C# only I use it for. For VO we exchange .prg's/mef's/.aef's and sometimes the whole repository. And VOPP provides daily backups to compare too if necessary. Not ideal, certainly not, but it works without the problems I encounter with whatever Source Safe I tried on VS.

Robert's answer is closest to what I want. Dividing C# and X# projects in directories is not really necessary but from your reply I also understand that even putting it in 1 directory won't work as I would expect. In short, if I am working on a solution which includes a C# commonly used project, found on C:ProjectsSharedCodeSharedLibrary1, and I make a few changes from the solution in C:ProjectsProject1, it means that the source control of C:ProjectsSharedCodeSharedLibrary1 is unaware of these changes. So I have to open a solution under source control containing C:ProjectsSharedCodeSharedLibrary1 as main project otherwise I can't exchange changed code.

I don't need different branches and whatever elaborate options source control may have. I just want to make sure that everyone in my team can update their version of the project with the changes the main programmer made. And maybe the other way around. Without having to think how & from where I open the code to maintain.

If that's impossible, and it looks like it is, source control could as well be replaced with a simple file comparison program which collects the real changes and sends them to other users. It would meet my simple requirements, without all the potential elaborate options but also without the problems I've been seeing since I started implementing this.

Dick

[Otto]

you can do the following:
1. designate one head parent folder. One to rule them all
e.g. c:projects
2. inside that folder you put your projects, the shared and the non shared projects.
3. in that main folder, create the solutions with the projects you want to combine.
e.g.
MySolution 1: containing Project 1, Project 2, and the shared project(s)
MySolution 2: containing Project 2 and the shared project(s)
MySolution 3: containing Project 4 and the shared project(s)

And if you like, One solution to rule them all containing Project 1, Project 2, Project 4 and the shared project(s).

We do this all the time.

But, consequences of using shared projects this way, is that you have to make sure that the shared project works together with all your projects before you can check in.

If however you create a nuget package for the shared projects, you can safely and controlled upgrade the assemblies of the shared projects for Project 1, 2, 3 and 4 independent of each other.

[TerryB1]

Hi Dick

Yes - that's right.

Terry

[ic2]

Quick reply. For now I solved the above error by copying the binaries from the "<VS_INSTALL>Common7IDECommonExtensionsMicrosoftTeamFoundationTeam ExplorerGitmingw32bin" folder to the "<VS_INSTALL>Common7IDECommonExtensionsMicrosoftTeamFoundationTeam ExplorerGitmingw32libexecgit-core" folder. Not sure if it's a problem in combination with Bitbucket (as I do see the problem mentioned in very recent posts concerning Github). Seems to be absent with VS 2017 before 15.7.5 (updating to 15.7.6 did not solve it). Anyhow, good reason to not update VS for the rest of the year - if this keeps working.

I'll check out all the advices next.

Dick