Re: info subversion
Guten Tag filomena ciola, am Montag, 10. Oktober 2011 um 18:28 schrieben Sie: > I need to erase all the old revisions, if it' s possible, how can I do for > make this automatically? This is no supported use case. Depending on what problem you really try to solve, as Mark already asked, you may think of creating new repositories with some versions dumped from old ones. But this wouldn't sound you really want version control either. > if this isn't possible, can I put a pw so only > authorized personell can see old revision? No, revisions are nothing where you can directly control access to. One wouldn't want to, there are more or less a technical implementation fact in this case, which the user shouldn't care about. Subversion works on files and folders, this is the abstraction level you have to think of and this is where Subversion gives you the ability to limit access. You can configure to limit read and write access to only authenticated users and even limit access to directories and files to individual users and groups. In the latter case the users and groups can only see the content they have access to, which includes the revisions in which this content is changed. But you can't say that users can only see version 1 to 104, not 105, but 106 to 110. This wouldn't be practical at all. http://svnbook.red-bean.com/en/1.6/svn.serverconfig.pathbasedauthz.html Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
RE: info subversion
> -Original Message- > From: filomena ciola [mailto:ciolafilom...@gmail.com] > Sent: 10 October 2011 17:28 > To: users@subversion.apache.org > Subject: info subversion > > Hello, > Please I need your help for a little question: > I need to erase all the old revisions, if it' s possible, how > can I do for make this automatically? if this isn't possible, > can I put a pw so only authorized personell can see old revision? > Thank you for your interesting > With best regards > > Mimma Ciola > Your question is not very clear, especially for subversion which is after all designed to keep old revisions available. Perhaps you could explain what your problem is (not just what you think the solution might be)? ~ mark c
Re: Best Method to move 500 Repositories
On Mon, Oct 10, 2011 at 5:30 PM, Phil Pinkerton wrote: > Looking for suggestion on best way to move 500 Repositories from Unix > Hardware to VM Linux Server > > old - Unix Server compiled and Built Subversion 1.6.5 from Source > > new - Linux VM Server will have Subversion Edge 1.6.17 > > ACL contains 2000 + users. > > Any experience at this scale ? Advise ? > > looking for clean , simple minimal risk approach. > > thanks There are too many factors to give a single answer. If you can easily establish read-only access for the new server, you can use "svnsync" to mirror all the repositories and keep them updated until the big switchover. Migrating the hook scripts and other configuration files, especially if any of them use symlinks, is your own adventure. This allows you to move a few at a time. And if you've done clever things with your post-commit and pre-commit and access control, you may have to to be creative in migrating those, no matter what OS you use. If you hve HTTP or HTTPS access with Apache, you can also use the "mod_proxy" tools to forwad traffic still pointed at the old server to the new server. And you'll need to think very carefully about *rollback*, the ability to roll back to the old server with the old repos. Frankly, with 500 repos, it may be time to have a talk with WanDisco about their multi-hosting toolkits.
Re: svnsync UTF8 problem
Srdan Dukic wrote on Tue, Oct 11, 2011 at 10:15:53 +1300:
> 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
>
The function is called svn_repos__validate_prop() (with a double
underscore) in 1.7 and had a different name (and was file-private)
in 1.6.
> 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+
>
Search the users@ list archives. _Many_ people asked here about their
non-UTF-8 svn:log properties (and one also asked about his svn:author
properties).
> 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.
>
Yes. The xxd and proplist dumps confirm that the properties are in
UTF-8 and LF linefeeds.
Now, what I'm asking is that you don't file a bug saying "Non-UTF-8
revprops are rejected". That's fine, we know about this, we decided
it's intentional. I do not object (in fact, I'll probably support)
filing bugs for situations where that error is raised even though all
the svn:* properties involved are in UTF-8 and LF linefeeds.
> 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
>
Happy to help, and hope I've clarified my position above. More below...
> 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?
> >
libsvn_subr/utf.c. For future reference, ctags can answer this question
more efficiently than the mailing list.
That said: don't condense double underscores into a single one; that's
wrong in C and in our case also violates our naming convention.
(A double underscore indicates a non-public API symbol.)
> >
> > Thank you
> > --
> > Srdan Dukic
> >
Looking forward, the error message in your Apache log appears only in
one place in the source (that place is svn_repos__validate_prop() which
I already mentioned), so I'd suggest looking for the property or
revision property that triggers throwing the error there.
(Usually subversion/po/*.po can tell you where a given error message
appears in the source.)
HTH,
Daniel
> > 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
Best Method to move 500 Repositories
Looking for suggestion on best way to move 500 Repositories from Unix Hardware to VM Linux Server old - Unix Server compiled and Built Subversion 1.6.5 from Source new - Linux VM Server will have Subversion Edge 1.6.17 ACL contains 2000 + users. Any experience at this scale ? Advise ? looking for clean , simple minimal risk approach. thanks
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 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://subve
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
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
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
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
> 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
info subversion
Hello, Please I need your help for a little question: I need to erase all the old revisions, if it' s possible, how can I do for make this automatically? if this isn't possible, can I put a pw so only authorized personell can see old revision? Thank you for your interesting With best regards * Mimma Ciola *
RE: svn relocate on 1.7.0-rc4 doesn't work on subdirectories anymore?
Our source tree is quite big (2G), and we provide svn:// access for RO and https:// access for RW using a SSO solution for authorization. Our scripts allow our users to perform a sparse checkout, and when they need to actually checkout something big, basically this is what we used to do. svn up --set-depth empty WC/bigSubDir svn sw --relocate RW_URL RO_URL WC/bigSubDir svn up --set-depth infinity WC/bigSubDir svn sw --relocate RO_URL RW_URL WC/bigSubDir This would speed up the big update (infinity) by about 60% in our case. The reason why we did it this way (relocating the subdir) is because in case the user had another big subdirectory checked out with infinity, the first svn switch would take so long that it was no longer worth it. I've been testing this with 1.7-rc4 and this is no longer the case, meaning the "svn relocate URL" seems to take constant time, independent of the size and amount of WC/subdir(s) you have. I guess that is expected with WC-NG since it only has to change metadata in one place. More and more this seems to be a non-issue for on my case. Regards Christian Asmussen -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: 10 October 2011 15:32 To: Asmussen, Christian; users@subversion.apache.org Subject: RE: svn relocate on 1.7.0-rc4 doesn't work on subdirectories anymore? > Hi, > On subversion 1.6 I am able to: > svn sw -relocate FROM_URL TO_URL WC/subdir > > When I try this on 1.7.0-rc4 I get an error E155019: > svn: E155019: Cannot relocate 'WC/subdir' as it is not the root > of a working copy; try relocating 'WC' instead. > > I noticed that the "-relocate" option has been deprecated by "svn relocate" > and from the documentation it changes the url of "the working copy". > > Is there a plan to support relocating subdirectories or is this feature "gone"? > > Thanks for any help! > Christian Asmussen > I'm curious what's the use case here. Relocate is used when you move a repository to a new location (URL). So, you moved your server but don't want to point the full working directory to the new server location? BOb Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS reserves the right to retain all messages. Messages are protected and accessed only in legally justified cases.
RE: svn relocate on 1.7.0-rc4 doesn't work on subdirectories anymore?
> Hi, > On subversion 1.6 I am able to: > svn sw -relocate FROM_URL TO_URL WC/subdir > > When I try this on 1.7.0-rc4 I get an error E155019: > svn: E155019: Cannot relocate 'WC/subdir' as it is not the root of a > working > copy; try relocating 'WC' instead. > > I noticed that the "-relocate" option has been deprecated by "svn relocate" > and from the documentation it changes the url of "the working copy". > > Is there a plan to support relocating subdirectories or is this feature > "gone"? > > Thanks for any help! > Christian Asmussen > I'm curious what's the use case here. Relocate is used when you move a repository to a new location (URL). So, you moved your server but don't want to point the full working directory to the new server location? BOb
