1
Introduction to code versioning
● Notions of code versioning- Local Data Model (RCS)- Client-Server Model (CVS,SVN)- Distributed model (Mercurial, Git)
● Bug tracking system● Publishing code● Windows tools● Tutorial
2
Notions of code versioning
Control revisions has existed for almost as long as writing has existed
3
Notions of code versioning
Google Docs
OpenOffice Documents
Microsoft Office documents
Version control is embedded in various types of software
Undo-Redo
4
Notions of code versioning
Similar terms:
● Version control● Source control● Revision control● Source code management● Software configuration management
5
Notions of code versioning
Code versioning can:
● Track the history and evolution of the project● Who, what, when, why ● Lone project : track errors, recover from
mistakes● Collaborative projects: + resolve conflicts● Restore, compare and merge revisions
6
Notions of code versioning
Evolution of versioning philosophy
● Local data model● Client-server model● Distributed model
7
Notions of code versioning
Local data model (Local Version Control System)
● Source Code Control System (SCCS)
● Revision Control System (RCS)– Repository is in a shred folder– Operates on individual files.– Delta files are in a RCS sub-directory (repository or store)– Revisions are in an ancestral tree R.L.B.S
revision = “Release”, “Level”, “Branch”, “Sequence number”
Trunk
Branch
Working directory
http://basepath.com/aup/talks/SCCS-Slideshow.pdfhttp://www.gnu.org/software/rcs/tichy-paper.pdfhttp://www.gnu.org/software/rcs/manual/rcs.pdf
Repository
8
Notions of code versioning
Local data model (Local Version Control System)
● Revision Control System (RCS)Create the repository
RCS/Repository: $ mkdir RCS
Add (initialize) a file
RCS/file1.txt,vRepository:
$ rcs -i -auser1,user2 -t-'file description' file1.txt
9
Notions of code versioning
Local data model (Local Version Control System)
● Revision Control System (RCS)Check-in or commit and Check-out
Check-in (commit)
file1.txt
RCS/file1.txt,vRepository:
$ ci -m'commit log' file1.txt
WorkingDir:
Creates revision 1.1
10
Notions of code versioning
Local data model (Local Version Control System)
● Revision Control System (RCS)Check-in or commit and Check-out
Check-in (commit)
file1.txt
RCS/file1.txt,vRepository:
file1.txt
Check-out
$ co -l file1.txt
Locked file. This prevent other user to modifyThe file in the repository.
WorkingDir:
11
Notions of code versioning
Local data model (Local Version Control System)
● Revision Control System (RCS)Check-in or commit and Check-out
Check-in (commit)
RCS/file1.txt,v
file1.txt
RCS/file1.txt,vRepository:
file1.txt
Check-out Check-outCheck-in
file1.txt
$ ci -l -m'commit log' file1.txt
A check-in followed by locked check-out
WorkingDir:
adds revision 1.2
12
Notions of code versioning
Local data model (Local Version Control System)
● Revision Control System (RCS)Log
file1.txt
file2.txt
file3.txt
README
1.1
1.2
1.3
1.1
1.1
1.2
1.2
1.1
1.1
1.1
1.2
1.2
1.3
1.1
1.2
1.2
1.3
1.2
$ rlog READMETime
See the version historyRCS file: ./RCS/hello_c.c,vWorking file: ./hello_c.chead: 2.4branch:locks: strict
jcabrera: 2.4access list:
jcabreraguest
symbolic names:rel1-0: 1.7This_compile: 1.6
keyword substitution: kvtotal revisions: 12; selected revisions: 12description:Main program of rcs example----------------------------revision 2.4 locked by: jcabrera;date: 2015/11/13 11:51:23; author: jcabrera; state: Exp; lines: +9 -5merged bug fix----------------------------revision 2.3date: 2015/11/13 11:50:20; author: jcabrera; state: Exp; lines: +5 -1added critical code
Tags
Head
Head revision
13
Notions of code versioning
Local data model (Local Version Control System)
● Revision Control System (RCS)Tag
file1.txt
file2.txt
file3.txt
README
1.1
1.2
1.3
1.1
1.1
1.2
1.2
1.1
1.1
1.1
1.2
1.2
1.3
1.1
1.2
1.2
1.3
1.2
$ rcs -ntag2: file* README$ co -rtag2 file* README
Time
Fix the status of revisions at a given time ( snapshot of file revisions)
Add a tagGet files with a given tag
14
Notions of code versioning
Local data model (Local Version Control System)
● Revision Control System (RCS)Keywords : $Id$ $Log$ ...rcs replace keyword with revision information at check-out
Add this lines in your code:
static char rcsid[] = "\$Id\$";…… printf("%s\n",rcsid);...
You will get this after check-out
static char rcsid[] = "$Id: hello_c.c,v 2.3 2015/11/13 13:12:23 jcabrera Exp jcabrera $";
";…… printf("%s\n",rcsid);...
15
Notions of code versioning
Local data model (Local Version Control System)
● Revision Control System (RCS)Diff
file1.txt
file2.txt
file3.txt
README
1.1
1.2
1.3
1.1
1.1
1.2
1.2
1.1
1.1
1.1
1.2
1.2
1.3
1.1
1.2
1.2
1.3
1.2
$ rcs diff -r 1.1 -r 1.2 file3.txt$ rcs diff -r 1.1 file3.txt
Time
Get differences between two revisions
Between two revisionBetween current and a given revision
16
Notions of code versioning
Local data model (Local Version Control System)
● Revision Control System (RCS)Release.
file1.txt
file2.txt
file3.txt
README
1.1
1.2
1.3
1.1
1.1
1.2
1.2
1.1
1.1
1.1
1.2
1.2
1.3
1.1
1.2
1.2
1.3
1.2
1.2
1.2
1.4
1.2
2.1
2.1
2.1
2.1
2.2
2.1
2.2
2.1
Time
$ rcs -nrel-1.0: file* README$ ci -m'NEW RELEASE' -f -r2 file* README
Add a tagForce revision to a new release number
The code can be use in production and/or publish
17
Notions of code versioning
Local data model (Local Version Control System)
● Revision Control System (RCS)Branching and Merge.
$ rcsclean -u file* README$ co -l -rrel1-0 file* README$ ci -m'fix bug' -l -r1.2.1 file1.txt
Clean Working-DirCheck-out old release
Fix bug and commit
Release 1 has a bug but release 2 is at-work and can not be used
file1.txt
file2.txt
file3.txt
README
1.2
1.2
1.3
1.2
...
...
...
...
1.2
1.2
1.4
1.2
2.1
2.1
2.1
2.1
2.2
2.1
2.2
2.1
Time
2.2
2.2
2.3
2.1
2.2
2.3
2.3
2.1
1.2.1.1
18
Notions of code versioning
Local data model (Local Version Control System)
● Revision Control System (RCS)Branching and Merge.
$ rcsclean -u file* README$ co -l -kk RCS/*$ rcsmerge -kk -A -r1.7.1.1 file1.txt$ ci -l -m'merge' file1.txt
Clean Working-DirCheck-out head revision with minimal keyword expansion
Merge with diff3 (r1.2.1.1,r2.2,working dir version)Edit file1.txt, resolve conflicts and check in
The fixed bug can be merge to new revision
file1.txt
file2.txt
file3.txt
README
1.2
1.2
1.3
1.2
...
...
...
...
1.2
1.2
1.4
1.2
2.1
2.1
2.1
2.1
2.2
2.1
2.2
2.1
Time
2.2
2.2
2.3
2.1
2.2
2.3
2.3
2.1
1.2.1.1
2.3
2.3
2.3
2.1
19
Notions of code versioning
Local data model (Local Version Control System)
● Branch and merge
int main(void){<<<<<<< hello_c.c printf("Bonjour monde!\n");||||||| 1.7.1.1 printf("Hello world!\n");======= printf("Hola Mundo!\n");>>>>>>> 2.3 printf("%s\n",rcsid); return EXIT_SUCCESS;}
Work dir
Head revision
Mering branch
20
Notions of code versioning
● Client-server model (Centralized Version Control System)
● Concurrent Versions System (CVS)
● Subversion (SVN)developers use a single shared repository
Repository can be:● Shared folder in a local machine● Shared folder in remote machine with:
ssh, http+web_dav or cvs/svn server
Harry Sallyhttp://ftp.gnu.org/non-gnu/cvs/source/feature/1.12.13/cederqvist-1.12.13.pdfhttp://svnbook.red-bean.com/en/1.7/svn-book.pdfhttp://tortoisesvn.net/support.html http://www.tortoisecvs.org
working-dirworking-dir
Repository/
+ You can work locally in your computero Lock files is discouraged use update + mergeo You are encouraged to make branches for development- commit possible only if server is accessible- commands speed depends on network
21
Notions of code versioning
● Client-server model (Centralized Version Control System)
● CVS revision number: like RCS
– Each file has its revision number
– Need tags to make snapshots of the way the repository looked after a commit (see RCS tag)
● Subversion revision numbers: an integer number(no extra labels)
– Each commit has its revision number rN (like a RCS tag)
– Tags are treated like branches
22
Notions of code versioning
● Client-server model (Centralized Version Control System)
cvsroot/ ├── CVSROOT
│ ├── (administrative files) │ ├── ... │ ├── commitinfo │ ├── commitinfo,v │ ├── loginfo │ ├── loginfo,v │ ├── taginfo │ ├── taginfo,v │ ├── verifymsg │ └── verifymsg,v ├── project1
│ ├── hello_c.c,v │ ├── hello_c.h,v │ ├── Makefile,v │ └── README,v ├── project2
│ └── files,v │ └── subproject2 │ └── files,v └── project3
Repository/ repos ├── conf
│ ├── authz │ ├── passwd │ └── svnserve.conf ├── db
│ ├── current │ ├── ... │ ├── revprops │ ├── revs │ └── ... ├── format ├── hooks
│ ├── postcommit.tmpl │ ├── ... │ └── startcommit.tmpl ├── locks
│ ├── db.lock │ └── dblogs.lock └── README.txt
23
Notions of code versioning
● Client-server model (Centralized Version Control System)
working-dir
project1 ├── CVS
│ ├── Entries │ ├── Repository │ └── Root ├── hello_c.c ├── hello_c.h ├── Makefile └── README
project1/ ├── branches
│ └── rel10 │ ├── hello_c.c │ ├── hello_c.h │ ├── Makefile │ ├── README │ └── .svn ├── .svn
│ ├── entries │ ├── format │ ├── pristine │ ├── tmp │ └── wc.db ├── tags └── trunk
├── hello_c.c ├── hello_c.h ├── Makefile └── README
24
Notions of code versioning
● Client-server model. copy-modify-merge solution
check-in
check-out check-out
check-in
cvs commit: Up-to-date check failed for A
updatemerge
check-in update
25
Notions of code versioning
● Client-server model (Centralized Version Control System)● Create the repository (in a remote server)
● CVS Add projects to the repository (in remote)
$ cd project; export CVSROOT=$HOME/cvsroot$ cvs import -m'cvs test repository project' project CECI start
● Check-out (get a working copy from server to local)
$ cvs -d $HOME/cvsroot init $ svnadmin create $rHOME/repos
● SVN Add projects to the repository (from local to remote) $ cd project$ svn import -m 'svn test repository project' \ svn+ssh://hmem/$rHOME/repos/project
$ svn co svn+ssh://hmem/$rHOME/test-svn/repos/project http[s]://, svn://, file:///
$ export CVS_RSH=ssh$ cvs -d :ext:user@host:/path/repository/cvsroot checkout project
‘:[g,k,p]server:’,‘:local:’
26
Notions of code versioning
● Client-server model.(Centralized Version Control System)
● Add, remove, rename files (need commit)
● Commit (check-in) to the server
$ cvs add -m'file description' [file ...]$ cvs remove [file ...]$ mv old new$ cvs remove old$ cvs add new$ cvs commit -m "old to new " old new
$ svn add [file ...]$ svn remove [file ...]$ svn move old new
$ cvs ci -m'commit log' [file ...] $ svn ci -m'commit log' [file ...]
27
Notions of code versioning
● Client-server model.(Centralized Version Control System)
● Log and status (needs server access)
● Tag
$ cvs tag -c tag_name
$ cvs log # history$ cvs status # status of working dir
$ svn log -v -r BASE:HEAD$ cvs status # status of working dir$ svn status -u # status of repository
$ cvs log # history$ cvs status # status of working dir$ cvs -n -q update # status of repository
$ svn copy svn+ssh://user@hostname/dir/repos/project/trunk \ svn+ssh://user@hostname/dir/repos/project/tags/tag_name \ -m 'tag description'
svn tag == branchsnv uses hard links to reduce size
28
Notions of code versioning
● Client-server model.(Centralized Version Control System)
● Update to a given revision or tag $ cvs update -r tag_name # example: 2.1 or rel1-0$ cvs update # update to head of branch$ cvs update -A # update to trunk head
$ cd project/tags$ svn co svn+ssh://hmem/$rHOME/test-svn/repos/project1/tags/tag_name$ cd tag_name
$ cd project/branches/branch_name # or cd project/trunk$ svn update -r8 # update to a given revision in the branch$ svn update # update to head of branch
29
Notions of code versioning
● Client-server model.(Centralized Version Control System)
● Keywords
CVS: same as RCS
SVN: missing Log key words.Need to activate keyword substitution on files
$ svn propset svn:keywords "Id Author" hello_c.c hello_c.h Makefile README
● Diff
$ svn diff # current modifications in working dir$ svn diff -r N:M # compares revision N and M
$ cvs diff # current modifications in working dir$ cvs diff -r rev1 -r rev2 # compares revision rev1 and rev2
30
Notions of code versioning
● Client-server model.(Centralized Version Control System)
● Branch and merge CVS$ cvs tag -b rel1-1
file1.txt
file2.txt
file3.txt
README
1.2
1.2
1.3
1.2
...
...
...
...
1.2
1.2
1.4
1.2
2.1
2.1
2.1
2.1
2.2
2.1
2.2
2.1
Time
2.2
2.2
2.3
2.1
2.2
2.3
2.3
2.1
1.2.2.1
1.2.2.1
1.4.2.1
1.2.2.1
31
Notions of code versioning
● Client-server model.(Centralized Version Control System)
● Branch and merge CVS$ cvs update -A # go to head of trunk$ cvs update -kk -j rel1-1 # resolve conflicts and commit
file1.txt
file2.txt
file3.txt
README
1.2
1.2
1.3
1.2
...
...
...
...
1.2
1.2
1.4
1.2
2.1
2.1
2.1
2.1
2.2
2.1
2.2
2.1
Time
2.2
2.2
2.3
2.1
2.2
2.3
2.3
2.1
1.2.2.1
1.2.2.1
1.4.2.1
1.2.2.1
2.3
2.3
2.3
2.1
update
commit
32
Notions of code versioning
● Client-server model.(Centralized Version Control System)
● Branch and merge SVN$ svn copy svn+ssh://hmem/$rHOME/test-svn/repos/project1/trunk \ svn+ssh://hmem/$rHOME/test-svn/repos/project1/branches/dev-branch \ -m 'development branch'
r1→ r3 → r4 → … → r17 → r19 → r20 → r22 trunk
r18 → r21 branch
33
Notions of code versioning
● Client-server model.(Centralized Version Control System)
● Branch and merge SVN$ cd project1/branches/dev-branch$ svn update$ svn merge ^/project1/trunk# resolve conflicts and check modification$ svn ci -m'merged trunk' # creates r23 in branch$ cd project1/trunk$ svn update$ svn merge --reintegrate ^/project1/branches/dev-branch$ svn ci -m'merged dev-branch back to trunk' # creates r24
r1→ r3 → r4 → … → r17 → r19 → r20 → r22 →r24 trunk
r18 → r21 → r23 branch
Trunk is always in production as development are done in branches !!!
34
Notions of code versioning
● Hooks or triggers (actions on server)
CVS:● ‘commitinfo’ → checking that the commit is allowed ● ‘verifymsg’ → verify the log message● ‘loginfo’ → action after commit (sent an email)
SVN:● start-commit — Notification of the beginning of a commit.● pre-commit — Notification just prior to commit completion.● post-commit — Notification of a successful commit.● pre-revprop-change — Notification of a revision property change attempt.● post-revprop-change — Notification of a successful revision property change.
● Client-server model.(Centralized Version Control System)
35
Notions of code versioning
● Distributed model (Distributed Version Control System)
● Mercurial
● Git
Fully mirror of the repository ● Repository are cloned on multiple machines:● Shared folder in remote machine with:
ssh, http protocol
Harry Sallyhttps://www.mercurial-scm.org/wiki/MercurialBookhttps://git-scm.com/book/en/v2
+ You can work locally and make draft copies+ Do not care about network for commits+ Less dependent on backups every clone is a backup
working-dir
Repository
working-dir
Repository
Repository
36
Notions of code versioning
● Distributed model (Distributed Version Control System)
$ hg init project
$ git init project
● Create the repository (in a remote server)
Repository
37
Notions of code versioning
● Distributed model (Distributed Version Control System)
Sally
working-dir
Repository
Repository
$ hg clone ssh://hmem///path/project
$ git clone git clone hmem:$rHOME/test-git/project
● Clone (from remote to local)
38
Notions of code versioning
● Distributed model (Distributed Version Control System)
● Before the use of hg or git set configuration
$ git config --global user.name "John Doe"$ git config --global user.email [email protected]
Edit ~/.hgrc file
[ui]username = John Doe <[email protected]>
Set global options for git
You can set other parameters as editor, merge tool ...
39
Notions of code versioning
● Distributed model (Distributed Version Control System)
● Add, remove, rename files (need commit)
● Commit (check-in) to the local repository $ hg ci -m' commit log' [file ...]
Use .gitignore or .hgignore files toselect files and folders you do not want to track
$ git commit -a -m' commit log' [file ...] -a automatically stage files
$ hg add [file ...]$hg rm file ...$hg mv old new
$ git add file ...$ git rm file ...$ git mv old new
Staged for commit
● Ignore files# Backup files left behind by the Emacs and vim editor.*~# Temporary files used by the vim editor..*.swp# compiled objects*.pyc*.o# directory fileter example (case sensitive)# ignore log dirLogs/
40
Notions of code versioning
● Distributed model (Distributed Version Control System)
changeset: 1:ccd961c70ae0tag: tipuser: Bryan O'Sullivan <[email protected]>date: Tue May 05 06:44:45 2009 +0000summary: Added tag v1.0 for changeset c78e12f9da76
changeset: 0:c78e12f9da76tag: v1.0user: Bryan O'Sullivan <[email protected]>date: Tue May 06 06:44:45 2009 +0000summary: Initial commit
hg commits are identified by revision:changeset (revision is local, changeset is global)
Git commits identified by global SHA-1 hashcommit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7Author: Scott Chacon <schacon@geemail.com>Date:Sat Mar 15 16:40:33 2008 0700removed unnecessary testcommit a11bef06a3f659402fe7563abf99ad00de2209e6Author: Scott Chacon <schacon@geemail.com>Date:Sat Mar 15 10:31:28 2008 0700first commit
41
Notions of code versioning
● Distributed model (Distributed Version Control System)
Sally
working-dir
Repository
Repository
$ hg push
$ git push
● Push (send repository modifications)
$ hg outgoing
See what will be push
42
Notions of code versioning
● Distributed model (Distributed Version Control System)
Sally
working-dir
Repository
Repository
$ hg pull
$ git fetch
● Pull/fetch (get repository modifications)
$ hg incoming
See what will be pull
You need to update to see changes
43
Notions of code versioning
● Distributed model (Distributed Version Control System)
● Log and status (needs server access)
● Tag
$ hg tag NAME [-m 'tag description]
$ git log # history$ hg status # status of working dir
$ hg log # history$ hg status # status of working dir
$ git tag -a NAME -m'tag description'
$ git log # history$ hg status # status of working dir
$ hg log # history$ hg status # status of working dir
44
Notions of code versioning
● Distributed model (Distributed Version Control System)
● Update to a given revision or tag $ hg update [-r REV] NAME # rev number or tag
$ git checkout NAME # tag name
$ git checkout <sha>
45
Notions of code versioning
● Distributed model (Distributed Version Control System)
● Branch and merge$ git branch iss53
● Branch and merge Git$ git checkout master$ git merge iss53
$ git branch iss53$ hg branch iss53
$ hg update default$ hg merge iss53
46
Notions of code versioning
● Distributed model (Distributed Version Control System)
● Hooks hg and git Add hooks in .hg/hgrc
● changegroup : This is run after a group of changesets has been brought into therepository from elsewhere.● commit : This is run after a new changeset has been created in the local repository.● incoming : This is run once for each new changeset that is brought into the repositoryfrom elsewhere. Notice the difference from....
● pre-commit hook is run first, before you even type in a commit message● prepare-commit-msg hook is run before the commit message editor is fired up but
after the default message is created. It lets you edit the default message before the commit author sees it
● commit-msg hook takes one parameter, which again is the path to a temporary file that contains the commit message written by the developer.
Add hooks in .git/hooks
47
Bug tracking system
● Use a Bug tracking system (trac, bugzzilla, redmine)
– Open a ticket with a bug or feature.
– Ticket gives details about the bug and the way to solve.
– Resolve the problem and use the ticket numberin the commit message 'fix bug #117'
48
●Publishing code
● Hg Archive
A clean copy of your code to publish$ hg archive -r 1.0 project-v1.0.zip$ hg archive project-`date +%Y-%m`.tar
49
Windows tools
● http://www.tortoisecvs.org/
● http://tortoisesvn.net/
● http://tortoisehg.bitbucket.org/
● https://tortoisegit.org/about/https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools
50
Tutorial
51
● Sources
https://en.wikipedia.org/wiki/Version_controlMercurial: The Definitive Guide http://hgbook.red-bean.com/read/http://www.gnu.org/software/rcs/tichy-paper.pdf
52