introduction to code versioning - uclouvain · introduction to code versioning ... control...

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

Notions of code versioning

Control revisions has existed for almost as long as writing has existed

Google Docs

OpenOffice Documents

Microsoft Office documents

Version control is embedded in various types of software

Undo-Redo

Similar terms:

● Version control● Source control● Revision control● Source code management● Software configuration management

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

Evolution of versioning philosophy

● Local data model● Client-server model● Distributed model

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”

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

● 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

● Revision Control System (RCS)Check-in or commit and Check-out

Check-in (commit)

file1.txt

$ ci -m'commit log' file1.txt

WorkingDir:

Creates revision 1.1

Check-in (commit)

file1.txt

Check-out

$ co -l file1.txt

Locked file. This prevent other user to modifyThe file in the repository.

WorkingDir:

Check-in (commit)

RCS/file1.txt,v

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

● Revision Control System (RCS)Log

file1.txt

file2.txt

file3.txt

README

$ 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

Head revision

● Revision Control System (RCS)Tag

file1.txt

file2.txt

file3.txt

README

$ rcs -ntag2: file* README$ co -rtag2 file* README

Fix the status of revisions at a given time ( snapshot of file revisions)

Add a tagGet files with a given tag

● 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);...

● Revision Control System (RCS)Diff

file1.txt

file2.txt

file3.txt

README

$ rcs diff -r 1.1 -r 1.2 file3.txt$ rcs diff -r 1.1 file3.txt

Get differences between two revisions

Between two revisionBetween current and a given revision

● Revision Control System (RCS)Release.

file1.txt

file2.txt

file3.txt

README

$ 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

● 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.1

● 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.1

● 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

● 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

● 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

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

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

● 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

● 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:’

● 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 ...]

● 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

● 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

● 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

● Branch and merge CVS$ cvs tag -b rel1-1

file1.txt

file2.txt

file3.txt

README

1.2.2.1

1.4.2.1

1.2.2.1

● 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.2.1

1.4.2.1

1.2.2.1

update

commit

● 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

● 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 !!!

● 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.

● 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

$ hg init project

$ git init project

● Create the repository (in a remote server)

Repository

working-dir

Repository

$ hg clone ssh://hmem///path/project

$ git clone git clone hmem:$rHOME/test-git/project

● Clone (from remote to local)

● Before the use of hg or git set configuration

$ git config --global user.name "John Doe"$ git config --global user.email johndoe@example.com

Edit ~/.hgrc file

[ui]username = John Doe <johndoe@example.com>

Set global options for git

You can set other parameters as editor, merge tool ...

● 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/

changeset: 1:ccd961c70ae0tag: tipuser: Bryan O'Sullivan <bos@serpentine.com>date: Tue May 05 06:44:45 2009 +0000summary: Added tag v1.0 for changeset c78e12f9da76

changeset: 0:c78e12f9da76tag: v1.0user: Bryan O'Sullivan <bos@serpentine.com>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

working-dir

Repository

$ hg push

$ git push

● Push (send repository modifications)

$ hg outgoing

See what will be push

working-dir

Repository

$ hg pull

$ git fetch

● Pull/fetch (get repository modifications)

$ hg incoming

See what will be pull

You need to update to see changes

● 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

● Update to a given revision or tag $ hg update [-r REV] NAME # rev number or tag

$ git checkout NAME # tag name

$ git checkout <sha>

● 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

● 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

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'

●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

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

Tutorial

● 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

introduction to code versioning - uclouvain · introduction to code versioning ... control...

Documents

extensibility and versioning

introduction to code versioning - uclouvain · revision...

versioning apis

versioning extensions to webdav (web distributed authoring...

semantic versioning

video versioning

release and versioning

database versioning

liquibase - database structure versioning

semantic versioning lightning talk

beyond source code versioning - git at sap

concurrent versioning system

versioning - esri

versioning theory

versioning your code with monticello - inria · we have...

ssl versioning guide

introduction to code versioning - center for high ... ·...

semantic versioning a large existing codebase · the...

causality based versioning

web service versioning