SVN合并和树冲突“本地添加,合并时传入添加”

2019年8月5日 245次阅读

我正在尝试遵循
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html中描述的发布分支模型,但在尝试进行合并时,我得到了合并冲突.

# Normal SVN Structure
svn-testing2> ls -l
total 12K
drwxrwxr-x 3 xxx yyy 4.0K Jan 13 17:28 branches/
drwxrwxr-x 3 xxx yyy 4.0K Jan 13 17:28 tags/
drwxrwxr-x 3 xxx yyy 4.0K Jan 13 17:28 trunk/

# Create & commit some  data
svn-testing2> echo "line1" > trunk/file1; svn add trunk/file1; svn commit -m "created file1 " trunk/file1
Adding         trunk/file1
Transmitting file data .
Committed revision 2.

# Create the release branch
svn-testing2> svn copy trunk branches/release
A         branches/release
svn-testing2> svn commit -m "created release branch" branches/release
Adding         branches/release
Adding         branches/release/file1

Committed revision 3.

# Make & commit a change to trunk
svn-testing2> echo "line1-file2" > trunk/file2; svn add trunk/file2; svn commit -m "created file2" trunk/file2
A         trunk/file2
Adding         trunk/file2
Transmitting file data .
Committed revision 4.

# Attempt to merge the change to trunk:
svn-testing2> cd branches/release/
svn-testing2/branches/release> svn merge ^/trunk
--- Merging r2 through r4 into '.':
   C file1
A    file2
Summary of conflicts:
  Tree conflicts: 1
bumjvr@mbs-p:~/svn-testing/svn-testing2/branches/release> svn st
 M      .
      C file1
      >   local add, incoming add upon merge
A  +    file2

我可以解决这个问题

svn-testing2> svn resolve --accept=working *

但我必须做到这一点似乎是错误的.

如果我然后将“修补程序”(例如创建“release / file3”)应用到我的发布分支,我该如何将其移植回主干？如果我将“release”合并到“trunk”中它合并OK,但是当将“trunk”合并回“release”时,我得到另一个本地add,在合并冲突时传入add. “文件3”

我不是试图“重新集成”一个功能分支,因为它们都是长时间运行的分支.

令人沮丧的是,SVN红皮书(通常非常出色)描述了这种常见的分支模式,没有实际运行命令的实例！

如果没有所有这些不正确的合并冲突,我到底需要运行什么来遵循这种分支模式？或者在任何地方都有这种分支模式的工作示例 – 我找不到任何！

最佳答案 这是因为您的复制操作完全在客户端完成.此操作不包括任何合并跟踪信息,因此当您尝试合并时,它会尝试在其自身之上添加file1.复制命令的帮助中的免责声明中描述了此行为：

> svn help copy

copy (cp): Copy files and directories in a working copy or repository.
usage: copy SRC[@REV]... DST

  SRC and DST can each be either a working copy (WC) path or URL:
    WC  -> WC:   copy and schedule for addition (with history)
    WC  -> URL:  immediately commit a copy of WC to URL
    URL -> WC:   check out URL into WC, schedule for addition
    URL -> URL:  complete server-side copy;  used to branch and tag
  All the SRCs must be of the same type. When copying multiple sources,
  they will be added as children of DST, which must be a directory.

  WARNING: For compatibility with previous versions of Subversion,
  copies performed using two working copy paths (WC -> WC) will not
  contact the repository.  As such, they may not, by default, be able
  to propagate merge tracking information from the source of the copy
  to the destination.

如果将副本更改为服务器端副本,则合并将成功：

# This is the difference, the copy happens on the server
> svn copy ^/trunk ^/branches/release2 -m "Creating release2"
Committed revision 5.

# Update our working copy to get the new release
> svn update branches
Updating 'branches':
A    branches\release2
A    branches\release2\file1
A    branches\release2\file2
Updated to revision 5.

> echo blah>trunk\file3; svn add trunk\file3; svn commit -m "created file3"
A         trunk\file3
Adding         trunk\file3
Transmitting file data .
Committed revision 6.

> cd branches\release2
> svn merge ^/trunk
--- Merging r5 through r6 into '.':
A    file3
--- Recording mergeinfo for merge of r5 through r6 into '.':
 U   .
点赞