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

svn_load_dirs.pl : locks, props, and links

From: Mark Reibert <svn_at_reibert.com>
Date: 2007-02-05 09:26:20 CET

Hello,

I ran across a couple of issue during a recent attempt to import a new
version of vendor drop into one of my repositories. The issues are:

1. svn_load_dirs.pl does not handle non-writable files in the staging
working copy when it copies files from the import directory. This
situation naturally occurs if the "svn:needs-lock" property is set on a
file.

2. The script will set "svn:executable" on *any* executable plain file,
even those that have not changed (MD5). This triggers the file to be
processed as an addition to the repository and copied from the import
directory into the staging working copy. This behavior seem
unintentional (or at least inconsistent) since all other properties (via
the -p option) are set only for newly added files. It can also trigger
the failure noted above if the only change to a "binary" file is in its
permissions.

3. The script is computing MD5s for plain files *and* links, provided
the target of the link is a plain file. That is, when the script finds a
link it tags it as a link but stores the MD5 of the link target (if the
target is a plain file). This does not seem correct since, for example,
what if the link pointed to a file outside the tree under revision
control? After all, if the link target is inside the tree the script
will find it as well as the link.

Below is a patch that deals with these three issues. The patch is
against the svn_load_dirs.pl delivered with Subversion 1.4.3. Issue #1
is handled by running "svn lock" if the target is not writable ... that
may be a little brute-force. Issue #2 is handled by setting
"svn:executable" only for newly added files. The last issue is handled
by simply skipping the MD5 for links. (Note this is a pre-condition for
the "svn lock" change to work correctly.)

Regards,
Mark Reibert

--- svn_load_dirs.pl.in-1.4.3 2006-11-10 12:07:14.000000000 -0700
+++ svn_load_dirs.pl.in 2007-02-05 01:18:31.000000000 -0700
@@ -925,6 +925,21 @@
                   {
                     print "U $source_path\n";
                     $upd_files{$source_path} = $del_info;
+
+ # It is possible for the destination file to be read
+ # only if it has the svn:needs-lock property set. In
+ # this case we get a lock (which is safe even if
+ # svn:needs-lock is not set). Note this only applies to
+ # plain files, but that is implied here since digests
+ # are computed only for plain files. Note also there is
+ # a corner case in which the lock request will fail if
+ # the file is locked by someone else.
+ unless (-w $dest_path)
+ {
+ read_from_process($svn, 'lock',
+ @svn_use_repos_cmd_opts,
+ $dest_path);
+ }
                   }
               }
           }
@@ -991,17 +1006,17 @@
                     last if $property->{control} eq 'break';
                   }
               }
- }

- # Add svn:executable to files that have their executable bit
- # set.
- if ($source_is_exe)
- {
- print "Adding to '$source_path' property 'svn:executable' with ",
- "value '*'.\n";
- my $property = {name => 'svn:executable', value => '*'};
- push (@{$add_files{$source_path}{properties}},
- $property);
+ # Add svn:executable to files that have their executable bit
+ # set.
+ if ($source_is_exe)
+ {
+ print "Adding to '$source_path' property 'svn:executable' with ",
+ "value '*'.\n";
+ my $property = {name => 'svn:executable', value => '*'};
+ push (@{$add_files{$source_path}{properties}},
+ $property);
+ }
           }

         # Now make sure the file or directory in the source directory
@@ -1593,7 +1608,7 @@
       return if $_ eq '.';
       my ($file_type) = &file_info($_);
       my $file_digest;
- if ($file_type eq 'f' or ($file_type eq 'l' and stat($_) and -f _))
+ if ($file_type eq 'f')
         {
           $file_digest = &digest_hash_file($_);
         }

-- 
----------------------
Mark S. Reibert, Ph.D.
svn@reibert.com
----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 5 09:26:37 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.