Version  Control  

So#ware  Quality  Quality  Audit  and  Cer2fica2on  

 Master  in  Computer  Engineering  

   

Roberto  García  (rgarcia@diei.udl.cat)        

Introduc2on  

•  Change-­‐control  procedures.  Avoid  uncontrolled  changes,  destabilize  and  degrade  quality:  

•  In  requirements,  disrupt  design  and  coding  •  In  design,  code  disagrees  with  requirements    •  In  the  code,  inconsistencies  and  uncertain2es    about  what  has  been  reviewed  and  tested  

–  Version  Control  Systems  (VCS):  •  Standalone  (CVS,  Subversion,  Git,…)  •  Word  processors  (MicrosoL  Office,  OpenOffice,…)  •  Content  Management  Systems  (Drupal,  Joomla,…)  •  Wikis  (MediaWiki,  TWiki,  Trac  (wiki+svn)…)  

Features  •  Backup  and  Restore.  Files  are  saved  as  they  are  edited,  and  you  can  jump  to  any  

moment  in  2me  •  SynchronizaAon.  Lets  people  share  files  and  stay  up-­‐to-­‐date  with  the  latest  version  •  Short-­‐term  undo.  Throw  away  your  changes  and  go  back  to  the  “last  known  good”  

version  in  the  database  •  Long-­‐term  undo.  Jump  back  to  the  old  version,  and  see  what  change  was  made  

that  day  •  Track  Changes.  As  files  are  updated,  you  can  leave  messages  explaining  why  the  

change  happened  (stored  in  the  VCS)  •  Track  Ownership.  A  VCS  tags  every  change  with  the  name  of  the  person  who  

made  it  •  Sandboxing.  You  can  make  temporary  changes  in  an  isolated  area  and  test  before  

“checking  in”  changes  •  Branching  and  merging.  A  larger  sandbox.  You  can  branch  a  copy  of  your  code  into  

a  separate  area  and  modify  it  in  isola2on  (tracking  changes  separately).  Later,  you  can  merge  your  work  back  into  the  common  area  

Basic  Setup  

•  Repository  (repo):  The  database  storing  the  files  

•  Server:  The  computer  storing  the  repo  •  Client:  The  computer  connec2ng  to  the  repo  •  Working  Set/Working  Copy:  Your  local  directory  of  files,  where  you  make  changes  

•  Trunk/Main:  The  primary  loca2on  for  code  in  the  repo,  the  main  development  line  

Basic  Ac2ons  

•  Add:  Put  a  file  into  the  repo  and  begin  tracking  it    •  Revision:  What  version  a  file  is  on  (v1,  v2,  v3,...)  •  Head:  The  latest  revision  in  the  repo  •  Check  out:  Download  a  file  from  the  repo  •  Check  in:  Upload  a  file  to  the  repository  (if  it  has  changed).  The  file  

gets  a  new  revision  number  •  Check  in  Message:  A  short  message  describing  what  was  changed  •  Changelog/History:  A  list  of  changes  made  to  a  file  since  it  was  

created  •  Update/Sync:  Synchronize  your  files  with  the  repository  to  grab  the  

latest  revisions  of  all  files  •  Revert:  Throw  away  your  local  changes  and  reload  the  latest  

version  from  the  repository  

Advanced  Ac2ons  •  Branch:  Create  a  separate  copy  of  a  file/folder  for  private  use  (bug  fixing,  tes2ng,

…)  •  Diff/Change/Delta:  Finding  the  differences  between  two  files.  Useful  for  seeing  

what  changed  between  revisions  •  Merge  (or  patch):  Apply  the  changes  from  one  file  to  another,  to  bring  it  up-­‐to-­‐

date.  For  example,  you  can  merge  features  from  one  branch  into  another  •  Conflict:  When  pending  changes  to  a  file  contradict  each  other  (both  changes  

cannot  be  applied)  •  Resolve:  Fixing  the  changes  that  contradict  each  other  and  checking  in  the  correct  

version  •  Locking:  Taking  control  of  a  file  so  nobody  else  can  edit  it  un2l  you  unlock  it.  Some  

version  control  systems  use  this  to  avoid  conflicts  •  Breaking  the  lock:  Forcibly  unlocking  a  file  so  you  can  edit  it.  It  may  be  needed  if  

someone  locks  a  file  and  goes  on  vaca2on  •  Check  out  for  edit:  Checking  out  an  “editable”  version  of  a  file.  Some  VCS  have  

editable  files  by  default,  others  require  an  explicit  command  

Scenario  

1.  Alice  adds  a  file  (list.txt)  to  the  repository  2.  She  checks  it  out,  makes  a  change  (puts  “milk”  on  the  list),  

and  checks  it  back  in  with  message  (“Added  required  item.”)  

 

Examples  based  on  the  Subversion  (svn)  VCS  

3.  Bob  updates  his  local  working  set  and  sees  the  latest  revision  of  list.txt  

4.  He  can  browse  the  changelog  or  diff  to  see  that  Alice  put  “milk”  

svn add list.txt(modify the file)svn ci list.txt -m "Added required item"!

Checkin  

•  Each  2me  we  check  in  a  new  version,  we  get  a  new  revision  (r1,  r2,  r3,  etc.)  

Checkout    

•  If  mul2ple  editors,  first  checkout  last  version  svn co list.txt (get latest version)...edit file...svn revert list.txt (throw away changes)svn co -r2 list.txt (check out particular version)

Diffs  

•  To  know  what  has  changed  between  versions  – Most  version  control  systems  store  diffs  rather  than  full  copies  of  the  file  

svn diff -r3:4 list.txt  

Branching  

svn copy trunk branch  

•  Branches  let  us  copy  code  into  a  new  “folder”  so  we  can  modify  it  separately  

Merging  

•  Merge  changes  from  one  branch  to  another  – Apply  the  changes  from  the  new    branch  and  add    that  to  main  

cd /trunksvn merge -r5:6 branch  

Conflicts  

•  Changes  are  automa2cally  merged  but  someAmes    there  are    conflicts  

Conflicts  

•  When  changes  overlap  and  contradict,  the  VCS  reports  a  conflict  and  avoids  check  in  

•  Asks  user  to  resolve  it,  approaches:  – Check  out  latest  version  and  re-­‐apply  changes  

•  Example:  sync  to  r4  and  add  “hot  dog”  to  the  list  that  already  has  “cheese”  

– Check  out  latest  version,  copy  over  your  version  and  check  in  

•  Examples:  this  removes  “cheese”  and  replaces  it  with  “hot  dog”  

Tagging  

•  Label  any  revision  for  easy  reference  

(in trunk)svn copy revision tag

Distributed  Version  Control  

•  Centralised  VCSs  (like  Subversion)  helps  backup,  track  and  synchronise  files  

•  However,  complicate  for  merging  and  branching  changes  people  make  –  As  projects  grow,  you  want  to  split  features  into  chunks,  developing  and  tes2ng  in  isola2on  and  slowly  merging  changes  into  the  main  line  

•  Distributed  CVSs  make  branching  and  merging  painless  because  they  rely  on  it,  so  it  easier  to  share  changes  –  DVCS,  done  right,  the  best  of  both  worlds:  simple  merging  and  centralized  releases  

Distributed  VCS  (DVCS)  

•  Every  developer  has  its  own  repository  •  Everyone  can  push  changes  into  a  common  repo  to  share  them  

DVCS  Core  Concepts  

•  Centralized  version  control  focuses  on  synchronizing,  tracking,  and  backing  up  files.  

•  Distributed  version  control  focuses  on  sharing  changes;  every  change  has  a  unique  id  

•  Downloading  and  applying  a  change  are  separate  steps  (in  a  centralized  system,  they  happen  together).  

•  Distributed  systems  have  no  forced  structure.  You  can  create  “centrally  administered”  loca2ons  or  keep  everyone  as  peers.  

•  New  Terminology  –  push:  send  a  change  to  another  repository  (may  require  permission)  –  pull:  grab  a  change  from  a  repository  

Key  Advantages  

•  Everyone  has  a  local  sandbox.  Make  changes  and  roll  back  on  your  local  machine  –  No  more  giant  checkins;  your  incremental  history  is  in  your  repo  

•  It  works  offline.  Just  need  to  be  online  to  share  changes  •  It’s  fast.  Diffs,  commits  and  reverts  are  all  done  locally  •  It  handles  changes  well.  Distributed  VCS  were  built  around  

sharing  changes  –  Every  change  has  a  guid  to  track  it  

•  Branching  and  merging  is  easy.  Every  developer  has  “own  branch”  and  guids  facilitate  to  combine  changes  and  avoid  duplicates  

Key  Disadvantages  

•  You  sAll  need  a  backup.  A  machine  to  push  changes  to    –  In  Subversion,  central  server  stores  main  repo;  do  the  same  for  a  Distributed  VCS  

•  There’s  not  really  a  “latest  version”.  Each  developer  different  version,  not  necessarily  one  the  latest  –  A  central  loca2on  helps  clarify  what  the  latest  “stable”  release  is  

•  There  aren’t  really  revision  numbers.  Every  repo  has  its  own  revision  numbers,  like  guid  ba63e7f  –  Tag  revisions  with  meaningful  names  

Basic  Commands  

•  Addi2onal  Resources  (in  the  “Addi2onal  Resources”  folder):  – git-­‐cheat-­‐sheet-­‐large.png  – gitcheatsheet.pdf  –  rc094-­‐010d-­‐git_2.pdf  

Repository  Structure  

•  Once  ini2alised,  the  repository  structure:  – A  working  copy.  The  files  currently  being  edited  – A  repository.  A  directory  (.git  in  Git)  containing  all  patches  and  metadata  (comments,  guids,  branches,  etc.)  

Users   have   their   own  repos,   with   independent  revision  histories  

Understanding  Updates  and  Merging  

•  Updates  happen  in  several  steps:  –  Ge]ng  the  change  into  a  repo    

(fetch)  –  Applying  changes  to  files    

(pull  or  rebase,  checkout)  –  Saving  the  new  version    

(commit)  

Understanding  Updates  and  Merging  

•  Depending  on  the  change,  you  can  update  or  merge:  – Updates  happen  when  there’s  no  ambiguity  

•  Example:  I  pull  changes  to  a  file  that  only  you’ve  been  edi2ng.  The  file  just  jumps  to  the  latest  revision,  since  there’s  no  overlapping  changes  

– Merges  are  needed  when  there  are  conflic2ng  changes.    

•  Example:  If  we  both  edit  a  file,  we  end  up  with  two  “branches”.  In  this  case  we  (probably)  want  to  merge  the  changes  together  

Merging  Scenario  

•  Conflicts  are  typically  detected  and  solved  quickly,  the  DVCS  keeps  track  of:  –  The  parent/child  rela2onship  among  changes  (the  merged  list  has  two  parents)  –  The  “heads”  or  latest  changes  in  each  branch  (before  merge  two  heads,  aLer  

just  one)  

•  A  merge  is  needed  because  (+Soup)  and  (+Juice)  are  changes  to  a  common  parent:  the  list  with  just  “Milk”.    

•  A#er  Joe  merges  the  files,  Sue  can  do  a  regular  “pull  and  update”  to  get  the  combined  file  from  Joe.  She  doesn’t  have  to  merge  again  on  her  own.  

Organizing  a  Distributed  Project  

•  Sue,  Joe  and  Eve  check  changes  into  a  common  branch.  Later,  a  maintainer  can  review  and  pull  changes  from  the  experimental  branch  into  a  stable  branch,  which  has  the  latest  release  

DVCS  Usage  Models  

•  A  distributed  VCS  helps  isolate  changes  but  s2ll  can  provide  the  “single  source”  of  a  centralized  system  

•  Support  many  models  of  development:  –  From  “pull  only”  (where  maintainers  decide  what  to  take,  and  is  used  when  developing  Linux)  

–  …  –  To  “shared  push”  (which  acts  like  a  centralized  system)  

•  Tech  Talk:  Linus  Torvalds  on  githpp://www.youtube.com/watch?v=4XpnKHJAok8    

 

Rebase  Workflow  •  In fact, our workflow is a little different, as we tend to do squash

merges instead of raw merges. This allows us to turn our entire feature branch into a single commit on master.

•  Then we delete our feature branch. This allows us to logically structure our commits on master, even if they're a little messy on our branches.

•  So, this is what we do:

clone  the  remote  repo  git  checkout  -­‐b  my_new_feature  ..work  and  commit  some  stuff  git  rebase  master  ..work  and  commit  some  stuff  git  rebase  master  ..finish  the  feature  git  checkout  master  git  merge  -­‐-­‐squash  my_new_feature  git  branch  -­‐D  my_new_feature  

hpp://stackoverflow.com/ques2ons/457927/git-­‐workflow-­‐and-­‐rebase-­‐vs-­‐merge-­‐ques2ons    

Ac2vity  

•  Share  your  miniproject  at  Github  (hpp://github.com)  and  set  and  organisa2on  for  your  group  (one  account  for  each  group  member)  

•  Some  help  (hpp://help.github.com):  – Download  and  install  Git,  Set  up  SSH  keys  and  user  info:  hpp://help.github.com/mac-­‐set-­‐up-­‐git/  

–  Create  a  repository:  hpp://help.github.com/create-­‐a-­‐repo/  

–  Follow  friends  and  projects,  issues  and  organisa2ons:  hpp://help.github.com/be-­‐social/