(09-27-2012, 03:03 PM)refraction Wrote: The "Up-to-date" result is used if one of the included projects during the build has already been compiled previously and hasnt changed since.What you say does make sense. So what that entry really means is that some included component didn't need recompilation as it already was 'up-to-date' in that regard.
Quote:The best thing to do is create a "patch" file, you can do this if you use tortoiseSVN http://tortoisesvn.net/I don't see how that would resolve the incompatibilities between VS versions. My SLN file, and possibly other files too in sub-projects, will inevitably contain differences that should not be added to the main source repository, though my intentional changes of code would need to be added.
That's why I think that a direct SVN update by me would be out of the question. And the same should go for any 'patch' based on full diffs between my source repository and that of the online server.
Edit:
On second thought I could get around that limitation by simply duplicating the repositories. Using an extra copy with my VS version, and then after modifying some source files there, simply copy those files back into the primary copy, still having unchanged versions of those other files that my VS version would have 'messed up' (== changed differently from the 'Pro' version).
But this method only works for modifications made in existing files. But in adding new files to a project, the related project and solution files must also be modified, and my VS version can not be relied on to do that in ways compatible to the 'Pro' version. (Especially not with the extensive use of 'Solution folders'.)
Best regards: dlanor