Version Control Systems SWEN-261

Transcription

1 Version Control Systems SWEN-261

2 Need Code Sharing Store multiple versions

3 What are your experiences with Version control? Technologies The good The bad The necessary

4 Need for Version Control Teammates working on software need: Sharing: keep the code in one place Concurrent Editing: work at the same time Revert: undo changes to a working state History: to understand what has been done Version control systems provide all of these

5 Consider the Alternative

6 Locking Another alternative: Disallow concurrent editing at the file level Lock the file, work, then unlock. Still not ideal Not good for working on the same code too much coordination Or, nobody looks at each other s code Need to wait on people to unlock What if you forget to lock?

7 Completely Synchronous? How about a Google Docs approach? Everyone is editing the same code at once Changes are seen immediately. Nope Still can t work concurrently: code needs to compile, and other people will break your code immediately. History becomes very messy What if we want to revert one person s change? What if we want all changes to be inspected? What if we are reporting a bug and the code has changed since we found the bug? How do you give a stable version to your customer while also working on a newer version?

8 The Version Control Way

9 Copy, Merge, Modify 1.Take from the repository 2.Make your changes 3.Merge your work with the repository No conflicts: Most merges are trivial (i.e. nobody else was working) Conflicts: Tools can help the merge process (i.e. incorporate other people's changes) 4.Merging is much easier than you think

10 Popular Version Control Systems Subversion (we ll use this) Git Central repository Most commonly used today Hottest today. Very good, but a bit advanced No central repository everyone has the repo Merging and branching is even easier Mercurial, BitKeeper, Bazaar, SourceSafe, ClearCase, CVS, RCS

11 Subversion Centralized repository Keeps a whole directory of files (e.g. source code) Can control read and write access Remembers every change to every file trunk == main development line Your working copy A copy of the source code from the repo Only difference: each directory has a.svn folder

12 SVN Commands Check out Create your working copy from the repository Do this once, work from there Update Check witha the repository for new changes Integrate those new changes Commit If updated, take your changes and incorporate them into the repository

13 Don t Break the Build By pushing to the repository, you are Publicizing your changes Completing a small task Your teammates should assume they are checking out clean code. Don t make them debug your code for you. Therefore: Commit often + Don t break the build = Work iteratively

14 A Day in the Life Assuming you ve already checked out a working copy Don t touch your code first!! First: update your clean working copy Then: work on code Commit your change Commit often!! Every 20 minutes or so. Commit working code, preferably. Make those commit comments matter! I read them. Your teammates read them. Make your commits logical, not just dumps of what you did Done for now? Commit so your working copy is clean

15 Advanced Concept: Distributed Distributed version control (e.g. git, hg) Pros: Cons: Each developer has a local copy of the repository Commit to my local repository, then push my commits to my public repository. Like what others are doing? Pull their changes Committing is no longer public until you push Truly decentralized à no arguing about who s a committer and who s not Still supports the centralized approach Can be more complicated to learn b/c more subdivided commands

16 Some Tips for Your Project Nip problems in the bud Small issues now, may be larger later No replacement for good team communication Start good practice early on And follow it Version control is your friend, not enemy It does require attention