After Dick's rather challenging post (to put it nicely) about my lack of knowledge about Source Control 'SC', I thought I would take a look at what I had been storing away - with very little effort - over the last few weeks while researching Reporting for Cologne. I was not really aware of this, its become rather automatic ....
Since it takes very little extra effort to include a new solution, and any new project in SC, and then a few times a day save the changes, I am surprised as to what is available to me through the SC system.
Tonight it is late, but I would still like to share a few images with you, of what is stored and what may be on offer if I require it.
First of all we can see plenty of date ordered entries :-
If I was using this in a more professional way I would make more of an effort with the Messages and the Tags etc., etc..
We seem to be able to get to the changes in each of the files :-
And we also seem to be able to compare files - 'now and then'. I think there are more options for comparing etc., but this is where my lack of knowledge lets me down - sorry!
There seem to be many more options for branching and syncing - for Team changes, and more.
Personally, if I needed this as a tool to do as has been discuss in the earlier Thread, I think I would invest some time to learn how to drive this software tool - it looks really good. And it seems to just be free, and lying there in VS 2015 windows and panes.
In case you are wondering - I use 'Team Explorer' and 'SC' simply because I once lost over four hours of hard coding on a very complex SQL app, supporting my son and his research. From then on I vowed to never have that happen ever again, and moved from micky mouse 'DIY' backing up with File Explorer, to doing things properly. Touch wood I have not lost any code since then, and just hope that if and when I do, the sort of information I share with you tonight will see me A-Okay ;-0) I include ALL new solution / projects in SC, its so easy to do.
Hope this interests a few.
After April and Cologne, I will look to adding a section on SC with VS into my 'ClickStartXSharp' eNotes.
without his encouragement for me to look further into TFS (Team Foundation Server) and SC (Source Control) I would NOT have discovered for myself just how powerful the in-built VS functionality is and can be. I will use it more I feel.
Let me tell you of a little experiment I just made, and the fantastic outcome I discovered. Remember, I only tend to use TFS as a better and smarter back-up facility - I suppose. It is easy to apply as well.
In the test projects I am doing for the Reporting session at Cologne 2018, I have a WPF app with a 'Main window' class at its root. If I highlight this PRG in my Solution Explorer pane (SE) I can see all the times that changes to this file were made (view history) - check out below :-
This is what was used to get the list of entries shown above :-
Now then, if I bring up the context menu on any of these saved 'entries', I have an option to 'Open' the entry - as shown below :-
This then opens a tab in the editor in R/O (Read Only) mode of that exact same code file - in full. As it was at the time it was 'committed' (we may loosely say saved, but its more than that).
Checkout below to see the heading details :-
Now then, we can even open up each one in turn and get a whole 'historic' bunch of the 'committed' file but at each different stage of its development - see the next 'Magic' image :-
I made this image by dragging and sliding the tabs from the editor onto an extra side screen on my office PC.
Now then, as well as the full details as described above for cross comparisons, we can select from the context menu of one selected committed entry, to compare it with its previous version - see the context meu options a couple of images back.
Now then lets see what we get when we ask the TFS system to compare for us - checkout this :-
Very nice, and also notice that we get some smart information in the scroll bar area as well.
So what have we got with TFS ?
Well, we can see each and every version of a selected PRG file that we have committed - and we can compare each with its previous version. However, we can manually compare any tab with any other, if we choose to.
It would also appear that we only get entries in the list if in fact there were any changes to that PRG file, when we made a global (solution / project) commit action.
To be honest, I thought this sort of SC functionality would be MUCH more difficult to use than this - it has proved to be really quite easy and straight forward.
The downside (perhaps) of this for some guys is that they may have VERY large files (judging by the forum posts) - we need to ask Robert if he thinks LARGE files would be any kind of a drawer back.
Hope this interests a few, as well as motivating some newbies to give TFS a try out. I consider myself as a newbie ;-0)
Best regards, and have a nice day,
With this info from you I will plan trying TFS/SC. What I miss in your story is that it seems to use GIT. I have never done anything with GIT, but according to this page www.visualstudio.com/learn/install-and-set-up-git/
it is again something which is controlled with obscure command and parameters ("you’ll be able to use Git from the command prompt or PowerShell."). Or can one avoid git and assign a place on the own hard disk?
Quick edit/update:I completely de-installed Ank, Tortoise and Github on my Pc. When you then select Project/Add to source control, some .Git files and directories are added in the project directory. I see no way to change the location. In the VS Tools/Options menu, Source Control I can choose for Git (which I don't want for the above reason) or VS TFS (which I don't want because it's cloud based and requires me to login in a VS account). Removing the source control again is a matter of deleting all .get files+dir.
With this page stackoverflow.com/questions/2653379/list...isual-studio-plugins
I tried another one : Visual SVN. But that requires Tortoise SVN as well. Plus that the project I tried the source control on (and deleted it again) now starts with An error occurred registering this project with source control. It is recommended that you do not make any changes to the project.
Great. I suspect it may be because I didn't install Tortoise. I quickly uninstalled Visual SVN again. Then the project start with:
The source control provider associated with this solution could not be found. The projects will be treated as not under source control. And then I can permanently delete the source control bindings which solved it again.
Before I consider using source control, I need to know where my repository is stored. And it seems that it is impossible to vary that per project. I could imagine that a project running from my on site working trainee could be under TFS (on line) while my own projects should be on my own Pc where I want them. But as usual I suspect I want something which is impossible with VS and nobody has ever had the idea that they want it working differently than it works now .
Once I figured things out I'll add it to the X# wiki page.
It certainly does not solve my quickly-locating-last-changed-entities-in-any-prg/cs issue but for other purposes it may be of some use if it's more reliable than Ank/Tortoise.
In case anyone is interested in WPF apps, then you need to know that the SC (Source Control) built into Visual Studio (I am using 2015 Pro) also nicely handles XAML script files as well as the standard X# code files.
Here is a sample from my Reporting app being developed for "xBase.Live", Köln 2018 :-
Sorry, but the only example I can give (it is a live SC sample) is a bit complex looking, simply because I obviously made a few changes from one commit to the next one - I use the graphical Designer surface a lot.
I think the first you need to is to consider you branching strategy, see link below. Especially if there is more than one developer for the Project. Even is I use microsofts repository I use GIT's branching strategy. It makes it easy to isolate development and testing in a separete branch until it's finished and ready to be merged with the main branch. The hardest part (except from keeping track of all the branches) is to make it easy for the tester to update the test Environment with the executable from the wanted branch.