我在SO上读过太多帖子，我现在处于分析瘫痪状态！
我使用Visual Studio 2010，我有很多小项目，其中很多都参考了库/共享项目。
如果我对共享代码进行更改，我真的不介意检查/重新构建依赖项目......我会尽快将TeamCity放到位，以帮助解决这个问题，但就目前而言，我只是下次我在项目上工作时修改代码。许多项目都是“一次写入而忘记”，所以他们永远不需要更新。
目前团队规模很小（ME！）但是今年早些时候会有新的开发人员，但它仍然是一个非常小的内部团队，如果有任何不同的话，项目周期很快。
目前我在磁盘上有一个非常扁平的文件夹结构，所以我的所有sln文件都在磁盘上的“开发”文件夹中。然后每个VS项目都有一个文件夹。这使得共享非常简单，并且还为packages留下了一个nuget文件夹。
我即将将所有内容导入SVN（VisualSVN），我想开始添加database scripts，docs，UAT tests等内容等。
an SVN folder-per-solution
然后使用trunk/src，trunk/docs并使用nuget
packages管理svn:eternals之类的内容？an SVN folder-per-solution但docs？注意：我正在使用SVN，因此我可以引入一些Java开发，但保持源代码以单一方式管理。我们还将与数据库团队分享，他们希望将docs / sql sripts等放在那里。我打算为DB和Java分别建立一个单独的存储库 - 但是对于每个存储库都希望有一个“类似”的文件夹结构。
注意2：我有一些SVN用户体验，但没有管理员体验。新的开发人员根本没有经验（他们来自AS / 400背景）所以解决方案越简单越好！我看了repo per project and svn:extenals虽然这是一个很好的解决方案，但它需要我一直管理和维护（以及做我自己的工作！哈哈）
非常感谢收到“在那里，做过GTTS”的人的任何建议。
好的，我现在有以下本地解决方案结构：
我所有的sln / suo文件都在同一个文件夹中 我的所有项目文件夹/文件都是子文件夹
这使得共享项目足够简单......但看起来非常混乱，很难找到任何东西:(
我应该使用svn：externals来管理“参考”项目，所以我可以分支/标记它们吗？ 我应该只引用构建的DLL - 以及随之而来的所有管理吗？ 我应该让VS2010管理我的文件夹，而不关心我有很多“nuget”文件夹等吗？
现在非常困惑......任何体面的答案？ ：（
注意：将ASC添加TeamCity（或类似的东西）以提供CI功能。对CI的任何严肃（和免费）建议也表示赞赏。
答案 0 :(得分：1)
这是我在工作和个人项目中使用的结构：
SVN结构：
定期（完全取决于您的需求）来自共享代码主分支的所有更改都将合并到共享代码的产品分支中。共享代码的更改要么在产品的分支中进行，然后合并回来，要么在主分支中进行，然后合并到产品中。
产品来源内容：
构建完整包所需的一切都被视为来源。例如。如果您有数据库脚本 - 它们是源代码的一部分。测试 - 也是。对于文档，我通常会在解决方案中添加一个单独的项目，其中包含构建文档的所有源，并在输出目录中生成结果。然后，创建安装程序的项目会将其包含在生成的分发中。
规划：
这可能有争议，但我更喜欢将任务列表存储在源旁边并将它们分支/合并在一起。如果任务在分支中完成，则在合并之前不会在中继中完成。更一般的计划可能适合或可能不适合存储在源旁边。
在磁盘上：
首先，我相信以这样的方式使用存储库，可以不为每个产品存储工作副本，但可以按需检查它们。当然，检查/删除每个更改的工作副本是不切实际的，所以我有一个目录，我正在经常工作的每个产品，在其中我检查我工作的分支（主干和其他一些）。如果您不希望很快开发出其他产品，则无需检查。