[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

issue #2692 - broken symlink modification prevents update and checkout

From: Igor Kovalenko <garrison_at_mail.ru>
Date: 2007-01-26 23:34:50 CET

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
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.
SVN-fs-dump-format-version: 2
UUID: 82e4110f-07c2-41a8-ba25-4b48b5cb5f5b
Revision-number: 0
Prop-content-length: 56
Content-length: 56
K 8
V 27
Revision-number: 1
Prop-content-length: 124
Content-length: 124
K 7
V 22
Commit a symbolic link
K 10
V 7
K 8
V 27
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
V 1
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
Revision-number: 2
Prop-content-length: 140
Content-length: 140
K 7
V 37
Erroneously changed symlink contents
K 10
V 8
K 8
V 27
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
Received on Fri Jan 26 23:58:21 2007

This is an archived mail posted to the Subversion Dev mailing list.