[ACCEPTED]-SVN best-practices - working in a team-svn
Encourage frequent commits. Teammates new to version control may feel 17 like they need to keep the code out of the 16 repository until "it works right". Teach 15 everyone to commit early and often to find 14 issues as soon as possible. Instead of 13 holding code 'till it works, propose that 12 your teammates create branches for feature 11 that might break trunk. That leads to...
Establish a branching and tagging practice. In 10 addition to branches for features, encourage 9 your teammates to use branches for large-bug 8 fixes. Tag major bug fixes at the beginning 7 and end of the work. Maintain tags (and 6 possibly branches) for production/qa releases.
Establish a policy for trunk and stick to it. One 5 example might be, "trunk must always build 4 without errors." or "trunk must always pass 3 all unit tests". Any work that can't yet 2 meet the standards of trunk must be done 1 in a branch.
Do not commit formatting changes with code changes
If you want to restructure a giant file's 5 whitespace (Control+K+D), fine. Commit the formatting 4 change separately from the actual logical 3 change. Same goes if you want to move functions 2 around in files. Commit the moving separately 1 from the actual editing.
One of the key concepts I always stick by 14 is to commit related code changes together. The corollary is do not commit unrelated code changes in the same commit. This means 13 don't fix 2 bugs in one commit (unless it's 12 the same fix), and don't commit half a bug 11 fix in each of 2 commits. Also, if I need 10 to add some new enhancement or something 9 to an unrelated part of the system that 8 I then need for some other work, I commit 7 the enhancement separately (and first). The 6 idea is that any change anyone might conceivably 5 want to have on its own (or roll back on 4 its own) should be a separate commit. It 3 will save you tons of headaches when it 2 comes time to do merges or to roll back 1 broken features.
A lot has been mentioned already, and here 19 are some more:
If you have files that you 18 don't want in source control (e.g. configuration, compiled 17 files, etc.), add them to the ignore list. This way 16 you notice any files that you forget to 15 add by always expecting an empty list of 14 files showing as unknown to SVN.
Add a post commit event that would send an email to your developer mailing list (or 13 a one specific for this target) relating 12 to the committed change and ideally the 11 patch for it.
Integrate with your bug tracker so that references to commits 10 show up on the bugs / feature requests with 9 links to the diffs. Bug trackers like MantisBT support 8 this.
Consider integrating with continuous integration (e.g. CruiseControl.NET), NAnt for 7 Build, and NUnit/VS for unit tests. This way 6 once a user check-ins code or on a scheduled 5 interval the code gets compiled, unit tests 4 are run, and the developer gets feedback 3 of the process. This would also alert the 2 rest of the team if the repository is broken 1 (i.e. doesn't build).
Well, the basics:
- Create tags before starting QA on a version
- Create tags before risky changes (i.e. big refactors)
- Create branches for released versions in order to freeze the code.
- Make sure that people know to update before starting work on a piece of code and update once again before committing it.
- SVN allows multiple check outs of the same file by different users. Make sure that everyone resolves any conflict that may occur.
- Never use the same SVN account for more than one user. Terrible things may result.
The answers that people are giving are great. Much 2 of this is summarized in the svn user doc 1 for best practices for SVN.
- Set up your repository structure (you should have project root with trunk, branches, and tags underneath)
- Choose your policy re branching (private branches, branches per milestone/release/bug, etc) and stick to it -- I'd recommend more branching rather than less, but no need for private branches
- Choose your policy re tagging -- more tags the better, but most importantly decide on your tag naming conventions
- Choose your policy re committing to trunk -- keep trunk as "clean" as possible, it should be release-able at any time
I would like to summarize best practices 6 I stick to:
- Do not commit binaries. There should be separate repository for binaries, such as Nexus, Ivy or Artifactory.
There should be repository structure. Personally 5 I use following repository structure:
/trunk /tags /builds /PA /A /B /releases /AR /BR /RC /ST /branches /experimental /maintenance /versions /platforms /releases
- Use specific list of branch types. My list is following: experimental, maintenance, versions, platforms, releases.
- Use specific types of tags:
- Minimize necessity of merging. There should be rules when merging is possible/encouraged and when it is not.
- Version numbering. There should be established version numbering approach to stick to. Usually it is described in such document as Software Configuration Management Plan, it is a part of high-level project documentation. Personally I use complex version numbering approach. According to this approach, versions have following patterns: N.x.x (maintenance/support branches), N.M.x (release branch), N.x.K (build), N.M.K (release).
- Commit as frequent as possible. If it tends to be difficult (for example, when there should be too many changes to be made in order to implement feature and even compile code), experimental branches should be used.
- Trunk should contain the latest development. For example, when there is a choice where to develop new major version (N.x.x) of application, in trunk or in branch, decision should be always made in favor of trunk. The old version should be branched into the maintenance/support branch. It assumes that there is a clear distinction between major versions and their specifics (architecture, compatibility) emerges as early as possible.
- Strict 'do not break the build' policy on release branches. In the meantime, it should not necessarily be strict for trunk as long as it might have either experimental development or codebase which needs merge issues to be resolved.
- Use svn:externals. It will allow to modularize your project, establish transparent release management procedure, divide and conquer over different functionality.
- Use issue tracking. You will be able to point out the issue reference inside the commit message.
- Disable empty commit messages. It could be done using pre-commit hooks.
- Define which branches you want to continuously integrate. For example I prefer using continuous integration for trunk, maintenance and release branches.
- Establish continuous integration policy for different types of branches. As I pointed out earlier, most strict "don't break the build" rules apply to release branches, while trunk and maintenance branches might be broken sometimes. Also there is difference between list of inspections run on the trunk/maintenance and release branches.
You 4 can find outline of my subversion best practices 3 in the form of diagram illustrating main principles 2 of software configuration management approach 1 I use.
One thing I've found very useful is the 5 svn:external property which means you can reference 4 directories from other repositories into 3 your own. It's gives really nice ways of 2 organizing your code and data. Some examples 1 are:
- If you have a separate repositories for code different modules/libraries and reference in the ones you are using. This means that you can have a meta repository for every executable. If it's a small executable that only uses a few modules, you won't need to checkout the entire tree. An effect of this is that you get SVN revision numbers per module.
- Adding large binary data such as compiled versions of libraries to code repository is generally considered a bad habit, but it can be really convenient. If you just add all versions of all libraries you use to a different repository you can get the best of two worlds. You reference in the versions of the libraries you use into your code repository. When checking out your code repository you'll get both the code and the binaries as well. However the binaries are stored in a large repository which you don't need to backup as rigorously as your source code and the source code repository stays small and contains only text.
Use integration with your bug tracking software. If 5 you use Bugzilla, you can set it up so if your comment 4 begins with "Bug XXXX" your SVN 3 comment is automatically added as a comment 2 to the given bug, including a link to you 1 SVN web interface to that revision.
Learn about SVN's branching and merging 12 tools and conventions.
The best way to work 11 with other team members is to break work 10 up into complete development features/fixes, then 9 work on individual changes, each in a branch. Then 8 merge the changes back to the mainline branch/trunk 7 when completed/ready/approved to be merged 6 in.
This way individuals can work towards 5 a common goal (either on the same branch 4 or seperate branches) without colliding 3 with other changes.
Your mileage may vary, and 2 this may be overkill for only two or so 1 people.
The golden rule for source control: Check In Early, Check In Often
For 1 tips how to organize your repository:
It makes it much easier if you're using 15 good tools that integrate well with SVN. These 14 make it easy to see what's been changed 13 and to then commit all or part of your changes 12 and to frequently update your working copy 11 to the latest version in SVN.
I recommend 10 Tortoise SVN (If you're using Windows) and Visual SVN (if you're 9 using VS).
Also see if you can set it up 8 so that you get e-mail or similar notification 7 any time a change is committed (usually 6 also including the commit message and a 5 list of changed files). Services like CVSDude offer 4 this. I find it helpful to know both that 3 an update has been made and then to have 2 some idea of what's contained in that update 1 before updating my working copy.
Besides branching policies et al. (where 2 one size does definitely not fit all), you 1 should have good commits:
- The commit should relate to a single piece of work if possible; a bug fix, a new feature- there should be some 'logic' to what changes you committed
- The commit should have a descriptive comment that will help you locate it browsing the repository history. Most people suggest writing a single sentence at the beginning that describes the whole commit and a more detailed account below
- If possible, you should tie the commit to your bug-tracking system if possible. Trac, Redmine et al. let you create links from bugs to commits and vice versa, which comes in very handy.
Consult with your team about their changes, or 5 at least look at the diff very carefully, before 4 fixing any merge conflicts. Ask them to 3 review the merged code themselves to make 2 sure their additions were not lost in the 1 merge.
One thing that I have seen that reduces 9 broken commits is to have good pre-commit 8 scripts. For example, you can run any unit 7 tests before the change is committed. This 6 will cause commits to be a little slow, but 5 you save time by avoiding stepping on someone's 4 toes and having to apologize. Of course 3 this becomes a lot harder to manage when 2 you have a large development team and very 1 frequent commits.
One of the examples of integration with 9 bug-tracker and commit policy enforcing 8 could be Trac's svn pre/post-commit hook scripts, which 7 can refuse commit if commit message doesn't 6 reference any ticket in bug-tracker and 5 add comments to existing tickets based on 4 message contents (i.e. commit message may 3 contain something like "Fixes #1, #2 2 and #8", where #1, #2, #8 are the tickets 1 numbers).
Best practice to use SVN:
When you first came 40 to office and open your Eclipse project, the first 39 step has to be done is to update your project.
After 38 taking update, start your work. When you 37 finished your coding, check it properly, whether 36 your application runs properly without any 35 exception. Once you are sure about your 34 code is working fine, it's time to commit 33 the code.
Note :While committing the code, don’t 32 commit directly. Make a synchronization 31 with server and check what are all needs 30 to be committed. Note: Don’t commit the 29 whole folder once. Because you may have 28 done some changes to file for your requirement 27 or you may have deleted some files in your 26 local system. But the settings are different 25 on the server. So check the files individually 24 and commit the code.
Don’t commit/update 23 conflict files directly.
When to do override 22 and update?
When you are pretty much sure 21 that you don’t need any of your local changes 20 and want to update the server copy completely. Note 19 down that once if you do the override and 18 update, you will not get any of your local 17 changes.
Note: Don’t keep the project without 16 updating for more than a day. Also don’t 15 keep the code without committing for many 14 days.
Communicate who are all working in 13 same component and discuss what changes 12 they have made every day.
Don’t commit the 11 properties and configuration file unless 10 there is some reason. Because the settings 9 will be different on a server and in the 8 cloud.
Don’t commit target folders into SVN, only 7 source code and resource folders has to 6 be maintained in an SVN repository.
When 5 you lost your code, don’t panic! You can 4 get back the earlier copy from the SVN history.
Don’t 3 checkout the project into multiple places 2 of your disk. Checkout it in one location 1 and work with it.
SVN by itself is a good start and some of 11 the other posters have offered some great 10 suggestions on best practices.
The only thing 9 I would add is that you should be hooking 8 up SVN with CruiseControl or TeamCity to 7 drive a Continuous Integration process. This 6 will send out build emails and let everyone 5 know when someone broke the build.
It will 4 be very telling early on who's following 3 your process and who isn't. Might lead 2 to some friction but your team will be better 1 off in the long run.
Precise comment for every commit
Don’t break 5 the (mainline) build!
Commit as soon as a 4 logical unit changes
Avoid using Subversion 3 as a backup tool
A little branching/merging 2 as possible
More details can be found in 1 SVN best practices.
Use this for the comments template:
[task 2 / story xxx][minor / major][comment][follow 1 up comment][URL to bug]
Do DEV work on Branches
- Frequent commits to your branch
- Discrete/Modular commits to your branch (see here)
- Update/Merge-from trunk often. Don't sit on your branch without re-basing
- Should always build/work
- One issue per commit (again see here) Mostly so you or others can back-things-out one at a time
- Don't conflate refactoring/whitespace changes with logical changes. Your teammates will have a tough time extracting what you actually did from a commit
Remember that the more incremental, modular, discrete 2 and succinct you make your commits, the 1 easier it will be for you (or likely others) to:
- Incrementally back out changes
- Visually realize what you actually did without sifting through tons of white space and variable name changes.
- The commit messages mean more when the ratio of work done to message length is lower.
More Related questions