Transcript PPT
Introduction to Version Control with SVN & Git
CSC/ECE 517, Fall 2012 Titus Barik ( [email protected]
) & Ed Gehringer, with help from Gaurav Tungatkar ( [email protected]
)
Local version control: RCS
File check out Version 3 • Keep many copies of files • Error prone • RCS stores deltas Version 2 Version 1
Centralized Version Control
• If you need to work with other programmers … Computer A check out File Version 3 Computer B File check out Version 2 Version 1
File Server vs. Version-Control Server
At first glance, the client server architecture of a version-control system looks much like a typical file server.
So why do we need version control ?
File Sharing Issues, 1
• Assume your project has 15 developers: – Each developer wants to make 1 change and must communicate this change to all other developers.
– What are the total number of interactions
that must occur?
• C(15, 2) = N(N – 1)/2 = 15(14)/2 = 105.
That’s a lot of information to track!
File Sharing Issues, 2
The problem is that users are stepping on each other’s feet!
Image: Version Control with Subversion
Approach 1: Lock, Modify, Unlock
1. Locking may cause administrative problems.
2. Locking may cause unnecessary serialization.
3. Locking may create a false sense of security.
Image: Version Control with Subversion
Approach 2: Copy
-
Modify-Merge
Sounds chaotic, but in practice, runs extremely smoothly.
Question:
When
is
locking necessary?
Image: Version Control with Subversion
Subversion (SVN)
• Open source, Apache License.
• Available on all major operating systems.
• Improvements such as “cheap” copying and branching, remote options (https), over legacy CVS.
• However, CVS has more mature tools, and SVN has it own flaws (DVCS).
Exercise 1
• Answer these questions • Give one advantage of using a version-control server for source-code management over using a fileserver.
• Suppose a project has 15 developers and no shared repository. Can you come up with a better way of communicating changes than N(N-1)/2 interactions? • Explain how locking can cause administrative problems. • Explain how locking can create a false sense of security.
• With copy modify-merge , when is locking necessary?
Branches and Tags
Trunk: Location where main development occurs.
Branches: Location used to isolate changes to another development line (e.g., experimental features).
Tags: Snapshot of the content (e.g., RTM, service packs, EOL).
Image: http://en.wikipedia.org/wiki/Subversion_(software)
Populated Repository
A Subversion repository layout. The folder names are just a convention, and have no special meaning to the repository.
Image: Version Control with Subversion
Creating a Branch
In Subversion, the underlying mechanism of a
branch
is implemented by performing a simple directory copy.
Image: Version Control with Subversion
Exercise 2
• Answer these questions about branches.
o Suppose, in fixing a bug, you modify three lines of code in two source files. Should you create a new branch? Why or why not? o Which would probably be more common, branches or tags?
o What are some of the risks of copying files in a repository? How do version-control systems minimize this risk?
Distributed Version Control
• Clients don’t check out individual files; • they mirror the repository.
• What’s the advantage?
Computer A File Version 3 Version 2 Version 1 Version 3 Version 2 Version 1 Computer B File Version 3 Version 2 Version 1
Git
• Came out of the Linux project, in 2005.
• Simple design • Strong support for non-linear development (thousands of parallel branches) • Fully distributed • Able to handle large projects like the Linux kernel efficiently (speed and data size)
Integrity & Checksums
• Everything checksummed with an SHA-1 hash – 40-character string – composed of hex characters – calculated based on the contents of a file or directory structure in Git • Example – 24b9da6552252987aa493b52f8696cd6d3b00373 • Git knows everything by hash, not filename
Snapshots, not Diffs
• See http://progit.org/book/ch1-3.html
• Every time you commit, Git takes a snapshot of your files.
• Files that have not changed are not copied.
Almost all ops are local • browse history • commit
3 States of a File in Git
• Modified working directory • Staged staging area check out the project • Committed git directory (repository) stage files commit
File Status Lifecycle
untracked unmodified modified staged add the file remove the file edit the file stage the file
Checking Status
• To check the status of your files: $ git status # On branch master nothing to commit (working directory clean) • Creating new files $ vim README $ git status # On branch master # Untracked files: # (use "git add
Checking status, cont.
• Begin to track the file: $ git add README • The file is now tracked: $ git status # On branch master # Changes to be committed: # (use "git reset HEAD
Remotes
• On a project, you may be working with several remote directories.
• “Origin” is the server you cloned your repository from $ git clone git://github.com/schacon/ticgit.git Initialized empty Git repository in /private/tmp/ticgit/.git/ remote: Counting objects: 595, done. remote: Compressing objects: 100% (269/269), done. remote: Total 595 (delta 255), reused 589 (delta 253) Receiving objects: 100% (595/595), 73.31 KiB, done. Resolving deltas: 100% (255/255), done. $ cd ticgit $ git remote origin • http://progit.org/book/ch2-5.html
Pulling, pushing to remote
• $ git fetch [remote-name] • E.g., git fetch origin • git push origin master
Common Workflow using Git
• Centralized workflow … • http://progit.org/book/ch5-1.html
• Integration-manager workflow … • Common use cases: http://progit.org/book/ch5-2.html
Exercise 3
• Answer these question about DVCSs.
o What is an advantage of referring to files and branches by hash, rather than by filename? o Can you think of one disadvantage of a DVCS compared to a centralized VCS?