<snip>
> > Is this a bug? Is it known before?
>
> It's not a bug, it's more like "don't do that." :-)
Tehe!
> If 'svn update' needs to change a working file, but the file
> is set to
> read-only, what do you expect? Of course the update will be
> interrupted. The update is obstructed.
Hmm, is it really? It's a matter of how you look at it I suppose.
I'm expecting that my files that are under version control do get
version controled. I would expect subversion to check if there are
any local modifications, and if not remove the read-only attribute
move the tmp file in place and reapply the read-only attribute.
Then telling me maybe that a readonly file was merged.
If the file was locally modified there would me more problems, maybe
tell the user what's going on and let them fix it.
Couldn't read-only attributes on a file or directory be seen as a
property in it self? Worthy of versioning? Check in a read-only file
and to day it will have lost it's read-only attribute when it's checked
out somewhere else.
As it is today, the few seconds wait and wierd message of a tmp-file
gets users confused. There is really no message telling me that the
file is read-only at all. All it says is access denied.
> Fix the working-file's
> permission, run 'svn cleanup' so the working copy can finish
> processing
> the interrupted work, then 'svn update' again to finish the update.
If that's the fix, couldn't that be written in the error message?
I can see how this kind of interactive work, issueing and reissueing
commands to subversion, might work with a smaller set of code. But
when you have a wc of 50k files and 5k folders each operation takes
at least 2-3 minutes. Also the read-only files might be (as they are
in our case) generated from a tool in many places. That means that this
procedure, getting the error, fixing the attribute, running cleanup,
running update, next error... can continue for hours.
Given this, would it be possible to have some kind of improvment
suggestion registered on this?
Ohh, by the way, the tool no longer generates read-only files :)
/Nicke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 6 15:45:59 2004