You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@subversion.apache.org by "Johan Corveleyn (JIRA)" <ji...@apache.org> on 2017/05/16 13:15:04 UTC

[jira] [Closed] (SVN-4681) "svn pget svn:externals -r . -R" dramatically slow

     [ https://issues.apache.org/jira/browse/SVN-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johan Corveleyn closed SVN-4681.
--------------------------------
    Resolution: Invalid

I'm sorry, but I'm closing this issue as invalid. You should first report problems to our users-mailinglist (as clearly stated on http://subversion.apache.org/reporting-issues.html). This gives it much more visibility, and opportunity for others to verify your issue or suggest workarounds. I already mentioned this in the previous issue you filed (SVN-4680).

Only after it's been confirmed as an issue in SVN should you create a new issue in JIRA (with a reference to the mailinglist-thread where it was discussed).

After you've discussed it on users@, and it has been confirmed as an issue, we can reopen this of course.

> "svn pget svn:externals -r <rev> . -R" dramatically slow
> --------------------------------------------------------
>
>                 Key: SVN-4681
>                 URL: https://issues.apache.org/jira/browse/SVN-4681
>             Project: Subversion
>          Issue Type: Bug
>    Affects Versions: 1.9.5
>         Environment: windows 7 x64, tortoisesvn command line tools
>            Reporter: Andrey
>              Labels: pget, recursively, svn:externals
>
> 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:
> {quote}
> https://domain.ab/svn/proj2/trunk - ^/../proj3/trunk/cmake cmake_proj3
> ^/solutions/project1/sdk proj2-sdk
> {quote}
> The content of the externals property with the -R flag is:
> {quote}
> 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 -
> {quote}
> 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:
> {quote}
> 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
> {quote}
> Dig a bit further and found this:
> {quote}
> svn info https://domain.ab/svn/proj2/trunk/proj2-gui
> svn: warning: W170000: URL 'https://domain.ab/svn/proj2/trunk/proj2-gui' non-existent in revision 1300
> svn: E200009: Could not display info for all targets because some targets don't exist
> {quote}
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Unbuddied issue workflow

Posted by Stefan Fuhrmann <st...@apache.org>.
On 16.05.2017 17:59, Stefan Sperling wrote:
> On Tue, May 16, 2017 at 03:49:32PM +0000, Daniel Shahaf wrote:
>> We could probably change the "File an issue" jira workflow to prevent
>> people from filing unbuddied issues, and instead, having jira tell them
>> to email users@.  I'm thinking of interjecting something into the
>> "Create issue" jira flow.
> Yes please!
+1.

-- Stefan^2.

Re: Unbuddied issue workflow (was: [jira] [Closed] (SVN-4681) "svn pget svn:externals -r . -R" dramatically slow)

Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, May 17, 2017 at 10:56 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Stefan Sperling wrote on Tue, May 16, 2017 at 17:59:28 +0200:
>> On Tue, May 16, 2017 at 03:49:32PM +0000, Daniel Shahaf wrote:
>> > We could probably change the "File an issue" jira workflow to prevent
>> > people from filing unbuddied issues, and instead, having jira tell them
>> > to email users@.  I'm thinking of interjecting something into the
>> > "Create issue" jira flow.
>>
>> Yes please! Is that easy to do?
>
> I don't know.  Does anybody volunteer to look into this?  (By reading
> jira docs or asking Ivan or asking infra.)

I have a bit of experience with JIRA from work, but not that much in
the area of customizing these interactions ... Depends heavily on how
infra sets things up too of course.
Anyway, I'll try to have a look (but if nothing moves in the next
couple of days, other hands would certainly be welcome).

Also, for newcomers it's hard to find our JIRA, coming from our own
website. The page http://subversion.apache.org/reporting-issues.html
doesn't even mention JIRA (the search links all correctly query JIRA,
but it's kind of hidden). There should at least be a link there to
simply go to JIRA to create new issues (it should probably mention
that you'll need to create an account if you don't have one already).
Right now there is no "create new issue" link, you have to click on
one of the search links, and go from there through the JIRA UI. The
"Reporting issues" page is mainly focused on deterring ... enforcing
our buddy guidelines etc ... but it's not very welcoming.

-- 
Johan

Re: Unbuddied issue workflow (was: [jira] [Closed] (SVN-4681) "svn pget svn:externals -r . -R" dramatically slow)

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Tue, May 16, 2017 at 17:59:28 +0200:
> On Tue, May 16, 2017 at 03:49:32PM +0000, Daniel Shahaf wrote:
> > We could probably change the "File an issue" jira workflow to prevent
> > people from filing unbuddied issues, and instead, having jira tell them
> > to email users@.  I'm thinking of interjecting something into the
> > "Create issue" jira flow.
> 
> Yes please! Is that easy to do?

I don't know.  Does anybody volunteer to look into this?  (By reading
jira docs or asking Ivan or asking infra.)

Re: Unbuddied issue workflow (was: [jira] [Closed] (SVN-4681) "svn pget svn:externals -r . -R" dramatically slow)

Posted by Stefan Sperling <st...@elego.de>.
On Tue, May 16, 2017 at 03:49:32PM +0000, Daniel Shahaf wrote:
> We could probably change the "File an issue" jira workflow to prevent
> people from filing unbuddied issues, and instead, having jira tell them
> to email users@.  I'm thinking of interjecting something into the
> "Create issue" jira flow.

Yes please! Is that easy to do?

Unbuddied issue workflow (was: [jira] [Closed] (SVN-4681) "svn pget svn:externals -r . -R" dramatically slow)

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn (JIRA) wrote on Tue, May 16, 2017 at 13:15:04 +0000:
> Johan Corveleyn closed SVN-4681.
> --------------------------------
>     Resolution: Invalid
> 
> I'm sorry, but I'm closing this issue as invalid. You should first
> report problems to our users-mailinglist (as clearly stated on
> http://subversion.apache.org/reporting-issues.html).

I suspect people are just searching for "subversion bug tracker" and
filing the bug without ever going through that page.  (Especially since
this trend of misfiled issues started after the tigris -> apache jira
migration.)

We could probably change the "File an issue" jira workflow to prevent
people from filing unbuddied issues, and instead, having jira tell them
to email users@.  I'm thinking of interjecting something into the
"Create issue" jira flow.

This would (a) free us^WJohan some time, (b) result in better UX.