Question

下午好，

我遇到“冲突树”的问题，其中的情况如下： - 该网站警告说，要解决此问题应升级到服务器1.6和1.6客户端，但我做了升级，但它只告诉，但不正确纠正。

问题：

用户A收到projeto.c并在提交版本为30后提交文件。
用户B在提交前进行了结账，并且在文件projeto.c的第29版中，他将文件移动到另一个名为“main”的文件夹并执行提交。
提交用户B的结果：

当执行提交是不可检测的冲突并警告该版本已过时，所以他做了更新并且已经证明冲突是在所谓的“三冲突”之后他要求解决并坚持提交到版本32而不是31.检测到版本31它删除了正确的文件用户文件并添加了旧用户B. 32它只显示提交并再次删除。

最终结果：文件projeto.c位于版本29的“main”中。

如何妥善解决这种情况？如何在用户自动执行提交之前执行更新？

THX

等待回应

Answer 1

如果我理解正确的话：

user1> svn co file:///var/svn/repo
Checked out revision 29.
....
user2> svn co file:///var/svn/repo
Checked out revision 29.
....
user1> svn mv foo ./dir/
A         dir/foo
D         foo
user1> echo 'some more work' >> dir/foo
...
user2> svn rm foo
D         foo
user2> svn ci -m'we don not need foo anymore'
Deleting       foo
Committed revision 30.
...
user1> svn ci -m'refactoring of foo has worked'
Adding         dir/foo
Deleting       foo
svn: Commit failed (details follow):
svn: '/foo' is out of date
user1> svn up
   C foo
At revision 30.
Summary of conflicts:
  Tree conflicts: 1
user1> svn stat
!     C foo
      >   local delete, incoming delete upon update
A  +    dir/foo

现在，user1＆amp; user2去喝一杯咖啡，然后决定实际做什么。如果他们决定foo应该留下来，应该发生什么（但我真的不知道这里出了什么问题）：

user1> svn resolve --accept=working foo
Resolved conflicted state of 'foo'
user1> svn stat
A  +    dir/foo
user1> svn ci -m'Shiny & glorious reintroduction of foo, all brand new, but with a history'
Adding         dir/foo
Transmitting file data .
Committed revision 31.
....
user2> svn up
A    dir/foo
Updated to revision 5.
user2> svn log dir/foo    
user2> tail --lines=1 dir/foo 
some more work

所以一切都应该没问题。问题是：在问题的情景中出了什么问题？我怀疑有人想到了一个命运多mer的合并。

至于第二部分：

“如何在用户自动执行提交之前执行更新？”

不要自动执行任何操作，应由项目开发人员定期更新自己的结帐。自动化它只会让事情变得更糟。他们应该能够处理这些类型的冲突。根据需要解决它们。

Subversion中的冲突解决方案

1 个答案: