tags:

views:

51

answers:

1

Good afternoon,

I have a problem with the "Conflict Tree" where the situation is as follows: - The site warned that to solve this problem should upgrade to server 1.6 and 1.6 client but I did the upgrades but it only tells, but does not correct properly.

Problem:

  • User A received a projeto.c and commit the file after the commit version was 30.
  • User B made a checkout before commit and was in version 29 of file projeto.c where he moved the file to another folder called "main" and performed the commit.

  • Results of the commit user B:

When performing commit was undectable conflict and warned that the version is out of date, so he made an update and has been shown that the conflict was in the so-called "three Conflict" after he asked to solve and held going to commit to version 32 and not 31. was detected that the version 31 it removed the right file the user file and added the old user B. the 32 it only shows the commit and delete again.

End result: The file projeto.c was in the "main" with version 29.

How to properly resolve this situation? How to perform an update before when the user performs a commit automatically?

thx

Await response

A: 

If I understand this correctly:

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

Now, user1 & user2 go to drink a cup of coffee with each other, and decide what actually to do. If they decide foo should stay, what should have happened (but I don't really get what went wrong here):

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

So everything should be OK. Question is: what went wrong / didn't work in the scenario from the question? I suspect someone thought up an ill-fated merge.

As for the second part:

"How to perform an update before when the user performs a commit automatically?"

Don't do anything automatically, it should be up to the developers on the project to regularly update their own checkout. Automating it could only make things worse. They should be able to handle these kinds of conflicts & resolve them as required.

Wrikken