问题标签 [version-control]

有很多关于如何设置 dotnet 项目的示例，但似乎没有一个适合我们的情况。

我们有一个具有多个应用程序、多个依赖项的解决方案。我们目前在 SourceSafe 上，并计划转向颠覆，但发现很难以正确的方式组织我们的源。

• 示例解决方案

  • 应用程序1
  • 应用程序2
  • 商务对象
  • 数据访问
  • 自定义控件

• 依赖项

  • BizObjects->数据访问
  • App1->自定义控件
  • App1->BizObjects
  • App1->数据访问
  • App2->自定义控件
  • App2->BizObjects

我们还有一个配置管理系统，它根据操作员的工作负载进行部署（通过数据库中的副本）。我们用一个版本标记一个应用程序“发布”，并为该发布添加多个文件依赖项。请记住，我们现在采用的解决方案是尝试将旧的（Windows 3.1 开发的）解决方案与 .NET 文件/依赖结构一起使用。

对于 App1，我们有 App1.exe、BizObjects.dll、DataAccess.dll 和 CustomControls.dll。由于 BizObjects 引用 DataAccess，我们对 App2 具有相同的依赖项集——但这是手动定义的。我们没有一个系统来识别依赖树。

“发布”的每个依赖项都是一个文件和版本 ID。对于不同的工作负载，同一个应用程序可能包含每个文件的不同版本。

1. 我们到底哪里错了？我们做错了吗？
2. 我们如何构建一个 svn 源代码树来适应部署需求？
   • 或者
3. 我们如何重构代码以更好地支持对我们的设置有意义的部署策略？

对于（看起来）一个相对简单的问题，我们有一个旧的和过度设计的解决方案。谁能引导我/我们朝着正确的方向前进？

编辑：我读了这个问题并记得我们也有相同的开发/测试/产品区域，代码必须通过这些区域。

我问了几个同事关于AnkhSVN的问题，他们都不满意。其中一位甚至说 AnkhSVN 已经多次搞砸了他的 devenv。

您对 AnkhSVN 的体验如何？我真的很怀念拥有 IDE 集成源代码控制工具。

作为源代码控制的初学者，最好的版本控制系统是什么？

我目前使用 AnkhSVN 将 subversion 集成到 Visual Studio 中。我有什么理由应该切换到 VisualSVN 吗？

AnkhSVN 是免费的（不止一种意义上的），而 VisualSVN 的价格为 50 美元。所以就在那里，除非我错过了 VisualSVN 的一些很棒的功能，否则我看不到任何切换的理由。

您的工作环境是否使用 Harvest SCM？我现在在两个不同的地方使用过它，发现它令人震惊。在一种情况下，我编写了一个转换脚本，这样我就可以在本地使用 CVS，然后在我睡觉时每天将更改导入 Harvest 系统。尽管 80% 的程序员都在为不同的东西哭泣，但该公司仍然热衷于使用 Harvest。它不必要地复杂、缓慢和沉重。现在我的工作要求是在我工作的地方不使用 Harvest。

有人用过Harvest吗？你有什么经验？跟我一样差？您是否采用了其他不同的解决方法？为什么今天仍然购买此产品？

我们的开发商店目前使用 Visual SourceSafe。我们都知道这会如何结束（很糟糕），所以我们正在调查其他系统。首先是 Perforce。有没有人有使用它并将其集成到 Visual Studio (2003/2005/2008) 的经验？它是否和其他任何产品一样好，或者相对而言它是否具有良好的功能？

我想听听使用分布式版本控制（又名分布式修订控制、分散式版本控制）的人以及他们是如何找到它的。你在用什么，Mercurial、Darcs、Git、Bazaar？你还在用吗？如果您过去使用过客户端/服务器 rcs，您会发现它更好、更差还是不同？你能告诉我什么能让我赶上潮流？或者就此而言，我很想听听有负面经历的人的意见。

我目前正在考虑更换我们当前的源代码控制系统（Subversion），这是这个问题的推动力。

我会对任何与其他国家的同事一起使用它的人特别感兴趣，因为您的机器可能不会同时打开，而且您的连接速度非常慢。

如果你不确定什么是分布式版本控制，这里有几篇文章：

分布式版本控制简介

维基百科条目

所以你知道很多 Mac 应用程序都使用“捆绑包”：它看起来像你的应用程序的单个文件，但它实际上是一个包含许多文件的文件夹。

对于一个版本控制系统来处理这个问题，它需要：

• 签出目录中的所有文件，以便应用程序可以根据需要修改它们
• 在办理登机手续时，
  • 提交已修改的文件
  • 添加应用程序创建的新文件
  • 标记为不再存在的已删除文件（因为应用程序删除了它们）
  • 将此作为一项原子更改进行管理

关于使用现有版本控制系统处理此问题的最佳方法的任何想法？是否有任何版本控制系统更擅长该领域？

我最近在工作中讨论了从 Subversion 切换到像 bazaar 这样的 DVCS，我想征求其他人的意见。

我已经设法将我不愿这样做的态度具体化为一个简单的平行线。

版本控制可以用得好也可以用得不好。

版本控制的“轻松的一面”是当您使用它来跟踪您的更改时，能够在您破坏内容时返回到旧版本，以及当您发布您的更改以便您的同行可以看到您的工作进行中.

版本控制的“阴暗面”是你没有正确使用它，所以你没有通过定期提交来“检查”你的工作，你在本地结帐中保留了一堆更改，并且你没有分享你的更改与其他人一起制作。

颠覆使光明面和黑暗面都相对困难。所有的基础都有效，但很少有人真正在 Subversion 中使用分支（除了标记和发布），因为合并一点也不简单。Subversion 本身对它的支持很糟糕，还有像 svnmerge 这样的脚本使它变得更好，但仍然不是很好。因此，如今，随着良好的分支和合并支持越来越被认为是协作开发的必要性，Subversion 无法与之匹敌。

另一方面，“黑暗面”也很难追随。您只需不时不时将本地更改提交到在线存储库，并通过您甚至不记得做过的简单编辑来破坏您的代码，您只需要被咬一次。所以你最终会定期提交，人们可以看到你正在做的工作。

所以，最终 Subversion 最终成为了一个很好的中途 VCS，虽然在实施最佳实践方面有点麻烦，但仍然很难把事情弄错。

相比之下，使用 DVCS，无论是完全进入光明面还是黑暗面的成本都要低得多。这些现代 VCS 系统的分支和合并要简单得多。但是分布式方面可以很容易地在您自己的机器上的一组本地分支中工作，为您提供检查点工作所需的细粒度提交，可能无需发布您的更改，以便其他人可以查看、查看和协作。将更改保留在本地分支中而不发布它们的摩擦通常低于在公共服务器上的某个分支中发布它们。

所以简而言之，问题是：如果我给我们工作中的开发人员一个 DVCS，我如何确保他们使用它去“轻松的一面”，仍然定期在中心位置发布他们的更改，并让他们理解他们不想分享的一周本地黑客可能只是其他开发人员在第一个开发人员度假时可以用来完成功能的东西？

如果 DVCS 的光明面和黑暗面都那么容易到达，我该如何让它们远离黑暗面？

在实时网站上维护备份和修订控制的最佳解决方案是什么？

作为我工作的一部分，我与几个实时网站合作。随着时间的推移，我们需要一种有效的方法来维护活动文件夹的备份。此外，更新这些站点可能会很痛苦，特别是如果更改发生在实时环境中，无论出于何种原因。

理想的情况是无忧的源代码控制。我实施了一段时间的 SVN，它作为备份和修订控制（轻松恢复临时或重大更改）等的半解决方案非常棒。

不幸的是，SVN 将 .SVN 隐藏目录放置在任何地方，这会导致问题，尤其是当其他开发人员更改文件夹结构或复制/移动网站目录时。我听说这是教育等问题，但 SVN 采取的方法对我们来说根本不是一个实际的解决方案。

我在想也许增量备份解决方案可能会更好。

其他可能性包括：

1. SVK，这只是命令行，这成为一个问题。此外，我不确定这是否合适。

2. Mercurial，可能带有一些触发器来隐藏分布式组件，这在这种情况下是不需要的，并且对于其他开发人员来说会不必要地复杂化。

   我对 Mercurial 进行了简短的试验，但找不到一个很好的方法来分离存储库并与实时文件夹工作副本保持同步。也许作为一个源代码控制解决方案（使存储库和活动文件夹在同一个地方）与另一个备份解决方案相结合，这可能是要走的路。

   Mercurial 的一个缺点是它不会将空文件夹置于源代码控制之下，这对于经常将空文件夹作为文件上传等占位符位置的网站来说是个问题。

3. Rsync，我还没有真正调查过。

我非常感谢您就维护实时网站备份的最佳方式提出的建议，最好是通过一种简单的方法快速检索过去的版本。

回复回复：

• @基比：

  • 与其说是教育，不如说是对 VSS 以外的任何东西都不熟悉，而且缺乏时间/精力来学习其他任何东西。

  • 我想 xcopy/7-zip 方法听起来很合理，但它很快就会占用很多空间，对吧？

  • 至于源代码控制，我想我希望源代码控制只是说“这是文件夹现在的状态，我会处理它，如果我不能匹配东西那是你的错，我”只会开始新的历史”，而不是努力失败。

• @史蒂夫米：

  • 是的，这是一种更好的方式，但需要进行重大的文化变革。话虽如此，我非常喜欢这种方法。

• @mk：

  • 不错，我没想过用 Rsync 来部署。这只会上传差异吗？由于站点停机，每次我们进行更改时覆盖整个实时目录都会有问题。

我仍然很好奇是否有更传统的选择