Back to the main page.
Bug 2190 - autosync does not work properly anymore?
| Status | CLOSED FIXED |
| Reported | 2013-06-06 14:26:00 +0200 |
| Modified | 2019-08-10 12:03:24 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Eelke Spaak - 2013-06-06 14:26:43 +0200
I committed a change to forward/ft_apply_montage.m (see bug 1886), expecting it to be autosynced to the other copies: bash-4.1$ find . -name ft_apply_montage.m ./plotting/private/ft_apply_montage.m ./fileio/private/ft_apply_montage.m ./forward/ft_apply_montage.m which all have autosync=true: bash-4.1$ find . -name ft_apply_montage.m -exec svn propget autosync {} \; true true true However, when after a minute I do svn update, nothing is changed in these other files.
Robert Oostenveld - 2013-06-14 13:43:28 +0200
Eelke and I looked at it, it seems to be related to the twitter post-commit hook failing. At the moment we have disabled it. Older commits might have gone wrong, though.
Robert Oostenveld - 2013-06-14 14:01:24 +0200
I have crafted the following script to find existing files that are out of sync #!/bin/sh FILE1=`tempfile` FILE2=`tempfile` touch $FILE1 touch $FILE2 echo $FILE1 echo $FILE2 svn propget autosync `find . -name \*.m` | cut -d ' ' -f 1 > $FILE1 for LINE in `cat $FILE1` ; do basename $LINE >> $FILE2 done for FUNCTION in `cat $FILE2 | sort | uniq` ; do unset FIRSTOCCURENCE for OCCURENCE in `grep $FUNCTION $FILE1` ; do if [ -z "$FIRSTOCCURENCE" ] ; then FIRSTOCCURENCE=$OCCURENCE fi echo =================================== diff $OCCURENCE $FIRSTOCCURENCE done done
Robert Oostenveld - 2013-06-14 14:05:23 +0200
(In reply to comment #2) More useful is diff -q $FIRSTOCCURENCE $OCCURENCE With that I get Files fileio/private/ft_apply_montage.m and forward/ft_apply_montage.m differ Files fileio/private/ft_datatype.m and fileio/private/ft_datatype_mvar.m differ Files fileio/private/ft_datatype_vol.m and plotting/private/ft_datatype_volume.m differ Files fileio/private/ft_voltype.m and forward/ft_voltype.m differ Files connectivity/private/getsubfield.m and fileio/private/getsubfield.m differ Files connectivity/private/getsubfield.m and forward/private/getsubfield.m differ Files connectivity/private/getsubfield.m and inverse/private/getsubfield.m differ Files connectivity/private/getsubfield.m and plotting/private/getsubfield.m differ Files connectivity/private/issubfield.m and fileio/private/issubfield.m differ Files connectivity/private/issubfield.m and forward/private/issubfield.m differ Files connectivity/private/issubfield.m and inverse/private/issubfield.m differ Files connectivity/private/issubfield.m and plotting/private/issubfield.m differ Files connectivity/private/rmsubfield.m and test/private/rmsubfield.m differ Files plotting/private/scale.m and private/globalrescale.m differ Files connectivity/private/setsubfield.m and fileio/private/setsubfield.m differ Files connectivity/private/setsubfield.m and test/private/setsubfield.m differ Files connectivity/private/warning_once.m and private/warning_once.m differ
Robert Oostenveld - 2013-06-14 14:07:48 +0200
(In reply to comment #3) oops, false positives! The dot in the ".m" is interpreted as regular expression, i.e. any character. Hence fileio/private/ft_datatype.m fileio/private/ft_datatype_mvar.m fileio/private/ft_datatype_vol.m plotting/private/ft_datatype_volume.m Beware
Eelke Spaak - 2013-06-14 14:18:35 +0200
Twitter has migrated to a new version of their API (again...), as I found out by checking the response: "The Twitter REST API v1 is no longer active. Please migrate to API v1.1. https://dev.twitter.com/docs/api/1.1/overview." I'll make the changes required.
Eelke Spaak - 2013-06-14 14:22:59 +0200
(In reply to comment #5) The twitter PHP script should work fine again. Robert, can you comment the "exit 0" line in post-commit-twitter?
Eelke Spaak - 2013-06-14 14:27:00 +0200
(In reply to comment #6) Although, now that I think of it, I did not find any indication that the twitter script was generating an error. So possibly the autosync failing is independent of the change in the twitter API? But that would not be in line with autosync succeeding again the moment we disabled the twitter hook.
Robert Oostenveld - 2013-06-14 14:29:34 +0200
mac001> svn commit engine/private/getsubfield.m connectivity/private/* fileio/private/ft_apply_montage.m -m "bugfix - some files were not properly autosynched, I made a small change to the latest of each set to trigger the autosync upon this commit. See http://bugzilla.fcdonders.nl/show_bug.cgi?id=2190" Sending connectivity/private/issubfield.m Sending connectivity/private/rmsubfield.m Sending connectivity/private/setsubfield.m Sending connectivity/private/warning_once.m Sending engine/private/getsubfield.m Sending fileio/private/ft_apply_montage.m Transmitting file data ...... Committed revision 8267. mac001> svn update At revision 8267. <===== this is not good! let's try it manually 1040 $ ./post-commit-autosync /home/svnroot/fieldtrip 8267 svn: Can't write to file '/home/svnroot/fieldtrip/hooks/autosync/trunk/test/.svn/tmp/text-base/test_bug1984_2187.mat.svn-base': No space left on device cp: preserving times for `/home/svnroot/fieldtrip/hooks/autosync/trunk/test/private/rmsubfield.m': Operation not permitted cp: preserving times for `/home/svnroot/fieldtrip/hooks/autosync/trunk/test/private/setsubfield.m': Operation not permitted cp: preserving times for `/home/svnroot/fieldtrip/hooks/autosync/trunk/utilities/private/warning_once.m': Operation not permitted cp: preserving times for `/home/svnroot/fieldtrip/hooks/autosync/trunk/test/private/warning_once.m': Operation not permitted cp: preserving times for `/home/svnroot/fieldtrip/hooks/autosync/trunk/private/warning_once.m': Operation not permitted cp: preserving times for `/home/svnroot/fieldtrip/hooks/autosync/trunk/engine/private/warning_once.m': Operation not permitted cp: preserving times for `/home/svnroot/fieldtrip/hooks/autosync/trunk/fileio/private/warning_once.m': Operation not permitted cp: preserving times for `/home/svnroot/fieldtrip/hooks/autosync/trunk/plotting/private/warning_once.m': Operation not permitted cp: preserving times for `/home/svnroot/fieldtrip/hooks/autosync/trunk/forward/private/warning_once.m': Operation not permitted cp: preserving times for `/home/svnroot/fieldtrip/hooks/autosync/trunk/statfun/private/warning_once.m': Operation not permitted cp: preserving times for `/home/svnroot/fieldtrip/hooks/autosync/trunk/specest/private/warning_once.m': Operation not permitted cp: preserving times for `/home/svnroot/fieldtrip/hooks/autosync/trunk/qsub/private/warning_once.m': Operation not permitted Sending autosync/trunk/connectivity/private/getsubfield.m Sending autosync/trunk/engine/private/issubfield.m Sending autosync/trunk/engine/private/rmsubfield.m Sending autosync/trunk/engine/private/setsubfield.m Sending autosync/trunk/engine/private/warning_once.m Sending autosync/trunk/fileio/private/getsubfield.m Sending autosync/trunk/fileio/private/issubfield.m Sending autosync/trunk/fileio/private/rmsubfield.m Sending autosync/trunk/fileio/private/setsubfield.m Sending autosync/trunk/fileio/private/warning_once.m Sending autosync/trunk/forward/ft_apply_montage.m svn: Commit failed (details follow): svn: File '/trunk/forward/ft_apply_montage.m' is out of date oh my, disk full!
Robert Oostenveld - 2013-06-14 14:33:34 +0200
I cleaned up some file (sorry lilmag and joedie), then triggered it again with roboos@dccn-l017:/home/svnroot/fieldtrip/hooks 1052 $ ./post-commit-autosync /home/svnroot/fieldtrip 8267 and now it seems to update and commit just fine. On my apple desktop I get mac001> svn update U engine/private/rmsubfield.m U engine/private/setsubfield.m U engine/private/issubfield.m U engine/private/warning_once.m U inverse/private/getsubfield.m U inverse/private/issubfield.m U plotting/private/getsubfield.m U plotting/private/setsubfield.m U plotting/private/warning_once.m U plotting/private/ft_apply_montage.m U plotting/private/rmsubfield.m U plotting/private/issubfield.m U connectivity/private/getsubfield.m U specest/private/issubfield.m U specest/private/rmsubfield.m U specest/private/getsubfield.m U specest/private/setsubfield.m U specest/private/warning_once.m U qsub/private/rmsubfield.m U qsub/private/getsubfield.m U qsub/private/setsubfield.m U qsub/private/issubfield.m U qsub/private/warning_once.m U utilities/getsubfield.m U utilities/setsubfield.m U utilities/private/warning_once.m U utilities/rmsubfield.m U utilities/issubfield.m U fileio/private/warning_once.m U fileio/private/issubfield.m U fileio/private/getsubfield.m U fileio/private/setsubfield.m U fileio/private/rmsubfield.m U private/warning_once.m U test/private/rmsubfield.m U test/private/setsubfield.m U test/private/warning_once.m U statfun/private/issubfield.m U statfun/private/rmsubfield.m U statfun/private/getsubfield.m U statfun/private/setsubfield.m U statfun/private/warning_once.m U forward/ft_apply_montage.m U forward/private/getsubfield.m U forward/private/setsubfield.m U forward/private/warning_once.m U forward/private/rmsubfield.m U forward/private/issubfield.m Updated to revision 8268. which also makes sense
Robert Oostenveld - 2013-06-14 14:36:22 +0200
I re-enabled post-commit-twitter.