Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
From: "Bert Huijben" <bert@qqmail.nl>
To: "'Sune Fischer'" <suneprogrammer@gmail.com>,
	<users@subversion.apache.org>
References: <4F87E363.7070809@gmail.com>
In-Reply-To: <4F87E363.7070809@gmail.com>
Subject: RE: Feature request: Easy tree conflick resolve mechanism
Date: Fri, 13 Apr 2012 16:37:33 +0200
Message-ID: <007801cd1982$f7672f70$e6358e50$@qqmail.nl>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQJmUks136aHsk8OmipaO3gPGzkJ3ZVmYAuQ
Content-Language: 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