Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <277282b9-aebf-6156-8244-d50c70e9f3af@apache.org>
References: <277282b9-aebf-6156-8244-d50c70e9f3af@apache.org>
From: Evgeny Kotkov <evgeny.kotkov@visualsvn.com>
Date: Wed, 22 Nov 2017 17:48:39 +0300
Message-ID: <CAP_GPNiKvONSN6ZBPO0tx3DFyAiRv9+5OkzNZ8+CeV+AysYyYA@mail.gmail.com>
Subject: Re: Subversion 1.10 RC1?
To: Julian Foad <julianfoad@apache.org>
Cc: dev@subversion.apache.org
Content-Type: text/plain; charset="UTF-8"
archived-at: Wed, 22 Nov 2017 14:49:06 -0000

Julian Foad <julianfoad@apache.org> writes:

> At the hackathon today we (me, Stefan Hett, Bert, Johan) have been talking
> about how to progress 1.10.
>
> We think all the features and changes are safe to release and are not going
> to get more testing until we produce a "release candidate". (For example, at
> that point Stefan will be able to justify taking time at his work to test
> the client in production scenarios.)

I did a couple of quick tests for these new features; some of my findings
that we might want to address before 1.10 GA and additional comments are
below:

>   * conflict resolution: we understand it is already much better than 1.9;
> low risk if parts of it don't work quite right; designed so that
> improvements can be made in patch releases.

I noticed that if the resolution of a tree conflict leads to a text conflict,
the temporary files (base, mine, theirs) are not cleaned up upon revert
and remain as unversioned files in the working copy.

    C  +    NewFile.txt
            > moved from OldFile.txt
    ?       NewFile.txt.2.tmp
    ?       NewFile.txt.3.tmp
    ?       NewFile.txt.tmp

>   * shelving v1: is isolated -- doesn't affect anything else; is limited but
> already useful; will be changed in the next release so APIs are marked
> "SVN_EXPERIMENTAL"; changes shelved by this release could be detected and
> 'upgraded' by a future release; should the CLI commands be marked
> "experimental" in the help, too (Johan thinks yes)?

One comment that I have is that marking the new commands experimental
might not prevent the users from using them on a regular basis (e.g., for
those who don't read help or use a GUI client like TSVN that might not
have the "experimental" labels).

Which, in turn, could mean that if the future format changes, we would
have to convert the data stored in the patch files to avoid a data loss
for such users.

Also, out of curiosity, are there any current plans to support binary changes
for the shelves?

As far as I recall, there has been a mention of using diff --git for these
purposes, and I also saw a recent commit where you added a test for diff
--git, which might be related to this topic :)


The other two features that I remember, are:

* improved authz with support for wildcards

* server-side search with `svn ls --search`

Speaking of the `ls --search`, I think that there is an issue with the
command-line parsing.  Based on what I see, the --search argument may
be interpreted as the target for listing, but not as the search pattern:

    svn ls --search *

    svn: warning: apr_err=SVN_ERR_WC_PATH_NOT_FOUND
    svn: warning: W155010: The node 'C:\Project\unversioned' was not found.
    ..\..\..\subversion\svn\list-cmd.c:453: (apr_err=SVN_ERR_ILLEGAL_TARGET)
    svn: E200009: Could not list all targets because some targets don't exist

    svn ls http://spbvo-ws09.ostyserver.net:8080/svn/master2 --search *
    svn: E155007: 'C:\AnotherProject' is not a working copy


Thanks,
Evgeny Kotkov