StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Personally I would definitely prefer separate repository per project. There are several reasons:</p> <ol> <li><p><strong>Revision numbers</strong>. Each project repository will have separate revisions sequence.</p></li> <li><p><strong>Granularity</strong>. With repository per project you just can't make a commit into different projects having the same revision number. I assume this more as advantage, while someone would say that it is a flaw.</p></li> <li><p><strong>Repository size</strong>. How large is your project? Does it have binaries under source control? I bet it has. Therefore, size is important - each revision of binary file increases size of the repository. Eventually it becomes clumsy and it's hard to support. Fine-grained policy of binary files storage should be supported, and additional administration provided. As for me, I still can't find how could I completely delete binary file (committed by some stupid user) and its contents history from repository. With repository per project it would be easier. </p></li> <li><p><strong>Inner repository organization</strong>. I prefer fine-grained, very organized, self contained, structured repositories. There is a <a href="http://scm.altern.kiev.ua/images/branches_naming_A3.en.jpg" rel="noreferrer">diagram</a> illustrating general (ideal) approach of repository maintenance process. I think you would agree that it is just NOT POSSIBLE to use 'all projects in one repo' approach. For example, my initial structure of repository (every project repository should have) is:</p> <pre><code>/project /trunk /tags /builds /PA /A /B /releases /AR /BR /RC /ST /branches /experimental /maintenance /versions /platforms /releases </code></pre></li> <li><p><strong>Repo administration</strong>. 'Repository per project' has more possibilities in users access configuration. It is more complex though. But there is also helpful feature: <a href="http://www.gentoo-wiki.info/HOWTO_Trac_with_Apache2_SVN_and_multiple_Repositories" rel="noreferrer">you can configure repositories to use the same config file</a></p></li> <li><p><strong>Repo Support</strong>. I prefer backing up repositories separately. Somebody says that in this case it is not possible to merge info from one repo into the other. Why on earth you would need that? The case when such merge is required shows that initial approach to source control is wrong. Evolution of the project assumes subsequent project separation into submodules, not the other way. And I know that there is approach to do that. </p></li> <li><p><strong>svn:externals</strong>. 'Repository per project' approach encourages svn:externals usage. That is a healthy situation when dependencies between project and submodules is established via soft links, which svn:externals is. </p> <p><strong>Conclusion</strong>. If you want to keep source control simple, use <em>one</em> repository. If you want to make software configuration management RIGHT: </p> <ol> <li>Use <em>'repository per project'</em> approach</li> <li>Introduce separate role of software configuration manager and assign team member to it</li> <li>Hire good administrator, who can cope with all subversion tricks :)</li> </ol></li> </ol> <p>PS. By the way, in spite I work with SVN all the time and I like it, 'repository per project' approach is why I see DCVS systems more attractive from the repository organization point of view. In DCVS repo is the project by default. There is even no question 'single vs multiple' possible, it would be just nonsense. </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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