On Fri, Apr 13, 2012 at 10:27:15AM +0200, Sune Fischer wrote:
> Hi,
>
> In the old days the .svn folder was in every folder and resolving a
> tree conflict was as easy as deleting the conflicting folder and
> doing an update. This solved 90% of our issues.
> This is no longer possible as the only the .svn is now at the root
> of the whole project!
Please keep in mind that blowing away .svn meta-data has never been
a supported way of resolving conflicts, or performing any Subversion
operation, for that matter.
> I assume there are some valid reasons for this, but how do you go
> about solving tree conflicts efficiently then?
This depends on the kind of conflict, and the resolution you'd like
to achieve. There is no general recipe that will resolve any tree
conflict. You need to consider each tree conflict on a case-by-case
basis and reason about how to resolve it.
> We typically get a tree conflict if one guy as deleted a file and
> another guy as made changes to the file.
> In the old days, the guy deleting the file could simply remove his
> folder, do an update and the delete the file again.
> This is not possible now, if he deletes the folder and does an
> update subversion won't give him the file back. Svn just keep
> claiming a tree conflict.
>
> What is the best way to resolve this?
> We did try clean-up and resolve etc..
I'm not quite sure I understand your conflict scenario.
So you're saying you get an incoming edit on top of a local delete?
And the desired resolution result is that the file should be deleted?
This sounds too simple to cause confusion about how to resolve the
conflict because this scenario is in fact trivial to resolve:
# The file alpha is locally deleted
$ svn status
D alpha
# An update brings down an edit on top of it
$ svn update
Updating '.':
C alpha
At revision 3.
Summary of conflicts:
Tree conflicts: 1
# Now we have a conflict marked in the working copy
$ svn status
D C alpha
> local delete, incoming edit upon update
Summary of conflicts:
Tree conflicts: 1
# We decide that alpha should be deleted. And it still is deleted...
$ ls
beta epsilon/ gamma/
# ... so the current working copy state is what we want to resolve to
$ svn resolve --accept working alpha
Resolved conflicted state of 'alpha'
$ svn status
D alpha
If the above doesn't match your situation, can you please take the
time to create a transcript that shows your situation, similar to
what I did above? Because minute details matter a lot when discussion
these kinds of things a simple transcript often says a lot more than a
thousand written words attempting to describe the situation. Thanks.
Received on 2012-04-13 12:52:58 CEST