Feature request: Easy tree conflick resolve mechanism

[Sune Fischer <su...@gmail.com>]

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!
I assume there are some valid reasons for this, but how do you go about 
solving tree conflicts efficiently then?

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

Regards, Sune

Re: Feature request: Easy tree conflick resolve mechanism

[Stefan Sperling <st...@elego.de>]

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.

RE: Feature request: Easy tree conflick resolve mechanism

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: Sune Fischer [mailto:suneprogrammer@gmail.com]
> Sent: vrijdag 13 april 2012 10:27
> To: users@subversion.apache.org
> Subject: Feature request: Easy tree conflick resolve mechanism
> 
> 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!
> I assume there are some valid reasons for this, but how do you go about
> solving tree conflicts efficiently then?
> 
> 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..

svn revert -R <folder>
will have the same result as you had in 1.6 when you removed the folder and
then performed the update.

The data that got missing in 1.6 when you got the tree conflict is now
already stored in the pristine store so the update is no longer necessary,
but it doesn't hurt to update anyway.

In 1.6 you should have resolved the tree conflict in the same way, but the
recovering process from missing data was about the same thing.

In 1.7 we can usually also recover from the missing conflicted data, so you
get the conflicted data back.

	Bert