Showing posts with label svn. Show all posts
Showing posts with label svn. Show all posts

Wednesday, August 12, 2009

Software Release Procedure Using Subversion

如果你用Subversion作为版本管理软件,那么,软件发布的时候,你可以参考下列流程:

1. branch一个,叫B_RE_0802。(本地的trunk copy可以切换为branch copy,或者本地的人直接下载一个)
2. 在本地branch copy上修改release所需要改的东西(版本号,添加最新Manual,制作installer)。
3. 从本地branch上build一个release出来。然后对此Branch进行Tag到服务器,此Tag为T_RE_0802。
4. 从本地Branch Merge回Trunk copy,然后commit trunk copy。
5. 有bug在branch上修改,然后merge回truck. 对0802Tag不要动,发B_RE_0802_f1 版本。

最后借用Dechu的一段,讲讲Release之前的开发流程,要到Release阶段真不容易,哈哈哈。(微软真屌)

1) pm work on spec, then all team members review, sign off
2) dev work on design, then all team members review, dev start working
3) test work on plan, then all team members revew, test start working
4) CC - code complete by dev
5) TCC - test case complete by test
6) RTW - bugs fixed, test case passed, release to world

Monday, June 1, 2009

Subversion Trac rules tutorial

A guide that I worte for company staff to follow.

SVN:

  • Use TortoiseSVN client.
  • Our subversion has the usual trunk/branches/tags layout. Never develop on trunk! Do your part in branches and merge it back to trunk.
  • Recommended check in frequency is every hour! Comment is a MUST.
  • Exclude unnecessary files that are not required in compile. (eg, obj, exe) Pay attention to check-in huge files that can’t be re-versioned!
  • ONLY merge changes that can be compiled and tested into truck. ( and reviewed! Will have detailed discussion about this.)
  • Commit changes as a single logical change set for one purpose. Thus all code changes for a single bug fix or enhancement should be checked-in together. This allows one to better follow the history log of changes.
  • Check-in code at the directory level and all changed files, recursively in the directory and subdirectories will be checked in together.
  • Using Trac integrated with Subversion, refer to the Trac ticket in the Subversion check-in comment using a "#" in front of the Trac ticket number (eg. #65). This generates a hyperlink when the Subversion logs are viewed in Trac.
  • The "tags" branches are NOT to be used as working branches but are snapshots of an existing branch. The "tags" are for historical reference such as a release, well tested version or progress milestone.

Trac:

  • Document project based information in Trac wiki. (eg, Anything that isn't obvious to fresh eyes gets documented on the Trac Wiki.)
  • Spend at least 0.5 hour a day documenting on the Wiki. This should get placed in the "Documentation" category on the time-tracking software.
  • Using Subversion integrated with Trac, refer to the Subversion specific revision in tickets using a “r” in front of the revision number (eg r103). This generates a hyperlink to view the source in Trac.

Saturday, April 11, 2009

SVN使用规范:Branch Tag的区别和在Subversion中的使用 (转载)

  • Trunk would be the main body of development, originating from the the start of the project until the present.

  • Branch will be a copy of code derived from a certain point in the trunk that is used for applying major changes to the code while preserving the integrity of the code in the trunk. If the major changes work according to plan, they are usually merged back into the trunk.

  • Tag will be a point in time on the trunk or a branch that you wish to preserve. The two main reasons for preservation would be that either this is a major release of the software, whether alpha, beta, RC or RTM, or this is the most stable point of the software before major revisions on the trunk were applied.

In open source projects, major branches that are not accepted into the trunk by the project stakeholders can become the bases for forks -- e.g., totally separate projects that share a common origin with other source code.

Branching / Tagging

One of the features of version control systems is the ability to isolate changes onto a separate line of development. This line is known as a branch. Branches are often used to try out new features without disturbing the main line of development with compiler errors and bugs. As soon as the new feature is stable enough then the development branch is merged back into the main branch (trunk).

Another feature of version control systems is the ability to mark particular revisions (e.g. a release version), so you can at any time recreate a certain build or environment. This process is known as tagging.

Subversion does not have special commands for branching or tagging, but uses so-called “cheap copies” instead. Cheap copies are similar to hard links in Unix, which means that instead of making a complete copy in the repository, an internal link is created, pointing to a specific tree/revision. As a result branches and tags are very quick to create, and take up almost no extra space in the repository.

Creating a Branch or Tag

If you have imported your project with the recommended directory structure, creating a branch or tag version is very simple:

Figure 4.34. The Branch/Tag Dialog

The Branch/Tag Dialog

Select the folder in your working copy which you want to copy to a branch or tag, then select the command TortoiseSVN → Branch/Tag....

The default destination URL for the new branch will be the source URL on which your working copy is based. You will need to edit that URL to the new path for your branch/tag. So instead of

    http://svn.collab.net/repos/ProjectName/trunk


you might now use something like



    http://svn.collab.net/repos/ProjectName/tags/Release_1.10


If you can't remember the naming convention you used last time, click the button on the right to open the repository browser so you can view the existing repository structure.



Now you have to select the source of the copy. Here you have three options:


HEAD revision in the repository

The new branch is copied directly in the repository from the HEAD revision. No data needs to be transferred from your working copy, and the branch is created very quickly.




Specific revision in the repository

The new branch is copied directly in the repository but you can choose an older revision. This is useful if you forgot to make a tag when you released your project last week. If you can't remember the revision number, click the button on the right to show the revision log, and select the revision number from there. Again no data is transferred from your working copy, and the branch is created very quickly.




Working copy

The new branch is an identical copy of your local working copy. If you have updated some files to an older revision in your WC, or if you have made local changes, that is exactly what goes into the copy. Naturally this sort of complex tag may involve transferring data from your WC back to the repository if it does not exist there already.




If you want your working copy to be switched to the newly created branch automatically, use the Switch working copy to new branch/tag checkbox. But if you do that, first make sure that your working copy does not contain modifications. If it does, those changes will be merged into the branch WC when you switch.



Press OK to commit the new copy to the repository. Don't forget to supply a log message. Note that the copy is created inside the repository.



Note that unless you opted to switch your working copy to the newly created branch, creating a Branch or Tag does not affect your working copy. Even if you create the branch from your WC, those changes are committed to the new branch, not to the trunk, so your WC may still be marked as modified with respect to the trunk.



To Checkout or to Switch...




...that is (not really) the question. While a checkout downloads everything from the desired branch in the repository to your working directory, TortoiseSVN → Switch... only transfers the changed data to your working copy. Good for the network load, good for your patience. :-)



To be able to work with your freshly generated branch or tag you have several ways to handle it. You can:





  • TortoiseSVN → Checkout to make a fresh checkout in an empty folder. You can check out to any location on your local disk and you can create as many working copies from your repository as you like.





  • Switch your current working copy to the newly created copy in the repository. Again select the top level folder of your project and use TortoiseSVN → Switch... from the context menu.



    In the next dialog enter the URL of the branch you just created. Select the Head Revision radio button and click on OK. Your working copy is switched to the new branch/tag.



    Switch works just like Update in that it never discards your local changes. Any changes you have made to your working copy which have not yet been committed will be merged when you do the Switch. If you do not want this to happen then you must either commit the changes before switching, or revert your working copy to an already-committed revision (typically HEAD).





  • If you want to work on trunk and branch, but don't want the expense of a fresh checkout, you can use Windows Explorer to make a copy of your trunk checkout in another folder, then TortoiseSVN → Switch... that copy to your new branch.







Figure 4.35. The Switch Dialog



The Switch Dialog



Although Subversion itself makes no distinction between tags and branches, the way they are typically used differs a bit.





  • Tags are typically used to create a static snapshot of the project at a particular stage. As such they not normally used for development - that's what branches are for, which is the reason we recommended the /trunk /branches /tags repository structure in the first place. Working on a tag revision is not a good idea, but because your local files are not write protected there is nothing to stop you doing this by mistake. However, if you try to commit to a path in the repository which contains /tags/, TortoiseSVN will warn you.





  • It may be that you need to make further changes to a release which you have already tagged. The correct way to handle this is to create a new branch from the tag first and commit the branch. Do your Changes on this branch and then create a new tag from this new branch, e.g. Version_1.0.1.





  • If you modify a working copy created from a branch and commit, then all changes go to the new branch and not the trunk. Only the modifications are stored. The rest remains a cheap copy.