如何使用 ODT 仅通过一个标签对数据库和代码进行 "check in" 更改？
How to "check in" changes on both database and code by just one tag using ODT?
我在一个团队工作，在 VS 环境中开发 .NET 代码，在 PL/SQL 中开发 Oracle 数据库。现在我们想使用 Team Foundation Server 作为版本控制，得到 Oracle Developer Tool 的帮助，这样我们就可以将数据库和代码存储在一个地方。我的问题是，是否有可能 "check in" 仅通过一个标签来更改数据库和代码？以便我们将来意识到这些更改与一个错误有关。
如果您使用的是 SQL 服务器，您可以使用内置于 Visual Studio 中的数据库项目功能（又名 SSDT / sqlproj）。
对于 Oracle，有 3rd 方工具可以做类似的事情。最受欢迎的可能是 RedGate 工具。
TFS 将允许您签入任何文件，如果它是一个 Sql 服务器数据库，那么您可以将您的 c# 代码放在一个项目中，将您的 sql 代码放在同一解决方案中的另一个项目中然后将所有代码一起签入真的很简单。
因为 PL/SQL 没有项目类型，你应该将你的模式/代码导出到单独的文件中，你可以将这些文件添加到不同类型的项目中，或者根本不包含它们而只是拥有它们在解决方案中的文件夹下的文件系统上。
在 TFS (VS 2013) 中，待定更改允许您查看解决方案中的更改，即项目中包含的文件，或者在解决方案下的文件系统中发生的所有更改，以便您可以看到所有更改然后通过一次签到让他们签到。
我经常在 visual studio 解决方案下创建额外的文件夹，其中包含无法使用 visual studio 打开的项目，并使用其他工具来管理它们，但使用 visual studio 将它们签入源代码管理，效果非常好。
对于 VS2013 - 要添加的一件事是当您签入时，如果 "Included Changes" 中没有显示更改 - 在 "Excluded Changes" 下有一个按钮 "Detected: XX add(s)" - 如果你进入你可以促进解决方案之外的更改，以便将它们包括在内。
一个简单的事实是，您不能像对待 Java、C# 或其他文件那样对待数据库对象。
原因有很多，我举几个：
文件本地存储在开发者的 PC 上，s/he 所做的更改不会影响其他开发者。同样，开发人员不会受到同事所做更改的影响。在数据库中（通常）情况并非如此，开发人员共享相同的数据库环境，因此提交给数据库的任何更改都会影响其他人。
发布代码更改是使用签入/提交更改等完成的（取决于您使用的源代码控制工具）。此时，开发人员本地目录中的代码被插入到
源代码控制存储库。想要获取最新代码的开发人员需要从源代码控制工具中请求它。在数据库中，更改已经存在并影响其他数据，即使它不存在
签入存储库。
在文件签入期间，源代码控制工具会执行冲突检查，以查看在您修改本地副本期间同一文件是否被其他开发人员修改并签入。又来了
在数据库中没有对此进行检查。如果你改变一个过程
您的本地 PC，同时我修改了相同的程序
从我的本地 PC 编写代码，然后我们覆盖彼此的更改。
代码的构建过程是通过获取标签/latest来完成的
将代码版本复制到一个空目录，然后执行构建-编译。输出是二进制文件，我们在其中复制并替换
现存的。我们不在乎以前是什么。在数据库中我们不能
重新创建数据库，因为我们需要维护数据！还有
部署执行构建中生成的 SQL 个脚本
过程。
执行 SQL 脚本时（使用 DDL、DCL、DML（对于静态
内容）命令）你假设当前的结构
创建脚本时环境与结构匹配。否则，您的脚本可能会失败，因为您正在尝试添加已存在的新列。
将SQL脚本视为代码并手动生成它们会导致语法错误、数据库依赖错误、脚本不
可重复使用，这使开发、维护、
测试那些脚本。此外，这些脚本可能 运行
与您认为的环境不同的环境 运行
上。
有时版本控制库中的脚本与被测试对象的结构不匹配，然后会出错
在生产中发生！
还有很多，但我想你已经明白了。
我发现以下内容有效：
使用强制版本控制系统，对数据库对象强制执行 check-out/check-in 操作。这将确保版本控制存储库与签入的代码匹配，因为它在签入操作中读取对象的元数据，而不是作为手动完成的单独步骤
使用影响分析，将基线作为
比较以确定冲突并确定是否发生变化（何时
比较源代码控制之间的对象结构
存储库和数据库）是一个真正的变化，起源于
源自不同路径的发展或变化，以及
那么应该跳过它，例如不同的分支或紧急情况
修复。
我写的一篇文章已发表here，欢迎阅读
我在一个团队工作，在 VS 环境中开发 .NET 代码，在 PL/SQL 中开发 Oracle 数据库。现在我们想使用 Team Foundation Server 作为版本控制，得到 Oracle Developer Tool 的帮助，这样我们就可以将数据库和代码存储在一个地方。我的问题是，是否有可能 "check in" 仅通过一个标签来更改数据库和代码？以便我们将来意识到这些更改与一个错误有关。
如果您使用的是 SQL 服务器，您可以使用内置于 Visual Studio 中的数据库项目功能（又名 SSDT / sqlproj）。
对于 Oracle，有 3rd 方工具可以做类似的事情。最受欢迎的可能是 RedGate 工具。
TFS 将允许您签入任何文件，如果它是一个 Sql 服务器数据库，那么您可以将您的 c# 代码放在一个项目中，将您的 sql 代码放在同一解决方案中的另一个项目中然后将所有代码一起签入真的很简单。
因为 PL/SQL 没有项目类型，你应该将你的模式/代码导出到单独的文件中，你可以将这些文件添加到不同类型的项目中，或者根本不包含它们而只是拥有它们在解决方案中的文件夹下的文件系统上。
在 TFS (VS 2013) 中，待定更改允许您查看解决方案中的更改，即项目中包含的文件，或者在解决方案下的文件系统中发生的所有更改，以便您可以看到所有更改然后通过一次签到让他们签到。
我经常在 visual studio 解决方案下创建额外的文件夹，其中包含无法使用 visual studio 打开的项目，并使用其他工具来管理它们，但使用 visual studio 将它们签入源代码管理，效果非常好。
对于 VS2013 - 要添加的一件事是当您签入时，如果 "Included Changes" 中没有显示更改 - 在 "Excluded Changes" 下有一个按钮 "Detected: XX add(s)" - 如果你进入你可以促进解决方案之外的更改，以便将它们包括在内。
一个简单的事实是，您不能像对待 Java、C# 或其他文件那样对待数据库对象。
原因有很多，我举几个：
文件本地存储在开发者的 PC 上，s/he 所做的更改不会影响其他开发者。同样，开发人员不会受到同事所做更改的影响。在数据库中（通常）情况并非如此，开发人员共享相同的数据库环境，因此提交给数据库的任何更改都会影响其他人。
发布代码更改是使用签入/提交更改等完成的（取决于您使用的源代码控制工具）。此时，开发人员本地目录中的代码被插入到 源代码控制存储库。想要获取最新代码的开发人员需要从源代码控制工具中请求它。在数据库中，更改已经存在并影响其他数据，即使它不存在 签入存储库。
在文件签入期间，源代码控制工具会执行冲突检查，以查看在您修改本地副本期间同一文件是否被其他开发人员修改并签入。又来了 在数据库中没有对此进行检查。如果你改变一个过程 您的本地 PC，同时我修改了相同的程序 从我的本地 PC 编写代码，然后我们覆盖彼此的更改。
代码的构建过程是通过获取标签/latest来完成的 将代码版本复制到一个空目录，然后执行构建-编译。输出是二进制文件，我们在其中复制并替换 现存的。我们不在乎以前是什么。在数据库中我们不能 重新创建数据库，因为我们需要维护数据！还有 部署执行构建中生成的 SQL 个脚本 过程。
执行 SQL 脚本时（使用 DDL、DCL、DML（对于静态 内容）命令）你假设当前的结构 创建脚本时环境与结构匹配。否则，您的脚本可能会失败，因为您正在尝试添加已存在的新列。
将SQL脚本视为代码并手动生成它们会导致语法错误、数据库依赖错误、脚本不 可重复使用，这使开发、维护、 测试那些脚本。此外，这些脚本可能 运行 与您认为的环境不同的环境 运行 上。
有时版本控制库中的脚本与被测试对象的结构不匹配，然后会出错 在生产中发生！
还有很多，但我想你已经明白了。
我发现以下内容有效：
使用强制版本控制系统，对数据库对象强制执行 check-out/check-in 操作。这将确保版本控制存储库与签入的代码匹配，因为它在签入操作中读取对象的元数据，而不是作为手动完成的单独步骤
使用影响分析，将基线作为 比较以确定冲突并确定是否发生变化（何时 比较源代码控制之间的对象结构 存储库和数据库）是一个真正的变化，起源于 源自不同路径的发展或变化，以及 那么应该跳过它，例如不同的分支或紧急情况 修复。
我写的一篇文章已发表here，欢迎阅读