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、不能同時列報購屋自住貸款利息支出。
2013年1月21日 星期一
2013年1月4日 星期五
公寓變套房，房東裝修前須提申請
發表日期： 2010-07-26 11:22
「包租公」、「包租婆」必須注意了！為避免改裝的公寓有損害公共安全的狀況發生，內政部在96年發布了新的解釋，規定房東不得擅自變更房屋格局，如要變更，必須先提出申請，否則視同違建，將處六萬到三十萬罰緩，甚至強制拆除。
96年二月開始 公寓裝修有新規定
以目前一般住宅產品的投資報酬率在3~5%左右、商用產品4~6%、學區套房約5~8%來看，投資房地產坐收租金，在通膨時代裡，特別讓人心動。不過有一個案例是，一位住在板橋的張先生，因看好木柵政大附近的套房市場，在附近社區買了間30坪舊公寓，打算將原本三房二廳的格局改建成幾間小套房，沒想到剛裝修好，就收到建設局發文要補申請，否則就視同違建，這讓他非常煩惱，也感到疑惑，為什麼以前這樣做都沒事、現在卻有問題？
在以前，房子裝修，尤其是公寓改裝成套房，依照建築法相關法令規定，五樓以下非供公眾使用的建築物室內裝修，是不必申請許可的。這是由於六層樓以上的集合住宅因為逃生動線較為複雜，公共安全的危險度較高，因此被歸類為「供公眾使用」建築物的範圍之一，所以，以往六樓以上的大樓住戶如果要變更原有的室內格局，包括分間牆及天花板，不管是敲除或是增加，都必須委託開業建築師針對建築物使用材料加以檢討、申請室內裝修執照並簽證負責，以確保整棟大樓的公共安全。
但近幾年有愈來愈多的公寓改建成套房出租的案例，為了避免改裝的公寓有損害公共安全的情形，96年2月26日內政部發布了新的解釋。依據建築法第七十七條之二第一項、第二項規定，指定非供公眾使用建築物之集合住宅及辦公室等，除建築物地面層至最上層屬同一所有權人外，其任一戶有下列情形之一者，應申請建築物室內裝修審查許可：
一、增設廁所或浴室；
二、增設兩間以上之居室造成隔間牆之變更。
也就是說，除了建築物上下樓層都是同一所有權人者外，只要裝修室內，有增設廁所或浴室、或增設兩間以上之居室造成隔間牆之變更，都必須向縣市政府建管處提出申請。
擅自變更 一經檢舉就開罰
在民眾提出申請時，也須依建築物室內裝修管理辦法規定，委請建築師或已向主管機關立案的室內裝修業者提出室內裝修申請，可別以為自己找熟識的裝潢師傅就可以自行變更格局。
如果在沒有建築師、土木技師或結構技師等專業技師的確認下，就擅自敲敲打打，很有可能破壞原本經過精密計算的建築物結構系統及耐震強度。例如幾年前，台南市五名女生因房東違法變更房屋格局，將熱水器安裝在密封陽台，導致一氧化碳中毒死亡，可見隨意變更不僅威脅民眾的生命財產安全，意外發生時可能還要負起刑責。
同時，室內裝修還必須符合法令規定，包括：
一、裝修材料應合於建築技術規則之規定；
二、不得妨害或破壞防火避難設施、消防設備、防火區劃及主要構造；
三、不得妨害或破壞保護民眾隱私權設施。所以，如果像張先生一樣事前未申請，裝修後應趕快補辦申請，以取得主管機關核發的許可證明，否則，一旦有別人檢舉時，就會被處以六萬元以上三十萬元以下的罰鍰。
裝修前先弄清楚相關法規
‧建築法第七十七條之二
建築物室內裝修應遵守左列規定：
一、供公眾使用建築物之室內裝修應申請審查許可，非供公眾使用建築物
，經內政部認有必要時，亦同。但中央主管機關得授權建築師公會或
其他相關專業技術團體審查。
二、裝修材料應合於建築技術規則之規定。
三、不得妨害或破壞防火避難設施、消防設備、防火區劃及主要構造。
四、不得妨害或破壞保護民眾隱私權設施。
前項建築物室內裝修應由經內政部登記許可之室內裝修從業者辦理。
室內裝修從業者應經內政部登記許可，並依其業務範圍及責任執行業務。
前三項室內裝修申請審查許可程序、室內裝修從業者資格、申請登記許可
程序、業務範圍及責任，由內政部定之。
‧建築法第九十五條之一
違反第七十七條之二第一項或第二項規定者，處建築物所有權人、使用人
或室內裝修從業者新臺幣六萬元以上三十萬元以下罰鍰，並限期改善或補
辦，逾期仍未改善或補辦者得連續處罰；必要時強制拆除其室內裝修違規
部分。
室內裝修從業者違反第七十七條之二第三項規定者，處新臺幣六萬元以上
三十萬元以下罰鍰，並得勒令其停止業務，必要時並撤銷其登記；其為公
司組織者，通知該管主管機關撤銷其登記。
經依前項規定勒令停止業務，不遵從而繼續執業者，處一年以下有期徒刑
、拘役或科或併科新臺幣三十萬元以下罰金；其為公司組織者，處罰其負
責人及行為人。
出處來源：永慶房仲網
訂閱：
文章 (Atom)