Sql server 使用版本控制(*.sqlproj)正确管理SSDT项目文件

Sql server 使用版本控制(*.sqlproj)正确管理SSDT项目文件,sql-server,visual-studio-2012,sql-server-data-tools,sqlproj,Sql Server,Visual Studio 2012,Sql Server Data Tools,Sqlproj,我们经常遇到项目XML文件*.sqlproj的问题。如果文件是在某个位置添加/重新保存/更改的,则会自动在某些意外位置添加/删除记录。之后,当有人更改该文件时,我们合并它会遇到很大的麻烦 我们得出的结论是,我们可以在签入前对其进行排序。我们将按字母顺序排序,在这种情况下,合并工具将更好地理解它 因此,我的问题是: 是否可以在每次签入之前以某种方式重新安排sqlproj文件?也许有一些选项/工具已经在这样做了? 有没有其他方法让开发人员的生活更轻松? 更新: 我又一次遇到了同样的问题。sqlpro

我们经常遇到项目XML文件*.sqlproj的问题。如果文件是在某个位置添加/重新保存/更改的,则会自动在某些意外位置添加/删除记录。之后,当有人更改该文件时,我们合并它会遇到很大的麻烦

我们得出的结论是,我们可以在签入前对其进行排序。我们将按字母顺序排序,在这种情况下,合并工具将更好地理解它

因此,我的问题是:

是否可以在每次签入之前以某种方式重新安排sqlproj文件?也许有一些选项/工具已经在这样做了? 有没有其他方法让开发人员的生活更轻松? 更新:

我又一次遇到了同样的问题。sqlproj文件被修改了3次,我只想合并到生产中最后一次更改,其他2次还没有测试。在合并工具中,我可以选择添加所有这3个新对象,或者不做任何更改。我无法仅选择最后一次更改

例如:

developerA创建了tableA并签入; developerB获得了dev分支的最新版本,创建了tableB并签入; developerC获得了devbranch的最新版本,创建了tableC并签入。DeveloperC测试了代码并准备投入生产。他试图将自己的代码合并到QA中,并得到冲突,在冲突中他只能选择进行所有更改。
1-您正在使用什么源代码管理?据我所知,没有任何源代码管理能够理解sqlproj文件的上下文,但这通常不是问题

2.a-这不应该是你经常遇到的问题,你是否定期入住/退房?我只希望看到不同的开发人员对项目进行大规模更改,并且在前后不签出/签入时出现问题

2.b-也有可能您没有正确合并,如果您同时进行两组更改,则正常情况下没有问题


ed

我非常理解您遇到的情况。当您在单个存储库的上下文中有多个工作流,并且您没有一个通用的升级计划时,通常会发生这种情况,因为所有工作都将同时转到QA,同时转到PROD

我有几种方法可以解决这个问题,每种方法都有利弊

锁定每个环境,直到所有内容都可以一起升级。在大多数情况下都不现实

当您准备好升级时,从源环境创建一个升级分支,并从升级分支中取出不准备升级到目标环境的内容。这使得开发人员能够继续工作,并且能够在不冻结的情况下进行升级

混合方法。。。在Dev准备好升级到测试之前,不要对其进行任何源代码控制。然后从那里开始执行选项1或2

创建一个更灵活的生态系统,该生态系统可以为每个功能分支构建一个环境,以便与其他功能分支进行演示/测试,或者至少在开发人员之间分配/轮换足够的资源,以实现相同的目标。一旦它被接受,就升级。这正是我们目前正在努力的方向,但当你拥有大量相互连接的数据库和应用程序共享它们时,构建基础设施和流程有点挑战性,至少在微软的世界里是这样


无论如何,我希望这有助于

1个TFS;2a经常检查,或多或少定期检查,没有大的变化;2b试图仅合并我的变更秀您正在修复冲突吗?包括来自冲突两半的更改?冲突窗口,在左侧和右侧打勾-我经常这样做,从来没有遇到过任何问题将事情放在错误的位置问题发生在我们处理几个问题时。假设我已经添加了对象,但尚未完成。之后,我切换到另一个任务,并添加了1个文件。已完成任务2并希望上线,但在proj文件中,我仍然有来自第一个任务的条目。这是一个小示例,但合并此文件时会遇到很多问题:好的,我会做两件事,您可以开始为tfs的每项工作创建分支,或者一次签入一个图片,如果task1未完成,请回滚,搁置它或只是获得另一个工作区-签入任务2,然后返回任务1,完成它,然后签入-将这样的东西混合在一起,你会发现合并更难,而且你有部署太多/太少的风险-是的,git和分支很漂亮,但是对于项目中的每一个更改,都很难在本地复制项目。使用GIT很容易,但是我们在当前的工作环境中使用TFS。