I will try to explain one more time. The files in question are settings files (think config files) and intermediate compilet generated files. The settings files can be recreated at any time. If they are wrong the only thing affected is the development environment. The other files get recreated every time the code is run, plus they never get into production. So they 1) could be recreated any time at will with the versioned code files and 2) they will never be in production anyway. Don't read more than what is stated otherwise you have a chance of being wrong and wasting time. Someone was claiming the files are "important" which I never stated. I didn't even respond to the mail since it was erroneous and irrelevant.
The real reason I responded is the force option eliminates the conflict but creates some questions. The documentation says using it will make sure "unversioned obstructiong paths do not cause a failure". Could that also be written as "unversioned obstructiong paths do not cause a conflict"? Or is there some other kind of failure that I do not know about. The problem this fixes displays as "Local unversioned, incoming add upon switch" which is the result of a switch. The revert command fails to bring my working copy back to its unconflicted state. Switching back also fails. The question is can I bring back my working directory from a failed switch (I'm talking undo, not resolve) so I can use the force option or must I always use the force option to be able to switch branches? Have a good weekend JM -----Original Message----- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Thursday, August 22, 2013 5:17 PM To: John Maher Cc: Edwin Castro; users@subversion.apache.org Subject: Re: Switching On Thu, Aug 22, 2013 at 1:34 PM, John Maher <jo...@rotair.com> wrote: > Again Les, you misunderstand. I have no problems with the workspace. It is > exactly the same for everyone, everytime. Please read carefully before you > respond. It has nothing to do with the build. It is user settings, a config > file, ini file, choose your terminology. If you don't understand please ask > for clarification instead of making incorrect assumptions. 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 always the same, I don't see the problem with committing it. If it isn't, and you need to reproduce it, you need to work out a way to do that, or use the multiple-checkout approach to maintain dirty workspaces, realizing that you can't reproduce them reliably. Personally, I don't like things that rely on any unversioned state getting into production releases. That developer will leave or that machine will crash and all the magic is gone - and if you can't do a matching build on a clean machine from a clean checkout, you won't ever know how much magic was involved. -- Les Mikesell lesmikes...@gmail.com
