Source Control Concepts

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

more share options
Embed For WordPress.com

Without related presentations

SCC – Source Code ControlVC – Version ControlSCM – Software Configuration ManagementMy points here are generally true. Like “root beer is not caffeinated”, then along comes Barq’s.Thanks to Joe Kuemerle (kemerlee) for his presentation on Getting Rid of VSSEric Sink’s excellent blog series

There are surprising benefits to using source control.The history and in particular the comment log help communicate what you were thinking when you wrote the codeIf you know something worked in a previous revision, you can compare the code to help isolate the breaking changesYou can make changes with confidence, knowing that you can always revertAutomation (build server, continuous integration) leads to more free time (thus liberation)Many “best practices” make using source control easier and more meaningfulAdditional benefits that aren’t so surprising:Audit trail/tracebilityCentral store, a known location where the canonical code is stored

“Repository = File System * Time”Eric Sink, http://www.ericsink.com/scm/scm_repositories.htmlThis means that changes are additive, not destructive. Even when you delete, it’s not really destructive.The repository should be an accurate representation of the history of the code base. Mistakes and all.Optimized for storing text files, not necessarily for binaryTwo popular types of SCC, distributed and server based.

aka Working Folder, Working Directory, or SandboxThis is where you put the stuff on your machine.with svn, you would use svn checkoutYou want to keep the value of your working copy low.As you write code and make changes, you are increasing the value of you working copy. When you commit those changes to the repository, you make your working copy worthless again.That’s what you want.You should be able to delete the working copy (or have a crash) and never lose more than a couple of hours of work.Whoa, is that a shift in culture?Let’s move on to workflow…

This is the more conservative, traditional model.It is used by VSS. Ugh.Obeys these rules:Working copy is always read-onlyDevs must check out (thus locking) a file in order to edit itCheckouts are exclusiveProsNo chance of conflictsDevs know what other devs are doingConsCan’t work in parallelRequires access to a central server

This is the more conservative, traditional model.It is used by CVS, SVN.This is my preferred model.Obeys these rules:Working copy is never read-onlyDevs can edit anything Devs are responsible for resolving conflicts. (Meaning that they must update and resolve before committing).ProsWorks well when offlineAllows parallel workLess mental overhead for devs (80% of the time)ConsNo visibility into what other devs are doingResolving conflicts (not a big deal for 80% of the time)

Regardless of the workflow you choose, you should always comment your commits.Why?To reveal the intention of your changes.So write meaningful comments. (It’s easy to be lazy).Also, many issue tracking scan the comments and do cool things. (Like close issues, etc.)

Assuming Edit, Merge, Commit model…There will be conflicts.Most tools will perform an “automerge” to resolve conflicts.Do you trust this? My experience has made me say “Yes”.However, sometimes manual intervention is needed.For example, edits to the same line in the same file. Or edits to a binary file.This is when you use a diff tool to merge the file and resolve the conflict.

A branch is another line of development that has a common history with the primary line of development.Often the primary line of development is called the “trunk”, or “main” or “master”.You want r2 and r1.01 to have a common history, but you don’t want to pollute the maintenance branch (1.01) with unfinished features from r2.The mechanics and semantics of branches differ on different platforms.Some use “folders” or repository paths to designate branches. (svn,tfs)Other define a “namespace” or “universe” that must be provided. It is not part of the path. (cvs, and maybe git…) I’m also not certain on the proper term for this…But what about the bug fixes from 1.01? We want those back in 2.0, right? How do we do that?

Merging a branch is sorta the whole point of creating it…This usually requires developer involvement, but that’s okay. The benefit is worth it.Always review the results of a merge before committing it back to the trunk.Svn and other system have the concept of a “merge history”. If you are doing merges on a regular basis, this can really help out.

Creating a tag (or label) is much the same as creating a new branch. At least it is with svn.The difference comes in how you treat the tag. A tag is used to mark a special or significant moment in the history of the code. For example, an RTM or immediately prior to major changes.Give an example of NHProf.Tags, unlike branches, shouldn’t really be added to. You should be confident when you retrieve a tag that it represents what the code really looked like at that moment.Mention the standard repository structure: branches, tags, trunk

Head – the most recent changeset on a line of development (trunk, branch, etc.)Revision – a point in repository or a file’s history. In svn, the repository’s revision number is updated after each commit.Atomic commit - all of the changes in a commit or checkin either succeed or fail. This is very important for ensuring a consistent state of the repository.Changeset – the set of changes in a commit. In other words, all of the changes (adds, modifications, deletes) that are part of a single commit or checkin.Blame – a tool that allows you to see who “owned” a given line on given file for a particular revision. Patch – when a user doesn’t have commit rights to a repository, they can create a single file that contains all of the changes that they have made to their working copy. This “patch” is then given to someone with commit rights. The committer “applies” the patch to their working copy, reviews the changes, and makes the commit when appropriate. This is a common practice in the open source community.

Bookslinks

1 Favorite

harrychou favorited this 2 months ago
Tags source software control

Source Control Concepts - Presentation Transcript

Source Control Conceptswith examples in Subversion
devlicio.us
bennage
Christopher Bennage
Blue Spire Consulting, Inc.
Microsoft MVP
there areSurprising Benefits
- Communication of intent
- Assistance with fixing bugs
- Liberation
- Encouragement of best practices
Repository
File System * Time
Working Copy
worfklow #1Check-out, Edit, Check-in
Check out the files to edit
Edit them
Check them back in
worfklow #2Edit, Merge, Commit
Update your working copy
Make your edits
(Resolve any conflicts)
Commit the changes
but alwaysComment!
Comments are the key to understanding your project’s history.
Conflicts will happen
Conflicts will happen
what isBranching?
r1
Begin
Development
r2
r1.01
mergingBranches
r1
Begin
Development
r2
r1.01
bug fixes
Tags
Tags mark special moments in the history of the code.
- official release
- just prior to breaking changes
Tags shouldn’t change.
A few other things…
- head
- revision
- atomic commit
- changeset
- blame
- patch
Subversion Resources
VisualSVNvisualsvn.com
easiest way to get started
TortoiseSVNtortoisesvn.tigris.org
popular UI for svn
Subversion subversion.tigris.org
svn client and server
“Red Bean” Book svnbook.red-bean.com
The manual for Subversion
Unfuddleunfuddle.com
hosted project management with svn
Git Resources
msysgitcode.google.com/p/msysgit
git for windows
Git Extensions sourceforge.net/projects/gitextensions
includes a Visual Studio plugin
GitHubgithub.com
social coding with git
Unfuddleunfuddle.com
hosted project management with git
Git Community Book book.git-scm.com
the manual for git
TFS Resources
Microsoft msdn.microsoft.com/en-us/teamsystem
Team System Home
Radio TFS radiotfs.com
podcasts about TFS
Team System Rocks teamsystemrocks.com
community site with tutorials and blogs
General Resources
Eric Sink ericsink.com/scm
How To guide for Source Control
Branching Primer msdn.microsoft.com/library/aa730834
primer regarding branching and merging
Visual Guide to Version Control
betterexplained.com/articles/a-visual-guide-to-version-control
An excellent overview of source control
Christopher Bennagedevlicio.us/blogs/christopher_bennage christopher@bluespire.comtwitter.com/bennageMicrosoft MVP