Svn wrapper or command line needed.

On many machines here, the ports or src tree upon [CMD=] svn up [/CMD] shows a large number of conflicts, half of which want an answer such as "postpone", the other "theirs-full". Re-downloading with svn seems to not resolve the conflicts. (Why they appear in the first place, nothing changed on this machine in the meantime, is a complete mystery.) The often recommended delete-and-re-checkout procedure is okay, but takes much more time (preserving extra files etc) than I"d like to, if there was any svn command that mimics the old cvs procedure of remove-directory and re- cvs it. Anyone knows of a succinct svn command for use in such situations, or if a wrapper could be crafted that puts forth the series of commands that would take less time than a new src or ports checkout? The handbook refers to the SVN redbook, it might have the answer, but I am reluctant to spend the time reading it thoroughly if someone else has and knows the answer(s) already.

Thanks.
 
Individual files or directories can be deleted and the next update will restore them from the repository without conflicts.
 
It still shows
Code:
D    C  /usr/src/contrib/vis > local dir unversioned, incoming dir upon update
About 289 of them for /usr/src/contrib or its parent directory.
Code:
/bin/rm -rf /usr/src/contrib
svn up /usr/src/contrib
svn status /usr/src contrib
# Tree conflicts: 289
So I am missing some command or procedure.
 
One more time:

Checking out a bunch of subdirectories is absolutely not the same as checking out the whole top-level directory. Stop doing that. Look in the subdirectories with ls -al and you will see that the top-level directories contain .svn directories. Only /usr/src should have those directories.
Code:
# mv /usr/src /usr/src.mixed-old
# svn checkout https:... /usr/src
 
Well, I can (not checking out, but revert-or-up them...) get conflicts for seemingly no reason.
Code:
 svn revert -R
fixes some of them; some other svn command with the depth parameter can fix checksum errors if those occur, but it seems some code would be smart enough to delete, revert, solve OR give the reason why for the mysterious tree conflicts which should not be there. If it were written, of course, by someone more expert than I who knew the ins-and-outs of it all. In the meantime, I've sort of planned since starting this thread to make a shell script to save the two directories with any changed files, delete and re svn the source tree. Would take time, but maybe less time, in this case, than figuring out a workaround or solution.
 
The tree conflicts are because you have multiple overlapping checkouts. Fix that problem and the rest go away.
 
Back
Top