4. SVN Revisions
❖ Commit – changes to the server state
❖ Every commit results in a new Revision
➢ Every revision has its unique identifier number
www.dreamix.eu
5. SVN Layout
❖ Typical (sane) repository layout
<Project Root> ( MyProjectName/)
- trunk
Contains the latest working (development) version
of the project.
- tags
Contains named revisions
- branches
Contains so called branches from the main development line.
www.dreamix.eu
8. Best practices
❖ Commit logical changesets
➢ make sure your change reflects a single purpose
❖ Use the issue-tracker wisely
➢ Two way links between SVN and issue-tracker
➢ If possible, refer to a specific issue ID in every commit log message.
➢ When appending information to an issue (to describe progress, or to close
the issue) name the revision number(s) responsible for the change.
❖ Always write a comment on your commit
❖ Trunk must be always compile-able and work-able
❖ SVN:ignore resulting artifact of the build process
➢ Classes/Bin directory
❖ Use standard coding formats
❖ Use SVN wisely to help you in multy-environment
(DEV, QA, UAT, PROD)
➢ Always tag every deployment and document it
www.dreamix.eu
9. Versioning of the
applciation
❖ Think of a good versioning number
➢ The X.Y.Z_Revision approach
➢ Change in X – Major change. Potential backward incompatibility
➢ Change in Y – Minor feature and bigfix is introduced
➢ Change in Z – Small changes, mostly bugfix releases
www.dreamix.eu
10. Branching
❖ The Never-Branch system
➢ Pros: Very easy policy to follow
➢ Cons: Chaotic development, code could be unstable at any time
❖ The Always-Branch System
➢ Pros: /trunk is guaranteed to be extremely stable at all times
➢ Cons: Requires users to do lots of extra merging.
❖ The Branch-When-Needed System
➢ Pros: /trunk is guaranteed to be stable at all times. The hassle of
branching/merging is somewhat rare.
➢ Cons: Adds a bit of burden to users' daily work: they must compile and
test before every commit
www.dreamix.eu
11. Common Branching
Patterns [1]
❖ Normal app lifecycle - code, test, release
➢ Developers keep writing new features while previous release is being
tested
➢ Support old releases
www.dreamix.eu
12. Common Branching
Patterns [1]
❖ Release branches
➢ Developers commit all new work to the trunk
➢ The trunk is copied to a “release” branch
➢ Teams continue to work in parallel
➢ The branch is tagged and released
➢ The branch is maintained over time
www.dreamix.eu
13. Common branching
patterns [2]
□ Feature Branches
■ It's a temporary branch created to work on a complex change without interfering with the stability of /trunk.
■ Feature branches are born, used for a while, merged back to the trunk, and then ultimately deleted
□ When do we create a feature branch
□ Regularly merge changes from trunk to the branch
www.dreamix.eu
16. Best practices [cont]
❖ Keep your SVN clean and tidy
➢ Delete branches that were successfully merged or reintegrated
❖ Use it to check differences between version
➢ Of the whole application
➢ Of a single resource or directory
❖ Very helpful for doing code reviews
www.dreamix.eu
