Source Control 101
•Als PPTX, PDF herunterladen•
2 gefällt mir•1,143 views
My brief introductory training on using source control. SubVersion was used during the presentation but it applies to most source control systems.
![What are we doing? Introduction Lab 1 ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie Source Control 101
Ähnlich wie Source Control 101 (20)
Mehr von Robert MacLean
Mehr von Robert MacLean (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Source Control 101
- 9. ReviewAlternatives to SVN Other TortoiseSVN Tools IDE Integration Proven Practises
- 10. Disclaimer The names and scenarios presented here are purely fictional. Any similarity to real people or scenarios is purely a coincidence. No animals were harmed during the making of this bootcamp.
- 11. Time to get a little crazy You need to be three people today Jim, the junior software dev. Just out of his local computer school and hired by BB&D. Wrote code at school and home – by himself. Simon, the “seasoned” software dev. Ran his own software company for a few years - that created iPhone apps. Company size of 1. Joined BB&D when Palm Pre killed the iPhone market. Mike, the grizzly IT Pro. Wears shirts that say things like “There are 10 types of people, those who know binary and those who don’t.”
- 12. Supporting cast The wizard – fly’s in and does magic! (used for stuff you need, but don’t care about) The customer, is all about giving: Gives you requirements. Gives you headaches. Gives you money.
- 13. Create a file share and do some changes. Time: 5min
- 14. Now... The customer needs a bug fixed in version 1
- 15. What’s in a Name?
- 16. What is source control? An agreed way to share development resources that gives us:
- 17. Terminology
- 21. Mike: Create a repo Simon: Check in a file Jim: Get a file Time: 5min
- 22. Lab 2 - Review Repo DAL.txt v1 Add Get DAL.txt v1
- 23. Lab 2 - Review Is this how you should do your repo? No, use the TCP/IP or SVN protocol. What is TortoiseSVN? The SVN client is a command line tool. TortoiseSVN is a wrapper for that.
- 24. Jim: Update the file & check it in. Simon: Sync and rollback. Time: 5min
- 25. Lab 3 - Review DAL.txt v2 DAL.txt v1 Update Repo Sync Again DAL.txt v2 Issue Rollback
- 26. Lab 3 - Review Why did we have to commit again? Because there was a change What revision are we now on? Revision 3 Can we get back to the code Jim put in, if we needed to? Yes
- 27. Jim: Change the file Simon: Change the file CONFLICT!! Time: 10min
- 28. Lab 4 - Review DAL.txt v3 DAL.txt v4b DAL.txt v5 Repo Sync Sync Update Update Update DAL.txt v3 DAL.txt v4
- 29. Lab 4 - Review Why did we have a .r3 and .r4 file? revision 3 & revision 4 What would happen if this was the changes and we tried to commit? It would auto merge Jim Simon
- 30. Simon: wants to do a major code change and make sure Jim doesn’t mess with him Time: 5min
- 31. Lab 5 - Review DAL.txt v5 Sync Repo Lock Sync DAL.txt
- 32. Lab 5 - Review Who locked the file? Developer, the user logged into Windows What happens if the person who locked the file goes on holiday? You can break the lock if needed.
- 33. Simon: As they are releasing version 1 they want to make sure they can fix issues while working on v2. Time: 10min
- 34. Lab 6 - Review Trunk Repo Trunk V1 Branch Branch
- 35. Lab 6 - Review Do we need to switch? No, but it helps keep focus and prevent issues across branches.
- 36. Lab 6 - Review What is shelving? Shelving is branching to a personal temporary branch. Why shelve? Interruptions: Pending changes that are not ready for check in. Integration/Handoff: Sharing code with someone else, without a check in. Review: Code for review Backup: Personal backup
- 37. Lab 6 - Review How to shelve? Create a new root folder named shelve, as we did for branches. In that a folder for each user. Branching as normal.
- 38. Lab 6 - Review Which is correct? V1.1 (start) V1.2 V1.1 (start) V1.1 FT3 DEV DEV 3 4 5 8 RI Branch FI V1,0 Hotfix 1 RI RI FI FI FI Branch V1.1 V1.2 V1.0 Production V1.1 1 2 6 7 MAIN Branch FI RI V1.1 (bug fix) V1.0 Production RELEASE Release 1.01
- 39. Scenario #1: Single Team Branching Model Nightly Build (Early Validation) All dev done on branch CI / Nightly Builds (Early validation) V1.2 V1.1 (start) V1.1 FT3 DEV 3 4 5 8 RI RI FI FI FI Branch V1.1 V1.2 1 2 6 7 MAIN V1.1 (bug fix) V1.0 Production Main should be very stable
- 40. Scenario #2: Concurrent Hot Fix, Service Pack, and v.Next 2 DEV … The two DEV branches are created as sequential tasks, but as one unit of work. All dev done on branches 2 DEV-1 Branch MAIN 1 Branch Branch FI R1 (SP) R2 (SP) 6 SERVICE PACK 3 Branch Branch When MAIN is ready to release, create the SERVICE PACK, HOT FIX, and RELEASE branches at the same time. Branch R1 (SP0) R1 (SP1) R2 (SP0) 4 7 HOT FIX Branch Branch Branch R1 (SP0) R1 (SP1) R2 (SP0) 5 8 RTM The RTM branch is a read-only copy of what was released These should be read only
- 41. Scenario #3: Branching and Labeling The two DEV branches are created as sequential tasks, but as one unit of work. TEST … 6 TEST-1 5 Branch V1.2 Release labels in branch DEV … 2 4 Branch V1.1 DEV-1 2 3 Branch 1 MAIN Main is just the latest
- 42. Simon: Needs to make sure v2 gets the same bug fix as v1 had. Time: 5min
- 43. Lab 7 - Review Branch v1 Conflict Merge Trunk No cartoons, cause this is too hard to show with cartoons.
- 45. WARNING The tools to be presented next are based on some personal use and discussion. They could break or not work – please consultant us and test prior to adoption.
- 46. IDE Integration http://ankhsvn.open.collab.net/ Free & Open Source http://www.pushok.com/soft_svn.php Costs ($27) & Proprietary & about a billion other SVN clients ;)
- 48. Proven Practises
- 49. Proven Practises
- 50. Proven Practises
Hinweis der Redaktion
- So for the demo’s today you need to imagine three people getting involved
- Revision control is the more generic term, used for source-control tools but also for other tools (Word, OpenOffice, ...). It references a version.Source Control offers revision control with branching and merging which are not always available in all revision tools (Word is not a Source Control, but offer revision control features)Version Control is a more general term than Source Control in that it manages version of anything (sources or binaries, or any kind of documents)
- Backup and Restore. Files are saved as they are edited, and you can jump to any moment in time. Need that file as it was on Feb 23, 2007? No problem.Synchronization. Lets people share files and stay up-to-date with the latest version.Short-term undo.Monkeying with a file and messed it up? (That’s just like you, isn’t it?). Throw away your changes and go back to the “last known good” version in the database.Long-term undo. Sometimes we mess up bad. Suppose you made a change a year ago, and it had a bug. 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, not the file). This makes it easy to see how a file is evolving over time, and why.Track Ownership. A VCS tags every change with the name of the person who made it. Helpful for blamestorming giving credit.Sandboxing, or insurance against yourself. Making a big change? You can make temporary changes in an isolated area, test and work out the kinks before “checking in” your changes.Branching and merging. A larger sandbox. You can branch a copy of your code into a separate area and modify it in isolation (tracking changes separately). Later, you can merge your work back into the common are
- Add: Put a file into the repo for the first time, i.e. begin tracking it with Version Control.Revision: What version a file is on (v1, v2, v3, etc.).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, and people can “check out” the latest one.
- Checkin 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 latest from the repository. This lets you grab the latest revisions of all files.Revert: Throw away your local changes and reload the latest version from the repository.
- A1) No, you should use the TCP/IP connection to share repositories, but this is great for our labs today.A2) TortoiseSVN is a front end for the SVN client. The SVN client is a command line based tool.
- A1) .r3 for revision 3 & .r4 for revision 4A2) Who ever checks in first will be fine. The second will get a commit, they will update but NOT get the conflict resolution files at it can auto merge. The second will need to then need to commit.
- A1) Developer – the windows account
- Branching Guidance– Scenario 1
- Branching Guidance– Scenario 1
- Same as scenario 1, but the advantage is that maintenance can occur very easily for a release
- Use source control: Use it, duhDon’t break the build: Build or tree – when you check in you should not break the ability to build the code.Keep up to date: Try to keep your working set as close to repo version. The more you get out of date the greater the chance of a conflictAutomerge is a for Get ONLY: Some shit (sourcesafe) allow automerge on commitDon’t check in binaries: just cause you can store everything in the system, doesn’t mean you should. Binaries are especially badSeparate repo for separate things: Don;t try to have one super repo, try to seprate them.
- Don’t delete: Why delete if you don’t need toWorking folders should be disposable: Your working folder should not become so valuable that you can’t afford to kill itUse non-working folders when needed: Most systems support a way to export WITHOUT repo information, use this for sharing code outside.Useful & meaningful messages: check in messages are important, use them wellDon’t use the audit trail to assign blame: using audit logs to assign blame is guarenteed to kill usageUse undo/revert sparingly Use undo/revert sparingly: You can trash your work easily, be careful
- Use labels: Labels are easier to remember than changeset id’sBe light and quick with checkouts: Check out as little as possible and the check it in as quickly as possible.Try concurrent: Concurrent locking scares a lot of people but can give great productivity benefits, especially with thinking developers.Use Shelving: If you don’t have time to finish, remember to shelve
- Don’t be afraid of branching: Like concurrent access it may seem to cause issues, but if you adopt it and use it responsibility then it will make your life great.Plan your branching strategy: Branching is tough – spend some time to plan aheadDon’t branch UNLESS you will look after it: Branches are like puppy’s you need to look after themTake responsibility for the merge: You need to devote time and plan your merge, then follow through with it.