Continuous staff improvement project

INTRODUCTION. USING VERSION CONTROL SYSTEM

YURII HOHAN
 INTRODUCTION
• INTERNSHIP OVERVIEW AND GOAL
• PROCESS
• ROLE OF A SOFTWARE ENGINEER
THE PROCESS
• Each day a 2 hour lecture on the topic.
• Either a 5 hour practical assignment or 4 hours of studies followed by a quiz.
If the topic is practical (most of them are), the task will be to write some code. The
result of the code review will be reflected in the mark. If the topic is theoretical, the
mark will be obtained during the quiz.
• Each separate task will be assessed with a mark daily and each separate course
will be assessed with a mark during exam. The final mark should be calculated
as:
Final_mark = 50% * average_daily_assessment_mark + 50% * exam_mark
SOFTWARE ENGINEERING
Typical formal definitions of software engineering are:
• "research, design, develop, and test operating systems-level software, compilers,
and network distribution software for medical, industrial, military,
communications, aerospace, business, scientific, and general computing
applications.“
• "the systematic application of scientific and technological knowledge, methods,
and experience to the design, implementation, testing, and documentation of
software"
• "the application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software"
An engineer is a professional practitioner of engineering, concerned with applying 
scientific knowledge, mathematics, and ingenuity to develop solutions for
technical, societal and commercial problems.
Ingenuity is the quality of being clever, original, and inventive, often in the process
of applying ideas to solve problems or meet challenges
HOW IS TIME SPENT
A rule of thumb for scheduling a software task (Fredrik Brooks):
• 1/3 planning
• 1/6 coding
• 1/4 component test and early system test
• 1/4 system test, all components in hand.
THE JOYS OF THE CRAFT
• First is the sheer joy of making things. As the child delights in his mud pie, so the
adult enjoys building things.
• Second is the pleasure of making things that are useful to other people.
• Third is the fascination of fashioning complex puzzle-like objects of interlocking
moving parts and watching them work in subtle cycles.
• Fourth is the joy of always learning, which springs from the nonrepeating nature
of the task.
• The delight of working in such a tractable medium. The programmer, like the
poet, works only slightly removed from pure thought-stuff. He builds his castles
in the air, from air, creating by exertion of the imagination
THE WOES OF THE CRAFT
• First, one must perform perfectly. 
• Other people set one's objectives, provide one's resources, and furnish one's
information. One rarely controls the circumstances of his work, or even its goal.
• Dependence upon other people's  programs (which are not perfect).
• The product over which one has labored so long appears to be obsolete upon
(or before) completion.
 CONSTRUCTS TO
DISCUSS
• PESSIMISTIC AND OPTIMISTIC LOCKING
• WHAT IS UPDATE
• WHAT IS COMMIT
• TYPES OF CONFLICTS
• BASIC BRANCHING
VERSION CONTROL SYSTEM
MOTIVATION
• Version control is a system that records changes to a file or set of files over time
so that you can recall specific versions later
• It can be useful not only for a developer, but also for a graphic designer, web
designer.
• It is like a “time machine”!
1. You can recover an older version
2. Examine the history of the project
3. Resolve conflicts when working in a team
4. Have many versions of the product easy to control
• Repository is the store of the project’s data
• Changeset - a group of changes made in different files.
MODELS OF VCS
• Client-server model (Centralized)
1. Uses Client-Server architecture
2. Based on the idea that there is a single “central” copy of the project
somewhere on the server.
3. All programmers “commit” their changes to the central repository
4. Examples : CVS, SVN, TFS, etc
• Distributed model
1. Uses distributed architecture
2. Based on the idea that each developer has its own repository with whole
history.
3. All programmers can synchronize their changes between each other without
any central repository
4. Examples: Mercurial, Git, Bazaar
CENTRALIZED VCS
• The main authority is repository server.
The server keeps the entire history of all
changes.
• All developers know only about the
central repository server. All changes are
sent to central server. In order to share a
change with another developer the change
must be “committed” to server.
• Each developer has its own working copy
on local machine. Working copy is a
snapshot of files at certain point in time.
DISTRIBUTED VCS
• Each developer has its own copy of
repository with all changes.
• Each repository can be connected with
as many repositories as needed
• Developer commit to local repository
its changes.
• Developer can choose which changes
to synchronize with other repositories.
WORKING PROCESS IN CENTRALIZED
VCS
WORKING PROCESS IN DISTRIBUTED VCS
CHECKOUT REPOSITORY
•1

•2
VISUAL STUDIO DIFF TOOL
• Shows the difference between two version of file
TEXT CONFLICT
• Text conflicts happen when local changes have been made to a file
and remote version also include changes to the file in such a way that
it can not be automatically determined how they should be merged.
<<<<<<< HEAD:mergetest
This is my third line
=======
This is a fourth line I am adding
>>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest
TEXT CONFLICT
VISUAL STUDIO TEXT CONFLICT
EDITOR
REMOVED FILE CONFLICT
• Removed file conflict occurs when one person edits a file, and
another person deletes that file in their branch.
• Removed file conflict can be resolved in following ways:
1. Resolving by keeping the edited file
2. Resolving by removing the file
REMOVED FILE CONFLICT
LOCKING IN CENTRALIZED VCS
• There are two forms of concurrency control that we can use in centralized VCS:
optimistic and pessimistic locking.
• Let us suppose that Mark and Albert are going to edit the same file containing
info about sales.
• With pessimistic locking whoever checks out the file first prevents anyone else
from editing it. So if Mark is first to check out, Albert can't work with the file
until Mark is finished with it and commits his changes.
• With optimistic locking both of them can make a copy of the file and edit it freely.
Mark and Albert can work on the file simultaneously, the first of them, Mark, will
commit the file without problems and Albert will have to deal with the conflict
during his commit (depending on the sophistication of the system).
BASIC BRANCHING
• Branch is a copy of an object under
revision control which has it’s own
history. Branch is like a nested repository
inside the repository.
• One repository must have at least one
branch.
• Branch allows to work parallel and
isolated on different versions of source
code.
BRANCH PER FEATURE
• Branch per feature is development process
when each new User story/feature is done
in its own branch.
• Branch per feature allows maintain main
branch in stable state, releasable at any
time.
• Feature branch is merged in main branch
when the work is done.
GIT SPECIAL FILES
• .gitignore – specifies intentionally untracked files that Git should
ignore. Almost all VCS contains such file.
• .gitattributes – defines attributes for path names. Usually is used to
specify line endings.
MAIN GIT COMMANDS
• git clone – creates a new local copy of remote repository
• git add – adds pending changes to index
• git commit – creates new commit
• git status – shows status of working tree
• git pull – get changes from remote repository branch
• git push – sends local commits to remote repository
• git checkout – switches working branch
• git branch – shows local branches
• gitk – Visualize the commit graph, showing the information related to
each commit
 ASSIGNMENT
• CREATE A REPOSITORY IN THE VERSION CONTROL SYSTEM OF
YOUR CHOICE (SVN, TFS OR GIT).
• DO SEVERAL TEST COMMITS.
• REPRODUCE A SITUATION FOR A TEXT CONFLICT AND EXPLAIN
HOW YOU RESOLVED IT.
• REPRODUCE A SITUATION FOR A DELETED FILE CONFLICT AND
EXPLAIN HOW YOU RESOLVED IT.
• CREATE A BRANCH FROM MASTER/TRUNK AND DO SEVERAL
COMMITS TO BRANCH AND MASTER.
• MERGE AND DELETE THE BRANCH.
REVISIONS
Number Author Date Description

1.0.0 Yurii Hohan 07.12.2015 Initial version

2.0.0 Serghei Grajdean 20.06.2016 SVN replaced with