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

Re: Bad interaction between merge and revert

From: Daniel Egger <degger_at_fhm.edu>
Date: 2004-07-31 19:10:53 CEST

On 31.07.2004, at 16:00, Ben Collins-Sussman wrote:

>> The only way to make this work reliably is to remove the WC and
>> start with a completely fresh checkout

> If you don't do this, then a repeat of the merge will try to re-add the
> files, and abort when an unversioned file of the same name is 'in the
> way'.

That's what I figured. :)

> So the proper algorithm is:

> svn merge
> svn revert -R
> delete unversioned files and dirs
> svn merge (again)

This might be faster than the recheckout but still has the problem
of removing all compilation products, configuration files, etc. that
are not part of the repository and shouldn't be.

NB: I also have symbolic links in the tree which would need to be
recreated in that case since SVN will not support symbolic links until
the upcoming version.

> I admit, this bites people quite often, and has become a FAQ. I wonder
> if it would be nice to add another switch to 'svn revert' that tells it
> to destroy any unversioned files.

I don't think this would be worthwhile, I'd rather like to see the
--force option to merge *really* overwrite the unversioned files instead
of complaining that one should use --force to overwrite unversioned

An alternative would be to remove the distracting message and instead
tag the files that should have been added by the merge but weren't
(for whatever reason) as such so they can be removed by the revert.

Thanks for consideration!


Received on Sat Jul 31 19:11:30 2004

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

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