Question

我一般都是源代码控制的新手，我想知道如何处理以下场景：

假设我有一个为一个平台编写的应用程序，在.NET中说Windows Forms，我使用Subversion（或我认为的任何SCM软件开发了它。）

现在，我想更新应用程序以使用WPF，并可能添加一些其他增强功能。我是否会继续在这个WPF版本2.0的树的分支中继续开发？

可能会有一些文件保持相同，包含业务逻辑，数据访问等等，但实际上我想要启动一个全新的解决方案，并且可能只是从版本1.0借用一些东西

什么是最佳做法？使用自己的树/分支/标记文件夹创建一个新的应用程序文件夹，或者尝试将新版本保留为原始1.0应用程序文件夹的一部分？

你是怎么做到的？

或者在一个不太激烈的案例中，例如将应用程序从Silverlight 2升级到Silverlight 3？那么呢？

我很感激那些经历过此事的人的指导。

Answer 1

我以这种方式构建我的项目：

/branches (different working sets)
/tags     (revisions, etc)
/trunk    (current production state)
  /lib      (3rd party libraries and dependencies)
  /tools    (build tools)
  /src
    /component-a
    /component-b
    /component-c

因为subversion只跟踪每次提交的增量，所以没有服务器端惩罚来分支trunk下的所有内容。唯一的考虑因素是您要使用的本地计算机上有多少磁盘空间。

当你推出代码时，在标签下“标记”它。当您需要剥离实验代码时，请创建一个分支。

编辑：就在不同操作系统或运行时环境之间共享库相关的挑战而言，它实际上取决于项目和组件的大小。在某些情况下，将“核心”逻辑拆分为自己的项目是有意义的，并将“版本化”编译库导出到（可能）许多消费者。这种方法只有在核心逻辑稳定且不经常版本时才能正常工作。

Answer 2

关于版本控制通常有几种思想流派，但我经常遇到的那个对我有意义的是：

您在主分支上执行所有推动项目前进的开发，即CVS中的HEAD和subversion中的“trunk”。这个接收所有更改，如您描述的更改，包括更改GUI库，更新第三方工具等等。该分支的提示应始终反映最新且有希望的最佳版本的软件，但它永远不会被视为发布的光。
对于每个版本，您都要创建一个发布分支。所有与发布相关的工作和仅发布都在此特定分支上进行。这些应该主要是错误修复。您可能在此分支上进行的更改可能会合并回主分支，但如果从主分支到发布分支有任何更改，我不会期望很多。主分支是移动目标，而释放分支不是。

Answer 3

根据您对@Timo Geusch的评论，似乎您的问题不仅仅是处理已发布软件的版本，而是更多地选择任意数字。重新排列代码与版本控制几乎没有关系，更多的是关于如何设置.NET解决方案（即代码架构）。让我们看看下面的例子，名字很简单：

MySolution
    /MyWinFormsProject

在这个例子中，我们有一个名为MySolution的解决方案。它是一个名为MyWinFormsProject的WinForms项目。当我们想要从一个WinForms项目切换到一个WPF项目时，它会有问题，因为你在Winforms应用程序中拥有的大多数代码都需要重写。如果你有10000多行代码，这将是一项令人痛苦的任务。

如果你处于这种情况，你真的应该通过删除公共代码并将其放在另一个项目（最好是Class Library）中来启动重构，我们可以将其称为MyCommonCode。请记住，您需要在MyCommonCode中引用MyWinFormsProject。

MySolution
    /MyWinFormsProject
    /MyCommonCode

完成后提交，修订号将会提升。如果你以后搞砸了，你可以恢复原状。接下来创建一个名为MyWPFProject的WPF项目。如果你想从那个开始，你只需要将MyWPFProject设置为启动项目。

MySolution
    /MyWinFormsProject
    /MyCommonCode
    /MyWPFProject

当你完成后，再次提交。在完成WPF之前，无需删除WinForms项目。

注意：如何准确区分和命名projects and namespaces取决于您，虽然查看一些open souce projects将有助于您获得灵感。

Answer 4

你tag目前在存储库的头部是“1.0版”/等。

如何在Subversion中处理新版本的.NET应用程序？

4 个答案: