代码之家 › 专栏 › 技术社区 › devuxer

使所有Visual Studio项目与库保持同步

projects-and-solutions mercurial version-control visual-studio .net

12

devuxer · 技术社区 · 15 年前

我有一个包含项目a、B和C的库。

我有两个解决办法。解决方案1包括项目a的副本,解决方案2包括项目a和B的副本。

当我构建解决方案1时,应该发生以下情况:

当我构建解决方案2时,应该发生以下情况:

我该怎么做?

如果我真的构建了自己的解决方案,我对它的工作原理有一些想法,但我希望您能提供以下任何意见:

可以是一个简单的控制台应用程序,带有用于指定“源解决方案”的命令行开关,例如:
```
c:\Program Files\Library Syncronizer\LibSync.exe /solution:Solution 1
```

<solutions>
  <solution>
    <name>Solution1</name>
    <path>c:\...\Projects\Solution 1</path>
  </solution>
  <solution>
    <name>Solution2</name>
    <path>c:\...\Projects\Solution 2</path>
  </solution>
  <!-- more solutions -->
</solutions>

程序将执行以下操作:
- 确定它有哪些库项目
- 将这些项目的文件夹复制到库中
- 循环遍历XML文件中的每个解决方案(源除外)
- 根据需要复制所有库项目的文件夹

这声音概念上相对简单,但这可能会产生我没有想到的严重意外后果。如果真的发生了,希望有人会警告我:)

更新-我复制项目文件夹的动机是什么?

在word版本控制中。

如果我将库项目保存在单独的文件夹中,并且仅在各种解决方案中链接到它们(而不是在解决方案文件夹中实际定位文件夹),则版本控制存储库最终不会包含库项目的源代码。因此,如果我更新到“三个版本之前”,并且我需要对我的一个库方法做一个小的更改,那么代码就不存在了。

如果我使用的是副本,那么所有的解决方案都会在它们的存储库中包含库源代码,我可以在任何需要的时候轻松地返回。

我应该在这里注意到,我一直在使用Ortoise HG(Mercurial)进行版本控制。

无论如何,我对这个问题的任何解决办法都持开放态度。它不需要复制项目文件夹——这是我唯一能想到的确保我的所有版本控制存储库都是完整的、独立的软件包的方法。

更新2

根据到目前为止的回复,我决定放弃“双向复制”的想法,转而参考我的图书馆项目。这是一个新的图表:

然而,我仍然有同样的目标:

每个解决方案的最新版本都使用最新的库代码
每个存储库一个解决方案/应用程序
每个存储库包含 全部的 源代码,包括库项目

目标#1是通过引用库项目而不是使用副本自动完成的,目标#2只是我如何设置存储库的问题,但目标#3和#4仍然难以实现。

subrepositories feature

目前,我认为一个好的解决办法可能是只存储 “我的解决方案”文件夹中的库项目的。当我说“备份副本”时,我的意思是字面意思。我仍然会引用库项目——这些副本的唯一目的是确保所有源代码都在我的存储库中(目标#3)。为了满足目标4,这些备份可以在studio中使用后期构建事件进行自动化。

5 回复 | 直到 6 年前

1

2

Vadim Kotov First Zero 7 年前

这听起来就像 sub repository support 在mercurial中是为。如果项目A和项目B等是独立的存储库,您可以在解决方案1和2中使它们成为子回购 .hgsub 1和2中的文件都有自己的版本,并指向A、B和C中的特定版本,因此您可以在每个解决方案中始终使用相同的版本进行构建,但不需要将它们保持在锁定状态。将更改从解决方案移回库变得很容易,如果需要,可以进行分支。

2

3

devuxer 15 年前

考虑为什么应用程序需要使用不同版本的库。如果您正确地设计了库,并确保在升级库时不会破坏任何东西(使用连续集成和单元测试,以及测试所有相关项目),那么在大多数情况下,最好(最简单、最干净)的方法就是让所有应用程序运行在相同版本的库上。我甚至想说,如果您的应用程序不能运行相同的库版本,这说明您的库没有得到正确的设计/实现/维护,您应该重新考虑您的方法。

我建议将库项目移动到库中。您的图表显示了应用程序解决方案构建库代码并将其向上推到库中,然后将构建的库文件向下吸回到项目中-双向复制,eek!只需将库项目放在库中并构建库,然后从您的项目中引用该库-一个单向副本。您可能认为这意味着您必须构建两个解决方案(库,然后是应用程序),但实际上您可以随时在应用程序解决方案中添加/删除库项目,因此此布局不需要两阶段构建过程。但库和应用程序之间的逻辑区别要清晰得多。

3

Mark Booth 15 年前

我的解决方案。

我们使用克隆的组合和

我们所做的是为我们的每个库建立一个核心存储库,其中包含该库的主线分支。创建新应用程序时,我们将所有相关库(每个库使用一个mercurial repo,其中一个库可能包含库及其测试应用程序)克隆到新应用程序旁边的目录中,并引用该应用程序中的库。

每当我们接触一个应用程序时,我们可以选择是继续使用旧库,还是更新到库的最新主线版本(甚至是另一个项目开发版本)。库更改并不是推送到每一个使用它们的应用程序上(有些可能是多年没有接触过的遗留应用程序,并且与它们所使用的库配合良好),它们是由在给定版本的库中需要新功能的应用程序引入的。

我为什么要这样做?

我在这里试图避免的问题是我在以前的公司经常遇到的问题。

我会让我的应用程序与给定的库一起工作。其他人会为他们的应用程序更改库,这样它就可以满足他们的需要,下次我去编辑我的项目时,它就不会编译了。然后,我将不得不花时间按照库现在想要的方式修复我的项目,或者花时间恢复对库所做的不适当的更改(然后将级联回其他开发人员)。

使用本地项目克隆,每个应用程序都可以在更新到更新的库版本时进行选择,从机会管理的角度来看,我们可以在库被合并回主线之前,检查由于应用程序需求而对库所做的更改。

针对这些难以实现的目标的具体解决方案。

3.每个存储库包含所有源代码,包括库项目

通过将库克隆到靠近应用程序的目录中,您可以获得一组存储库,这些存储库可以一起管理,并可能最终很好地转换为“应用程序”超级repo的子repo。

我使用存储在应用程序目录中的一堆批处理文件来实现这一点。

例如,给定的应用程序“_projects.bat”可能包含:

@echo off
@shift
set APPDIR=%CD%
cd ..\Library1
%0 %1 %2 %3 %4 %5 %6 %7 %8 %9

cd ..\Library2
%0 %1 %2 %3 %4 %5 %6 %7 %8 %9

cd ..\Library3
%0 %1 %2 %3 %4 %5 %6 %7 %8 %9

cd %APPDIR%
%0 %1 %2 %3 %4 %5 %6 %7 %8 %9

pause

然后,我有批处理文件来执行有用的同步操作,比如检查将使用“\uuu incoming.bat:

@echo off
call _projects hg incoming

并检查用“\uuuu outgoing.bat”推送的内容:

@echo off
call _projects hg outgoing

或者实际使用“uuu push.bat”执行这些操作:

@echo off
call _projects hg push

和“uuu pull.bat”:

@echo off
call _projects hg pull

当“_update.bat”将所有内容更新为最新版本时(在同一分支内,您仍然需要在当前分支外显式更新):

@echo off
call _projects hg update

我最喜欢的一个是“_id.bat”,它显示了当前正在使用的变更集(和分支)以及它们是否有未完成的未注释变更:

@echo off
call _projects hg id

每当我开始进行应用程序更新时,我都会检查是否有更新的库,下拉所有适当的内容,更新到我想要的版本,然后继续开发。

未来的选择。

最终,我希望通过使用子repos(因此整个应用程序及其所有库的状态都记录在一个应用程序变更集中)来完全自动化这个工作流,但是尽管它在Mercurial中变得非常稳定,但TortoiseHG集成似乎并不是一个优先事项。上次尝试时,我无法让THG提交工具做任何有用的事情(大约0.8.3)。我真的应该用0.9.3重新测试,但我不记得在变更日志中看到过任何关于次级回购的注释,所以除非人们告诉我已经悄悄添加了次级回购支持,否则就不值得了。

事实上,批处理文件工作得很好。我的待办事项列表上的下一件事是一个“\uuu clone.bat”,这将使克隆应用程序及其所有库变得更加容易,但我还没有时间让它正常工作。

做记号

4

0

devuxer 15 年前

我不确定我是否理解你“图书馆”的目的?

为什么这两个解决方案实际上没有引用同一个项目而不是一个副本?

如果目的是能够在“库”的不同分支上工作,那么您所描述的是由SVN之类的源代码控制软件处理的事情。

5

0

Vasyl Boroviak 15 年前

对不起,我没有读完这一页的全文。但是简单的回答是: VisualStudio可以实现所有必要的自动化 .

我们有相似的结构。解决方案1、解决方案2和包含多个项目的公共库。我们在SVN下的文件夹结构如下:

\myRepository
            \Solution1
            \Solution2
            \CommonLibrary\
                          \Project1
                          \Project2
                          \Project3

禁止复制 在这里两种解决方案都只是参考了 ..\CommonLibrary\ProjectX

PS:再看看这个软件 http://svnnotifier.tigris.org/ 它可以自动(通过计时器)或通过鼠标单击更新任意数量的存储库本地副本。