Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Remember that subversion is just a fancy filesystem that supports versioning. Think of a repository as a "drive root" like "C:/".</p> <p>Each project gets a trunk, tags and branches directory. All of your day to day work happens in the trunk. Experimental code is done in a branch and then merged back into the trunk at a later date. Tags are for when you release the software. These are <strong>not</strong> to be edited. When you release the software, you create a tag with a unique name based on what is currently in the trunk.</p> <p>I can't say whether or not you need a separate repository for each project, there are pros and cons. This <a href="http://blogs.open.collab.net/svn/2007/04/single_reposito.html" rel="nofollow noreferrer">blog posting</a> details them:</p> <blockquote> <ol> <li>Simplified administration. One set of hooks to deploy. One repository to backup. etc.</li> <li>Branch/tag flexibility. With the code all in one repository it makes it easier to create a branch or tag involving multiple projects.</li> <li>Move code easily. Perhaps you want to take a section of code from one project and use it in another, or turn it into a library for several projects. It is easy to move the code within the same repository and retain the history of the code in the process.</li> </ol> <p>Here are some of the drawbacks to the single repository approach, advantages to the multiple repository approach.</p> <ol> <li>Size. It might be easier to deal with many smaller repositories than one large one. For example, if you retire a project you can just archive the repository to media and remove it from the disk and free up the storage. Maybe you need to dump/load a repository for some reason, such as to take advantage of a new Subversion feature. This is easier to do and with less impact if it is a smaller repository. Even if you eventually want to do it to all of your repositories, it will have less impact to do them one at a time, assuming there is not a pressing need to do them all at once.</li> <li>Global revision number. Even though this should not be an issue, some people perceive it to be one and do not like to see the revision number advance on the repository and for inactive projects to have large gaps in their revision history.</li> <li>Access control. While Subversion's authz mechanism allows you to restrict access as needed to parts of the repository, it is still easier to do this at the repository level. If you have a project that only a select few individuals should access, this is easier to do with a single repository for that project.</li> <li>Administrative flexibility. If you have multiple repositories, then it is easier to implement different hook scripts based on the needs of the repository/projects. If you want uniform hook scripts, then a single repository might be better, but if each project wants its own commit email style then it is easier to have those projects in separate repositories</li> </ol> </blockquote>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload