2015-01-13 42 views
4

我试图按照在http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html描述的版本分支模型,但试图进行合并时,我得到合并冲突。SVN合并和树冲突“本地添加,传入添加合并”

# 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 
[email protected]:~/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 * 

解决这个问题,但似乎错了,我必须这样做。

如果我然后对我的发布分支应用“hotfix”(例如创建“release/file3”),我该如何将它移回到trunk?如果我将“release”合并到“trunk”中,它将合并成OK,但是当将“trunk”合并回“release”时,我会遇到另一个local add, incoming add upon merge冲突。 “file3”

我不想“重新集成”一个功能分支,因为这些都是长时间运行的分支。

令人沮丧的是,SVN红皮书(通常很棒)描述了这种常见的分支模式,没有任何可以运行的命令的实例。

究竟我需要运行遵循这种分支模式,没有所有这些不正确的合并冲突?或者有没有这种分支模式的任何工作的例子 - 我找不到任何!

+0

我想一个你评论关闭。 '试图合并到trunk'的变化应该说'...释放',而不是,对吧? –

回答

2

这是由于您的copy操作完全在客户端完成。此操作不包含任何合并跟踪信息,因此当您尝试合并时,它会尝试在其本身之上添加file1。这种行为在声明中帮助描述为copy命令:

 
> 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. 

如果你改变了copy到服务器端副本,合并会成功:

# 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 . 
+0

ARGH谢谢!我正在阅读svn红皮书,我没有阅读“复制”的帮助。 – Mark