[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Feature request: Easy tree conflick resolve mechanism

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 13 Apr 2012 16:37:33 +0200

> -----Original Message-----
> From: Sune Fischer [mailto:suneprogrammer_at_gmail.com]
> Sent: vrijdag 13 april 2012 10:27
> To: users_at_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
Received on 2012-04-13 16:38:16 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.