On Thu, Aug 22, 2013 at 4:49 PM, Travis Brown <travisb_at_travisbrown.ca> wrote:
> On Thu, Aug 22, 2013 at 04:16:49PM -0500, Les Mikesell claimed:
> <snip>
>>The contents of the file are irrelevant. The point is that it has to
>>either be versioned so svn can delete it knowing that you can get it
>>back, and then delete the containing directory that is really the
>>issue, or you have to delete it yourself. Pick one. If it really is
> <snip>
>
> Why must svn delete the directory in order to create it?
When it creates it, it will create it as a versioned object with
history. What is it supposed to do with that history when it can't
create it because there is already an unversioned instance there?
Svn doesn't pretend that things that just happen to have the same
names are the same object, they actually have to have the same
history.
> Reading this thread it seems to me that the core of the issue is that svn
> switch is not symmetrical when dealing with directories.
I think it would have the same problem with any unversioned object
with the same name as the versioned one that it needs to create.
> Why can svn not, instead, simply interpret an already existing directory
> as not a conflict? Certainly if a versioned file would overwrite an
> unversioned file of the same name then that is a true conflict because
> the content may differ. A directory has nicely compartmentalized units
> of content which can be handled in a smarter way.
No, look at your logs of directory history. They aren't just
containers for whatever happens to be there, the history of adds and
deletes are there. It might be possible to make things work where it
would pretend that it created a directory keeping the history from the
repo but ignoring extraneous content, but its not what I'd expect.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2013-08-23 00:01:03 CEST