On Fri, Aug 23, 2013 at 1:09 PM, Edwin Castro <0ptikGhost_at_gmx.us> wrote:
>> I can't, off the top of my head, think of a scenario where it would be
>> harmful to replace an unversioned directory with a versioned instance,
>> leaving any unversioned local files that happen to be there alone.
> Leaving unversioned local files alone in a directory is not the problem.
I think it is the problem we've been discussing. Leaving them means
you have to keep the containing directory, which becomes unversioned
as you switch away from the branch having it, and then a conflict when
you switch back.
> I've personally ran into scenarios where the local directory contained
> unversioned local files that obstruct a file that will be added by a
Don't think that's the case here. These files are supposed to be
svn-ignored, so they should not have a copy in the repo.
> If the local file's content matches
> the content in the repository, then I think it is safe to simply replace
> the unversioned local file with the versioned file from the repository.
Yes, that would be handy - and harmless - as well.
> Often, the content has not been the same. It all depends on a lot of
> factors such as how it became unversioned, what has happened to the file
> while it was unversioned, etc. Replacing the content of the local file
> with the content in the repository looses local data.
Agreed, there is no reasonable way to handle this case automatically.
But it shouldn't happen as long as the clutter is never committed.
It is probably bad practice to default to letting cruft stay across
switches since your workspace would end up different than a fresh
checkout but it would be handy to have a way to force mostly-harmless
operations without overwriting any differing file data.
Received on 2013-08-23 20:31:59 CEST