Understanding the problem (incuding your "problems"
communication and usage of svn status) isn't the problem at all;
the problem is how to solve it: About manually deleting
the blocking files see my previous email.
Also note that I am not proposing a new property anymore
for some time now due to convincing arguments from others;
see for example my previous email for details.
John Peacock wrote:
> Folker Schamel wrote:
>
>> In our case (replacement(!) of a directory containing temporary
>> files, where svn update fails without changing the wc)
>> the only solution I know is to delete the complete directory
>> (including .svn directories @%§&@) before update,
>> or to selectively delete all svn:ignore files before update
>> (how should I do this under windows? @%§$"%@)
>> Does anyone knows an alternative?
>
>
> I know you don't agree with me, but I still maintain that this was a
> case of project management and intra-project communication failures,
> combined with less-than-clear error messages from Subversion. The
> easiest fix for Subversion is to improve the error messages, so that the
> users can respond to the actual situation (which is where the solution
> ultimately has to lie). There is no need for a new property (which
> someone would have to remember to set, after all) to prevent this from
> happening again.
>
> Since your original e-mail was not an accurate description of your
> use-case, we spent a lot of time arguing about the wrong things. I
> think I know what your actual use-case was, but I could still be wrong.
> If you can actually produce a recipe, it would be very helpful.
>
> My understanding is this:
>
> 1) User A deleted a directory containing a submodule and then created a
> new directory with the same name for a replacement submodule (equivalent
> to the original?);
>
> 2) User B, as part of building the entire project, had unversioned .obj
> files for this submodule, but User B has no direct knowledge of this
> submodule;
>
> 3) User B attempted to update, and Subversion reported that the update
> was blocked due to the presence of unversioned files.
>
> There are two problems I see here:
>
> A) User A didn't communicate to the other project members that a major
> code restructuring had occurred (this should be the norm for large
> projects) and that some manual intervention might be required during
> subsequent updates;
>
> B) User B didn't know enough about the tool to run 'svn status' to see
> what unversioned files were blocking the update.
>
> With forwarning that a change had occurred in a part of the project that
> may be unfamiliar, and knowledge of how the tool works, User B could
> have easily determined which files were blocking the update, deleted
> them (and only them) then the 'svn up' would proceed without issue.
>
> John
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Dec 21 11:45:03 2003