Re: svnsync 1.6.0 fails to sync repositories with ^M in an svn:ignore

On Sat, Mar 28, 2009 at 14:58, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> B Smith-Mannschott wrote on Sat, 28 Mar 2009 at 12:43 +0100:

>> I've made a hacked-up variant of svnsync which will correct impure
>> eol-style in property values where the real 1.6.0 complains and dies.
>> (see patch at end of mail).
>>
>> This is obviously not a permanent solution.
>>
>> ---------------------
>> Don't try this at home kids: this is an *evil* hack. A validation
>> function which mutates an input marked as const is truly not a pretty
>> sight.
>>
>
> Less evil would be to change svnsync itself rather than the validation
> logic --- see how subversion/svnsync/main.c handles the
> SVNSYNC_UNSUPPORTED_STRIP_MERGEINFO flag.  That way you also wouldn't have
> to modify consts.

Thanks for the tip. This is what I came up with:

----------------------------------

--- a/subversion/svnsync/main.c
+++ b/subversion/svnsync/main.c
@@ -754,6 +754,7 @@ typedef struct {
   svn_boolean_t mergeinfo_stripped; /* Did we strip svn:mergeinfo? */
   svn_boolean_t svnmerge_migrated; /* Did we convert svnmerge.py data? */
   svn_boolean_t svnmerge_blocked; /* Was there any blocked svnmerge data? */
+ svn_boolean_t fix_prop_val_eol_style; /* in svn:* props */
 } edit_baton_t;

@@ -1084,6 +1085,22 @@ change_dir_prop(void *dir_baton,
       name = SVN_PROP_MERGEINFO;
       eb->svnmerge_migrated = TRUE;
     }
+ /* Here we force consistent eol-style for svn:* properties that
+ don't have it. not, that by being on the else branch of the
+ previous if, this only kicks in if we haven't already
+ rewritten the property as part of a merge-info conversion. */
+ else if (eb->fix_prop_val_eol_style && svn_prop_is_svn_prop(name) && value)
+ {
+ /* Only actually do the conversion if there's actually at
+ least one \r present. Is this premature optimzation? */
+ if (strchr(value->data, '\r'))
+ {
+ apr_array_header_t *lines =
+ svn_cstring_split(value->data, "\r\n", FALSE, pool);
+ const char *joined_lines = svn_cstring_join(lines, "\n", pool);
+ real_value = svn_string_create(joined_lines, pool);
+ }
+ }

   /* Remember if we see any svnmerge-blocked properties. */
   if (eb->migrate_svnmerge && (strcmp(name, "svnmerge-blocked") == 0))
@@ -1198,6 +1215,12 @@ get_sync_editor(const svn_delta_editor_t *wrapped_editor,
       eb->migrate_svnmerge = TRUE;
       eb->strip_mergeinfo = TRUE;
     }
+ if (getenv("SVNSYNC_FIX_PROP_VAL_EOL_STYLE"))
+ {
+ /* force consistent eol-style on svn:* properties by stripping
+ \r, leaving only \n as line terminator. */
+ eb->fix_prop_val_eol_style = TRUE;
+ }

   *editor = tree_editor;
   *edit_baton = eb;

-----------------------

It works for me, and I think I'll patch my local svnsync this way
until we've migrated the central servers to 1.6 and cleaned up our
repositories accordingly.

The svn internals are still pretty opaque to me, so this is monkey
(see, monkey do) code. Am I doing anything here that seems obviously
wrong?

The bash script below demonstrates the behavior in combination with
the repo.dump file attached to the first message in this thread.

--------------------------

#!/bin/bash

# set as appropriate
SVNSYNC=../installed/bin/svnsync
SVNADMIN=../installed/bin/svnadmin
DUMPFILE=repo.dump

test ! -d repo || rm -rf repo
$SVNADMIN create repo
$SVNADMIN load repo < $DUMPFILE

test ! -d clone || rm -rf clone
$SVNADMIN create clone
ln -s /bin/true clone/hooks/pre-revprop-change
$SVNSYNC init file://$PWD/clone file://$PWD/repo

unset SVNSYNC_FIX_PROP_VAL_EOL_STYLE
echo "* svnsync without SVNSYNC_FIX_PROP_VAL_EOL_STYLE"
if $SVNSYNC sync file://$PWD/clone
then echo "** svnsync fix should have failed here."
else echo "** svnsync failed as expected"
fi

export SVNSYNC_FIX_PROP_VAL_EOL_STYLE=1
echo "* svnsync with SVNSYNC_FIX_PROP_VAL_EOL_STYLE"
if $SVNSYNC sync file://$PWD/clone
then echo "** svnsync succeeded as expected"
else echo "** svnsync should have succeeded, but failed instead"
fi

--------------------------

// Ben

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1470762

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-29 15:39:17 CEST