工作中的subversion存储库没有对其结构进行太多规划。目前没有配置显式标签，主干或分支，尽管通过使用subclipse：标签存在一些标记元数据
目前，存储库的格式为：
/ CoreCodeA
/ CoreCodeB
/ PROJECT1
/ Project2的
最近，一位新开发人员开始使用我们内部应用程序的“第2版”，并将其置于不同的文件夹下：
/新/ NewCoreA
/新/ NewCoreB
/新/项目3
/新/ Project4
这些项目都依赖于核心代码的各个部分，以及类似的项目（例如，几个项目可能依赖于相同的主题）。这些依赖项在一些基于文本的项目属性文件的内容中引用。
我一直在使用svndumpfilter命令，通过sed管道输出并将其重组为两个单独的存储库（“old”和“new”）。很容易做到，我现在有两个不同的存储库，其中设置了主干，标签和分支（可以在以后重新解析subclipse标记信息）。
我担心的是，通过在每次提交时摆弄subversion结构，我打破以前工作的构建，特别是考虑到对其他项目的依赖。另一方面，我需要尽快在此代码库中使用标记和分支。但是，如果我在几个月后改变主意，我也不想强迫开发人员重新检查他们的项目。
我想我对每个存储库的选择是：
前两个选项很容易做到 - 但是我想从其他开发者那里了解一下他们在类似情况下做了什么，以及出了什么问题或者说错了。
答案 0 :(得分：4)
存储库布局（更改）更多地是关于您的开发组织而不是任何技术。在不知道代码量，重组后代码所需的更改次数以及代码处理人数的情况下，很难推荐任何特定的内容，但我首先要让所有受影响的人员参与其中。将1-2天用于repo大修 - 代码冻结，只允许修改代码可构建。最后，每个人都会更快乐。试图做这个秘密可能会让你和一个流氓开发者在你的SVN服务器的某个黑暗角落里做他/她自己的分支。
我不会担心访问历史代码布局。您始终可以在/ oldlayoutdonottouchthisoutoutoutneed之类的标签下标记当前布局，并将其留在那里以修补旧版本。对于这样的技巧，SVN是一个非常棒的工具。
P.S。我从来没有使用过subclipse，但看起来像subclipse标签与通过书本的SVN标签完全不同。他们似乎更喜欢CVS标签。确保你没有混淆。
答案 1 :(得分：1)
我不会触及历史。那时候很糟糕，如果你想再回到那里，你将不得不付出代价。
当然，你可能会“知道”你会经常重温过去，然后通过＃3将整个回购放入所有重要点的新.1版本中，这可能是有道理的。
答案 2 :(得分：0)
有什么方法可以让构建属性文件反映相对路径而不是硬编码路径？
假设您的任务涉及将主文件夹组织成标签，分支和主干，我认为子文件夹/文件（至少在某种程度上）将保留其相对位置？
如果我是你，我会考虑修改我的属性文件，使其变得更通用，并且与绝对路径无关。
希望这有帮助..干杯！