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

[Johan Corveleyn]

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 to have an optimized way of doing this,
>>> and I expect we would be open to suggestions and patches.
>> I tested it a bit deeper.
>> I checked out entire directory for the 1193 revision on the drive
>> (took ~6 seconds) and recall the command w/o "-r " (took ~1 second).
>> I don't think this is about optimization because (i checked it) the
>> server is not so busy to hangs about 1 minute. Is it much like
>> excessive search somethere?
>
> You're making assumptions about the implementation without actually
> looking at it. As Bert said, we don't have an optimized code path for
> recursive search of properties in the repository. It's as simple as that.

Agreed.

Though it's interesting to know that "checkout + recursive propget on
working copy" is an order of magnitude faster than "recursive propget
on url". It illustrates the impact of this non-optimized code path.

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 a
ramdisk if it's not too big), and run the propget on that; then delete
the checkout.

Also, extra help is always welcome here, Andrey. So if you think this
optimization is really important, and you have some time and interest,
we'd certainly welcome a patch to improve this. [1]

[1] See http://subversion.apache.org/docs/community-guide/general.html#patches

-- 
Johan

RE: Error running make for subversion

[Joseph, Anselm]

Thank you both for responding.
When I run configure --without-apxs, make install completes cleanly. But my 
problem is that mod_dav_svn.so is not building . I tried different options and 
still cannot get  mod_dav_svn.so to build. 
When I run .configure with-apxs= /opt/eai/ci/httpd-2.2.32/apache/bin/apxs
make install fails as follows:
if true ; then cd subversion/mod_dav_svn ; 
/opt/eai/ci/subversion/build/install-sh -c -d 
"/opt/eai/ci/subversion-1.9.5/svn/libexec" ; 
/opt/eai/ci/httpd-2.2.32/apache/bin/apxs -i -S 
LIBEXECDIR="/opt/eai/ci/subversion-1.9.5/svn/libexec" -a -n dav_svn 
mod_dav_svn.la ; fi
/opt/eai/ci/httpd-2.2.32/apache/build/instdso.sh 
SH_LIBTOOL='/opt/freeware/lib/apr-1/build/libtool' mod_dav_svn.la 
/opt/eai/ci/subversion-1.9.5/svn/libexec
rm -f /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so
/opt/freeware/lib/apr-1/build/libtool --mode=install cp mod_dav_svn.la 
/opt/eai/ci/subversion-1.9.5/svn/libexec/
libtool: install: warning: relinking `mod_dav_svn.la'
libtool: install: (cd /opt/eai/ci/subversion/subversion/mod_dav_svn; /bin/sh 
"/opt/eai/ci/subversion/libtool"  --tag CC --silent --mode=relink gcc -shared 
-g -O2 -g -O2 -pthread -L/opt/freeware/lib -rpath 
/opt/eai/ci/subversion-1.9.5/svn/libexec -avoid-version -module -o 
mod_dav_svn.la activity.lo authz.lo deadprops.lo liveprops.lo lock.lo merge.lo 
mirror.lo mod_dav_svn.lo posts/create_txn.lo reports/dated-rev.lo 
reports/deleted-rev.lo reports/file-revs.lo reports/get-location-segments.lo 
reports/get-locations.lo reports/get-locks.lo reports/inherited-props.lo 
reports/log.lo reports/mergeinfo.lo reports/replay.lo reports/update.lo 
repos.lo status.lo util.lo version.lo 
../../subversion/libsvn_repos/libsvn_repos-1.la 
../../subversion/libsvn_fs/libsvn_fs-1.la 
../../subversion/libsvn_delta/libsvn_delta-1.la 
../../subversion/libsvn_subr/libsvn_subr-1.la )
libtool: install: cp .libs/mod_dav_svn.aT 
/opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.a
libtool: install: cp .libs/mod_dav_svn.lai 
/opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.la
chmod 755 /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so
chmod: /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so: A file or 
directory in the path name does not exist.
apxs:Error: Command failed with rc=65536
.
make: 1254-004 The error code from the last command is 1.


Stop.

-Original Message-
From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com] 
Sent: Wednesday, May 17, 2017 8:42 PM
To: Daniel Shahaf
Cc: Joseph, Anselm; Subversion Users
Subject: Re: Error running make for subversion

CAUTION - EXTERNAL EMAIL



> On May 17, 2017, at 19:41, Ryan Schmidt  
> wrote:
>
>
>> On May 16, 2017, at 17:18, Daniel Shahaf  wrote:
>>
>> Joseph, Anselm wrote on Tue, May 16, 2017 at 21:04:57 +:
>>> chmod: /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so: A file or 
>>> directory in the path name does not exist.
>>> apxs:Error: Command failed with rc=65536
>>
>> Note that if you use svn:// or svn+ssh://, you don't need mod_dav_svn 
>> and can disable building it with --without-apxs to configure.
>
> You mean http:// and https://. mod_dav_svn isn't involved with svn:// or 
> svn+ssh://.
>

And, sorry, I mis-parsed your sentence. Never mind.

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

[Branko Čibej]

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 suggestions and patches.
> I tested it a bit deeper.
> I checked out entire directory for the 1193 revision on the drive
> (took ~6 seconds) and recall the command w/o "-r " (took ~1 second).
> I don't think this is about optimization because (i checked it) the
> server is not so busy to hangs about 1 minute. Is it much like
> excessive search somethere?

You're making assumptions about the implementation without actually
looking at it. As Bert said, we don't have an optimized code path for
recursive search of properties in the repository. It's as simple as that.

-- Brane

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

[Andrey]

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 deeper.
I checked out entire directory for the 1193 revision on the drive (took ~6  
seconds) and recall the command w/o "-r " (took ~1 second).
I don't think this is about optimization because (i checked it) the server  
is not so busy to hangs about 1 minute. Is it much like excessive search  
somethere?

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

[Branko Čibej]

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?
>>
>> There will be no accidental remove; when you commit, your new file will
>> remain unversioned in the working copy:
> I meant delete revert. It silently replaces unversioned one.


Ah. We probably shouldn't be doing that; silently losing data is bad.

-- Brane

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

[Andrey]

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 commit, your new file will
remain unversioned in the working copy:

I meant delete revert. It silently replaces unversioned one.

In the first case, I suppose we could display something like the  
following:


D  +foo
> moved to bar

or:

D  ?foo
> moved to bar


to indicate that the file was deleted, but still exists on disk.

The more interesting question is how, if at all, this would affect the
Subversion API.

That would be good. Thx!

Re: "svn status" does not show unversioned items been deleted but not committed

[Andrey]

Stefan Sperling  писал(а) в своём письме Thu, 18 May 2017  
15:52:17 +0300:



On Thu, May 18, 2017 at 03:09:51PM +0300, Andrey wrote:

If i'll revert it then i'll LOSE CHANGES


Of course. That is the entire point of this command.

$ svn help revert
revert: Restore pristine working copy state (undo local changes).


If that bothers you, then I would suggest you do not use it.
It looses changes of a file NOT RELATED TO UNDO. It is ANOTHER file just  
missed to be add for commit instead of renamed one. Why the svn does  
silently erase it just because of the name collision? It is definitely a  
not good behavior for the svn.

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

[Andrey]

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, but I guess it's fine). So
the property is there, but has no content. That's not the problem.
When you request "svn propget svn:externals -R $URL" the client and
server still have to do the work to retrieve that property from all
nodes in the entire subtree -- it doesn't matter whether it's empty or
not at this point (it doesn't even matter whether it's defined or not,
they still have to look it up).

To rule out any relation to "svn:externals" in itself, can you test if
you get the same "propget -R" performance if you retrieve another
property with exactly the same command?

For instance, try:
svn pget fooprop "https://domain.ab/svn/proj2/trunk@1193; -R  
--non-interactive
Ok, i see your point. Yes, the svn:ignore works the same way and nothing  
to do with these 2 "external records".



On my svn repository that command takes also a minute or 2 for a
reasonably large tree.

So even without any property defined anywhere, your "propget -R"
request still makes the client (and/or server) crawl the entire
subtree and requesting the property at every node, and this seems to
take a lot of time (like Bert said, "There is no optimized code path
for retrieving properties recursively directly from the server.")
Ok. May be a --depth option for the "svn co" command like "--depth  
directories"

to workaround this for script writers?

I am writing script to collect these externals and seems 1-2 minute of  
waiting one directory of about (i've opened it in the Repository Browser  
and took a look on the depth of directories there, it took 5 seconds) ~100  
subdirectories and ~400 files is not worth to wait so long. So i suggest  
some command to take all these
externals on the drive as is w/o files, for example, in to the TEMP  
directory to traverse it offline.


I don't know, but why is not? At least it could reduce server disk work or  
something.

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

[Branko Čibej]

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 status.
>>
>> So what do you suggest we do instead?
>>
>> There's a file named 'foo' that was deleted with 'svn rm' but not
>> committed, and also a file named 'foo' that you created on disk before
>> committing the deletion (or rename). What do you propose  'svn status'
>> should show?
> 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 commit, your new file will
remain unversioned in the working copy:

brane@zulu:~/test/wc$ svn mv foo bar
A bar
D foo
brane@zulu:~/test/wc$ echo foo > foo
brane@zulu:~/test/wc$ svn st
A  +bar
> moved from foo
D   foo
> moved to bar
brane@zulu:~/test/wc$ svn ci -mm
Adding bar
Deleting   foo
Committing transaction...
Committed revision 2.
brane@zulu:~/test/wc$ svn st
?   foo

So far, this is what you reported. Now see what happens when you
actually run 'svn add' to replace the deleted file:

brane@zulu:~/test/wc$ touch qux
brane@zulu:~/test/wc$ svn add qux 
A qux
brane@zulu:~/test/wc$ svn ci -mm
Adding qux
Transmitting file data .done
Committing transaction...
Committed revision 3.
brane@zulu:~/test/wc$ svn mv qux baz
A baz
D qux
brane@zulu:~/test/wc$ echo qux > qux
brane@zulu:~/test/wc$ svn add qux
A qux
brane@zulu:~/test/wc$ svn st
A  +baz
> moved from qux
?   foo
R   qux
> moved to baz
brane@zulu:~/test/wc$ svn ci -mm
Adding baz
Replacing  qux
Transmitting file data .done
Committing transaction...
Committed revision 4.
brane@zulu:~/test/wc$ svn st
?   foo


In the first case, I suppose we could display something like the following:

D  +foo
> moved to bar

or:

D  ?foo
> moved to bar


to indicate that the file was deleted, but still exists on disk.

The more interesting question is how, if at all, this would affect the
Subversion API.

-- Brane

Re: "svn status" does not show unversioned items been deleted but not committed

[Johan Corveleyn]

On Thu, May 18, 2017 at 2:03 PM, 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 then i'll LOSE CHANGES because the svn will remove
> another file w/o warning in this case. Just because it had the same name.
>
> 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.

Hm. If you 'svn add file1.txt' (the new file that's being hidden by
the delete), then I guess it's visible as a "replace" (R), right?

So for an uncommitted delete and add at the same path we have a
special status, R. But for an uncommitted delete + unversioned at the
same path we don't. I suppose in theory we could also show a special
status for that (like R, but then for an "unversioned replacement").
It's a special case, but doesn't sound all that far fetched.

I guess you're counting on the "unversioned detection" for instance to
get the help of TortoiseSVN for not forgetting unversioned files (in
the commit dialog it shows unversioned files and has checkboxes to add
them directly from within that dialog).

-- 
Johan

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

[Stefan Sperling]

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 doing this,
and I expect we would be open to suggestions and patches.

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

[Johan Corveleyn]

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 cause. By the link i mean peace of string
> in the output from the "svn pget svn:externals" command.
>
> There is 2 records which are empty:
> ```
> https://domain.ab/svn/proj2/trunk/proj2-gui -
> https://domain.ab/svn/proj2/trunk/proj2-gui/lib/Resource/Files -
> ```
> 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, but I guess it's fine). So
the property is there, but has no content. That's not the problem.
When you request "svn propget svn:externals -R $URL" the client and
server still have to do the work to retrieve that property from all
nodes in the entire subtree -- it doesn't matter whether it's empty or
not at this point (it doesn't even matter whether it's defined or not,
they still have to look it up).

To rule out any relation to "svn:externals" in itself, can you test if
you get the same "propget -R" performance if you retrieve another
property with exactly the same command?

For instance, try:
svn pget fooprop "https://domain.ab/svn/proj2/trunk@1193; -R --non-interactive

On my svn repository that command takes also a minute or 2 for a
reasonably large tree.

So even without any property defined anywhere, your "propget -R"
request still makes the client (and/or server) crawl the entire
subtree and requesting the property at every node, and this seems to
take a lot of time (like Bert said, "There is no optimized code path
for retrieving properties recursively directly from the server.")

-- 
Johan

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

[Stefan Sperling]

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 link i mean peace of string
> in the output from the "svn pget svn:externals" command.
> 
> There is 2 records which are empty:
> ```
> https://domain.ab/svn/proj2/trunk/proj2-gui -
> https://domain.ab/svn/proj2/trunk/proj2-gui/lib/Resource/Files -
> ```
> Why just not to ignore them? Anyway they are don't have any mapping to a
> local directory.

My impression is that you misunderstand how the SVN system was designed.

'svn propget' is showing property contents and is oblivious to the
semantics of that content. There are different kinds of properties
(not just svn:externals) and 'propget' is a generic tool that
works for all of these properties.

If you need a tool which specifically interprets svn:externals
property content in some way, then you would need to write one.
Such as a wrapper script which does post-processing on the content.

BTW, using svn:externals to excessively link between source code files
and modules has downsides. svn:externals were *not* designed to be
a dependency management or linking system. Though admittedly many
people end up using it as such, and then sometimes get confused by
the inherent limitations of the user interface. For example, merging
between branches can become unnecessarily complicated when externals
are used excessively in a project. Simply put, I always recommend
that if there is another way to solve a problem then don't use
svn:externals to solve the problem.

svn:externals are just a convenience wrapper around functionality
provided by 'svn checkout'. If you keep this in mind, and look at
how Subversion's properties work (again, please refer to the
svnbook I linked in my previous mail), then you should see why
the propget command behaves as it does.

> PS: Please add me to a mail copy next time.

Your address has been (and is now) in the To: header of email I send to you.
Is that not enough?

Re: "svn status" does not show unversioned items been deleted but not committed

[Andrey]

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
another file w/o warning in this case. Just because it had the same name.

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.

PS: Please send me a mail copy (CC) next time. You know is hard to put
everything in the answer from a raw mail in the mailing list archive.

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

[Andrey]

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
...
The following repository access (RA) modules are available:

* 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
* ra_serf : Module for accessing a repository via WebDAV protocol using
serf.
- using serf 1.3.9 (compiled with 1.3.9)
- handles 'http' scheme
- handles 'https' scheme

The following authentication credential caches are available:

* Wincrypt cache in C:\Users\Andry\AppData\Roaming\Subversion
```

svnadmin --version
```
$ svnadmin --version
svnadmin, version 1.9.5 (r1770682)
 compiled Dec  1 2016, 14:48:33 on x86_64-unknown-linux-gnu
...
The following repository back-end (FS) modules are available:
* fs_fs : Module for working with a plain file (FSFS) repository.
* fs_x : Module for working with an experimental (FSX) repository.
* fs_base : Module for working with a Berkeley DB repository.
```


Just as background: svn:externals definitions can also optionally take
a peg revision (the @REV notation) [1], [2]. Maybe in the future you
can use the peg revision syntax to avoid this problem of the "external
source" disappearing at some point in history.

It's not mine repo to avoid such cases. Basically people use HEAD
revisions to
take last changes by one external reference at once (as a solution of
multiple projects).
I see nothing wrong with what.

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

[Andrey]

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
...
The following repository access (RA) modules are available:

* 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
* ra_serf : Module for accessing a repository via WebDAV protocol using
serf.
- using serf 1.3.9 (compiled with 1.3.9)
- handles 'http' scheme
- handles 'https' scheme

The following authentication credential caches are available:

* Wincrypt cache in C:\Users\Andry\AppData\Roaming\Subversion
```

svnadmin --version
```
$ svnadmin --version
svnadmin, version 1.9.5 (r1770682)
 compiled Dec  1 2016, 14:48:33 on x86_64-unknown-linux-gnu
...
The following repository back-end (FS) modules are available:
* fs_fs : Module for working with a plain file (FSFS) repository.
* fs_x : Module for working with an experimental (FSX) repository.
* fs_base : Module for working with a Berkeley DB repository.
```


Just as background: svn:externals definitions can also optionally take
a peg revision (the @REV notation) [1], [2]. Maybe in the future you
can use the peg revision syntax to avoid this problem of the "external
source" disappearing at some point in history.

It's not mine repo to avoid such cases. Basically people use HEAD
revisions to
take last changes by one external reference at once (as a solution of
multiple projects).
I see nothing wrong with what.

Re: "svn status" does not show unversioned items been deleted but not committed

[Andrey]

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
another file w/o warning in this case. Just because it had the same name.

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.

PS: Please send me a mail copy (CC) next time. You know is hard to put
everything in the answer from a raw mail in the mailing list archive.

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

[Andrey]

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 svn:externals" command.

There is 2 records which are empty:
```
https://domain.ab/svn/proj2/trunk/proj2-gui -
https://domain.ab/svn/proj2/trunk/proj2-gui/lib/Resource/Files -
```
Why just not to ignore them? Anyway they are don't have any mapping to a  
local directory.


PS: Please add me to a mail copy next time.

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

[Andrey]

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?

There's a file named 'foo' that was deleted with 'svn rm' but not
committed, and also a file named 'foo' that you created on disk before
committing the deletion (or rename). What do you propose  'svn status'
should show?
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]

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 then i'll LOSE CHANGES because the svn will remove
> another file w/o warning in this case. Just because it had the same name.
>
> 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?

There's a file named 'foo' that was deleted with 'svn rm' but not
committed, and also a file named 'foo' that you created on disk before
committing the deletion (or rename). What do you propose  'svn status'
should show?

-- Brane

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

[Andrey]

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
...
The following repository access (RA) modules are available:

* 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
* ra_serf : Module for accessing a repository via WebDAV protocol using  
serf.

  - using serf 1.3.9 (compiled with 1.3.9)
  - handles 'http' scheme
  - handles 'https' scheme

The following authentication credential caches are available:

* Wincrypt cache in C:\Users\Andry\AppData\Roaming\Subversion
```

svnadmin --version
```
$ svnadmin --version
svnadmin, version 1.9.5 (r1770682)
   compiled Dec  1 2016, 14:48:33 on x86_64-unknown-linux-gnu
...
The following repository back-end (FS) modules are available:
* fs_fs : Module for working with a plain file (FSFS) repository.
* fs_x : Module for working with an experimental (FSX) repository.
* fs_base : Module for working with a Berkeley DB repository.
```


Just as background: svn:externals definitions can also optionally take
a peg revision (the @REV notation) [1], [2]. Maybe in the future you
can use the peg revision syntax to avoid this problem of the "external
source" disappearing at some point in history.
It's not mine repo to avoid such cases. Basically people use HEAD  
revisions to
take last changes by one external reference at once (as a solution of  
multiple projects).

I see nothing wrong with what.

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

[Stefan Sperling]

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 command is like running 'svn ls' on
> > every directory + fetching the properties on every file and every
> > directory. (It is slightly more optimized than that, but not much)
> 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.

There is no concept of a "link", as you called, it in Subversion.
So I am not sure what an "empty link" would mean.
If you wish to brush up your working knowledge of his part of
the system, please read:
http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
Then we could have a conversion where both sides use the same terminology.

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

[Andrey]

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  
another file w/o warning in this case. Just because it had the same name.


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.


PS: Please send me a mail copy (CC) next time. You know is hard to put  
everything in the answer from a raw mail in the mailing list archive.

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

[Andrey]

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 properties on every file and every  
directory. (It is slightly more optimized than that, but not much)

Why is that important when the links are empty?

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

[Bert Huijben]

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: woensdag 17 mei 2017 19:57
> To: Andry 
> Cc: users@subversion.apache.org
> Subject: 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 revisions. The WC is in the middle,
> say at rev 1193 (the current), the show log shows 1191 at the last revision,
> the HEAD revision say 1300.
> > Trying to cd into WC directory and run the command. Needs about 1
> minute  to wait it's response. The Process Hacker shows traffic with the
> server up to about 2MB.
> >
> > If try to run command w/o -R flag - command returns immediately.
> >
> > The content of the externals property without the -R flag is:
> > https://domain.ab/svn/proj2/trunk - ^/../proj3/trunk/cmake cmake_proj3
> > ^/solutions/project1/sdk proj2-sdk
> >
> > The content of the externals property with the -R flag is:
> > https://domain.ab/svn/proj2/trunk - ^/../proj3/trunk/cmake cmake_proj3
> > ^/solutions/project1/sdk proj2-sdk
> > https://domain.ab/svn/proj2/trunk/proj2-gui -
> > https://domain.ab/svn/proj2/trunk/proj2-gui/lib/Resource/Files -
> >
> > I think the 2 last records draws the svn mad and it begin to crawl the 
> > server
> for something for about 1 minute.
> >
> > I tries variations of the command. For example all these having the same
> result as above:
> > svn pget svn:externals -r "1193" "https://domain.ab/svn/proj2/trunk; -R --
> non-interactive
> > svn pget svn:externals -r "1193"
> "https://domain.ab/svn/proj2/trunk@1193; -R --non-interactive
> > svn pget svn:externals "https://domain.ab/svn/proj2/trunk@1193; -R --
> non-interactive
> >
> > Dig a bit further and found this:
> > svn info https://domain.ab/svn/proj2/trunk/proj2-gui
> > svn: warning: W17: URL 'https://domain.ab/svn/proj2/trunk/proj2-gui'
> non-existent in revision 1300
> > svn: E29: Could not display info for all targets because some targets
> don't exist
> >
> > Seems the 2 last records reference URL's what does not exist anymore in
> the HEAD.
> >
> > These 2 records are left after an upgrade from a previous version of
> database, but why is the svn runs so slow about it? Anyway, i can't just
> cleanup the externals because they are from 3dparty repository in which i
> have no access.
> 
> Thanks for bringing the issue here to the list.

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 properties on every file and every directory. (It is 
slightly more optimized than that, but not much)

Bert

RE: Facing issues in Enable editing log messages.

[Ramamurthy, Manochitra]

Hi Eric,

So I believe the script which I have used for pre-revprop-change hook is 
correct.

I will try to check about csvn user and password. But I have no clue with whom 
to check here. I will try to find it out.

Thanks for your quick response.

Thanks,
Mano

From: Eric Johnson [mailto:e...@tibco.com]
Sent: 17 May 2017 22:22
To: Ramamurthy, Manochitra
Cc: users@subversion.apache.org
Subject: Re: Facing issues in Enable editing log messages.

EXTERNAL EMAIL


The failures shown in your screenshot are due to authentication, and appear to 
be unrelated to Subversion. It would appear that the csvn user is either an 
invalid user or you have the wrong password.

Eric.

On Wed, May 17, 2017 at 3:26 AM, Ramamurthy, Manochitra 
> wrote:
Hi Team,

Greetings !

I’m unsure whom to contact I found this mailing address when I do search for 
this issue.

I have joined this organization INTEVA before few months and taking of SVN. I 
have query regarding Enable editing log messages in SVN which I have no clue on 
it. But just googling I followed below steps but no luck.


• Created “pre-revprop-change” hook under hooks directory.

• Added below script in it.

---SNIP---

REPOS="$1"

REV="$2"

USER="$3"

PROPNAME="$4"

if [ "$PROPNAME" = "svn:log" ]; then exit 0; fi

if [ "$PROPNAME" = "svn:date" ]; then exit 0; fi

exit 1

---SNIP---



Pasted from 

• Executed this svn propset -r * revision no* --revprop svn:log new 
message *URL*



[cid:image001.png@01D2CFD6.FFE51580]


Please assist me or point me to someone who can help me.

Thanks,
Mano
+91 8046552670
Available from 10am to 5pm IST

Re: FW: SVN error

[Branko Čibej]

On 18.05.2017 09:29, Ramamurthy, Manochitra wrote:
> Hi Team,
>
> A user is not able to use the option "Get lock" to lock a particular file in 
> SVN. Please refer below screenshot for error details.
>
> I checked user permissions, I don't think this forbidden error is related to 
> permissions. Can you please guide me? Thanks.


If you look carefully at your screen shot, you'll see that what failed
was not "lock" but "unlock". The file is already locked by someone else.

-- Brane