Re: Proposal: svn:temporary property

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

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org