[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-dev
Subject:    Re: Bad interaction between merge and revert
From:       Daniel Egger <degger () fhm ! edu>
Date:       2004-07-31 17:10:53
Message-ID: 948895C6-E314-11D8-AF8D-000A958E35DC () fhm ! edu
[Download RAW message or body]


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

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!

Servus,
       Daniel

["PGP.sig" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]