subversion-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Zhakov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SVN-2122) 'svn status -u' can crash with partial -N working copy
Date Sat, 17 Oct 2015 13:03:05 GMT

    [ https://issues.apache.org/jira/browse/SVN-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14920937#comment-14920937
] 

Ivan Zhakov edited comment on SVN-2122 at 10/17/15 1:02 PM:
------------------------------------------------------------

Resolved, with reservations, in r11876.

There is still an underlying problem here.  Take the working copy created in the
above recipe, which consists of:
{noformat}
   ./            @r213, non-recursive
   ./README      @r213
   ./www/        @r213, non-recursive
   ./scripts/    @r213, non-recursive
{noformat}

Meanwhile, the repository is at r246 or so, and has many trees not represented in the working
copy, such as the people/ tree and the tags/ tree, with plenty of subtrees underneath them.
 Some of that data existed in r213, and was not checked out only because we passed -N.  But
other data was created after r213.

Now we run {{svn st -u}} in the working copy, using a Subversion that has the r11876 fixes:
{noformat}
   $ svn st -u
          *      213   www/IGNORE-ME
          *      213   www
          *            people/dato/packages/.../some_file
          *            people/dato/packages/.../another_file
          *            people/dato/packages/.../etc
          *            people/dato/packages/.../etc
          *      213   scripts/svn-hooks/post-commit
          *      213   scripts/IGNORE-ME
          *      213   scripts/update-www
          *      213   scripts
          *            tags/packages/some_tag/etc...
          *            tags/packages/some_tag/etc...
          *            tags/packages/other_tag/etc...
          *            tags/packages/other_tag/etc...
   Status against revision:    246
   $ 
{noformat}

You can't tell from looking, but paths reported in scripts/ and www/ are 'D'eletions or 'M'odifications
(confirmed this while debugging).  All the other statuses, for paths not present locally,
are 'A'dded.  This is expected, given the r11876 changes.

The question is, what *should* we report?  Mike Pilato and I tentatively agree that we shouldn't
report status on paths that aren't officially in the working copy at all.  By "officially",
we mean paths that are omitted because this was a -N checkout, not paths that are missing
because they were 'svn rm'd or just plain 'rm'd.

However, the client->server reporter language has no way to express "Please ignore all
changes under PATH" at the moment.  Not only that, the .svn/entries file in the top of the
working copy doesn't really "know" that it's missing anything.  It's not marked as incomplete,
nor does it have dummy entries for "people/" and "tags/".

So first we need working copy awareness of non-recursivity.  Then we need the working copy
to express that to the server, and the server to DTRT with the information.

This is part of issue SVN-695, so marking this as a dependency.



was (Author: kfogel):
{noformat:nopanel=true}
Resolved, with reservations, in r11876.

There is still an underlying problem here.  Take the working copy created in the
above recipe, which consists of:

   ./            @r213, non-recursive
   ./README      @r213
   ./www/        @r213, non-recursive
   ./scripts/    @r213, non-recursive

Meanwhile, the repository is at r246 or so, and has many trees not represented
in the working copy, such as the people/ tree and the tags/ tree, with plenty of
subtrees underneath them.  Some of that data existed in r213, and was not
checked out only because we passed -N.  But other data was created after r213.

Now we run 'svn st -u' in the working copy, using a Subversion that has the
r11876 fixes:

   $ svn st -u
          *      213   www/IGNORE-ME
          *      213   www
          *            people/dato/packages/.../some_file
          *            people/dato/packages/.../another_file
          *            people/dato/packages/.../etc
          *            people/dato/packages/.../etc
          *      213   scripts/svn-hooks/post-commit
          *      213   scripts/IGNORE-ME
          *      213   scripts/update-www
          *      213   scripts
          *            tags/packages/some_tag/etc...
          *            tags/packages/some_tag/etc...
          *            tags/packages/other_tag/etc...
          *            tags/packages/other_tag/etc...
   Status against revision:    246
   $ 

You can't tell from looking, but paths reported in scripts/ and www/ are
'D'eletions or 'M'odifications (confirmed this while debugging).  All the other
statuses, for paths not present locally, are 'A'dded.  This is expected, given
the r11876 changes.

The question is, what *should* we report?  Mike Pilato and I tentatively agree
that we shouldn't report status on paths that aren't officially in the working
copy at all.  By "officially", we mean paths that are omitted because this was a
-N checkout, not paths that are missing because they were 'svn rm'd or just
plain 'rm'd.

However, the client->server reporter language has no way to express "Please
ignore all changes under PATH" at the moment.  Not only that, the .svn/entries
file in the top of the working copy doesn't really "know" that it's missing
anything.  It's not marked as incomplete, nor does it have dummy entries for
"people/" and "tags/".

So first we need working copy awareness of non-recursivity.  Then we need the
working copy to express that to the server, and the server to DTRT with the
information.

This is part of issue #695, so marking this as a dependency.
{noformat}


> 'svn status -u' can crash with partial -N working copy
> ------------------------------------------------------
>
>                 Key: SVN-2122
>                 URL: https://issues.apache.org/jira/browse/SVN-2122
>             Project: Subversion
>          Issue Type: Bug
>          Components: libsvn_wc
>    Affects Versions: all
>            Reporter: Karl Fogel
>            Assignee: Ben Reser
>             Fix For: unscheduled
>
>
> {noformat:nopanel=true}
> Adeodato Simó <asp16@alu.ua.es> posted this report to dev@ today.  The message
> hasn't shown up in the archives yet, but it's this one:
>    From: Adeodato Simó <asp16@alu.ua.es>
>    To: dev@subversion.tigris.org
>    Subject:  crash when doing svn st -u (assertion failed)
>    Date: Fri, 12 Nov 2004 00:32:25 +0100
>    Message-ID: <20041111233225.GA23928@chistera.yi.org>
> The recipe is simple, and reproduces for me with svn 1.2 (dev build):
>    $ svn co -N -r 213 svn://svn.debian.org/pkg-kde .
>    A  README
>    Checked out revision 213.
>    
>    $ svn up -r 213 scripts www
>    [ List of scripts/* files.]
>    Updated to revision 213.
>    [ List of www/* files.]
>    Updated to revision 213.
>    
>    $ svn st -u
>       *      213   www/IGNORE-ME
>       *      213   www
>    svn: subversion/libsvn_wc/status.c:910: tweak_statushash:       \
>       Assertion `repos_text_status == svn_wc_status_added' failed. \
>       Aborted (core dumped)
> At first, I thought this might be related to SteveKing's status crash bug report, at
>    Original post:
>      From: SteveKing <steveking@gmx.ch>
>      Subject:  crash when fetching status
>      Message-ID: <4187D596.6040205@gmx.ch>
>      Date: Tue, 02 Nov 2004 19:44:38 +0100
>      http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=82253
>    Whole thread:
>      http://tinyurl.com/4tzqd
> However, looking more closely now, I'm less optimistic that it's the same bug. 
> The assertion that's failing in this new report is one added in r6913, yet it's
> apparently not being triggered in SteveKing's situation.  Investigating now.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message