Distributed Version Control Systems version, and give an idea of the - PDF document

Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Abstract This presentation is an introduction to Version Control Systems, and in particular, modern and decentralized ones. We start with a presentation of the problems to solve, and the historical solutions, presenting briefly CVS and its successor Sub- Distributed Version Control Systems version, and give an idea of the requirements not meet by these systems with the example of the Linux kernel. The talk presents then the notion of Decentralized (or “distributed”) Version Con- Matthieu Moy trol System, with the example of Bazaar (also known as bzr). Without going into details, we present the way branching and merging is managed in such systems. Computer Science and Automation The conclusion gives pointers to learn more about Bazaar and its competitors. Indian Institute of Science Bangalore About the Author: Matthieu Moy, has been contributing to Baz, the ancestor of Bazaar. He is one of the main contributor of Emacs-DVC, the Emacs interface to October 2006 several version control systems (GNU Arch, Bazaar, Mercurial, cogito. . . ). Matthieu Moy (CSA/IISc) DVC October 2006 < 1 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 2 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Outline Backups: The Old Good Time Basic problems: Motivations, Prehistory 1 ◮ “Oh, my disk crashed.” / “Someone has stolen my laptop!” ◮ “@#%!!, I’ve just deleted this important file!” ◮ “Oops, I introduced a bug a long time ago in my code, how can I see History and Categories of Version Control Systems 2 how it was before?” Historical solutions: Version Control for the Linux Kernel 3 ◮ Replicate: $ cp -r ~/project/ ~/backup/ Bazaar (bzr): One Decentralized Revision Control System 4 ◮ Keep history: $ cp -r ~/project/ ~/backup/project-2006-10-4 ◮ Keep a description of history: Conclusion 5 $ echo "Description of current state" > \ ~/backup/project-2006-10-4/README.txt Matthieu Moy (CSA/IISc) DVC October 2006 < 2 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 4 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Backups: Improved Solutions Collaborative Development: The Old Good Time Basic problems: Several persons working on the same set of files “Hey, you’ve modified the same file as me, how do we merge?”, 1 “Your modifications are broken, your code doesn’t even compile. Fix 2 Replicate over multiple machines your changes before sending it to me!”, Incremental backups: Store only the changes compared to previous “Your bug fix here seems interesting, but I don’t want your other 3 revision changes”. ◮ With file granularity Historical solutions: ◮ With finer-grained (diff) ◮ Never two person work at the same time. When one person stops Many tools available: working, (s)he sends his/her work to the others. ◮ Standalone tools: rsync , rdiff-backup , . . . ⇒ Doesn’t scale up! Unsafe. ◮ Versionned filesystems: VMS, Windows 2003+, cvsfs, . . . ◮ People work on the same directory (same machine, NFS, . . . ) ⇒ Painful because of (2) above. ◮ People lock the file when working on it. ⇒ Doesn’t scale up! ◮ People work trying to avoid conflicts, and merge later. Matthieu Moy (CSA/IISc) DVC October 2006 < 5 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 6 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Merging: Problem and Solution Merging Space of possible revisions My version Your version Common ancestor (arbitrarily represented in 2D) #include <stdio.h> #include <stdio.h> #include <stdio.h> Merged revision Mine int main () { int main () { int main () { printf("Hello"); printf("Hello!\n"); printf("Hello"); return EXIT_SUCCESS; return 0; return 0; } } } Tools like diff3 can solve this Yours Ancestor Merging relies on history! Collaborative development linked to backups Matthieu Moy (CSA/IISc) DVC October 2006 < 7 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 8 / 43 >

Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Revision Control System: Basic Idea CVS: The Centralized Approach Keep track of history: ◮ User makes modification and use commit to keep a snapshot of the current state, Configuration: ◮ Meta-data (user’s name, date, descriptive message,. . . ) recorded ◮ 1 repository (contains all about the history of the project) together with the state of the project. ◮ 1 working copy per user (contains only the files of the project) Use it for merging/collaborative development. Basic operations: ◮ Each user works on its own copy, ◮ checkout : get a new working copy ◮ User explicitly “takes” modifications from others when (s)he wants. ◮ update : update the working copy to include new revisions in the Efficient storage (“delta-compression” ≈ incremental backups): repository ◮ At least at file level ( git ) ◮ commit : record a new revision in the repository ◮ Usually store a concatenation of diffs (Optional) notion of branch: ◮ Set of revisions recorded, but not visible in mainline, ◮ Can be merged into mainline when ready. Matthieu Moy (CSA/IISc) DVC October 2006 < 9 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 11 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion CVS: Example Commit/Update Approach Space of possible revisions Start working on a project: "commit" creates new revision $ cvs checkout project $ cd project Work on it: New User runs "update" upstream $ vi foo.c # or whatever revisions See if other users did something, and if so, get their modifications: And so on ... ! $ cvs update Review local changes: $ cvs diff Record local changes in the repository (make it visible to others): Existing revision $ cvs commit -m "Fixed incorrect Hello message" Matthieu Moy (CSA/IISc) DVC October 2006 < 12 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 13 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Conflicts Conflicts: an Example Someone added \n , someone else added ! : #include <stdio.h> When several users change the same line of code concurrently, int main () { Impossible for the tool to guess which version to take, <<<<<<< hello.c ⇒ CVS leaves both versions with explicit markers, user resolves printf("Hello\n"); manually. ======= Merge tools (Emacs’s smerge-mode , . . . ) can help. printf("Hello!"); >>>>>>> 1.6 return EXIT_SUCCESS; } Matthieu Moy (CSA/IISc) DVC October 2006 < 14 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 15 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion CVS: Obvious Limitations Subversion: A Replacement for CVS Idea of subversion: drop-in replacement for CVS (could have been File-based system. No easy way to get back to a consistant old “CVS, version 2”, fix the obvious limitation, but no major change/innovation: revision. ◮ Atomic, tree-wide commits (commit is either successful or unsuccessful, No management of rename ( remove + add ) but not half ), Bad performances ◮ Rename management, ◮ Optimized performances, some operations available offline. Matthieu Moy (CSA/IISc) DVC October 2006 < 16 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 17 / 43 >