首先，有两个操作参数：
我主要使用Visual Source Safe和SourceGear Vault源代码控制系统。在每个中，我将存储库的根映射到本地工作目录。例如：
$/ --> C:\source
只要本地目录存在，我就可以设置“工作副本”（svn）或“工作文件夹”（VSS）。
要处理已存在于源代码存储库中的新项目，我需要“获取该项目目录的最新”（VSS）版本。
当我进入存储库中的任何子目录并“获取最新”（即svn checkout）时，客户端将自动为我创建完整的目录层次结构，镜像我本地磁盘上的结构。因此，当我得到最新的
$/foo/bar/project1
它是在驱动器上创建的
C:\source\foo\bar\project1
在subversion中，当我签出目录时，我必须指定工作副本目录位置。如果我想正确镜像我的工作副本目录结构以匹配存储库，我必须手动构建路径中的每个子目录，或者将存储库根目录检出到工作副本根目录，从而获取存储库中的所有内容。
有没有办法在层次结构中删除存储库目录，以便在没有所有人工干预的情况下在匹配的本地工作副本目录结构中创建？
这对小型存储库来说不是问题，但在大多数情况下，我不需要很大比例的源存储库。必须维护物理结构，以便对项目和资源的文件引用不会中断。此外，考虑到文件的所有工作基础副本，SVN的磁盘成本是实际源大小的两倍。
我目前正在使用Tortoise。是否有可能有其他SVN客户端会做我正在寻找的东西？
答案 0 :(得分：3)
Subversion“签出”操作会创建一个新工作副本。您可能想要做的是检查整个项目（它会自动创建存储库中的正确目录结构），然后使用Subversion“更新”操作。此更新将更新指定目录和子目录中的所有内容。
这可能是由于VSS和Subversion之间的术语不同。 Subversion Book值得一读，特别是关于Basic Usage的章节。
更新：我想我不太了解您的预期用例是什么。这听起来像您可能需要的新版Subversion 1.5功能之一是sparse checkouts。这使您可以选择性地获取存储库的一部分，而不必获取整个事物。它为您提供了管理需要的选项，它非常灵活。
由于稀疏结账相对较新，我不认为SVN书已经更新，不包含有关此功能的信息。它已更新，请参阅注释。
更新2：听起来你可以通过使用--depth = empty选项将存储库的顶层检入c：\ source来构建你想要的东西。然后，对于您想要的每个子目录，请根据需要使用--depth = empty或--depth = infinity更新该子目录。
我相信所有这些都源于Subversion的设计目标，即能够在您的系统上同时拥有多个独立的源树。使用VSS，$ /被全局配置为引用特定目录（c：\ source），因此您只能进行一次检出（每次要切换时都没有乱七八糟的全局配置）。
答案 1 :(得分：2)
简单回答粗体打印的问题：否无法在项目位置上方创建所有文件夹
原因稍长：
您正在考虑在VSS工作流程中，您有1个工作文件夹，其本地目录上有固定路径。所以你要做的就是检查另一个项目，它将在你工作文件夹中的本地高清上创建整个目录结构。
在SVN中，您有浮动 workingcopys，您可以将存储库中的特定位置检出到您想要的任何位置。你甚至可以将你的工作副本移到另一个地方！您的工作副本不需要HD上的固定位置。
因此，您不需要需要来重新创建项目上方的文件夹结构。对于您的项目，它也应该没有任何区别。通过使用 floating workingcopys的SVN工作流，您可以更加灵活，其中绝对路径不重要。
但是，如果您在使用旧的基于VSS的工作流程时感觉更舒服，可以使用--sparse-checkout参数签出并手动重新创建结构，或者编写一个简单的批处理文件来执行此操作。我看不出这有什么好处，你肯定会忘记这样做，如果你继续使用SVN并忘记了旧生锈的VSS工作流程
答案 2 :(得分：1)
答案 3 :(得分：1)
我似乎找到了解决问题的合适方法。
使用TortoiseSVN，repo浏览器中的“Update item to revision”操作可用于本地重建存储库的任意repo路径的文件夹结构。
详细步骤如下：
这将使用所选repo路径的内容更新您的工作副本，包括所有父目录，直到结帐工作副本的开头，从而镜像工作副本中存储库的文件夹层次结构。
关于“更新项目到修订”上下文菜单选项的注释：
答案 4 :(得分：0)
但问题的关键在于我不希望整个存储库只是在初始结账时创建目录结构。
很抱歉，如果我不清楚我是从干净，空的工作副本位置开始的。
我已经阅读了SVN书的很多部分。但是，它不包括这些问题。
答案 5 :(得分：0)
答案 6 :(得分：0)
我一般都在理解你们所说的“SVN如何运作”。也许问题不在于我不清楚，但我是一个更高的代码组织问题的受害者。
问题的根源来自项目依赖性。我有许多具有许多依赖项的应用程序。由于.NET项目的层次结构，依赖性预计在某些物理位置。所以如果我要开始研究这个项目：
http://mysvn/svn/foo/bar/project1
该项目将进入
C:\source\foo\bar\project1
现在该项目依赖于另一个项目。在.NET项目文件中，项目引用相对“反向引用”：
..\..\..\bar\foo\project2
所以依赖关系应该在
的本地工作副本中C:\source\bar\foo\project2
因此，父目录结构至关重要。
我不能将依赖项目存储为任何特定应用程序/项目的子项，因为它们在许多项目中共享。因此，他们住在一个特定项目树之外的自己的位置。因此，我确实需要确保将任何给定项目（及其依赖项）签出到相对于源树根的特定树位置，以确保对项目的引用不会中断或者它们不会开发人员之间有所不同。否则，我们每个人都会不断更新引用，使它们在源历史记录中产生大量噪音，并在开发人员之间不断中断。此外，构建服务器也不会将它们放在正确的位置。
我还没有找到关于使用SVN进行.NET开发的任何好信息。 .NET中有很多使用SVN或CVS的开源项目。但是，我所看到的那些似乎总是处于相当孤立的结构中，因此所有不同的项目都属于单个源树位置。这使得获取所需的一切变得微不足道，因为您可以简单地以递归方式检出一条路径并获得所需的一切。
我非常有兴趣听到任何使用SVN进行.NET企业开发的人员以及跨越项目存储位置边界的许多共享项目。
开始觉得在团队中工作的唯一解决方案是简单地检查整个存储库以确保结构正确且一致。对于拥有许多源代码的存储库来说，这是不幸的。
答案 7 :(得分：0)
好的，首先，你工作的方式最终会导致问题。
您要寻找的原则是每个项目都应该有一个与任何其他项目无关的主干/分支/标签结构。检查trunk会自动获取所有代码，包括依赖项，这足以构建您的项目。
你显然不是那种立场，转而采取行动需要付出一些努力。但是，有一种解决方法可以让您根据需要使用外部设备。
svn：externals属性的示例可能是：
http://mysvn/svn/foo/bar/project1 foo/bar/project1
http://mysvn/svn/bar/foo/project2 bar/foo/project2
虽然最好使用红皮书中详述的相对参考文献。
答案 8 :(得分：-1)
不确定为什么要做你要问的事。大多数人只是创建一个工作的本地副本，并在他们想要的任何目录上工作。这是因为Subversion的工作方式。它不会锁定源代码。我使用SourceSafe启动了源代码控制，所以我对你正在经历的内容有了一些了解。
您可能想要的是使用svn：externals属性。这里有几篇帖子谈论这个。这是其中之一：