http://www.oracle.com/technetwork/java/dataaccessobject-138824.html
2013年1月26日 星期六
2013年1月23日 星期三
Subversion Best Practices: Repository Structure
Published by jthornsby on October 24, 2011 in Subversion and WANdisco. 4CommentsTags: best practices, open source, oss, subversion, wandisco, wdfront.
Maintaining a Subversion repository can become a complex task, and implementing the right project layout from the very beginning is crucial. As Subversion doesn’t impose a strict file structure, users are free to tailor Subversion repositories to their project’s needs. Users can organize Subversion on a ‘one project per repository’ basis or create multiple projects within the same repository; and have considerable freedom when it comes to how they use Subversion’s trunk and branches. In this post, we’ll look at some guidelines and best practices on how to keep Subversion files, for users who are embarking on a new project in Subversion.
Multiple Projects: Single Repository vs. Multiple Repositories
In modern software development, it’s normal for teams to be working on multiple projects simultaneously. If this sounds like your organization, the first question you’ll need to answer is: should I set up a single repository for multiple projects, or create one repository per project? Although the experience will be slightly different for each project, there are some general benefits and drawbacks to each approach.
Single Repository
Single repositories are typically suited to organizations managing multiple, small projects that require cross references, cross tracking, etc.
Positives:
- there is a single location where all the code is stored, even for projects you aren’t directly involved in.
- ability to reuse common libraries.
- lack of duplicated maintenance (e.g only one repository needs to be backed up.)
- the ability to move data between projects more easily, and without losing any versioning information.
- all projects share the same repository history.
- typically less administration – new projects can be created without creating a new repository, and without the help of sysadmin.
- you can delete entire projects without losing the record from Subversion.
Negatives:
- Subversion uses repository-global revision numbers which apply to entire trees, not to individual files. The revision number for projects will increase in accordance with the rest of the repository, even if no changes have been made to that particular project.
- unable to use unified logging (svn log command).
- branching can be complex when many folders and files are involved.
- dumping/loading one huge repository can be time-consuming.
Multiple repositories
These are typically suited to multiple large unrelated projects.
Positives
- the ability to define different access permissions, for different users.
- each project repository will have its own revision sequence.
- the version number is meaningful for all projects.
- projects have a tendency to increase in size, and numerous large projects on a single repository can become difficult to maintain. It is typically easier to manage large projects with a ‘one repository per project’ approach.
- can tailor each repository’s structure to suit a project’s unique needs. This can include branching, tagging, naming conventions, etc.
Negatives:
- Subversion does not support merging code between projects in different repositories, and the transplanted code will appear in the new repository with no history. This also means you cannot perform merges if you need to temporarily maintain two versions of related code.
- different projects have different mailing lists, which can be a problem if there’s cross-over between two related, but separate, projects.
There is also the potential to have more than one repository, and to group related projects within the same repository. This allows related projects to share data, and when new revisions are added to a repository, they are more likely to be relevant to everyone who uses the repository.
Project Layout
Once you’ve decided whether to organize your projects in a single or multiple repository structure, it’s time to plan your project layout. Putting some thought into your layout in the beginning, can help you avoid having to move files around later.
An illustration of how a Subversion Repository evolves using branching, tagging and a code trunk.
Here are some best practices for getting the most out of your project layout:
- Project root – This is the anchoring point for a project. A repository may contain one project root, or multiple roots, but each project root contains three subdirectories: /trunk, /branches, and /tags. The use of a project root is officially recommended by the Apache Subversion project.
- Trunk - This is where you should store current release code – only! Don’t muddy the trunk directory with revisions or release names.
- Branches – Use these to work on significant changes, variations of code etc, without disrupting the current release code.
- Bug fixing on a branch – Branches should be created to fix major bugs; this allows bug changes to be immediately worked on without disrupting whatever work is currently underway in the trunk/development branches.
- “Toe in the water” branches – Branches can be used as a code “sandbox” where new technology can be tested without risking the working code. If things go right, the new code can always be merged back into the trunk.
- Tags – Should be used as “code milestones” providing a snapshot of the code at specific points in its history.
- Tagging bug fix / development branches – when creating a code or bug fix branch, it’s useful to create a “pre” tag, and a “post” tag after the bug fix or code change has been completed:
http://10.2.5.2:9880/encom/tags/PRE_authchange_bug9343
http://10.2.5.2:9880/encom/tags/POST_authchange_bug9343
Ready to start a new project with Apache Subversion? Certified open source Apache Subversion binaries can be downloaded from the WANdisco website.
About jthornsby
4 Responses to “Subversion Best Practices: Repository Structure”
-
Julio Aguilar
In my company we use three big repositories and the big size and maintenance points are spot on.
Yet, I differ in two smaller points:
- Revision numbers have become completely irrelevant for us. Using the proper tools (in our case, mainly, TortoiseSVN, Netbeans and sventon) we use dates, comments and diffs to find previous versions and nobody even flinches about numbers not being consecutive in a particular project.
- SVN through apache allows to set permissions to users in particular paths in one repository. -
“the ability to define different access permissions, for different users.”
You can still do this with one repo though… you can define per folder access permissions.
Here is an example:
-
Daniel
Hi
in the case of cloud based subversion it may be more attractive to have fewer repositories in order to keep the costs down. Each repository may have more than one .NET solution dir structure. Is there anyway to apply separate versioning to each dir structure; with each held under the branch structure?
-
Hi Daniel,
Thanks for your comment! With Apache Subversion, it’s not possible to have branches with different revision numbers in the same repository. Whenever you perform a commit, the revision number will increase across all of your repository’s files and folders, regardless of whether they’ve actually changed. If revision numbers changing based on other branches is a problem, you should create separate repositories.
« Branching Options for Development
Getting Started with Jenkins in uberSVN »
- Svetoslav Gyurov Oracle blog » Setup Subversion on Oracle Enterprise Linux
Pingback on Nov 1st, 2011 at 9:39 am
- Busy Developer’s Guide to Subversion Best Practices - WANdisco Subversion Blog
Pingback on Dec 21st, 2011 at 11:03 am
- Subversion Tip of the Week - WANdisco Subversion Blog
Pingback on Jan 30th, 2012 at 9:44 am
2013年1月22日 星期二
屋屋租賃房客戶籍遷入會造成的影響
(轉載自591租屋交流討論區 無聊房東 大作)
房客其實只要僅憑著租賃契約書就可以將戶籍遷入承租的房屋中(這也是房客的權利).但因為房客要遷戶籍到租屋處會增加房東某些負擔與風險.
1.出租之房子無法享有自用住宅稅率，地價稅、土地增值稅也會提高.
每年要繳的地價稅稅率會從原來自用0.2%變成1%、增加5倍.
房屋稅如果房客仍供住家使用者，稅額不變。但是如果變成營業用,
a. 水電費會變成營業用。
b. 房屋稅會從住宅用(1.2%)變成營業用(3%)
c. 承租人每年會開立你個人的房屋租賃所得扣繳憑單，會增加個人的綜合所得額。
如果房屋一部分當辦公室，一部分當住家用，則可向稅捐處申請部份當自用住宅、部分當營業的使用情形來分別課稅，稅捐處會派員前往查看實際使用情形後。
土地增值稅問題:將來如果要出售，同樣因為出租他人，而不得享用自用土地增值稅優惠稅率(規定出售前1年不得出租、營業)。也就是說如果房客退租,房東想要把房子賣掉,那房東就不能用自用的土地增值稅.這一個影響很大,從幾千到甚至幾百萬,都是有可能的!!
2.若房客把租金拿去報稅,租金將併入房東的綜合所得裡面,年度所得稅可能會增加.
租賃所得計算方式
租賃所得應就租金收入減除必要費用後的餘額申報。至於減除之必要費用，可採以下方式計算，並擇較高者申報，以達節稅之目的：
(一)列舉扣除租賃合理而必要的損耗及費用：如折舊、修理費、地價稅、房屋稅及其附加捐、以該房屋為保險標的物所投保的保險費、向金融機構貸款購屋而出租所支付利息等之憑證。
(二)不列舉必要的損耗及費用者：依財政部頒定之必要損耗及費用標準（97年度為43％）。
例如月租金10000元，10000x12(月)=120000元(租金總收入)
如果不列舉費用，可扣除43％之(法定)必要費用，所以申報租金收入為120000x(1-43％)=68400元
將租金總收入併入房東綜合所得，再依房東應繳綜合所得稅率計算所得稅，例如級距為6％，依上例，稅金68400x6％=4104元；級距為13％，依上例，稅金為68400x13％=8892元。
納稅是國民應盡的義務,所以合約上租金有沒有包含稅金必須寫清楚.
3.房客將戶籍遷入後，發生卡債欠繳、官司纏身.....等問題.房客逃離卻沒將戶籍遷出.之後所有法院的傳票、甚至"財務管理"公司都會到他的戶籍地址進行一些"必要"的動作，對於房東來說，會是很煩的一件事。
4.房客租約到期搬離，但是戶籍卻沒遷出.
房東可以帶所有權狀(稅單)、身分證、印章、已到期合約書，到戶政事務所請求將房客的戶籍遷離.此後房東不會再有此房客戶籍上的困擾。將來該房客要遷戶籍時，可在遷入地辦理遷入，與房東無關!!
房客必須具備以下資格，才能申報租金支出列舉扣除：1、所租自用的房子，必須在中華民國境內，且不能當營利事業使用或執行業務（如醫師、律師、會計師、代書）使用的房屋；2、租屋人必須是納稅人本人、配偶或受扶養直系親屬，其他受扶養親屬名義租的房子不可認列；3、房客應以實際的房租支出申報，最高以12萬為上限；4、不能同時列報購屋自住貸款利息支出。
訂閱：
文章 (Atom)