Version Control Systems (VCS)

Xianyi Zeng [email protected]

Department of Mathematical Sciences The University of Texas at El Paso. October 13, 2019. Version Control Systems Let’s get the textbook!

• Online textbook: Victor Eijkhout, “Introduction to High- Performance Scientific Computing”. http://pages.tacc.utexas.edu/~eijkhout/istc/ istc.html • Get both the pdf version and source files. https://bitbucket.org/VictorEijkhout/ hpc-book-and-course • Fetch all the resources! hg clone ssh://hg@bitbucket.org/Victor Eijkhout/hpc-book-and-course mycopy Version Control Systems Source control at a glance

• The preceding command to get a repository. hg clone source target VCS tool. Action. Repository. Local copy. • Some common VCS tools: cvs: Concurrent version system. svn: Subversion. git:“The stupid content tracker”. hg: Mercurial. • What do they do? Keep track the development history of a project. Maintain different versions of the project. Facilitate collaborations on the same project. Is NOT worry free! Mostly reliable on tracking text files. Version Control Systems Source control at a glance

• The preceding command to get a repository. hg clone source target VCS tool. Action. Repository. Local copy. • Some common VCS actions: clone: Get the source from a repository. add/rm/mv/cp: File management of the source under control. checkout: Switch to a certain revision of a certain branch. commit: Save the changes and create a check point (reversion). diff: Compare different reversions. merge: Combine different branches. Examples are for hg; other VCS tools have similar actions. A Simple Git Project Get started: Record keeping Let’s start a project on fluid-solid interaction.

• What do we do? Create a directory fsi.git and cd it. mkdir fsi.git && cd fsi.git Initiate a git repository git init This will create .git/ Create and add some files to the repository using: git add. Commit all the changes git commit -m "Some development message" This will create the first check point (revision) of the project. Continue to do so and create several revisions when appropriate. A Simple Git Project Get started: Record keeping Let’s start a project on fluid-solid interaction.

• What can we do? Make a copy of the project: git clone fsi.git loc.copy && cd loc.copy Check the configuration file loc.copy/.git/config. Look at the development history: git log Switch back to a previous revision: git checkout Discussion: How about git reset or git revert? Compare two different revisions: git diff [something] A Simple Git Project Create a new branch Two people join and work on the fluid and solid, respectively.

• Create a new branch called “fluid”. Make a clone of the repository. git clone fsi.git fluid.git && cd fluid.git Create the new branch. git branch fluid && git checkout fluid A Simple Git Project Create a new branch Two people join and work on the fluid and solid, respectively.

• Keep both the origin and current repositories updated. Push the new branch/any changes to the origin. git push origin fluid:fluid Gather the new information from the origin. git fetch origin Pull the updates from the origin. git pull origin fluid:fluid A Simple Git Project Merge branches and resolve conflicts Let’s say we make some progress on master, and want to get anything new from fluid.

When we are on the branch master: • Attempt to merge the branch fluid. git merge fluid • An automatic algorithm is called to merge the two branches. • Upon success, both the sources and the logs are merged. • Upon success, a new commit is created. A Simple Git Project Merge branches and resolve conflicts Let’s say we make some progress on master, and want to get anything new from fluid.

When automatic merge fails, we need to resolve the conflicts: • Option 1: choose which version to keep. • Option 2: manually modify the conflicted files. • Once finished, mark the conflict as resolved and commit. • Won’t be able to commit if there are unresolved conflicts. Other VCS Systems and Resources Repository models and concurrency models Repository model. • Client-server model: Developers access a master repository via a client (local working copy). Any changes must be committed to the master repository. The server maintains a full development history. Examples: cvs, svn. • Distributed model: Repositories act as peers. Any peer can talk to any other peer/peers. Each repository maintain its version history. Examples: git, hg. Other VCS Systems and Resources Repository models and concurrency models Concurrency model. • “Lock” model: Only allow one user to modify one file at the a time. A user must “lock” a file before making changes to it. Usually only possible in a client-server model. Example: svn. • “Merge” model: Many developers are allowed to edit the same file simutaneously. Users are informed of possible conflicts upon merging. Distributed system almost always implies a “merge” model. Examples: cvs, svn, git, hg. • Do not bet everything on the lock-unlock model, or the au- tomatic merge. Developers should talk to each other whenever necessary! Other VCS Systems and Resources Further reading A very good tutorial on git: https://www.atlassian.com/git/tutorials/ learn-git-with-bitbucket-cloud A graphical guide to mercurial: https://www.mercurial-scm.org/wiki/ UnderstandingMercurial Eclipse: A GUI for various version control systems. http://www.eclipse.org Bitbucket: A web-based hosting service we use for this course. https://bitbucket.org GitHub: Another web-based hosting service that supports git. https://github.com