Denis Excoffier wrote on Sat, 02 Mar 2019 09:17 +00:00: > What would be the best strategy? I can figure out this one: > > 1) Within the working copy, delete the existing tree (not svn delete) > 2) Extract the new tree at the same place > 3) Interpret the result of 'svn status' in terms of 'svn add' and > 'svn delete' to apply on the working copy (details omitted here) > 4) Commit >
That should work, though the 'svn status' will be expensive because the usual optimization (not read()ing a file in full if its size+mtime haven't changed) won't kick in. In step 3 you can do 'svn add --force ./'. There's an addremove branch [1] that attempts to implement this, but I don't know what its state is. (It's named after the analogous hg command.) [1] https://svn.apache.org/viewvc/subversion/branches/addremove/ > The difficulty is to make sure that all peculiarities of a file system > changes (say: only files, folders and symlinks) are handled properly. > I don't talk about I/O errors of course. Yeah, I see no reason why it shouldn't be possible to version circular symlinks. You can certainly create them with svnmucc, for example. Cheers, Daniel
