Back to the main page.

Bug 2505 - remove symbolic links from svn repository

Reported 2014-03-19 16:01:00 +0100
Modified 2016-06-14 16:14:45 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P3 normal
Assigned to: Robert Oostenveld
Depends on:
See also:

Robert Oostenveld - 2014-03-19 16:01:59 +0100

On 19 Mar 2014, at 15:08, Johanna Zumer wrote: I have a Linux Ubuntu VMware guest running on a Windows 7 host. The host has 2 harddrives (250 GB SSD on C:\ and 2 TB SATA on D:\). Both the Windows OS as well as VMware run on the C drive. When I run within Linux VM on the /home/zumerj path the svn checkout, then it all works fine. However, I would like to put the code on the C or D drive (mounted on the VM) so that I can see it when I'm not running the VM. But if I run a separate svn checkout from within Linux VM on /mnt/hgfs/D which is the mounted D drive, I get this error: svn: In directory 'fieldtrip_svn/realtime/bin/glnxa64' svn: Can't create symbolic link 'fieldtrip_svn/realtime/bin/glnxa64/': Operation not supported And then I have to 'svn cleanup' and then: svn: Failed to add file 'realtime/bin/glnxa64/': an unversioned file of the same name already exists so I remove it and 'svn update' and it restores it, but then complains about other files all within that subdirectory. I've tried removing the whole fieldtrip folder and doing a fresh checkout but it's happened several times now, and never fully gets through. (Sorry, I forget now what the final error is that I couldn't get past).

Robert Oostenveld - 2014-05-07 15:18:37 +0200

hmm, these symbolic links indeed don't work on windows. I found these lrwxr-xr-x 1 roboos staff 15 Apr 17 2013 -> lrwxr-xr-x 1 roboos staff 15 Apr 17 2013 -> lrwxr-xr-x 1 roboos staff 15 Apr 17 2013 -> -rwxr-xr-x 1 roboos staff 1473185 Apr 17 2013 but don't understand why the same file needs to be present 4 times. It would be only used by tia2ft. roboos@mentat001> ldd tia2ft ./tia2ft: /usr/lib64/ version `GLIBCXX_3.4.14' not found (required by ./ => (0x00007fffbc3ff000) => /lib64/ (0x00000033ace00000) => not found => not found => not found => ./ (0x00007f698e06d000) => /usr/lib64/ (0x00000033b3200000) => /lib64/ (0x00000033ad200000) => /lib64/ (0x00000033b2e00000) => /lib64/ (0x00000033ac600000) /lib64/ (0x00000033ac200000) I have tried cleaning it up, please try again roboos@mentat001> svn commit Deleting glnxa64/ Replacing glnxa64/ Deleting glnxa64/ Deleting glnxa64/ Committed revision 9471.

Robert Oostenveld - 2014-05-14 20:08:49 +0200

closed several of my bugs that have been resolved

Johanna - 2014-06-19 14:59:00 +0200

Sorry for the late reply, but I have tested this, and it now works. Thank you!

Johanna - 2016-01-20 18:45:30 +0100

Hi Robert, I've been having new problems with svn (and I think a symbolic link). I checked out a fresh copy of FT and the error is svn: In directory 'fieldtrip_svn/contrib/nutmegtrip/private' svn: Can't create symbolic link 'fieldtrip_svn/contrib/nutmegtrip/private/parameterselection.m.tmp': Operation not supported I then try 'svn update' and get this error: svn: Working copy 'contrib/nutmegtrip/private' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) I then 'svn cleanup' and then 'svn update' again, and get this error: svn: Failed to add file 'contrib/nutmegtrip/private/nmt_ts_intervalpower.m': an unversioned file of the same name already exists [I cc Sarang so he is aware of the problem for symbolic links (though I know he's on holiday now until March, and so he probably won't respond!)] I'm not exactly sure what's going on here, or whether this is the same issue as this original bug, but as it seemed closely related, I reopened this one. Thank you, JOhanna

Robert Oostenveld - 2016-01-21 14:52:50 +0100

(In reply to Johanna from comment #4) You are right, there are a number of symbolic links here: mac011> pwd /Users/roboos/matlab/fieldtrip/contrib/nutmegtrip/private mac011> ls -al total 88 drwxr-xr-x 11 roboos staff 374 Nov 20 08:53 . drwxr-xr-x 14 roboos staff 476 Nov 20 08:53 .. lrwxr-xr-x 1 roboos staff 31 Nov 20 08:53 atlas_lookup.m -> ../../../private/atlas_lookup.m -rw-r--r-- 1 roboos staff 9815 Nov 18 08:50 freezeColors.m lrwxr-xr-x 1 roboos staff 28 Nov 20 08:53 getdimord.m -> ../../../private/getdimord.m lrwxr-xr-x 1 roboos staff 28 Nov 20 08:53 getdimsiz.m -> ../../../private/getdimsiz.m -rw-r--r-- 1 roboos staff 251 Nov 18 08:50 nmt_coord_diff.m -rw-r--r-- 1 roboos staff 129 Nov 18 08:50 nmt_rownorm.m -rw-r--r-- 1 roboos staff 309 Nov 18 08:50 nmt_ts_intervalpower.m lrwxr-xr-x 1 roboos staff 37 Nov 20 08:53 parameterselection.m -> ../../../private/parameterselection.m -rwxr-xr-x 1 roboos staff 3611 Nov 18 08:50 unfreezeColors.m Rather than symlinks, this should have been implemented according to --- I removed the symlinks in commit 11089. Then I did mac011> svn copy ../../../private/atlas_lookup.m . A atlas_lookup.m mac011> svn copy ../../../private/getdimord.m . A getdimord.m mac011> svn copy ../../../private/getdimsiz.m . A getdimsiz.m mac011> svn copy ../../../private/parameterselection.m . A parameterselection.m mac011> svn propget autosync *.m getdimord.m - true getdimsiz.m - true parameterselection.m - true here I notice that atlas_lookup.m does not yet have autosync=true. This sets it to both: mac011> svn propset autosync true atlas_lookup.m property 'autosync' set on 'atlas_lookup.m' mac011> svn propset autosync true ../../../private/atlas_lookup.m property 'autosync' set on '/Users/roboos/matlab/fieldtrip/private/atlas_lookup.m' And this finalizes it: mac011> svn commit . ../../../private/atlas_lookup.m Adding contrib/nutmegtrip/private/atlas_lookup.m Adding contrib/nutmegtrip/private/getdimord.m Adding contrib/nutmegtrip/private/getdimsiz.m Adding contrib/nutmegtrip/private/parameterselection.m Sending private/atlas_lookup.m Committed revision 11090. --------- PS note that due to bug 3049 (migrate from svn to github) in the future a different solution is needed. Probably a github web hook that calls a shell script.

Robert Oostenveld - 2016-06-14 16:14:45 +0200

Hereby I am closing multiple bugs that have been resolved for some time now. If you don't agree to the resolution, please reopen.