Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>to "putting all projects into same trunk":</p> <p>From my experience this is no good idea - because each project has it's own history and changes and often projects are/will be maintained by different developers. This can lead to conflicts - even if you state out, that currently the projects interfere heavily.</p> <p>So why don't you use common tags (with milestones as names to) for all of your projects to ensure a same code base and a build script, which can check out the projects (trunks) automagically? It's more work, but like usual in OOP (capsulation) I would prefer to split the projects into separate SVN directories, too.</p> <p>But: Collecting a bunch of small libs and apps into a common directory under the same trunk is no problem (see "apps" and "tools" in my example below) - so maybe "small projects" can stay in the shared/big trunk.</p> <p>Here as example my directory structure of SVN:</p> <pre><code>/projects/ /projects/CustomerA/ /projects/CustomerA/ProjectX/ /projects/CustomerA/ProjectX/trunk/ /projects/CustomerA/ProjectX/tags/ /projects/CustomerA/ProjectX/branches/ /thirdparty/ /thirdparty/ExtLibY/ /thirdparty/ExtLibZ/ /tools/ /tools/trunk/ /tools/tags/ /tools/branches/ /apps/ /apps/trunk/ /apps/tags/ /apps/branches/ </code></pre> <p>So all of the external stuff is stored in /thirdparty/ and all internals (projects, tools, apps) have the subdirs:</p> <pre><code>/trunk/ /tags/ /branches/ </code></pre> <p>...like advised in the Subversion book and the previous post.</p> <p>Even if that looks a little bit much efforts at first sight - it is really worth it, especially when your code base grows.</p> <p>ciao, Chris</p>
 

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