An introduction to Version Control Systems
•Transferir como KEY, PDF•
2 gostaram•679 visualizações
First half of a UCS Staff Seminar on version control systems.
![Version Control
Systems
what they are and why you want one
Jon Warbrick
Tony Finch
[and Ben Harris]](https://image.slidesharecdn.com/jw35-vcs-120418063405-phpapp01/85/An-introduction-to-Version-Control-Systems-1-320.jpg)
Recomendados
Recomendados
Mais conteúdo relacionado
Mais de Jon Warbrick
Mais de Jon Warbrick (10)
Último
Último (20)
An introduction to Version Control Systems
- 1. Version Control Systems what they are and why you want one Jon Warbrick Tony Finch [and Ben Harris]
- 2. Do you recognise this?
- 3. Media Wiki
- 4. Some other examples Game saved states MS Word ‘track changes’ Apple Time Machine Adobe Version Que MS Sharepoint
- 5. What do you get? • Revision history • Change comments • What’s changed? • Collaborative and group working • Somewhere for automation
- 6. Version control 101
- 7. “repository”
- 8. “check out”
- 9. “working tree” (or “working copy”)
- 10. “committing”
- 11. $ diff -c mary2.txt mary1.txt *** mary2.txt --- mary1.txt 2012-04-17 17:44:24.000000000 +0100 2012-04-17 17:45:04.000000000 +0100 “diff” *************** *** 1,6 **** Mary had a little lamb, ! whose flees where white as snow. And everywhere that Mary went, the lamb was sure to go. --- 1,11 ---- Mary had a little lamb, Visual diff example ! whose fleece was white as snow. And everywhere that Mary went, the lamb was sure to go. + It followed her to school one day + which was against the rules. + + It made the children laugh and play, + to see a lamb at school.
- 12. “locking”
- 13. “merging”
- 14. “branch”
- 15. Good for/Not good for • Good for: • Changes made by humans • Things that look like software source trees • Not good for • Bug tracking, build management • Big blobs of data
Notas do Editor
- ...or Revision Control systems, Source Code Control systems, Software Configuration Management systems, or...\n\nThis talk was written by Jon, Tony and Ben even if only Jon and Tony are presenting it.\n
- Everything changes. Anyone recognise this way of tracking changes? It’s the ‘Save as...’ approach. Do you find it works well?\n
- Media Wiki, so the CS managed Wiki Service, so the CS Wiki, has quite sophisticated change tracking. Revisions. Comments. Diffs.\n
- Quite a lot of other software has built-in history tracking. Here are some examples.\n
- What do you typically get with something like this? What use is it?\n
- Lets define some terms. We are drifting into ‘traditional’ VCSs here and away from application-specific VCS support.\n
- The place where stuff gets stored. Typically looking like a directory tree. Might be a single local directory or on a central server. In the case of a ‘distributed’ VCS there might be lots of repositories but with support or transmitting and synchronising changes between them (the latter being deep magic).\n
- The act of taking a copy of something to work on. Typically only you see your subsequent changes until you take further action.\n
- In many systems you check out all (or a significant lump) of the repository. This is your private working copy, or working tree. You may need to refresh it to take account of changes made by others.\n
- The act of updating the repository with your changes. Once you’ve committed a change then others can see it. \n\nCommits are normally accompanied by a comment describing the changes, what they are intended to achieve, etc. Serve at least three purposes: make it easier to find a particular change; provide documentation to remind you what you did; provide documentation to others to tell them what you did.\n
- (for “difference”). It’s normally possible to ask to see the difference between different versions of something in a repository. Easy(ish) for text files - more challenging for things like images, videos (but see link)...\n\n[Many VCSs store revisions _as_ diffs (to save space), but that’s not directly relevant]\n
- Some VCSs let you ‘lock’ a file while you are working on it to stop any one else also making changes. Slows development, esp. when people forget! Modern systems rely instead on merging (see next).\n
- Modern systems let people work on the same file at the same time. When changes are checked in they systems try to merge them together. Providing they affect different parts of the file they can do this automatically - if not then human intervention is needed. Modern systems also need to do merging to support branching.\n
- Getting a bit advanced. Sometimes you want to work on a new version of something, while keeping the old version around and working on that too. E.g. maintaining version n of a software product while at the same time developing version n+1. Branches let you do this _and_ transfer changes made in one branch to another.\n
- "To a man with a hammer, everything looks like a nail."-Mark Twain. How to identify real VCS nails.\n
- Had to add sccs!\n\nGiven a liking for “free” (as in speech and/or beer), the highlighted products are probably of most use.\n
- Had to add sccs!\n\nGiven a liking for “free” (as in speech and/or beer), the highlighted products are probably of most use.\n
- Had to add sccs!\n\nGiven a liking for “free” (as in speech and/or beer), the highlighted products are probably of most use.\n
- Had to add sccs!\n\nGiven a liking for “free” (as in speech and/or beer), the highlighted products are probably of most use.\n
- Had to add sccs!\n\nGiven a liking for “free” (as in speech and/or beer), the highlighted products are probably of most use.\n
- Had to add sccs!\n\nGiven a liking for “free” (as in speech and/or beer), the highlighted products are probably of most use.\n
- Had to add sccs!\n\nGiven a liking for “free” (as in speech and/or beer), the highlighted products are probably of most use.\n