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.