Source Control Concepts and Examples in Subversion
•
2 recomendaciones•1,567 vistas
An introduction into the basic concepts of source control. Some specific examples are in Subversion (svn).
![there areSurprising Benefits ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Source Control Concepts and Examples in Subversion
Similar a Source Control Concepts and Examples in Subversion (20)
Más de Christopher Bennage
Más de Christopher Bennage (9)
Último
Último (20)
Source Control Concepts and Examples in Subversion
- 1. Source Control Conceptswith examples in Subversion devlicio.us bennage Christopher Bennage Blue Spire Consulting, Inc. Microsoft MVP
- 3. Assistance with fixing bugs
- 4. Liberation
- 6. Working Copy
- 7. worfklow #1Check-out, Edit, Check-in Check out the files to edit Edit them Check them back in
- 8. worfklow #2Edit, Merge, Commit Update your working copy Make your edits (Resolve any conflicts) Commit the changes
- 9. but alwaysComment! Comments are the key to understanding your project’s history.
- 10. Conflicts will happen Conflicts will happen
- 11. what isBranching? r1 Begin Development r2 r1.01
- 12. mergingBranches r1 Begin Development r2 r1.01 bug fixes
- 14. just prior to breaking changesTags shouldn’t change.
- 16. revision
- 17. atomic commit
- 18. changeset
- 19. blame
- 21. 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
- 22. 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
- 23. 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
Notas del editor
- 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