Subversion 1.10 RC1?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Subversion 1.10 RC1?

Julian Foad-5
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.)

   * 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.

   * LZ4 compression: in some senses the risk of bugs here is higher,
but it seems like it is high quality already; is there one remaining
place where we should add LZ4 negotiation (one direction of svnserve
protocol)?

   * 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)?

After any issues raised in this discussion are resolved, we feel we
should go ahead and produce RC1 as soon as possible.

- Julian (& Stefan, Bert, Johan)
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Branko Čibej
On 22.11.2017 11:53, Julian Foad wrote:

> 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.)
>
>   * 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.

Other than the new compiler warnings that keep popping up on trunk
related to the conflict resolution, I have no objections.

>   * LZ4 compression: in some senses the risk of bugs here is higher,
> but it seems like it is high quality already; is there one remaining
> place where we should add LZ4 negotiation (one direction of svnserve
> protocol)?

Would be nice to have LZ4 negotiation everywhere but not a blocker.

>   * 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)?

Unless you're absolutely certain that the format and semantics of the
CLI commands won't change, I do suggest adding an "experimental" warning
to the help text.

> After any issues raised in this discussion are resolved, we feel we
> should go ahead and produce RC1 as soon as possible.

+(1 − ε)

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Stefan Sperling-9
In reply to this post by Julian Foad-5
On Wed, Nov 22, 2017 at 11:53:11AM +0100, Julian Foad wrote:

> 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.)
>
>   * 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.

One conflict option that's not done yet is one that merges a textual change
from a path ^/trunk/B to a path ^/branch/A, after a move A -> B on trunk.
I don't consider this a release blocker. We can always add this option in
a patch release.

I would welcome a 1.10.0-RC1 release very much. It feels long overdue.
But I probably won't have time to help with preparations.
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Stefan Fuhrmann
In reply to this post by Julian Foad-5
On 22.11.2017 11:53, Julian Foad wrote:
> 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.)
My idea for the hackathon was to add native 'svn list' support
to ra_serf. But that is not a release blocker.
>
>   * 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.
If we broke something, it is likely one of the more complicated
cases where the need for manual intervention is not all that
surprising to the user.
>
>   * LZ4 compression: in some senses the risk of bugs here is higher,
> but it seems like it is high quality already; is there one remaining
> place where we should add LZ4 negotiation (one direction of svnserve
> protocol)?
ra_svn is certainly the ra layer that may benefit the most from LZ4.
Browsing through the code, I found a couple of TODOs that should
be simple to address this week.

I've got some ideas to enhance the protocol in 1.11 and that would
include using LZ4 for "mod_compress"-like full protocol compression.
However, those are non-trivial and are the one thing I like to discuss
with the people at the hackathon.
>
>   * 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)?
+1 on letting people gain experience with shelving.
+1 on marking the feature "experimental" in the UI b/c we might not
want to fully commit ourselves to upgradability. That is a departure
from the policy of previous releases.
>
> After any issues raised in this discussion are resolved, we feel we
> should go ahead and produce RC1 as soon as possible.
Assuming no blockers come up, I think coming weekend would be
a reasonable value for $asap.

-- Stefan^2.
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Evgeny Kotkov
In reply to this post by Julian Foad-5
Julian Foad <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Julian Foad-5
Re. shelving...

Evgeny Kotkov wrote:

> Julian Foad <[hidden email]> writes:
>>    * 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.

I agree we need to take care of data stored by the user using this
version. As the patches stored by this version are simple patch files
compatible with 'svn patch', we would not need to be able to upgrade
them to a new format. It would be possible to keep support for them in
the existing format. In the worst case, the user can recover them
manually and use 'svn patch'.

> 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 :)

Yes, absolutely, binary support is high on my priority list, and yes I'm
considering git-diff format.

Thanks!

- Julian

Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Julian Foad-5
In reply to this post by Branko Čibej
Re. shelving...

Branko Čibej wrote:
> Unless you're absolutely certain that the format and semantics of the
> CLI commands won't change, I do suggest adding an "experimental" warning
> to the help text.

Done. Thanks.

- Julian

Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Daniel Shahaf-2
Julian Foad wrote on Wed, Nov 22, 2017 at 17:17:34 +0100:
> Re. shelving...
>
> Branko Čibej wrote:
> > Unless you're absolutely certain that the format and semantics of the
> > CLI commands won't change, I do suggest adding an "experimental" warning
> > to the help text.
>
> Done. Thanks.

I don't think saying "This command is not forwards compatible" in the help text
will prevent users from relying on it being forwards compatible; which, in
turn, will discourage us, come 1.11, to make incompatible changes to this
command.

Perhaps we should rename the command to, say, "xshelve" — like the "X-" prefix
of experimental email headers, but without a minus for ease of typing?  Then we
could have a convention, "any command whose name starts with 'x' is not
guaranteed to be forwards compatible", and we'd be able to make incompatible
changes (to "xshelve") without worrying about users asking for compatibility
despite the documentation.  In 1.11, if we wanted to make "shelve" stable, we
could even continue to accept "xshelve" as an alias, if the semantics of
xshelve@1.10 and shelve@1.11 are compatible.
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Daniel Shahaf-2
In reply to this post by Stefan Sperling-9
Stefan Sperling wrote on Wed, Nov 22, 2017 at 13:41:11 +0100:
> But I probably won't have time to help with preparations.

Likewise.
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Paul Hammant-3
In reply to this post by Stefan Sperling-9

One conflict option that's not done yet is one that merges a textual change
from a path ^/trunk/B to a path ^/branch/A, after a move A -> B on trunk.
I don't consider this a release blocker. We can always add this option in
a patch release.


Is that a regression versus v1.9 and before?

- Paul
 
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Stefan Sperling-9
On Thu, Nov 23, 2017 at 10:55:02AM -0500, Paul Hammant wrote:
> >
> >
> > One conflict option that's not done yet is one that merges a textual change
> > from a path ^/trunk/B to a path ^/branch/A, after a move A -> B on trunk.
> > I don't consider this a release blocker. We can always add this option in
> > a patch release.
> >
> >
> Is that a regression versus v1.9 and before?

Far from it.
This discussion is about the new conflict resovler added in 1.10.

We can and always could perform such merges by manually specifying
the paths, i.e. running a merge from ^/trunk/B to branch/A.

The goal of the resolver is to make it easier to perform such merges
in the straightforward 'svn merge ^/trunk' style.
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Paul Hammant-3

> Is that a regression versus v1.9 and before?

Far from it.
This discussion is about the new conflict resovler added in 1.10.

We can and always could perform such merges by manually specifying
the paths, i.e. running a merge from ^/trunk/B to branch/A.

The goal of the resolver is to make it easier to perform such merges
in the straightforward 'svn merge ^/trunk' style.

OK, so at the risk of representing the department of unsolicited advice, I don't know why you would not ship with as 'off' but able to be toggled 'on' client-side with a new option --with-experimental-1-10-conflict-enhancement-technology (or a better name). The 0.1% of users that want to play with it before it is ready can do.

- Paul
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Stefan Sperling-9
On Thu, Nov 23, 2017 at 03:53:02PM -0500, Paul Hammant wrote:

> >
> >
> > > Is that a regression versus v1.9 and before?
> >
> > Far from it.
> > This discussion is about the new conflict resovler added in 1.10.
> >
> > We can and always could perform such merges by manually specifying
> > the paths, i.e. running a merge from ^/trunk/B to branch/A.
> >
> > The goal of the resolver is to make it easier to perform such merges
> > in the straightforward 'svn merge ^/trunk' style.
> >
>
> OK, so at the risk of representing *the department of unsolicited advice*,
> I don't know why you would not ship with as 'off' but able to be toggled
> 'on' client-side with a new option
> --with-experimental-1-10-conflict-enhancement-technology
> (or a better name). The 0.1% of users that want to play with it before it
> is ready can do.
>
> - Paul

Why? There's a lot of benefits in this feature. It has been worked on
sicnce May 2015 and is already pretty useful. There's a high-level
description in the 1.10 release notes, have you seen that?
http://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver

You're a bringing your concerns up a little late :)
But I'm not even sure why you would have any concerns about this.
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Paul Hammant-3
I think you're misunderstanding me. I noted this in the conversation above: "One conflict option that's not done yet is one that merges a textual change from a path ^/trunk/B to a path ^/branch/A, after a move A -> B on trunk. I don't consider this a release blocker. We can always add this option in a patch release."  

I interpreted that comment to be about something merged/integrated that should not go ahead just yet, and deserving of some consideration. 

I felt I had a suggestion that may be helpful to allow the release of something alpha/beta/RC-ish to go ahead even with something the team felt wasn't ready for release.

To reiterate: I agree the feature is useful and I have nothing to say that I would wish to have interpreted as a concern, was trying to help speed things up not slow things down.



On Thu, Nov 23, 2017 at 4:04 PM, Stefan Sperling <[hidden email]> wrote:
On Thu, Nov 23, 2017 at 03:53:02PM -0500, Paul Hammant wrote:
> >
> >
> > > Is that a regression versus v1.9 and before?
> >
> > Far from it.
> > This discussion is about the new conflict resovler added in 1.10.
> >
> > We can and always could perform such merges by manually specifying
> > the paths, i.e. running a merge from ^/trunk/B to branch/A.
> >
> > The goal of the resolver is to make it easier to perform such merges
> > in the straightforward 'svn merge ^/trunk' style.
> >
>
> OK, so at the risk of representing *the department of unsolicited advice*,
> I don't know why you would not ship with as 'off' but able to be toggled
> 'on' client-side with a new option
> --with-experimental-1-10-conflict-enhancement-technology
> (or a better name). The 0.1% of users that want to play with it before it
> is ready can do.
>
> - Paul

Why? There's a lot of benefits in this feature. It has been worked on
sicnce May 2015 and is already pretty useful. There's a high-level
description in the 1.10 release notes, have you seen that?
http://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver

You're a bringing your concerns up a little late :)
But I'm not even sure why you would have any concerns about this.



--
Paul Hammant DevOps Let me give your enterprise a step by step plan to get out of the hell crazy branching models (ClearCase maybe?) and into the world of high-throughput CD on DevOps foundations.
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Julian Foad-5
In reply to this post by Julian Foad-5
Julian Foad wrote:
> At the hackathon today we (me, Stefan Hett, Bert, Johan) have been
> talking about how to progress 1.10.

It seems we have general consensus to move to an RC1. A few things we'd
like to fix but no real blockers -- nothing we can't address during the
RC phase.

I volunteer to drive the 1.10 release. It will be good to learn the
process as I haven't done it before.

(We also have some outstanding fixes in 1.9 and 1.8. Maybe I will drive
those too. Doing all three in parallel would encourage me to keep the
release process automation up to date.)

- Julian

Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Stefan
On 25/11/2017 22:14, Julian Foad wrote:

> Julian Foad wrote:
>> At the hackathon today we (me, Stefan Hett, Bert, Johan) have been
>> talking about how to progress 1.10.
>
> It seems we have general consensus to move to an RC1. A few things
> we'd like to fix but no real blockers -- nothing we can't address
> during the RC phase.
>
> I volunteer to drive the 1.10 release. It will be good to learn the
> process as I haven't done it before.
>
> (We also have some outstanding fixes in 1.9 and 1.8. Maybe I will
> drive those too. Doing all three in parallel would encourage me to
> keep the release process automation up to date.)
>
> - Julian

Great Julian, thanks for taking care about this.

Regards,
Stefan

Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Stefan Fuhrmann
In reply to this post by Evgeny Kotkov
On 22.11.2017 15:48, Evgeny Kotkov wrote:

> 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

There seems to be little that could be done here (suggestions welcome).
The problem is that the asterisk is being expanded by the shell itself.
I made SVN print its command line parameters and this is the result:

        $ ./subversion/svn/svn ls svn://localhost/kde --search M*
        0: ./subversion/svn/svn
        1: ls
        2: svn://localhost/kde
        3: --search
        4: Makefile
        5: Makefile.in

That can be prevented by adding quotation marks:

        $ ./subversion/svn/svn ls svn://localhost/kde --search "M*"
        0: ./subversion/svn/svn
        1: ls
        2: svn://localhost/kde
        3: --search
        4: M*

So, I extended the user docstring accordingly in r1817053.

-- Stefan^2.
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Stefan Fuhrmann
In reply to this post by Stefan Fuhrmann


On 22.11.2017 14:21, Stefan Fuhrmann wrote:

> On 22.11.2017 11:53, Julian Foad wrote:
>> 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.)
> My idea for the hackathon was to add native 'svn list' support
> to ra_serf. But that is not a release blocker.

Work on 'svn ls --search' has been completed now,
release notes and friends have been updated.

-- Stefan^2.
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Stefan Sperling-9
On Mon, Dec 04, 2017 at 12:51:26PM +0100, Stefan Fuhrmann wrote:
> Work on 'svn ls --search' has been completed now,
> release notes and friends have been updated.
>
> -- Stefan^2.

Thank you!
Reply | Threaded
Open this post in threaded view
|

Re: Subversion 1.10 RC1?

Evgeny Kotkov
In reply to this post by Stefan Fuhrmann
Stefan Fuhrmann <[hidden email]> writes:

> There seems to be little that could be done here (suggestions welcome).
> The problem is that the asterisk is being expanded by the shell itself.
> I made SVN print its command line parameters and this is the result:
>
>         $ ./subversion/svn/svn ls svn://localhost/kde --search M*
>         0: ./subversion/svn/svn
>         1: ls
>         2: svn://localhost/kde
>         3: --search
>         4: Makefile
>         5: Makefile.in
>
> That can be prevented by adding quotation marks:
>
>         $ ./subversion/svn/svn ls svn://localhost/kde --search "M*"
>         0: ./subversion/svn/svn
>         1: ls
>         2: svn://localhost/kde
>         3: --search
>         4: M*

Unfortunately, on Windows both `--search M*` and (quoted) `--search "M*"`
would expand the asterisk.  While this is not the default shell behavior,
currently it's enabled for svn and a couple of other binaries by linking
to setargv.obj.  In turn, this probably means the command-line client
users on Windows could get quite unexpected results when using the
`--search ARG` syntax.

A potential cheap solution for this issue, I think, would be to make the
--search argument work as a substring to search for in filenames, instead
of using it as a pattern that the (whole) filename should match.  While
there are some cases where the latter approach gives more flexibility,
my guess would be that a substring search would work well in the majority
of scenarios.

(Also, as far as I recall, `log --search` currently searches for a substring,
 so that would be consistent with it, and would probably avoid surprising
 the users by having a switch with the same name, but behaving differently.)


Thanks,
Evgeny Kotkov
12