Re: "svn pget svn:externals -r . -R" dramatically slow

So, for the time being you could use this as a workaround, Andrey (if you're scripting this): checkout to a temp directory (or even aramdisk if it's not too big), and run the propget on that; then deletethe checkout. I can not afford to check out everything in the temp, it would be slower

RE: "svn pget svn:externals -r . -R" dramatically slow

> -Original Message- > From: Branko Čibej [mailto:br...@apache.org] > Sent: donderdag 18 mei 2017 15:19 > To: users@subversion.apache.org > Cc: Andrey <an...@inbox.ru> > Subject: Re: "svn pget svn:externals -r . -R" dramatically slow > > On 18

Re: "svn pget svn:externals -r . -R" dramatically slow

On Thu, May 18, 2017 at 8:22 PM, Branko Čibej wrote: > On 18.05.2017 16:21, Andrey wrote: >> Stefan Sperling писал(а) в своём письме Thu, 18 May >> 2017 15:55:36 +0300: >> >>> And this, we have to admit, can be a problem for some use cases. >>> It would be nice

Re: "svn pget svn:externals -r . -R" dramatically slow

On 18.05.2017 16:21, Andrey wrote: > Stefan Sperling писал(а) в своём письме Thu, 18 May > 2017 15:55:36 +0300: > >> And this, we have to admit, can be a problem for some use cases. >> It would be nice to have an optimized way of doing this, >> and I expect we would be open to

Re: "svn pget svn:externals -r . -R" dramatically slow

Stefan Sperling писал(а) в своём письме Thu, 18 May 2017 15:55:36 +0300: And this, we have to admit, can be a problem for some use cases. It would be nice to have an optimized way of doing this, and I expect we would be open to suggestions and patches. I tested it a bit

Re: "svn pget svn:externals -r . -R" dramatically slow

On 18.05.2017 15:51, Andrey wrote: > Branko Čibej писал(а) в своём письме Thu, 18 May > 2017 16:19:23 +0300: > >>> may be add file content hash to represent 2 statuses of the same file >>> paths? At least it will protect file from accidental remove and miss >>> of add to commit?

Re: "svn pget svn:externals -r . -R" dramatically slow

Branko Čibej писал(а) в своём письме Thu, 18 May 2017 16:19:23 +0300: may be add file content hash to represent 2 statuses of the same file paths? At least it will protect file from accidental remove and miss of add to commit? There will be no accidental remove; when you

Re: "svn pget svn:externals -r . -R" dramatically slow

Johan Corveleyn писал(а) в своём письме Thu, 18 May 2017 15:51:01 +0300: Why just not to ignore them? Anyway they are don't have any mapping to a local directory. In general I think it's fine for a directory to have an empty svn:externals property (have not tested it,

Re: "svn pget svn:externals -r . -R" dramatically slow

On 18.05.2017 13:51, Andrey wrote: > Branko Čibej писал(а) в своём письме Thu, 18 May > 2017 14:41:17 +0300: > >>> However, I don't want to revert anything, i am talking about >>> possibility of forget to add files because they are obscured by the >>> deletion state in the

Re: "svn pget svn:externals -r . -R" dramatically slow

On Thu, May 18, 2017 at 02:51:01PM +0200, Johan Corveleyn wrote: > (like Bert said, "There is no optimized code path > for retrieving properties recursively directly from the server.") And this, we have to admit, can be a problem for some use cases. It would be nice to have an optimized way of

Re: "svn pget svn:externals -r . -R" dramatically slow

On Thu, May 18, 2017 at 1:58 PM, Andrey wrote: >>> Why is that important when the links are empty? >> >> External references are stored in properties called svn:externals. >> I think Bert is referring to the retrieval of those properties. > > I meant an external reference of

Re: "svn pget svn:externals -r . -R" dramatically slow

On Thu, May 18, 2017 at 02:58:51PM +0300, Andrey wrote: > > > Why is that important when the links are empty? > > External references are stored in properties called svn:externals. > > I think Bert is referring to the retrieval of those properties. > I meant an external reference of cause. By the

Re: "svn pget svn:externals -r . -R" dramatically slow

First a couple questions to get our context right: what version of svn on the client and on the server? Is there a slow network between client and server, or are they on the same LAN? svn --version ``` svn, version 1.9.5 (r1770682) compiled Nov 26 2016, 14:22:31 on x86-microsoft-windows

Re: "svn pget svn:externals -r . -R" dramatically slow

First a couple questions to get our context right: what version of svn on the client and on the server? Is there a slow network between client and server, or are they on the same LAN? svn --version ``` svn, version 1.9.5 (r1770682) compiled Nov 26 2016, 14:22:31 on x86-microsoft-windows

Re: "svn pget svn:externals -r . -R" dramatically slow

Why is that important when the links are empty? External references are stored in properties called svn:externals. I think Bert is referring to the retrieval of those properties. I meant an external reference of cause. By the link i mean peace of string in the output from the "svn pget

Re: "svn pget svn:externals -r . -R" dramatically slow

Branko Čibej писал(а) в своём письме Thu, 18 May 2017 14:41:17 +0300: However, I don't want to revert anything, i am talking about possibility of forget to add files because they are obscured by the deletion state in the status. So what do you suggest we do instead?

Re: "svn pget svn:externals -r . -R" dramatically slow

On 18.05.2017 13:27, Andrey wrote: >>> As you see the file1.txt is missed in second status output as >>> unversioned and so can be missed from add before a commit. >> It's not unversioned, it's in the "deleted" state. You can't have both, >> since you can revert the deletion. > If i'll revert it

Re: "svn pget svn:externals -r . -R" dramatically slow

First a couple questions to get our context right: what version of svn on the client and on the server? Is there a slow network between client and server, or are they on the same LAN? svn --version ``` svn, version 1.9.5 (r1770682) compiled Nov 26 2016, 14:22:31 on x86-microsoft-windows

Re: "svn pget svn:externals -r . -R" dramatically slow

On Thu, May 18, 2017 at 02:17:26PM +0300, Andrey wrote: > Bert Huijben писал(а) в своём письме Thu, 18 May 2017 > 13:09:07 +0300: > > > There is no optimized code path for retrieving properties recursively > > directly from the server. > > > > The implementation of this specific

Re: "svn pget svn:externals -r . -R" dramatically slow

As you see the file1.txt is missed in second status output as unversioned and so can be missed from add before a commit. It's not unversioned, it's in the "deleted" state. You can't have both, since you can revert the deletion. If i'll revert it then i'll LOSE CHANGES because the svn will remove

Re: "svn pget svn:externals -r . -R" dramatically slow

Bert Huijben писал(а) в своём письме Thu, 18 May 2017 13:09:07 +0300: There is no optimized code path for retrieving properties recursively directly from the server. The implementation of this specific command is like running 'svn ls' on every directory + fetching the

RE: "svn pget svn:externals -r . -R" dramatically slow

> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: woensdag 17 mei 2017 19:57 > To: Andry <an...@inbox.ru> > Cc: users@subversion.apache.org > Subject: Re: "svn pget svn:externals -r . -R" dramatically slow > >

Re: "svn pget svn:externals -r . -R" dramatically slow

On Tue, May 16, 2017 at 11:42 PM, Andry wrote: > Hello Users, > > Original issue: https://issues.apache.org/jira/browse/SVN-4681 > > Just discovered a really strange case where exactly titled command bring > really slow response. > > The repository contains more than 1000