Back to the main page.
Bug 1751 - Adding the autosync SVN property does not trigger a sync.
| Status | CLOSED WONTFIX |
| Reported | 2012-09-28 13:45:00 +0200 |
| Modified | 2012-12-31 11:46:21 +0100 |
| Product: | FieldTrip |
| Component: | release |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | All |
| Importance: | P3 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Boris Reuderink - 2012-09-28 13:45:35 +0200
I have removed some mex files (nansum and friends), and added a new version a few commits later. These new files didn't have the autosync property that tells the SVN server to update all related copies. Fine. So, in https://code.google.com/p/fieldtrip/source/detail?r=6591 I added the property, and expected that this would take care of syncing all files. It didn't. The files are now all have the autosync property, but are in different states. Perhaps this is for safety reasons, but I think it is unexpected.
Boris Reuderink - 2012-09-28 13:48:22 +0200
Also, what does happen when a autosync-enabled file is deleted? Are all the linked files deleted as well?
Robert Oostenveld - 2012-09-28 15:56:54 +0200
The autosync only pertains to modifications. When you first add, commit, and then set the property, there is nothing synched. If you first svn add, then set the property (locally), then svn commit, it will get synched to the other instances of the file. When deleting one copy, the others are not deleted. To fix the inconclusive state, you have to commit a change to the latest version of the file. This is easy with an m-file, just change some whitespace and then commit. The solution for binary file is to copy the latest version over an older version, then svn commit the (updated) old version -> this will synchronize all exemplars to the latest version.
Boris Reuderink - 2012-10-05 12:07:25 +0200
I just reopened #1768, because files with the autosync tag were not in sync. I discovered that the checksums of linked files differed. Imagine the following scenario: 1) Files that have the autosync property, and have the same file name are meant to be the same file. 2) Let's call the linked set of files a group. 3) If a group has files with different checksums, there is a violation — this is a state that has to be resolved by they autosync script. Checking changes in a new commit is a sufficient condition given an valid initial state. 4) Violation (3) can be resolved by propagating the newest changes to the rest of the group. 5) Commit, and everything is valid again. Of course this is complicated by additional properties (executable bits, other tags).
Boris Reuderink - 2012-10-05 12:15:18 +0200
Actually, I did some command lining, and there are quite some files out of sync: # Get all linked files: $ svn propget -R autosync > linked.txt # Extract filename, path and checksum for these files: $ for fname in `cat linked.txt | cut -d " " -f1` ; do echo `basename $fname` $fname `sha1sum $fname`; done | sort > grouped.txt # List groups of files that do not have an unique checksum: $ cat grouped.txt | cut -d " " -f1,3 | uniq | cut -d " " -f1 | uniq -d ama2vol.m bounding_mesh.m channelposition.m ctf2grad.m data2raw.m dataset2files.m find_innermost_boundary.m find_outermost_boundary.m fixdimord.m fixname.m ft_apply_montage.m ft_checkdata.m ft_checkopt.m ft_convert_units.m ft_datatype_comp.m ft_datatype_dip.m ft_datatype_freq.m ft_datatype.m ft_datatype_mvar.m ft_datatype_raw.m ft_datatype_sens.m ft_datatype_source.m ft_datatype_spike.m ft_datatype_timelock.m ft_estimate_units.m ft_fetch_data.m ft_fetch_header.m ft_findcfg.m ft_getopt.m ft_getopt.m ft_hastoolbox.m ft_inside_vol.m ft_progress.m ft_senslabel.m ft_senstype.m ft_voltype.m getsubfield.m globalrescale.m hasyokogawa.m headcoordinates.m issubfield.m istrue.m keyvalcheck.m keyval.m match_str.m matlabversion.m mergeconfig.m nanmean.mexw32 neuralynx_crc.m neuralynx_getheader.m offset2time.m parameterselection.m preproc.m pthread.h pthreadVC2.lib read_neuralynx_dma.m rigidbody.m rotate.m scale.m sched.h setsubfield.m sine_taper.m smartinput.m solid_angle.m solid_angle.m specest_nanfft.m tokenize.m traditional.m translate.m triplot.m uimage.m uimagesc.m warp_apply.m This seems quite a list. Perhaps I made a mistake somewhere. But at least nanmean.mexw32 is there, for which I know there is a problem.
Boris Reuderink - 2012-10-05 12:20:53 +0200
Ok, there is probably a series of false positives due to the $Id tag of SVN: $ diff ./plotting/private/scale.m ./utilities/private/scale.m 44c44 < % $Id: scale.m 3550 2011-05-16 18:58:45Z roboos $ --- > % $Id: scale.m 3486 2011-05-10 09:29:30Z roboos $
Boris Reuderink - 2012-10-05 12:48:47 +0200
After removing the false positives (skipping the $Id: line in the checksum), the following text files remain: $ find . -name "sched.h" ./realtime/src/external/pthreads-win64/include/sched.h ./realtime/src/external/pthreads-win32/include/sched.h $ find . -name "pthread.h" ./realtime/src/external/pthreads-win64/include/pthread.h ./realtime/src/external/pthreads-win32/include/pthread.h These should probably not be autosynced, since the content is supposed to be different. The only binary file in comment 4 is nanmean.mexw32, which is taken care of in #1768. I have removed the autosync on sched.h and pthread.h in SVN revision 6703. *So, in summary there is not really a problem with the current state of autosynced files.*.
Boris Reuderink - 2012-10-05 14:22:53 +0200
Update: forgot about pthreadVC2.lib. Also removed autosync tag for this file.
Robert Oostenveld - 2012-10-05 16:24:48 +0200
(In reply to comment #3) > 1) Files that have the autosync property, and have the same file name are meant > to be the same file. > 2) Let's call the linked set of files a group. > 3) If a group has files with different checksums, there is a violation — this > is a state that has to be resolved by they autosync script. Checking changes in > a new commit is a sufficient condition given an valid initial state. > 4) Violation (3) can be resolved by propagating the newest changes to the rest > of the group. > 5) Commit, and everything is valid again. Re. 3: this violation is what triggers the autosync script. It does not know however about checksums, it only knows that one exemplar from the group has been updated, it copies it over the other exemplars and commits. However, you are apparently able (due to some subtle difference in how you do updates compared to how other do it) to break the script. The script breaking is something the script cannot be made robust against. So item 4 and 5 are part of the current script (but not based on checksums), but sometimes they are not executed. Might it be that you are not doing an svn update following your svn commit and that therefore your other copies are not updated? Have a look in /home/svnroot/fieldtrip/hooks/post-commit-autosync on the svn server (you can open that file after logging in with your normal account).
Robert Oostenveld - 2012-10-05 16:25:10 +0200
I checked two of the problem files: manzana> svn info realtime/src/external/pthreads-win64/include/pthread.h Path: realtime/src/external/pthreads-win64/include/pthread.h Name: pthread.h URL: svn+ssh://roboos@svn.fcdonders.nl/home/svnroot/fieldtrip/trunk/realtime/src/external/pthreads-win64/include/pthread.h Repository Root: svn+ssh://roboos@svn.fcdonders.nl/home/svnroot/fieldtrip Repository UUID: 0cf7c7f0-3615-4144-b4e6-68da3bce3cd0 Revision: 6705 Node Kind: file Schedule: normal Last Changed Author: borreu Last Changed Rev: 6703 Last Changed Date: 2012-10-05 12:47:38 +0200 (Fri, 05 Oct 2012) Checksum: f781fae7a2ba70179bccc1ad82866575 manzana> svn info realtime/src/external/pthreads-win32/include/pthread.h Path: realtime/src/external/pthreads-win32/include/pthread.h Name: pthread.h URL: svn+ssh://roboos@svn.fcdonders.nl/home/svnroot/fieldtrip/trunk/realtime/src/external/pthreads-win32/include/pthread.h Repository Root: svn+ssh://roboos@svn.fcdonders.nl/home/svnroot/fieldtrip Repository UUID: 0cf7c7f0-3615-4144-b4e6-68da3bce3cd0 Revision: 6705 Node Kind: file Schedule: normal Last Changed Author: borreu Last Changed Rev: 6703 Last Changed Date: 2012-10-05 12:47:38 +0200 (Fri, 05 Oct 2012) Checksum: 8b389a9959dba88a89d8226304542158
Robert Oostenveld - 2012-10-05 16:27:26 +0200
(In reply to comment #9) for these two I also notice that manzana> svn propget autosync realtime/src/external/pthreads-win32/include/pthread.h manzana> svn propget autosync realtime/src/external/pthreads-win64/include/pthread.h return both nothing. So the files are not synched. From the svn log I also understand that to be intentional.
Robert Oostenveld - 2012-10-05 16:28:46 +0200
(In reply to comment #10) or more specifically http://code.google.com/p/fieldtrip/source/detail?r=6703
Robert Oostenveld - 2012-10-29 13:46:04 +0100
as far as I can tell, the autosync issues have been resolved, right?