Era*_*dan 3 svn version-control starteam configuration-management
我想知道如何在SVN中执行以下常见的StarTeam任务
1.如何更新标签以包含仅1个文件的较新版本？
在StarTeam中创建视图标签后(类似于SVN中的标签) - 我能够在该视图标签中包含更新的文件版本 - 例如,更新视图以仅包含该文件(而不包括自该文件以来也发生更改的其他文件)创建该视图标签
2.如何根据另一个标签创建标签？
在发布版本的同时继续开发时,虽然签入了一些功能,但是不会包含一些功能.在StarTeam中,我曾经基于先前的视图创建了一个视图标签(再次像标签一样)(然后执行我描述的内容)问题1).据我所知,在SVN我可以创建一个基于另一个的标签,但它是只读的,我需要一个分支.但我真的不需要分支机构.
3.如何签入/添加现有标签？
在StarTeam中,视图标签位于主干/分支上,因此我可以在创建视图后检入文件并修改标签以包含它,在SVN中我必须检查分支
让我先说我不熟悉StarTeam,所以我可能不完全理解你试图重现的工作流程.
Subversion本身不区分标签和分支.按照惯例,标签只是一个您永远不会修改的分支.即使分支只是一个"svn copy"操作,也没有单独的"分支"功能.分支只是一个廉价的副本,而标记是按惯例只读的分支.svn中的副本非常便宜,所以你不必担心创建分支 - 标签不比分支便宜.您可能想阅读有关创建分支的文档.它进一步解释了一些事情......并且有一个关于"廉价副本"的盒装部分.
根据您在StarTeam中使用"查看标签"的情况,svn externals可能对您的用途有用.我一般不喜欢它们,但这取决于场景.
更直接地回答你的问题......
1)这取决于文件中是否有其他更改.您是否希望在一个文件中对一个修订进行更改？或者1个文件的所有更改(多个修订版,只有1个文件).希望你的意思是前者.在这种情况下,通常的行为是合并
假设您有以下情况:
------------------------------------> /trunk
| | fix merged to 1.0 branch
| v
\------------> /branches/1.0
| ^ |
| \ /tags/1.1 1.1 tag, fix released to customer(s)
\ /tags/1.0 - 1.0 GA tag, release sent to customer(s)
你在干线上发展.在修订版10中,您的产品已准备好发货1.0!您创建一个分支:
svn copy /path/to/trunk /path/to/branches/1.0
然后继续在trunk上进行开发,同时在1.0分支上进行一些额外的验证.准备好发货时,您可以创建一个标签:
svn copy /path/to/branches/1.0 /path/to/tags/1.0
此标记是一个冻结的时间点,与您向客户发送的内容完全匹配.
您发现已在trunk上完成的1.0版本客户所需的错误/功能/更新.在您的情况下,您已声明对特定文件的更改.
假设更改发生在版本15的主干上.然后你会这样做(从一个干净的/branches/1.0工作副本):
svn merge -c 15 /url/to/repo/path/to/trunk
在理想情况下,修订的更改是自包含的,并且需要修订中的所有文件.有时候还有一些你不想合并的东西.在这种情况下,在合并之后,将更改还原到您不想合并的文件,测试所有内容,然后提交.合并有一个缺点 - >恢复一些文件 - >提交工作流,这是subversion将记录合并发生,但你已经排除了它的一部分.如果有问题的分支不太可能进一步改变(或重新集成到另一个分支),这可能无关紧要,但我更喜欢为您想要的1文件中的更改创建补丁文件,并手动将它们应用于分支像那样.我不是100%肯定cmd行语法,但我认为它会非常相似:
svn diff -c 15/path/to/file(在repo或其他工作副本中)> my-patch.diff
并使用其他工具.我通常在GUI中创建/应用补丁,因此具体细节将作为练习留给您.
完成后,再次在分支上创建一个新标记,其中包含新的合并更改.
svn copy /path/to/branches/1.0 /path/to/tags/1.1
然后,您有一个与旧标记相同的新标记,除了对1文件进行更改.在#3中我还会提到你可以重新创建标签(虽然它取决于你使用标签的内容是否是一个好主意).r,但我只会在标签不代表发货代码的情况下执行此操作.
2)实际上,由于按照惯例,标签是只读的,因此来自另一个标签的标签实际上不会有所不同.但是,如果您改为使用第一个分支,然后创建一个标记(如建议的那样),您可以稍后根据同一分支创建第二个标记(在提交其他更改之后),它将与您的第一个不同仅标记从那时起应用于该分支的更改.
3)同样,你通常会使用一个分支.如果分支/标记仅在内部使用(我不建议删除已发布代码的发布标记,虽然它不是真的"丢失",但通常不应该 - ),你可以删除并重新创建标签.您的标签(工作副本)的消费者可以在删除并重新创建标记后执行正常的"svn更新",并且可以继续正常工作,就好像什么也没发生一样.这不能用于#1,但是当你真的想要更新标签时可以用于#2.诀窍是结合标记和分支来实现您想要的.如果您还使用它来部署到网站或其他东西,您可以组合分支,标记和外部.
例如/ path/to/production可以签出,其中包含/tags/1.0的外部条目,当你想要应用修复时,你执行#2中的步骤并创建一个/tags/1.1并调整外部条目.或者,只需将其指向分支,无需重新创建标记.
我希望这是一个半有用的开始.