The issue here was a bug that:
if a symlink is checked in with svn:executable set, and the symlink
points at a file which follows the symlink in checkout order, then
checkouts on linux (maybe any platform which supports an execute bit)
will fail.
Nasty. The workaround was to check out the directory with the symlink
under windows (which doesn't have an execute bit or symlinks) and
propdel the svn:executable bit.
This could be a frequent problem in a unix-y environment because it is
very common to have a foo.so which is actually a soft link to a
like-named file with a version suffix, e.g. foo.so.4.
Any ideas on how to prevent these from getting committed in the first place?
Or, failing that, how to catch one of these early? svnadmin verify
had no problem with this setup, although I would get the "svn: Unknown
node kind" on certain accesses to the file.
Thanks,
Kylo
On 3/23/07, Kylo Ginsberg <kylo.ginsberg@gmail.com> wrote:
> Converted our large repository with cvs2svn 2 days ago, and an import
> today resulted in a file which can't be checked out:
>
> svn: In directory 'dvcprohd/dvcprohd/bin'
> svn: Can't change perms of file
> 'dvcprohd/dvcprohd/bin/libmcdv_proHD.so': No such file or directory
>
> When I try to access via URL:
>
> svn pl http://snow/svnroot/trunk/omneon/imports/mainconcept/dvcprohd/dvcprohd/dvcprohd/bin/libmcdv_proHD.so
> svn: Unknown node kind for
> 'http://snow/svnroot/trunk/omneon/imports/mainconcept/dvcprohd/dvcprohd/dvcprohd/bin/libmcdv_proHD.so'
>
> I'm running an "svnadmin verify" to see what it reports.
>
> Advice?
>
> Thanks,
> Kylo
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Mar 24 04:06:05 2007