Re: svn commit: r1803143 - in /subversion/trunk/subversion: include/ libsvn_delta/ libsvn_ra_serf/ mod_dav_svn/

[Daniel Shahaf]

Bert Huijben wrote on Wed, 30 Aug 2017 12:24 +0200:
> I think this just documents current behavior. Yes a 1.9+ client
> against a 1.9+ server will always have a checksum, but this is not the
> case when mixing older clients and servers.
>
> Original serf versions (form before we declared this stable) typically
> never provided the checksum. And in some cases bulk requests didn't
> have all the checksums either. I remember fixing a few cases around
> WC-NG to make sure all ra layers reported the same errors in some
> exceptional cases.

Thanks for the clarification, Bert.  It sounds like the various commit
editors (libsvn_ra's and libsvn_repos's, at least) should document that
they do verify checksums --- I didn't check whether they already
document that --- and the svn_delta_editor_t docs should be updated to
state that the leeway for receivers not to verify checksums is deprecated.

Re: Unbuddied issue workflow

[Daniel Shahaf]

Johan Corveleyn wrote on Wed, 30 Aug 2017 23:44 +0200:
> After chatting on #asfinfra, they first have to investigate the
> possibilities in JIRA. If it's at all possible, we'll have to come up
> with a good text (perhaps depending on the screen real-estate we can
> afford for this). Any suggestions?
> 

"Has one of the Subversion committers asked you to file an issue?

( ) yes   ( ) no"# radio button

then if they tick "(x) no", display:

"The issue tracker is reserved for use by the Subversion developers.
Please send any usage questions, bug reports, and support questions,
directly to the mailing list us...@subversion.apache.org.  
Thanks!".

... and disable (grey out) the "Next >" or "Continue" button.

Needs some wordsmithing, but the main point is to only show the
"301 Moved Permanently" message after the user has pressed a radio
button; I hope that would lead to better success rates.

---

Also, we could ask Ivan; he did our jira migration so he might have an
idea off the top of his head.

> We could take inspiration from the big yellow box on
> http://subversion.apache.org/reporting-issues.html or from
> http://subversion.apache.org/docs/community-guide/issues.html I guess
> ...


Cheers,

Daniel

Re: Unbuddied issue workflow

[Johan Corveleyn]

On Wed, Aug 30, 2017 at 11:14 PM, Johan Corveleyn  wrote:
> On Thu, May 18, 2017 at 9:59 AM, Johan Corveleyn  wrote:
>> On Wed, May 17, 2017 at 10:56 AM, Daniel Shahaf  
>> wrote:
>>> Stefan Sperling wrote on Tue, May 16, 2017 at 17:59:28 +0200:
 On Tue, May 16, 2017 at 03:49:32PM +, 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.
>
> Hmm, seems issues are still filed unbuddied regularly, without passing
> by users@. Interjecting a screen in the "Create Issue" workflow seems
> indeed a good idea. I'll try to take this up with infra.

See https://issues.apache.org/jira/browse/INFRA-14990.

After chatting on #asfinfra, they first have to investigate the
possibilities in JIRA. If it's at all possible, we'll have to come up
with a good text (perhaps depending on the screen real-estate we can
afford for this). Any suggestions?

We could take inspiration from the big yellow box on
http://subversion.apache.org/reporting-issues.html or from
http://subversion.apache.org/docs/community-guide/issues.html I guess
...

-- 
Johan

Re: Unbuddied issue workflow

[Johan Corveleyn]

On Thu, May 18, 2017 at 9:59 AM, Johan Corveleyn  wrote:
> On Wed, May 17, 2017 at 10:56 AM, Daniel Shahaf  
> wrote:
>> Stefan Sperling wrote on Tue, May 16, 2017 at 17:59:28 +0200:
>>> On Tue, May 16, 2017 at 03:49:32PM +, 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.

Hmm, seems issues are still filed unbuddied regularly, without passing
by users@. Interjecting a screen in the "Create Issue" workflow seems
indeed a good idea. I'll try to take this up with infra.

-- 
Johan

Re: Tip of the day: Cheatsheet for common cmdline client operations

[Johan Corveleyn]

On Tue, Aug 29, 2017 at 2:15 PM, Pavel Lyalyakin
 wrote:
> Hello,
>
> On Fri, Aug 25, 2017 at 2:03 PM, Johan Corveleyn  wrote:
>>
>> [ cc -= svnbook-dev, as I guess this will not become book-material.
>> More below ... ]
>>
>> On Thu, Jul 13, 2017 at 6:34 PM, C. Michael Pilato
>>  wrote:
>> > On Thu, Jul 13, 2017 at 11:21 AM, Daniel Shahaf 
>> > wrote:
>> >>
>> >> [moving from users@ ]
>> >>
>> >> Daniel Shahaf wrote on Fri, 30 Jun 2017 09:15 +:
>> >> > I just ran into the following cheatsheet:
>> >> >
>> >> > http://www.chim.unifi.it/~signo/did/etc/subversion/neat.html
>> >> >
>> >> > It covers the normal multi-user workflow, branching, etc..
>> >> >
>> >> > (Kudos to the author, Giorgio Signorini, not to me.)
>> >>
>> >> As some of you know, the author gave us permission to incorporate that
>> >> cheatsheet into the official documentation.  Any volunteers to start the
>> >> process?
>> >>
>> >> Cheers,
>> >>
>> >> Daniel
>> >>
>> > With respect to the author and the work he's done, I'm not really 
>> > interested
>> > in us maintaining yet another collection of the same information already
>> > covered -- in some cases multiple times, when you factor in the reference
>> > sections -- by the book.  At best this cheatsheet would be an appendix.  
>> > I'm
>> > happy to link to the cheatsheet from from the book website, though.
>> >
>> > -- Mike
>>
>> FWIW, I think this cheatsheet is quite good and valuable (though I
>> agree there is a lot of overlap with existing documentation),
>> especially for newcomers. Just to have a good summary / reminder of
>> common things you'll encounter.
>>
>> We have our own quickstart page: http://subversion.apache.org/quick-start
>>
>> How about:
>>
>> - Putting a link at the bottom of that page (there is already a link
>> to the quickstart section of the book), linking to the original
>> webpage of the author.
>>
>> or
>>
>> - Incorporating (some of) the content of that cheatsheet directly on
>> http://subversion.apache.org/quick-start, so it's right there in front
>> of you ...
>>
>>
>> The latter option would be my personal preference (putting my user /
>> admin hat on) -- I like having short info right in front of me in the
>> right place -- but obviously imposes some amount of doc-maintenance
>> work on "us".
>>
>> Maybe someone on this list would be willing to take this doc-task
>> (migrating the current content, and keep an eye on keeping it up to
>> date)?
>>
>> --
>> Johan
>
> IMO, this doc-task has to be reworded into composing a walkthrough for SVN end
> user who wants to start performing basic version control tasks over remote
> repository, but did not read SVNBook or other SVN-related documentation. What 
> do
> you think?
>
> I feel that the cheatsheet[1] needs to be reworked or at least restructured. 
> In
> the current state I feel that it is just personal notes that describe various
> common SVN tasks, actions and tricks. Cheatsheet or personal notes is not
> a "quick start" guide.

Hm, I guess you're right. Though I think there is also a place for
snippets / reminders / recipes (common SVN tasks, actions and tricks),
I suppose a good walkthrough is even better for bootstrapping new
users.

> Anyway, I like the idea of adding some of the content from the cheatsheet to
> the quick start page[2] and I would be glad to take this task.

That would be great!

> The question is: what kind of topics should the quick start page cover?
>
> My idea is that the page should provide task-based guidance for SVN end user 
> on
> how to
> * checkout a working copy,
> * update the working copy,
> * modify the data in the working copy and commit it,
> * make a branch or tag,
> * perform a simple merge.

Sounds terrific.

The current quickstart page focuses on "how do I quickly set up a my
own little repository, locally (with file:///) and put some stuff in
there". Like a beginning user / student / ... perhaps would like to
version his own files. I think it's a good way to introduce the
concepts of repository and working copy, and help them get started by
versioning some of their own files locally.

Do you think you can start from that "setup", and continue with the
topics you listed above? Or would you like to take a different angle?

> BTW, don't miss SVN-related docs on StackOverflow Documentation[3]. I'm pretty
> sure that some of the topics from that doc will be useful.

Interesting! Maybe we can link to that, or look what of those topics
we can cover as well.

> [1]: http://www.chim.unifi.it/~signo/did/etc/subversion/neat.html
> [2]: http://subversion.apache.org/quick-start
> [3]: https://stackoverflow.com/documentation/svn/topics
>
> --
> With best regards,
> Pavel Lyalyakin
> VisualSVN Team

Thanks for taking a look at this.

Cheers,
-- 
Johan

Re: svn commit: r1806017 - /subversion/trunk/subversion/libsvn_ra_serf/merge.c

[Evgeny Kotkov]

Bert Huijben  writes:

>> ra_serf: Prevent the server from generating and sending the full MERGE
>> response in cases when we don't require it.
>>
>> The full response is not required when working over HTTPv2 protocol.
>> When working over HTTPv1, it's only required when the new working copy
>> properties need to be stored as part of a commit (indicated by a non-null
>> svn_ra_push_wc_prop_func_t callback).
>
> Nice catch!
>
> Does this affect performance enough that we should backport this fix?

Thanks!

I guess that it would be nice to backport this fix, as it prevents the
server from reading the list of the committed changes after the commit
and also reduces the size of the sent response.  I think that the full
MERGE response can be quite large for commits with thousands of
changed paths, although I don't have any real numbers at this time.

With that in mind, I have put nominating this change on my todo list,
unless someone else beats me to it.


Regards,
Evgeny Kotkov

RE: svn commit: r1803143 - in /subversion/trunk/subversion: include/ libsvn_delta/ libsvn_ra_serf/ mod_dav_svn/

[Bert Huijben]

> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: woensdag 30 augustus 2017 07:07
> To: kot...@apache.org
> Cc: dev@subversion.apache.org; comm...@subversion.apache.org
> Subject: Re: svn commit: r1803143 - in /subversion/trunk/subversion:
> include/ libsvn_delta/ libsvn_ra_serf/ mod_dav_svn/
> 
> Good morning Evgeny,
> 
> kot...@apache.org wrote on Thu, 27 Jul 2017 09:00 +:
> > +++ subversion/trunk/subversion/include/svn_delta.h Thu Jul 27 09:00:43
> 2017
> > @@ -678,6 +690,9 @@ svn_txdelta_skip_svndiff_window(apr_file
> >   * @{
> >   */
> >
> > +/* Forward declarations. */
> > +typedef struct svn_delta_editor_t svn_delta_editor_t;
> > +
> >  /** A structure full of callback functions the delta source will invoke
> >   * as it produces the delta.
> >   *
> > @@ -859,7 +874,7 @@ svn_txdelta_skip_svndiff_window(apr_file
> >   * dead; the only further operation which may be called on the editor
> >   * is @c abort_edit.
> >   */
> > -typedef struct svn_delta_editor_t
> > +struct svn_delta_editor_t
> >  {
> >/** Set the target revision for this edit to @a target_revision.  This
> > * call, if used, should precede all other editor calls.
> > @@ -1131,9 +1146,38 @@ typedef struct svn_delta_editor_t
> >svn_error_t *(*abort_edit)(void *edit_baton,
> >   apr_pool_t *scratch_pool);
> >
> > +  /** Apply a text delta stream, yielding the new revision of a file.
> > +   *
> > +   * @a file_baton indicates the file we're creating or updating, and the
> > +   * ancestor file on which it is based; it is the baton set by some
> > +   * prior @c add_file or @c open_file callback.
> > +   *
> > +   * @a open_func is a function that opens a #svn_txdelta_stream_t
> object.
> > +   * @a open_baton is provided by the caller.
> > +   *
> > +   * @a base_checksum is the hex MD5 digest for the base text against
> > +   * which the delta is being applied; it is ignored if NULL, and may
> > +   * be ignored even if not NULL.  If it is not ignored, it must match
> 
> What's the rationale for allowing drivees to ignore the checksum?
> 
> This leeway enables failure modes that wouldn't be possible without it.
> (Drivers that are aware of this leeway will validate checksums even if the
> drivee doesn't, leading to duplicate work; drivers that are unaware of this
> requirement might not get checksum errors they should have.)
> 
> I get that you just copied this part of the docstring from apply_textdelta(),
> but I'd like to understand what's the rationale here.  (And to see if this
> leeway should be deprecated)

I think this just documents current behavior. Yes a 1.9+ client against a 1.9+ 
server will always have a checksum, but this is not the case when mixing older 
clients and servers.

Original serf versions (form before we declared this stable) typically never 
provided the checksum. And in some cases bulk requests didn't have all the 
checksums either. I remember fixing a few cases around WC-NG to make sure all 
ra layers reported the same errors in some exceptional cases.

Bert