issue #2692 - broken symlink modification prevents update and checkout

The problem we are stuck with is basically that erroneous commit made
using subversion client from windows machine prevent checkout and/or
update to corresponding revision.

I see excellent in-detail description (with a workaround) in the issue comments
here http://subversion.tigris.org/issues/show_bug.cgi?id=2692

My colleagues just reproduced the same problem. Repository dump created
on unix by combining symlink.dump of regression suite data with a bit
of hacking in working copy, followed by single commit, is appended to this mail.

 From recent (Jan 23, 2007) discussion on #svn-dev the following propositions
can be made:

--
1. If we get a special file of unknown type, just write the internal
representation out, don't error. That is what is now done for symlinks on windows.
2. If we try to commit changes to a special file of unknown type, error.
This may be done on client side - to inform user about erroneous change to item
of unknown type and to stop feeding the server with garbage change.
--
Now what I learned from the subversion implementation.
By looking at the code a real problem with wc code appears to be in too much
coupling between checks for svn:special and HAVE_SYMLINK dependent conditional
compilation. For example, assemble_status() on windows does not check for
svn:special property value at all, because all the checking is under ifdef
HAVE_SYMLINK!
Instead, checks for svn:special property value should be done unconditionally.
At the time the actual wc item is to be inspected, platforms with HAVE_SYMLINK
set should do the symlink stat stuff and others resort to the appropriate emulation.
Then, to my mind repository code should do appropriate checking on it's own
anyway, to prevent inconsistent changes from crippling in. Probably good idea
is to support that in svnadmin load/verify too.
If a change is to an item of special type, server can decide if that change is
allowed, because all supported svn:special file types are known anyway. For example,
svn:special "link" can change it's special type only if it is "replaced", but
svn:special "link dest1" can be changed to svn:special "link dest2" as one would
expect for symlinks.
Comments?
--
SVN-fs-dump-format-version: 2
UUID: 82e4110f-07c2-41a8-ba25-4b48b5cb5f5b
Revision-number: 0
Prop-content-length: 56
Content-length: 56
K 8
svn:date
V 27
2007-01-10T21:16:13.268177Z
PROPS-END
Revision-number: 1
Prop-content-length: 124
Content-length: 124
K 7
svn:log
V 22
Commit a symbolic link
K 10
svn:author
V 7
malcolm
K 8
svn:date
V 27
2007-01-10T21:18:08.532835Z
PROPS-END
Node-path: from
Node-kind: file
Node-action: add
Prop-content-length: 33
Text-content-length: 7
Text-content-md5: 2419f8600825e9410d1b9a62a34570ec
Content-length: 40
K 11
svn:special
V 1
*
PROPS-END
link to
Node-path: to
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 0
Text-content-md5: d41d8cd98f00b204e9800998ecf8427e
Content-length: 10
PROPS-END
Revision-number: 2
Prop-content-length: 140
Content-length: 140
K 7
svn:log
V 37
Erroneously changed symlink contents
K 10
svn:author
V 8
garrison
K 8
svn:date
V 27
2007-01-26T21:26:41.481981Z
PROPS-END
Node-path: from
Node-kind: file
Node-action: change
Text-content-length: 9
Text-content-md5: c645cbac3817a48c2d384d099f674453
Content-length: 9
junk data
-- 
Kind regards,
Igor V. Kovalenko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org