Deleting a directory with a space in it.
Hi, I've got a directory in subversion with a space in the name which I'd like to delete. This is what I've tried: svn rm http://subversion/src/Repo/Grad Training svn rm "http://subversion/src/Repo/Grad Training" svn rm "http://subversion/src/Repo/Grad%20Training"; svn rm http://subversion/src/Repo/Grad%20Training svn rm http://subversion/src/Repo/Grad\ Training svn rm "http://subversion/src/Repo/Grad\ Training" and I keep getting: svn: URL 'http://subversion/src/Repo/Grad%2520Training' does not exist svn: Your commit message was left in a temporary file: svn:'svn-commit.9.tmp' I've also tried checking out the parent directory, deleting the directory and committing the changes, but I get a permission error: error: you don't have enough permissions for this transaction: you can't remove Grad Training/ and from the Apache logs: [Tue Sep 20 16:28:00 2011] [error] [client 192.168.1.70] Could not MERGE resource "/src/Repo/!svn/act/9f05c85e-f478-4f0e-8d08-d06b5c3d8781" into "/src/Repo". [409, #0] [Tue Sep 20 16:28:00 2011] [error] [client 192.168.1.70] Commit blocked by pre-commit hook (exit code 1) with output:\nerror: you don't have enough permissions for this transaction:\nyou can't remove Grad Training/\n [409, #165001] How do you delete directories with a space in subversion? The version of the client I am running is: # svn --version svn, version 1.6.11 (r934486) compiled May 31 2011, 05:46:33 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet ( http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme Thank you -- Srđan Đukić
Re: Deleting a directory with a space in it.
On 20 September 2011 17:48, Lorenz wrote: > Srdan Dukic wrote: > > I don't think you have a problem with spaces here. > > So, just to confirm, ignoring the permissions issues, the only way to delete a directory with a space in it in Subversion 1.6 is to check out the parent folder, delete the directory in your working copy and commit the changes? -- Srđan Đukić
Re: Deleting a directory with a space in it.
On 21 September 2011 08:53, Stephen Butler wrote:
>
>
> No, you can delete (on the command line) directly in the repository
> by escaping each " " in the URL with "\ " or "%20".
>
>
This is what I've tried:
svn rm http://subversion/src/Repo/Grad Training
svn rm "http://subversion/src/Repo/Grad Training"
svn rm "http://subversion/src/Repo/Grad%20Training";
svn rm http://subversion/src/Repo/Grad%20Training
svn rm http://subversion/src/Repo/Grad\ Training
svn rm "http://subversion/src/Repo/Grad\ Training"
and I keep getting:
svn: URL 'http://subversion/src/Repo/Grad%2520Training' does not exist
svn: Your commit message was left in a temporary file:
svn:'svn-commit.9.tmp'
It seems like it's first escaping the space, making it %20 and then it's
escaping this again to make it %2520. ('%' = '%25' URL encoded).
Cheers
--
Srđan Đukić
svnsync UTF8 problem
Hi, I'm using svnsync to mirror a repository and am doing the initial synchronization, when I get the following error: Transmitting file data .svnsync: At least one property change failed; repository is unchanged svnsync: Error setting property 'log': Could not execute PROPPATCH.Error setting property 'author': Attempted DAV:set operation could not be completed due to other errors.Error setting property 'date': Attempted DAV:set operation could not be completed due to other errors. On the mirror side, I get the following from the Apache logs: [Wed Oct 05 09:46:47 2011] [error] [client 192.168.1.11] Could not execute PROPPATCH. [500, #206] [Wed Oct 05 09:46:47 2011] [error] [client 192.168.1.11] Cannot accept 'svn:log' property because it is not encoded in UTF-8 [500, #125005] [Wed Oct 05 09:46:47 2011] [error] [client 192.168.1.11] Attempted DAV:set operation could not be completed due to other errors. [424, #0] [Wed Oct 05 09:46:47 2011] [error] [client 192.168.1.11] Attempted DAV:set operation could not be completed due to other errors. [424, #0] I've tried converting the 'svn:log' property to UTF8 and syncing as described at: https://help.codesion.com/View.jsp?title=How-to-Deal-with-Svn-Backups-Failing-Due-to-UTF8-Error&procId=fc29d38015b4321e01b645a2e02ae5e9 but still end up getting the same error. I've also tried deleting the 'svn:log' property altogether using 'propdel', but to my surprise, I still get the same error. The actual value of the svn:log property is: "When printing a form through the full task list the client's TEF number has and beside it (for cds)." Which doesn't have any characters that should need any UTF8 handling. Has anyone else had this problem? If so, how did you solve it? The version of both of the subversion source and mirror are 1.6.11 and the command line tools are also this version. Thank you -- Srdan Dukic
Re: svnsync UTF8 problem
So, has no one seen this problem before? I guess I'll have to open a bug report. -- Srdan Dukic On 5 October 2011 11:38, Srdan Dukic wrote: > Hi, > > I'm using svnsync to mirror a repository and am doing the initial > synchronization, when I get the following error: > > Transmitting file data .svnsync: At least one property change failed; > repository is unchanged > svnsync: Error setting property 'log': > Could not execute PROPPATCH.Error setting property 'author': > Attempted DAV:set operation could not be completed due to other > errors.Error setting property 'date': > Attempted DAV:set operation could not be completed due to other errors. > > On the mirror side, I get the following from the Apache logs: > > [Wed Oct 05 09:46:47 2011] [error] [client 192.168.1.11] Could not execute > PROPPATCH. [500, #206] > [Wed Oct 05 09:46:47 2011] [error] [client 192.168.1.11] Cannot accept > 'svn:log' property because it is not encoded in UTF-8 [500, #125005] > [Wed Oct 05 09:46:47 2011] [error] [client 192.168.1.11] Attempted DAV:set > operation could not be completed due to other errors. [424, #0] > [Wed Oct 05 09:46:47 2011] [error] [client 192.168.1.11] Attempted DAV:set > operation could not be completed due to other errors. [424, #0] > > I've tried converting the 'svn:log' property to UTF8 and syncing as > described at: > > > https://help.codesion.com/View.jsp?title=How-to-Deal-with-Svn-Backups-Failing-Due-to-UTF8-Error&procId=fc29d38015b4321e01b645a2e02ae5e9 > > but still end up getting the same error. I've also tried deleting the > 'svn:log' property altogether using 'propdel', but to my surprise, I still > get the same error. > > The actual value of the svn:log property is: > > "When printing a form through the full task list the client's TEF number > has and beside it (for cds)." > > Which doesn't have any characters that should need any UTF8 handling. > > Has anyone else had this problem? If so, how did you solve it? > > The version of both of the subversion source and mirror are 1.6.11 and the > command line tools are also this version. > > Thank you > -- > Srdan Dukic >
Re: svnsync UTF8 problem
> Odd. Perhaps some other revision property of that revision contains > non-UTF-8? > The other revision properties are: # svn proplist --revprop -r 6107 http://subversion/project/Flow Unversioned properties on revision 6107: svn:log svn:author svn:date > > > The actual value of the svn:log property is: > > > > > > "When printing a form through the full task list the client's TEF > number > > > has and beside it (for cds)." > > > > > > Which doesn't have any characters that should need any UTF8 handling. > > > > > svn propget --revprop -rN --strict svn:log | xxd > When I look at the contents of the properties, they all seem to be in regular ASCII: # svn propget --revprop -r 6107 --strict svn:author http://subversion/project/Flow | xxd 000: 5869 6e67Xing # svn propget --revprop -r 6107 --strict svn:date http://subversion/project/Flow | xxd 000: 3230 3034 2d30 342d 3238 5430 313a 3331 2004-04-28T01:31 010: 3a34 302e 3030 3030 3030 5a :40.00Z # svn propget --revprop -r 6107 --strict svn:log http://subversion/project/Flow | xxd 000: 5768 656e 2070 7269 6e74 696e 6720 6120 When printing a 010: 666f 726d 2074 6872 6f75 6768 2074 6865 form through the 020: 2066 756c 6c20 7461 736b 206c 6973 7420 full task list 030: 7468 6520 636c 6965 6e74 2773 204e 4849 the client's NHI 040: 206e 756d 6265 7220 6861 7320 3c42 3e20 number has 050: 616e 6420 3c2f 423e 2062 6573 6964 6520 and beside 060: 6974 2028 666f 7220 6364 7329 2e it (for cds). > > Has anyone else had this problem? If so, how did you solve it? > > > > > svnsync sync --source-prop-encoding > > Is this a valid option to pass to svnsync? When I attempt to run svnsync with this option, I get the following error: svnsync: invalid option: --source-prop-encoding The only other thing I can think of is that the original commit may have been done on a windows machine where the locale was set to some non-english value, but even then, the properties seem to all be in plain ASCII Thank you -- Srdan Dukic
Re: svnsync UTF8 problem
Thank you for your help. I'll try and turn on debugging on the dav_svn module to see what actual values are being passed across the network and if that doesn't turn up anything, I guess I'll just ask on the dev mailing list or open a bug. Thanks again -- Srdan Dukic On 11 October 2011 08:40, Daniel Shahaf wrote: > Your revprops values are all ASCII and LF linefeeds, so r6107 should > get committed to the mirror without issue. The --source-prop-encoding > is new in 1.7. > > So, yes, if you're still seeing the error *while syncing r6107* (i.e., > mirror HEAD is r6106), I'm not really sure what's going on. > > Srdan Dukic wrote on Tue, Oct 11, 2011 at 08:29:04 +1300: > > > Odd. Perhaps some other revision property of that revision contains > > > non-UTF-8? > > > > > > > The other revision properties are: > > > > # svn proplist --revprop -r 6107 http://subversion/project/Flow > > Unversioned properties on revision 6107: > > svn:log > > svn:author > > svn:date > > > > > > > > > The actual value of the svn:log property is: > > > > > > > > > > "When printing a form through the full task list the client's TEF > > > number > > > > > has and beside it (for cds)." > > > > > > > > > > Which doesn't have any characters that should need any UTF8 > handling. > > > > > > > > > > > svn propget --revprop -rN --strict svn:log | xxd > > > > > > > When I look at the contents of the properties, they all seem to be in > > regular ASCII: > > > > # svn propget --revprop -r 6107 --strict svn:author > > http://subversion/project/Flow | xxd > > 000: 5869 6e67Xing > > > > # svn propget --revprop -r 6107 --strict svn:date > > http://subversion/project/Flow | xxd > > 000: 3230 3034 2d30 342d 3238 5430 313a 3331 2004-04-28T01:31 > > 010: 3a34 302e 3030 3030 3030 5a :40.00Z > > > > # svn propget --revprop -r 6107 --strict svn:log > > http://subversion/project/Flow | xxd > > 000: 5768 656e 2070 7269 6e74 696e 6720 6120 When printing a > > 010: 666f 726d 2074 6872 6f75 6768 2074 6865 form through the > > 020: 2066 756c 6c20 7461 736b 206c 6973 7420 full task list > > 030: 7468 6520 636c 6965 6e74 2773 204e 4849 the client's NHI > > 040: 206e 756d 6265 7220 6861 7320 3c42 3e20 number has > > 050: 616e 6420 3c2f 423e 2062 6573 6964 6520 and beside > > 060: 6974 2028 666f 7220 6364 7329 2e it (for cds). > > > > > > Has anyone else had this problem? If so, how did you solve it? > > > > > > > > > > > svnsync sync --source-prop-encoding > > > > > > > > Is this a valid option to pass to svnsync? When I attempt to run svnsync > > with this option, I get the following error: > > > > svnsync: invalid option: --source-prop-encoding > > > > The only other thing I can think of is that the original commit may have > > been done on a windows machine where the locale was set to some > non-english > > value, but even then, the properties seem to all be in plain ASCII > > > > Thank you > > -- > > Srdan Dukic >
Re: svnsync UTF8 problem
I had no intention of filing a bug until I had done as much debugging as
possible, not being a developer myself. Thank you for your advice about
where to look for the error in the source code. I can see that the error is
thrown in the 'svn_repos_validate_prop' function in the file you mentioned.
Specifically, the line is 182:
/* Validate "svn:" properties. */ 176 if (svn_prop_is_svn_prop(name) &&
value != NULL) 177 { 178 /* Validate that translated props (e.g., svn:log)
are UTF-8 with 179 * LF line endings. */ 180 if
(svn_prop_needs_translation(name)) 181 { 182 if
(svn_utf__is_valid(value->data, value->len) == FALSE) 183 { 184 return
svn_error_createf 185 (SVN_ERR_BAD_PROPERTY_VALUE, NULL, 186 _("Cannot
accept '%s' property because it is not encoded in " 187 "UTF-8"), name);
188 }
So, it seems that the "svn_utf_is_valid" function is the one that is
rejecting this value. Would you happen to know where this function is
defined?
Thank you
--
Srdan Dukic
On 11 October 2011 09:08, Daniel Shahaf wrote:
> Don't and don't.
>
> If you want to see what values cross the network, go to the validation
> function in libsvn_repos/fs-wrap.c that generates the error message you
> get.
>
> And I _am_ a developer, and I already asked you not to file a bug.
> Please don't until you have identified a problem we don't already know
> about. Thanks.
>
> Srdan Dukic wrote on Tue, Oct 11, 2011 at 08:59:38 +1300:
> > Thank you for your help. I'll try and turn on debugging on the dav_svn
> > module to see what actual values are being passed across the network and
> if
> > that doesn't turn up anything, I guess I'll just ask on the dev mailing
> list
> > or open a bug.
> >
> > Thanks again
> > --
> > Srdan Dukic
> >
> > On 11 October 2011 08:40, Daniel Shahaf wrote:
> >
> > > Your revprops values are all ASCII and LF linefeeds, so r6107 should
> > > get committed to the mirror without issue. The --source-prop-encoding
> > > is new in 1.7.
> > >
> > > So, yes, if you're still seeing the error *while syncing r6107* (i.e.,
> > > mirror HEAD is r6106), I'm not really sure what's going on.
> > >
> > > Srdan Dukic wrote on Tue, Oct 11, 2011 at 08:29:04 +1300:
> > > > > Odd. Perhaps some other revision property of that revision
> contains
> > > > > non-UTF-8?
> > > > >
> > > >
> > > > The other revision properties are:
> > > >
> > > > # svn proplist --revprop -r 6107 http://subversion/project/Flow
> > > > Unversioned properties on revision 6107:
> > > > svn:log
> > > > svn:author
> > > > svn:date
> > > >
> > > >
> > > > > > > The actual value of the svn:log property is:
> > > > > > >
> > > > > > > "When printing a form through the full task list the client's
> TEF
> > > > > number
> > > > > > > has and beside it (for cds)."
> > > > > > >
> > > > > > > Which doesn't have any characters that should need any UTF8
> > > handling.
> > > > > > >
> > > > >
> > > > > svn propget --revprop -rN --strict svn:log | xxd
> > > > >
> > > >
> > > > When I look at the contents of the properties, they all seem to be in
> > > > regular ASCII:
> > > >
> > > > # svn propget --revprop -r 6107 --strict svn:author
> > > > http://subversion/project/Flow | xxd
> > > > 000: 5869 6e67Xing
> > > >
> > > > # svn propget --revprop -r 6107 --strict svn:date
> > > > http://subversion/project/Flow | xxd
> > > > 000: 3230 3034 2d30 342d 3238 5430 313a 3331 2004-04-28T01:31
> > > > 010: 3a34 302e 3030 3030 3030 5a :40.00Z
> > > >
> > > > # svn propget --revprop -r 6107 --strict svn:log
> > > > http://subversion/project/Flow | xxd
> > > > 000: 5768 656e 2070 7269 6e74 696e 6720 6120 When printing a
> > > > 010: 666f 726d 2074 6872 6f75 6768 2074 6865 form through the
> > > > 020: 2066 756c 6c20 7461 736b 206c 6973 7420 full task list
> > > > 030: 7468 6520 636c 6965 6e74 2773 204e 4849 the client's NHI
> > > > 040: 206e 756d 6265 7220 6861 7320 3c42 3e20 number has
> > > > 050: 616e 6420 3c2f 423e 2062 6573 6964 6520 and beside
> > > > 060: 6974 2028 666f 7220 6364 7329 2e it (for cds).
> > > >
> > > > > > Has anyone else had this problem? If so, how did you solve it?
> > > > > > >
> > > > >
> > > > > svnsync sync --source-prop-encoding
> > > > >
> > > > >
> > > > Is this a valid option to pass to svnsync? When I attempt to run
> svnsync
> > > > with this option, I get the following error:
> > > >
> > > > svnsync: invalid option: --source-prop-encoding
> > > >
> > > > The only other thing I can think of is that the original commit may
> have
> > > > been done on a windows machine where the locale was set to some
> > > non-english
> > > > value, but even then, the properties seem to all be in plain ASCII
> > > >
> > > > Thank you
> > > > --
> > > > Srdan Dukic
> > >
>
Re: svnsync UTF8 problem
I'm not going to open a bug, I just wanted to search to see whether there
were any existing issues and this is what I found:
I went to the Subversion bug tracker and searched for the phrase
"svn_utf__is_valid" which turned up three results, none of which seem to be
related:
http://subversion.tigris.org/issues/buglist.cgi?long_desc_type=fulltext&long_desc=svn_utf__is_valid
I also did a search for the "svn_repos_validate_prop" function, but this
didn't return any results:
http://subversion.tigris.org/issues/buglist.cgi?long_desc_type=fulltext&long_desc=svn_repos_validate_prop
Am I searching correctly? Searching for the error message, returns a large
number of errors, most of which seem irrelevant:
http://subversion.tigris.org/issues/buglist.cgi?long_desc_type=fulltext&long_desc=Cannot+accept+%27svn%3Alog%27+property+because+it+is+not+encoded+in+UTF-8+
The one issue that I saw that might be related is
http://subversion.tigris.org/issues/show_bug.cgi?id=3817. However, I think
that we've established that the source property is in ASCII, which should be
compatible with UTF-8.
Thank you again for your help, it's great to have someone who's working on
the Subversion code looking at the problem.
Thank you
--
Srdan Dukic
On 11 October 2011 09:38, Srdan Dukic wrote:
> I had no intention of filing a bug until I had done as much debugging as
> possible, not being a developer myself. Thank you for your advice about
> where to look for the error in the source code. I can see that the error is
> thrown in the 'svn_repos_validate_prop' function in the file you mentioned.
> Specifically, the line is 182:
>
> /* Validate "svn:" properties. */ 176 if (svn_prop_is_svn_prop(name) &&
> value != NULL) 177 { 178 /* Validate that translated props (e.g.,
> svn:log) are UTF-8 with 179 * LF line endings. */ 180 if
> (svn_prop_needs_translation(name)) 181 { 182 if
> (svn_utf__is_valid(value->data, value->len) == FALSE) 183 { 184 return
> svn_error_createf 185 (SVN_ERR_BAD_PROPERTY_VALUE, NULL, 186 _("Cannot
> accept '%s' property because it is not encoded in " 187 "UTF-8"), name);
> 188 }
> So, it seems that the "svn_utf_is_valid" function is the one that is
> rejecting this value. Would you happen to know where this function is
> defined?
>
>
> Thank you
> --
> Srdan Dukic
>
> On 11 October 2011 09:08, Daniel Shahaf wrote:
>
>> Don't and don't.
>>
>> If you want to see what values cross the network, go to the validation
>> function in libsvn_repos/fs-wrap.c that generates the error message you
>> get.
>>
>> And I _am_ a developer, and I already asked you not to file a bug.
>> Please don't until you have identified a problem we don't already know
>> about. Thanks.
>>
>> Srdan Dukic wrote on Tue, Oct 11, 2011 at 08:59:38 +1300:
>> > Thank you for your help. I'll try and turn on debugging on the dav_svn
>> > module to see what actual values are being passed across the network and
>> if
>> > that doesn't turn up anything, I guess I'll just ask on the dev mailing
>> list
>> > or open a bug.
>> >
>> > Thanks again
>> > --
>> > Srdan Dukic
>> >
>> > On 11 October 2011 08:40, Daniel Shahaf wrote:
>> >
>> > > Your revprops values are all ASCII and LF linefeeds, so r6107 should
>> > > get committed to the mirror without issue. The --source-prop-encoding
>> > > is new in 1.7.
>> > >
>> > > So, yes, if you're still seeing the error *while syncing r6107* (i.e.,
>> > > mirror HEAD is r6106), I'm not really sure what's going on.
>> > >
>> > > Srdan Dukic wrote on Tue, Oct 11, 2011 at 08:29:04 +1300:
>> > > > > Odd. Perhaps some other revision property of that revision
>> contains
>> > > > > non-UTF-8?
>> > > > >
>> > > >
>> > > > The other revision properties are:
>> > > >
>> > > > # svn proplist --revprop -r 6107 http://subversion/project/Flow
>> > > > Unversioned properties on revision 6107:
>> > > > svn:log
>> > > > svn:author
>> > > > svn:date
>> > > >
>> > > >
>> > > > > > > The actual value of the svn:log property is:
>> > > > > > >
>> > > > > > > "When printing a form through the full task list the client's
>> TEF
>> > > > > number
>> > > > > > > has
Editing svn:log property on file
Hi, I'm trying to setup an subversion replication between two servers (both running version 1.6.11). When I try to replicate the data, I get the following error in the logs: Cannot accept 'svn:log' property because it is not encoded in UTF-8 [500, #125005] I've figured out which property it is, but the problem is that it is the property on the file that was modified itself, rather than on the revision. This is the "svn:log" property on the revision, which is not causing the problem (I've modified it to remove and special characters and ran it through xxd): $ svn propget --revprop -r 6107 --strict svn:log " http://subversion/src/Flow/"; When printing a form through the full task list the clients NHI number has B and B beside it for cds. This is the "svn:log" property on the actual file which was modified, which I believe is causing the issue (see the formatting around "client"): $ svn proplist -v servicePack_merge.c5x Properties on 'servicePack_merge.c5x': svn:log When printing a form through the full task list the client?\146s NHI number has and beside it (for cds). svn:author Xing svn:date 2004-04-28T01:31:40.00Z I've tried modifying this property on the file, as opposed to the revision, with not much luck. The following command lets me modify the revision "svn:log" as opposed to the one associated directly with the file: svn propedit -r 6107 --revprop svn:log " http://subversion/src/Flow/trunk/servicePack_merge.c5x"; I've also tried this command to edit the property: svn propedit -r 6107 svn:log http://subversion/src/Flow/trunk/servicePack_merge.c5x svn: Try 'svn help' for more info svn: Cannot specify revision for editing versioned property 'svn:log' But still no luck. Can anyone tell me how to modify the "svn:log" property on the file itself, as opposed to the revision property? Has anyone seen this issue before? Thank you -- Srdan Dukic
Re: Editing svn:log property on file
Thanks for that. Using svnadmin "dump" and then "load" worked. I didn't even have to pass the "--bypass-prop-validation" option to the load command, as it seems the non-UTF8 symbols were converted to a "?" by the dump command. -- Srdan Dukic On 30 October 2012 15:57, Daniel Shahaf wrote: > Srdan Dukic wrote on Tue, Oct 30, 2012 at 15:20:24 +1300: > > Hi, > > > > I'm trying to setup an subversion replication between two servers (both > > running version 1.6.11). When I try to replicate the data, I get the > > following error in the logs: > ... > > But still no luck. Can anyone tell me how to modify the "svn:log" > property > > on the file itself, as opposed to the revision property? Has anyone seen > > this issue before? > > By the way, there is another solution: you try doing a dump/load of the > revision that sets the bogus property value. (Dump from the master, > load on the slave.) (You could generate the dump with svnrdump -r N or > with 'svnadmin dump -r N --deltas --incremental'.) Pass > --bypass-prop-validation to 'svnadmin load'. > > [ Note for the archives: the sense of the --bypass-prop-validation > boolean (presence/absence) flag was reversed, for revision properties > only, up to 1.7.7 (inclusive). See r1237779. ] >
Re: Editing svn:log property on file
Checked it by examining the contents of the dump file (cat [dumpfile]). Where I expected to see: client?\146s I instead got: client?s Then, after copying it over to the slave and running "load", without the "--bypass-prop-validation" flag, the dump is loaded without any errors complaining about the encoding of the properties. -- Srdan Dukic On 30 October 2012 16:51, Daniel Shahaf wrote: > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:45:36 +1300: > > Thanks for that. Using svnadmin "dump" and then "load" worked. > > > > I didn't even have to pass the "--bypass-prop-validation" option to the > > load command, as it seems the non-UTF8 symbols were converted to a "?" by > > the dump command. > > How are you checking that? The 'dump' command doesn't know about UTF-8 > requirements for property values; it should preserve arbitrary byte > sequences. (In other words, the output of 'propget --strict | xxd' > should be identical between master and slave.) >
Re: Editing svn:log property on file
Hmmm... yes indeed. This does seem to be the case, as the same developer committed the same file, with the same log message in another location, and this time the dump/load is not working. Even though the load doesn't throw any errors, when continuing with the svnsync after loading, it starts complaining about UTF-8 again and won't load the version. -- Srdan Dukic On 30 October 2012 17:04, Daniel Shahaf wrote: > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:58:01 +1300: > > Checked it by examining the contents of the dump file (cat [dumpfile]). > > Where I expected to see: > > > > client?\146s > > > > Wrong expectation, dump files never include this syntax. > > > I instead got: > > > > client?s > > > > This doesn't say whether it was a literal question mark (0x3F) in the > file or not. > > > > Then, after copying it over to the slave and running "load", without the > > "--bypass-prop-validation" flag, the dump is loaded without any errors > > complaining about the encoding of the properties. > > > > -- > > Srdan Dukic > > > > On 30 October 2012 16:51, Daniel Shahaf wrote: > > > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:45:36 +1300: > > > > Thanks for that. Using svnadmin "dump" and then "load" worked. > > > > > > > > I didn't even have to pass the "--bypass-prop-validation" option to > the > > > > load command, as it seems the non-UTF8 symbols were converted to a > "?" by > > > > the dump command. > > > > > > How are you checking that? The 'dump' command doesn't know about UTF-8 > > > requirements for property values; it should preserve arbitrary byte > > > sequences. (In other words, the output of 'propget --strict | xxd' > > > should be identical between master and slave.) > > > >
Re: Editing svn:log property on file
Yes, it was the "svn:log" property on the revision (as opposed to the node) which was causing the issue. Was able to modify it with the "propset" command and it has allowed svnsync to continue the sync. So, the file to be patched is: http://svn.apache.org/repos/asf/subversion/trunk/subversion/svnsync/sync.c Is it the section that's commented as "Normalize svn:* properties as necessary." that the error's being thrown? -- Srdan Dukic On 30 October 2012 17:21, Daniel Shahaf wrote: > IIRC svnsync would only complain about revisions add or modify an > svn:log property --- other changes to files having that property (even > with a bad value) should sync errorlessly. See validate_revision() in > subversion/libsvn_repos/fs-wrap.c > > Anyway. I suggest you figure out a way to exclude "svn:log" node > properties from the sync. If there is an easier way to do that than to > patch change_file_prop() in subversion/svnsync/, I'm sure someone will > suggest it. > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 17:15:18 +1300: > > Hmmm... yes indeed. This does seem to be the case, as the same developer > > committed the same file, with the same log message in another location, > and > > this time the dump/load is not working. > > > > Even though the load doesn't throw any errors, when continuing with the > > svnsync after loading, it starts complaining about UTF-8 again and won't > > load the version. > > > > -- > > Srdan Dukic > > > > On 30 October 2012 17:04, Daniel Shahaf wrote: > > > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:58:01 +1300: > > > > Checked it by examining the contents of the dump file (cat > [dumpfile]). > > > > Where I expected to see: > > > > > > > > client?\146s > > > > > > > > > > Wrong expectation, dump files never include this syntax. > > > > > > > I instead got: > > > > > > > > client?s > > > > > > > > > > This doesn't say whether it was a literal question mark (0x3F) in the > > > file or not. > > > > > > > > > > Then, after copying it over to the slave and running "load", without > the > > > > "--bypass-prop-validation" flag, the dump is loaded without any > errors > > > > complaining about the encoding of the properties. > > > > > > > > -- > > > > Srdan Dukic > > > > > > > > On 30 October 2012 16:51, Daniel Shahaf > wrote: > > > > > > > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:45:36 +1300: > > > > > > Thanks for that. Using svnadmin "dump" and then "load" worked. > > > > > > > > > > > > I didn't even have to pass the "--bypass-prop-validation" option > to > > > the > > > > > > load command, as it seems the non-UTF8 symbols were converted to > a > > > "?" by > > > > > > the dump command. > > > > > > > > > > How are you checking that? The 'dump' command doesn't know about > UTF-8 > > > > > requirements for property values; it should preserve arbitrary byte > > > > > sequences. (In other words, the output of 'propget --strict | xxd' > > > > > should be identical between master and slave.) > > > > > > > > >
