Re: Update problem: Tree conflicts vs content conflicts

Erik Huelsmann <ehuels@gmail.com> writes:

> # break history here
> $ svn rm a
> $ echo you >a
> $ svn add a
> $ svn up
> $ svn st
> # shows R a
> $ cat a
> # shows
>>you
>>mine
>
> As you can see, svn merged the changes into 'a' without so much as a
> warning. I think this sholud be a conflict though: the file being
> changed is not related anymore to the file which was originally
> modified on the other branch. The update operation should have
> resulted in a 'C'onflict.

There is a similar problem if 'a' is not replaced but simply schedule
'D': update causes the working file to get restored, although the
schedule 'D' remains.

There is yet another problem is 'a' is schedule 'R' and the update
deletes rather than modifies: update causes the schedule 'R' file to
become unversioned.

Is a 'C'onflict correct? An alternative would be that the text-base
of the deleted file gets updated but that the scheduling and the
working file should not be touched. If the update deletes the file,
then the schedule replace could become a schedule add, if the update
replaces the file then a 'C'onflict is probably necessary.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org