Source Code Management For CSE 3902 By: Matt Boggus

Overview Motivation and benefits of source code control Concepts underlying source code control implementations Options integrated into Visual Studio and usage tips

Basic premises of team project work Save previous versions of project (files) Source code Build instructions (.sln, .vsproj) Data / Art files Documentation Not Visual Studio user settings Provide a unique label or index for each previous version and be capable of getting each previous version on demand Track who made each edit Allow multiple users to view and modify the project simultaneously

Usually sub-optimal option Keep all project files on a one computer, allow multiple users to view the files Image from https://eduspiral.com/best-university-to-study-information-systems-security-in-malaysia/

Usually sub-optimal option Keep all project files on a USB drive, physically pass it around as needed Image from https://www.makeuseof.com/tag/ways-usb-stick-security-risk/

Usually sub-optimal option Everyone keeps their own copy of the project, and each time anyone changes a file they might: Email the new files to everyone Save the new files on a shared network drive (ex: BuckeyeBox) Image from https://www.recordnations.com/articles/using-cloud-storage-keep-upload-move/

Ultimately a process design decision Might be made by: Team Team leaders Boss(es) Consider the team and file formats when choosing how to manage project assets Might use version control for source code and shared drive for images and art assets Petabytes of data might be transferred faster using hard drives and the US postal service than over the internet Source code management does not eliminate the need to communicate with your teammates

File consistency Local copy Webserver copy

Practice question How would you implement a program that takes a string input then allows the user to change the string, but also revert it back to any of its previous states?

Storing results vs. storing file differences Figures for next few slides are from https://betterexplained.com/articles/a-visual-guide-to-version-control/

You local working copy is separate from versions stored elsewhere

Conflicts

Branching

Merging

Commit structure for one repository Figures from next few slides from http://web.cse.ohio-state.edu/~giles.25/3901/lectures/lecture02.pdf

Entire commit history is a directed, acyclic graph (DAG)

Centralized vs. Decentralized Two options integrated within Visual Studio Team Foundation Version Control (subversion or SVN based) Centralized ; one repository GIT Distributed ; every machine is a repository Image from http://www.slideshare.net/premaseem/git-presentation-10589300

Central Server Remote Server Clipart figure from files.channel9.msdn.com/thumbnail/d8ad47a0-5798-4e6d-9b8a-2d0843fa718c.pptx

Setup for source control in Visual Studio Team->Connect to… In Team Explorer, Select Team Projects… Click Servers… button, then Add… Copy-paste URL from the project creator, then click ok Should look something like this: https://TEAMORPROJECTOWNERNAME.visualstudio.com/ Select server to connect, signing in with the same account you set up for Visual Studio Online task planning

Working with TFVC In Visual Studio, connect to your team’s project First time setup Set local directory where you will store your copy of the project Map & Get Day-to-day use Under Team Explorer, click Source Control Explorer Right click on root folder->Get latest version After adding code and successfully rebuilding the solution, check in the changes

Working with GIT In Visual Studio, connect to your team’s project First time setup Clone repository on your local machine Day-to-day use Under Team Explorer, click Source Control Explorer Fetch commits Pull commits After adding code and successfully rebuilding the solution, push your commit The GUI options in Visual Studio for GIT are significantly less powerful than the command line options

Important practice After resolving a merge or conflict, get the latest version / fetch and pull the master branch, then make sure it still compiles and runs If you broke the build it is your responsibility to fix it

Source control and visual studio project files: An example of a common problem MarioCoder’s .proj file BlockCoder’s .proj file <Project xmlns="http://schemas.microsoft.com/develo per/msbuild/2003"> <ItemGroup> <Compile Include="helloworld.cs" /> </ItemGroup> <Target Name="Build"> <Csc Sources="@(Compile)"/> </Target> </Project> <Project xmlns="http://schemas.microsoft.com/develo per/msbuild/2003"> <ItemGroup> <Compile Include="helloworld.cs" /> </ItemGroup> <Target Name="Build"> <Csc Sources="@(Compile)"/> </Target> </Project>

How to avoid this problem Only allow 1 person to add new files to project / commit changes to project file Update before committing The shorter the time between getting code updates and committing new code, the less likely you will break the build Some version control supports locking files

References and additional learning resources Microsoft documentation on Git and VSTS https://docs.microsoft.com/en- us/vsts/git/overview?view=vsts#tfvc_or_git_summary 3901’s GIT lecture http://web.cse.ohio- state.edu/~giles.25/3901/lectures/lecture02.pdf https://betterexplained.com/articles/a-visual-guide-to-version- control/ files.channel9.msdn.com/thumbnail/d8ad47a0-5798-4e6d-9b8a- 2d0843fa718c.pptx https://home.usn.no/hansha/documents/software/software_development/topics/resources/TFS%20Overview.pdf mentions several other useful tools within VSTS, though the screenshots and content refer to the old name, Team Foundation Services (TFS)