如何使用 Visual Source Safe 2005？
我目前工作的环境仍然有 VSS 2005。我目前没有能力更改为 Subversion、TFS 等。
使用 VSS 2005 时需要注意的主要问题是什么 - 我怎样才能最好地使用它尝试保存我的版本而不破坏我的源代码？ 例如，将其与 Visual Studio 2008 集成更好，还是仅使用 VSS 客户端更好？
I'm currently working in an environment that still has VSS 2005. I currently do not have the power to change to Subversion, TFS, etc.
What are the main gotchas to watch out for with VSS 2005--how can I best use it to try and save my versions and not blow up my source code? For example, is it better to integrate it with Visual Studio 2008, or just use the VSS client?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我上次尝试时（很久以前），Visual Studio 集成在使用 VSS 项目分支时表现不佳。
我只使用VSS客户端。
其他建议：
The last time I tried it (which was a long time ago), Visual Studio integration played badly with using VSS project branches.
I just use the VSS client.
Other recommendations:
不要用 VSS 做任何复杂的事情。 我认为许多从未遇到过 VSS 问题的人只是将其用作文件共享（即文件签入一次并且永远不会修改）——具有讽刺意味的是，使用 VSS 作为普通文件备份实际上会增加灾难性丢失的可能性！
VSS 会让您陷入一堆措辞糟糕的问题中。 每个问题都没有唯一的答案，你必须停下来思考每一个问题。 当与 VSS 断开连接时，系统会不断询问您是否要切换到使用 IIS 上的 VSS，如果您这样做，则如何撤消它并不明显。
不要使用 VSS 插件来获取初始项目或签出项目。 VSS 插件往往会将您的文件放在意想不到的位置，使用 VSS 客户端，它更有可能为您提供反映 VSS 中项目结构的文件夹结构。
不要使用内置功能来分支，不要合并。 创建一个新的 VSS 项目（即新的文件夹集）并签入代码，就像当您需要分支时它是一个全新的东西一样。 如果您需要模拟合并，请使用“无法比较”之类的东西。
不要重命名文件，而是添加新文件，复制粘贴，然后删除。 这会破坏历史链，但会减少麻烦。
确实允许多次签出，但非正式地不要让太多工作在同一代码区域上完成，不要让其他开发人员让他们的版本变得太陈旧，因为那样你就尝试合并旧工作文件夹版本和最新版本以及 VSS 往往会让初级开发人员陷入他们不理解的问题中。
不要进行非常大的签到。 请勿在没有第三方产品的慢速网络连接上使用。
如果您在 Visual Studio 中使用 VSS 插件，请定期使用 VSS 客户端来比较和同步您的工作文件夹，但要逐个文件而不是批量进行。
不要让存储库变得太大。 将存储库拆分为不相关的工作。
不要被登录密码所欺骗。 VSS 并不比文件夹上的 NTFS 权限更安全。
当开发人员离开公司时，要求他们撤消结账。 使用相同的计算机和用户凭据和工作文件夹撤消签出比使用管理员帐户撤消其他人的签出要容易一个数量级。
任何源代码控制系统的所有最佳实践也适用，例如，将二进制文件的连续版本签入为binaryfile.bin，而不是binaryfilev1.bin、binaryfilev2.bin，但请告诉VSS .bin 或您的意思是二进制，否则它会尝试进行文本合并。
Don't do anything complicated with VSS. I think many people who've never had problems with VSS were just using it as file share (i.e. files get checked in once and are never modified)-- ironically using VSS as ordinary file backup actually increases the odds of catastrophic loss!
VSS drowns you in a barrage of poorly worded questions. There is not a single answer to each question, you will have to stop and think about each one. When disconnecting from VSS you'll be constantly asked if you want to switch to using VSS over IIS, if you do so, it will not be obvious how to undo it.
Don't use the VSS plug in to get an initial project or check out a project. The VSS plug in tends to put your files in unexpected places, use the VSS client, which is much more likely to give you a folder structure that mirrors the project structure in VSS.
Don't use build in features to branch, don't merge. Create a new VSS project (i.e. new set of folders) and check in code as if it was a brand new thing when you need to branch. Use something like beyond compare if you need to simulate a merge.
Don't rename files, instead add new, copy paste, then delete. This breaks the history chain but has fewer aggravations
Do allow multiple checkout, but informally don't let too many much work be done on the same area of code, don't let other developers let their version get too stale because then you're trying to merge your old working folder version and the latest version and VSS tends to drown junior developers in questions they don't understand.
Don't do extremely large check ins. Don't use on a slow network connection without 3rd party products.
If you use the VSS plug in in visual studio, do periodically use the VSS client to compare and synchronize your working folder, but do so file by file, not in a batch.
Don't let the repository get too big. Split repositories for unrelated work.
Don't be fooled by the logon password. VSS is no more secure than the NTFS permissions on the folder.
When a developer leaves the company, ask them to undo their checkouts. It is an order of magnitude easier to undo checkouts using the same machine and user credentials and working folder than to use the admin account to undo someone else's check outs.
All best practices for any source control system also apply, e.g. check in successive versions of binaries as binaryfile.bin, not binaryfilev1.bin, binaryfilev2.bin, but do tell VSS that .bin or what have you means binary or it will try to do text merges.
酒精。 很多。
Alcohol. Loads of it.
使用自动作业运行秘密 SVN 存储库，该作业每天晚上检出最新的 VSS 文件并将其检入 SVN。
当 VSS 死掉时（它会）告诉老板我们有第二个存储库可供使用。
Run a stealth SVN repository with an automatic job that checks out latest VSS files every night and checks them into SVN.
When VSS dies (and it will) tell the boss we have a second repository ready to go.
我在尝试将 VSS 与 VS 集成方面只有负面经历，所以我建议不要这样做。 然而，我们当时正在处理 ASP.Net 1.1 项目，该项目没有能够驻留在任何类型的文件夹结构中的任何位置的好功能，而这主要是我们遇到问题的地方 - 尝试同步带有 VSS 存储库的项目结构。
除此之外，我只能建议您不要通过容易掉线的 VPN 连接签入代码。 事实上......我建议根本不要远程检查代码；）如果连接在提交过程中断开，您可以加倍确定数据库是否刚刚损坏。
I've had nothing but negative experiences with trying to integrate VSS with VS, so I would recommend not doing that. However, we were dealing with ASP.Net 1.1 projects at the time, which didn't have the nice feature of being able to live anywhere in any sort of folder structure, and that's mainly where we were running into problems - trying to sync the project structure with the VSS repository.
Other than that, I can only suggest that you don't check in code over a VPN connection that's prone to dropping. In fact... I would suggest never checking in code remotely at all ;) If the connection drops in the middle of a commit, you can double-down on whether the database just corrupted.