Re: Escape sequences in log messages [etc]

[Doug Robinson]

Daniel, et. al.:

On Mon, Jan 2, 2023 at 5:14 PM Daniel Sahlberg 
wrote:

> In a thread started by Vincent Lefevre in October [1] it was noted that
> Subversion prints several pieces of information from the repository to the
> terminal (including log messages and author names) without considering if
> they may affect terminal behaviour.
>
> As demonstrated by DanielSh [2] a user may inject escape sequences into a
> log message and when running svn log, these affect terminal color. Git
> behaves the same way, as demonstrated by me [3].
>

Any idea what Git is going to do with this?


> Can we reach consensus if this behaviour is intended, unintended but
> desirable or unintended and undesirable? I would value the opinions of the
> oldtimers who might have background information if this was ever discussed
> or considered in the early days.
>
> In the original thread there were several arguments both pro and con
> regarding filtering/quoting escape sequences.
>

>From my perspective trying to do anything about this is opening up a huge
investigation that may result in incompatible-with-history choices.

1. What about "svn diff" ?  (any modifications here could break "patch",
et. al.)
2. What about "svn cat" ?
3. What about properties?  (I just verified you can place escape sequences
in them).
...

(I doubt my list above is complete.)

A "complete" implementation of a "feature" to mask/protect-against escape
sequences is also going to need an option to enable the raw output
(including the escape sequences) for every command/context where they could
be coming out today.  The reason is that somebody out there has possibly
used that "feature" as a "capability" to automate something.  Preventing
the output now would completely break whatever automation they cooked up.
And it is unlikely that anyone inheriting that automation will understand
it enough AND be reading this thread to object.

Changing the default behavior is also something that could be argued to be
breaking change requiring a "major number" to get bumped (e.g. a new
release - not a patch)...

Just some thoughts.

Doug

-- 


 


THIS MESSAGE AND ANY ATTACHMENTS ARE 
CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Re: 20th anniversary press?

[Doug Robinson]

Folks:

On Mon, Jan 6, 2020 at 9:21 AM Nathan Hartman 
wrote:

> Daniel Shahaf  wrote:
> >
> > We're coming up on the 20th anniversary of the first commit to
> > Subversion's CVS repository:
> >
> > [[[
> > % svn log ^/subversion -r 0:HEAD -l 3 | vipe
> > 
> > r836421 | kfogel | 2000-02-29 20:32:07 -0600 (Tue, 29 Feb 2000) | 2 lines
> > Changed paths:
> > A /subversion/trunk/src
> > A /subversion/trunk/src/LICENSE
> >
> > initial checkin
> >
> > 
> > % ]]]
> >
> > Sounds like an excuse to do a press release?  Or something to mention in
> > the announcement of 1.14.0-LTS, at least?
>
>
> It's super cool that Subversion's birthday is Leap Day 2000. [1]
>
> I think it's a great idea to celebrate with a press release.
>

There's a LinkedIn discussion group for SVN (and CVS) [3].  Perhaps posting
there might get some testimonials?

[3] https://www.linkedin.com/groups/157593/

Cheers.

Doug


> [1] That day is cool for a variety of reasons. It's the year 2000. It
> has a leap day, contrary to most years divisible by 100 (because it's
> also divisible by 400 [2]). And it's the birthday of the best version
> control system ever!
>
> [2] https://www.timeanddate.com/date/leapyear.html
>
> Nathan
>


-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The *LiveData* Company
*Find out more 
*wandisco.com *



 



THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Re: 20th anniversary press?

[Doug Robinson]

Nathan:

Let me see what we can do.

Cheers.

Doug

On Fri, Jan 10, 2020 at 10:20 AM Nathan Hartman 
wrote:

> On Fri, Jan 10, 2020 at 10:07 AM Doug Robinson 
> wrote:
>
>> Folks:
>>
>> On Mon, Jan 6, 2020 at 9:21 AM Nathan Hartman 
>> wrote:
>>
>>> It's super cool that Subversion's birthday is Leap Day 2000. [1]
>>>
>>
>> That's amazing!  First commit on a leap day?!  Cool.
>>
>
> Not just any leap day, one that happens only every 400 years.
>
> Let me know if WANdisco can help the celebration in any way.
>>
>
> We need testimonials, preferably from highly visible corporate users;
> anything that answers the question "Who uses Subversion?" for the press
> release.
>
> If you can help us secure some testimonials, that will be very helpful and
> much appreciated!
>
> Cheers,
> Nathan
>
>
>

-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* <http://wandisco.com/>*

**The *LiveData* Company
*Find out more 
*wandisco.com <http://wandisco.com/>*



 
<https://www.wandisco.com/liveanalytics>


THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Re: 20th anniversary press?

[Doug Robinson]

Folks:

On Mon, Jan 6, 2020 at 9:21 AM Nathan Hartman 
wrote:

> Daniel Shahaf  wrote:
> >
> > We're coming up on the 20th anniversary of the first commit to
> > Subversion's CVS repository:
> >
> > [[[
> > % svn log ^/subversion -r 0:HEAD -l 3 | vipe
> > 
> > r836421 | kfogel | 2000-02-29 20:32:07 -0600 (Tue, 29 Feb 2000) | 2 lines
> > Changed paths:
> > A /subversion/trunk/src
> > A /subversion/trunk/src/LICENSE
> >
> > initial checkin
> >
> > 
> > % ]]]
> >
> > Sounds like an excuse to do a press release?  Or something to mention in
> > the announcement of 1.14.0-LTS, at least?
>
> It's super cool that Subversion's birthday is Leap Day 2000. [1]
>

That's amazing!  First commit on a leap day?!  Cool.


> I think it's a great idea to celebrate with a press release.
>

Let me know if WANdisco can help the celebration in any way.

Cheers.

Doug


>
> Let me know how I can help.
>
>
> [1] That day is cool for a variety of reasons. It's the year 2000. It
> has a leap day, contrary to most years divisible by 100 (because it's
> also divisible by 400 [2]). And it's the birthday of the best version
> control system ever!
>
> [2] https://www.timeanddate.com/date/leapyear.html
>
> Nathan
>


-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The *LiveData* Company
*Find out more 
*wandisco.com *



 



THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Re: "svn patch" and the TAB character

[Doug Robinson]

Brane, Stefan, Daniel, Nathan:

Thank you for the discussion - it filled in history that I could not find.
I understand the issues now.  Cheers!

Happy Holidays!

Doug

On Tue, Dec 17, 2019 at 9:42 AM Branko Čibej  wrote:

> On 17.12.2019 14:58, Stefan Sperling wrote:
> > On Tue, Dec 17, 2019 at 08:33:09AM -0500, Doug Robinson wrote:
> >>>  And of course, both the
> >>> filename and the label (= the part after the tab character) may
> contain an
> >>> arbitrary number of spaces.
> >> The problem is parsing the line into proper tokens when every character
> out
> >> there can be part of the file name.  There must be a structure to the
> field
> >> or parsing is not really parsing anymore.
> > The output of 'svn diff' was not designed with 'svn patch' in mind.
> > The diff command preceded the patch command by many years.
> >
> > I still believe that making --patch-compatible produce filenames without
> > any trailing annotations in the output of 'svn diff' is the best answer.
>
>
> Agreed. Plain-vanilla BSD patch should be able to apply such patches, as
> should 'svn patch'.
>
>
> > This whole discussion started off with the problem statement that the
> > --patch-compatible option produces a diff which cannot be applied after
> > tabs are replaced with spaces.
> >
> > This filename parsing problem isn't limited to 'svn patch'. Other patch
> > implementations might run into the same problem. The way 'svn patch'
> finds
> > the filename is based on Larry Wall's original patch program.
>
> Precisely. That TAB *is* the canonical delimiter. The (implicit)
> specification is decades old, and it would be an error to try to
> second-guess it at this point.
>
> Designing a stricter universal format for transmitting contextual
> changes is a different matter entirely, one that we tried to tackle in
> the past and failed; other version control systems tried and failed,
> too. It would be a nice thing to have, but it's hardly something this
> community can do in isolation.
>
> > Generally, patches being mangled in transit is a notorious problem
> especially
> > with web-based email. It's not really a safe format for this purpose. If
> patches
> > get changed in transit in any way there is no guarantee they will apply
> cleanly.
> > That's not a new problem, it's a long-standing issue. And it's not
> SVN-specific.
> > There is already a way to transfer changes without such problems: svn
> commit
>
> And note that the tabs-to-spaces headache doesn't stop with parsing the
> filename out of the header, it affects the filename itself. I can put
> tabs in a filename on most Unix filesystems ... that would probably
> break even the original patch tool.
>
> -- Brane
>


-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* <http://wandisco.com/>*

**The *LiveData* Company
*Find out more 
*wandisco.com <http://wandisco.com/>*



 
<https://www.wandisco.com/liveanalytics>


THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Re: "svn patch" and the TAB character

[Doug Robinson]

On Mon, Dec 16, 2019 at 8:55 PM Daniel Shahaf 
wrote:
> Doug Robinson wrote on Mon, Dec 16, 2019 at 11:13:25 -0500:
> > So the two file names, differing only by a TAB in the "right place" will
> > currently have completely different behaviors:
> >
> >   My File NameSPACE(Revision 12)
> >   My File NameTAB(Revision 12)
> >
> > I see no point in maintaining that the "TAB" is critically significant
and
> > different from the "SPACE".  The difference is easier parsing vs. 1
visually
> > indistinguishable use case (depending on what tool you are using to
view the
> > diff file).
> >
> > And the "sequence of SPACE" instead of just a single "SPACE" falls into
the
> > same visually indistinguishable category.  So keep the parsing simple
and
> > just declare file names with "SP/TAB(Revision #)" at the end to not be
> > supported.
>
> You can't assume the string after the tab will be "(revision %ld)".
>
> First of all, as I already pointed out, that string is translatable.

Then we're screwed.  Some languages will have the revision number before
the word.  Some may actually require characters on both sides of the
revision number.

There's a reason that languages like C, C++, Java, etc. have "keywords" -
so they can properly parse the code.  In this case the "code" is in the
form of a "diff" file and the language-variant "SVN diff" needs a
fixed-text keyword with a specific operational sequence, e.g. "(KEYWORD
OPERAND)", i.e. "(revision 1234)".  Short of that parsing is purely
accidental.

> Second of
> all, we also have to support patches generated by third-party tools,
which may
> contain arbitrary text after the tab character.

Define the language.  Require the tooling to comply.  Trying to make
everything work (everybody happy) is the path to failure.

>  And of course, both the
> filename and the label (= the part after the tab character) may contain an
> arbitrary number of spaces.

The problem is parsing the line into proper tokens when every character out
there can be part of the file name.  There must be a structure to the field
or parsing is not really parsing anymore.

> Please propose an algorithm for parsing a filename out of a diff header
line
> (a '---' line or a '+++' line) that doesn't contain tabs, under these
conditions.
> (We don't have to fix _all_ cases, but fixing the bug just for English
speakers
> isn't going to fly.)

Anything I propose without keywords/structure I can trivially
counter-example.  Something will break.  As is the current situation.

-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* <http://wandisco.com/>*

**The *LiveData* Company
*Find out more 
*wandisco.com <http://wandisco.com/>*



 
<https://www.wandisco.com/liveanalytics>


THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Re: "svn patch" and the TAB character

[Doug Robinson]

On Sat, Dec 14, 2019 at 6:13 AM Stefan Sperling  wrote:

> 'svn patch' already behaves like regular patch, i.e. it assumes the whole
> line
> denotes a file name if no TAB can be found.
>
> The problem is that svn diff's revision number marker " (revision XY)" must
> be separated by a TAB. Otherwise it becomes part of the file name.
> Perhaps --patch-compatible should omit those markers?
>

The real problem is historical: poorly defined headers.
If the headers were simply:

  Something1: 
  Something2: 

Then there would be no problem.  With the current setup, the ambiguity means
that some file names are explicitly disallowed from being supported due to a
lack of disambiguating syntax (some type of quoting).  So the two file
names,
differing only by a TAB in the "right place" will currently have
completely different
behaviors:

  My File NameSPACE(Revision 12)
  My File NameTAB(Revision 12)

I see no point in maintaining that the "TAB" is critically significant and
different
from the "SPACE".  The difference is easier parsing vs. 1 visually
indistinguishable
use case (depending on what tool you are using to view the diff file).

And the "sequence of SPACE" instead of just a single "SPACE" falls into the
same visually indistinguishable category.  So keep the parsing simple and
just
declare file names with "SP/TAB(Revision #)" at the end to not be supported.

Cheers.

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The *LiveData* Company
*Find out more 
*wandisco.com *



 



THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

"svn patch" and the TAB character

[Doug Robinson]

Folks:

If I use "svn diff --patch compatible" to produce a patch file.  Then edit
that patch file using an editor with settings that replace the TAB with a
"proper" number of SPACE characters, the "svn patch" command will declare:

$ svn patch ../n.txt
Skipped missing target: 'TheFile  (revision 18)'
Summary of conflicts:
  Skipped paths: 1

(the TAB was between "TheFile" and "(revision...)".  Changing the spaces
back to a tab enables the "svn patch" command to work.

I'm wondering if this is:
A. "goodness" as in "protection against diff chunks being
contaminated/modified" or
B. "bug" as in "the other patch tools out there don't enforce that TAB".

I looked through old postings and didn't see a discussion.

Thoughts?

Cheers.

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The *LiveData* Company
*Find out more 
*wandisco.com *



 



THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Re: Last-Modified HTTP header in GET responses

[Doug Robinson]

Daniel:

On Mon, Nov 25, 2019 at 1:31 PM Daniel Shahaf 
wrote:

> Doug Robinson wrote on Mon, 25 Nov 2019 14:11 +00:00:
> > Can we get this fix back-ported into 1.10.x please? Breaking an LTS is
> > unfortunate as is waiting until the next LTS.
>
> r1866425 is already in
>
> https://svn.apache.org/repos/asf/subversion/branches/1.10.x/STATUS?p=r1870409
> .
> It will likely receive the third vote and be merged before the next
> 1.10.x release.  We haven't scheduled that release yet.
>
> That revision was already merged to 1.12.x, too, so it should be
> reasonably safe to cherry-pick.
>

Thank you.

Cheers!

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* <http://wandisco.com/>*

**The *LiveData* Company
*Find out more 
*wandisco.com <http://wandisco.com/>*



 
<https://www.wandisco.com/liveanalytics>


THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Re: Last-Modified HTTP header in GET responses

[Doug Robinson]

Folks:

Can we get this fix back-ported into 1.10.x please?  Breaking an LTS is
unfortunate as is waiting until the next LTS.

Cheers.

Doug

On Wed, Sep 4, 2019 at 8:03 PM Johan Corveleyn  wrote:

> On Wed, Sep 4, 2019 at 2:47 PM Johan Corveleyn  wrote:
> >
> > On Wed, Sep 4, 2019 at 2:01 PM Branko Čibej  wrote:
> > >
> > > On 04.09.2019 11:44, Johan Corveleyn wrote:
> > > > On Tue, Sep 3, 2019 at 8:01 AM Branko Čibej 
> wrote:
> > > [...]
> > > >>> Anyway, how about bringing this feature back in some form?
> > > >>> - Revert r1724790?
> > > >> This is clearly the simplest solution, but I have no idea what the
> > > >> performance impact would be. From looking at the diff, my best
> guess is
> > > >> that svn_fs_node_created_rev() and svn_fs_revision_prop() dominate.
> > > >>
> > > >>> - or only for "external GET urls"?
> > > >>> - or only if some Apache directive is set?
> > > >>>
> > > >>> Thoughts?
> > > >> I would prefer not to add yet another configuration knob to the
> server.
> > > >> I agree that versioned-resource URLs are only interesting for
> DAV-aware
> > > >> clients, and those clients already know how to check for
> modifications
> > > >> without looking at Last-Modified. That would imply that adding the
> > > >> header for external URLs is the right solution.
> > > >>
> > > >> -- Brane
> > > > Thanks for your response, Brane.
> > > >
> > > > I think the below patch would do it (set the Last-Modified header
> only
> > > > for "external URLs").
> > > > It's basically a revert of r1724790 (and adding a test), plus
> wrapping
> > > > the actual setting of Last-Modified inside the following condition:
> > > >
> > > > if ((resource->type == DAV_RESOURCE_TYPE_REGULAR)
> > > > && (resource->info->repos_path ==
> resource->info->uri_path->data))
> > >
> > > Yes, all our resources are "regular", I think. The second part of the
> > > condition just says that if something is called "/foo/bar" in the
> > > repository, it's being accessed as
> > > "http://example.org/repos-root/foo/bar; and not some alias. Which is
> > > exactly what you want.
> >
> > Perfect.
> >
> > > >  const char *
> > > >  dav_svn__getetag(const dav_resource *resource, apr_pool_t *pool)
> > > >  {
> > > > @@ -3219,6 +3263,25 @@ set_headers(request_rec *r, const
> dav_resource *re
> > > >if (!resource->exists)
> > > >  return NULL;
> > > >
> > > > +  if ((resource->type == DAV_RESOURCE_TYPE_REGULAR)
> > > > +  && (resource->info->repos_path ==
> resource->info->uri_path->data))
> > > > +{
> > > > +  /* Include Last-Modified header for 'external' GET requests
> > > > + (i.e. requests to URI's not under /!svn), to support usage
> of an
> > > > + SVN server as a file server, where the client needs
> timestamps
> > > > + for instance to use as "last modification time" of files
> on disk. */
> > > > +  apr_time_t last_modified;
> > > > +
> > > > +  last_modified = get_last_modified(resource);
> > >
> > > "Declaration is initialisation" please, wherever possible. So:
> > >
> > > const apr_time_t last_modified = get_last_modified(resource);
> > >
> > >
> > > This also prevents you from accidentally modifying last_modified later
> on.
> >
> > Ack, will fix.
> >
> > > > +  if (last_modified != -1)
> > > > +{
> > > > +  /* Note the modification time for the requested resource,
> and
> > > > + include the Last-Modified header in the response. */
> > > > +  ap_update_mtime(r, last_modified);
> > > > +  ap_set_last_modified(r);
> > > > +}
> > > > +}
> > > > +
> > > >/* generate our etag and place it into the output */
> > > >apr_table_setn(r->headers_out, "ETag",
> > > >   dav_svn__getetag(resource, resource->pool));
> > > > Index: subversion/tests/cmdline/mod_dav_svn_tests.py
> > > > ===
> > > > --- subversion/tests/cmdline/mod_dav_svn_tests.py(revision
> 1866345)
> > > > +++ subversion/tests/cmdline/mod_dav_svn_tests.py(working copy)
> > > > @@ -640,6 +640,29 @@ def propfind_propname(sbox):
> > > >actual_response = r.read()
> > > >verify_xml_response(expected_response, actual_response)
> > > >
> > > > +@SkipUnless(svntest.main.is_ra_type_dav)
> > > > +def last_modified_header(sbox):
> > > > +  "verify 'Last-Modified' header on 'external' GETs"
> > > > +
> > > > +  sbox.build(create_wc=False, read_only=True)
> > > > +
> > > > +  headers = {
> > > > +'Authorization': 'Basic ' +
> > > > base64.b64encode(b'jconstant:rayjandom').decode(),
> > > > +  }
> > > > +
> > > > +  h = svntest.main.create_http_connection(sbox.repo_url)
> > > > +
> > > > +  # GET /repos/iota
> > > > +  # Expect to see a Last-Modified header.
> > > > +  h.request('GET', sbox.repo_url + '/iota', None, headers)
> > > > +  r = h.getresponse()
> > > > +  if r.status != httplib.OK:
> > > > +raise svntest.Failure('Request failed: %d %s' % 

Re: Better choice for Linux semaphore than spinlock?

[Doug Robinson]

Rüdiger:

On Mon, Oct 7, 2019 at 3:51 PM Ruediger Pluem  wrote:

> On 10/07/2019 08:40 PM, Branko Čibej wrote:
> > On Mon, 7 Oct 2019, 19:47 Doug Robinson,  <mailto:doug.robin...@wandisco.com>> wrote:
> >
> > Folks:
> >
> > I spoke with this user late last week.  They stated that they can
> only get approximately 400 parallel SVN operations
> > before the "system time" consumes all available CPU for an 8-core
> machine.  Adding more cores won't help because of
> > the nature of spin locks (it makes things worse).  Turns out that
> even with ~100 parallel SVN operations the "system
> > time" starts becoming significant/measurable (~10%).  Both HTTP
> (mod_dav_svn) and "svnserve" protocols participate
> > in the lock contention.
> >
> > Your help would be greatly appreciated.
> >
> > Whew. So. Reducing this issue to "use a more efficient lock" is not
> going to work, and you provided far too little
> > information to even attempt a diagnosis. For starters, I recommend
> gathering as much info as possible (anonymised of
> > course) about the server configuration, everything from httpd an
> svnserve to the repository config and underlying
> > filesystem, if possible. Getting stack traces of the "stuck" threads
> would be necessary, too. Without knowing exactly
> > what is happening, these kinds of problems are extremely hard to
> understand, let alone fix.
>
> Plus depending on which part of the code requires this lock a different
> locking mechanism that might suit better for
> this use case can possibly be chosen via configuration changes (e.g. httpd
> allows this for most of its locking).
>

That would be awesome!  I'll definitely try to get those stack tracebacks.

Cheers.

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* <http://wandisco.com/>*

**The *LiveData* Company
*Find out more 
*wandisco.com <http://wandisco.com/>*



 
<https://www.wandisco.com/liveanalytics>


THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Re: Better choice for Linux semaphore than spinlock?

[Doug Robinson]

Brane:

On Mon, Oct 7, 2019 at 2:40 PM Branko Čibej  wrote:

> On Mon, 7 Oct 2019, 19:47 Doug Robinson, 
> wrote:
>
>> I spoke with this user late last week.  They stated that they can only
>> get approximately 400 parallel SVN operations before the "system
>> time" consumes all available CPU for an 8-core machine.  Adding more cores
>> won't help because of the nature of spin locks (it makes things worse).
>> Turns out that even with ~100 parallel SVN operations the "system time"
>> starts becoming significant/measurable (~10%).  Both HTTP (mod_dav_svn) and
>> "svnserve" protocols participate in the lock contention.
>>
>> Your help would be greatly appreciated.
>>
>
> Whew. So. Reducing this issue to "use a more efficient lock" is not going
> to work, and you provided far too little information to even attempt a
> diagnosis. For starters, I recommend gathering as much info as possible
> (anonymised of course) about the server configuration, everything from
> httpd an svnserve to the repository config and underlying filesystem, if
> possible. Getting stack traces of the "stuck" threads would be necessary,
> too. Without knowing exactly what is happening, these kinds of problems are
> extremely hard to understand, let alone fix.
>

I'll try to get this information and report back.  Or perhaps they can join
this conversation (I gave them a pointer).

I'd be surprised if the spinlock is the actual culprit. AFAIK, kernel-level
> locks hand off to the scheduler if they spin too long; on multiprocessor
> machines, this is usually more efficient than immediately yielding and
> causing an expensive context switch. It's possible that you're seeing an
> unfortunate timing "resonance" that might go away with either more *or*
> less cores being available. The behaviour is really hard to predict.
>

Note: the told me that RHEL support was used and that they identified the
culprit as SVN mutex locks being translated into spin-locks at the OS level.
They also provided the example of Apache itself already having worked
around this in better ways but because this is really buried deep in
mod_dav_svn/svnserve the Apache work-arounds won't help.

Again, I'll see what I can obtain in terms of stack tracebacks, etc.

Cheers.

Doug


>
> -- Brane
>
>
>
>> On Fri, Oct 4, 2019 at 9:20 AM Doug Robinson 
>> wrote:
>>
>>> Folks:
>>>
>>> From a Subversion user:
>>>
>>> “... we have very high concurrent connections to Subversion that seem to
>>> crater Subversion. The SVN Serve process we use to access the Subversion
>>> repository is using the “svn” protocol by our “system user”, mostly
>>> read-only.  Then, we, on behalf of the user make request to Subversion
>>> using the “http” protocol to fetch their data. So we have lots of
>>> connections to Subversion. But the volume of concurrent requests over the
>>> “svn” protocol cause the “svnserve” process to consume CPU cycles in a
>>> kernel “mutex-lock” which is implemented using “spin locks”. The “svnserve”
>>> process makes the mutex calls using the “apache” (APR) semaphore wait
>>> calls, but on Linux this is a “mutext-lock” request.”
>>>
>>> So is there a better, more scalable, semaphore that can be used?
>>>
>>
>
>

-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* <http://wandisco.com/>*

**The *LiveData* Company
*Find out more 
*wandisco.com <http://wandisco.com/>*



 
<https://www.wandisco.com/liveanalytics>


THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Re: Better choice for Linux semaphore than spinlock?

[Doug Robinson]

Folks:

I spoke with this user late last week.  They stated that they can only get
approximately 400 parallel SVN operations before the "system time" consumes
all available CPU for an 8-core machine.  Adding more cores won't help
because of the nature of spin locks (it makes things worse).  Turns out
that even with ~100 parallel SVN operations the "system time" starts
becoming significant/measurable (~10%).  Both HTTP (mod_dav_svn) and
"svnserve" protocols participate in the lock contention.

Your help would be greatly appreciated.

Cheers.

Doug

On Fri, Oct 4, 2019 at 9:20 AM Doug Robinson 
wrote:

> Folks:
>
> From a Subversion user:
>
> “... we have very high concurrent connections to Subversion that seem to
> crater Subversion. The SVN Serve process we use to access the Subversion
> repository is using the “svn” protocol by our “system user”, mostly
> read-only.  Then, we, on behalf of the user make request to Subversion
> using the “http” protocol to fetch their data. So we have lots of
> connections to Subversion. But the volume of concurrent requests over the
> “svn” protocol cause the “svnserve” process to consume CPU cycles in a
> kernel “mutex-lock” which is implemented using “spin locks”. The “svnserve”
> process makes the mutex calls using the “apache” (APR) semaphore wait
> calls, but on Linux this is a “mutext-lock” request.”
>
> So is there a better, more scalable, semaphore that can be used?
>
> Cheers.
>
> Doug
> --
> *DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER
>
> T +1 925 396 1125
> *E* doug.robin...@wandisco.com
>


-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* <http://wandisco.com/>*

**The *LiveData* Company
*Find out more 
*wandisco.com <http://wandisco.com/>*



 
<https://www.wandisco.com/liveanalytics>


THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Better choice for Linux semaphore than spinlock?

[Doug Robinson]

Folks:

>From a Subversion user:

“... we have very high concurrent connections to Subversion that seem to
crater Subversion. The SVN Serve process we use to access the Subversion
repository is using the “svn” protocol by our “system user”, mostly
read-only.  Then, we, on behalf of the user make request to Subversion
using the “http” protocol to fetch their data. So we have lots of
connections to Subversion. But the volume of concurrent requests over the
“svn” protocol cause the “svnserve” process to consume CPU cycles in a
kernel “mutex-lock” which is implemented using “spin locks”. The “svnserve”
process makes the mutex calls using the “apache” (APR) semaphore wait
calls, but on Linux this is a “mutext-lock” request.”

So is there a better, more scalable, semaphore that can be used?

Cheers.

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The *LiveData* Company
*Find out more 
*wandisco.com *



 



THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Re: patch on files with svn:keywords ends up with 0600 perms

[Doug Robinson]

Stefan:

Thank you!

Cheers!

Doug

On Mon, Aug 5, 2019 at 10:38 AM Stefan Sperling  wrote:

> On Mon, Aug 05, 2019 at 08:40:48AM -0400, Doug Robinson wrote:
> > Gentle reminder.
> >
> > On Fri, Jul 26, 2019 at 5:43 PM Doug Robinson <
> doug.robin...@wandisco.com>
> > wrote:
>
> Hi Doug,
>
> The problem should be fixed with this commit:
> https://svn.apache.org/r1864440
> It's a simple matter of creating temporary files in the working copy's temp
> directory instead of the system-wide one.
>
> Regards,
> Stefan
>
> > > Committers, et. al.:
> > >
> > > This was just sent to us by a customer.  We've verified on at 1.10.4.
> I
> > > checked in JIRA and didn't find a matching bug.  Should I create a new
> JIRA?
> > > 
> > >
> > > $ svnadmin create test_repo
> > >
> > > $ svn co file:///tmp/test_repo accnt
> > > Checked out revision 0.
> > >
> > > $ cd accnt/
> > > $ touch a.c b.c
> > > $ svn add a.c b.c
> > > A a.c
> > > A b.c
> > >
> > > # Adding property only on a.c
> > > $ svn propset svn:keywords "Id Revision Date URL Author Header" a.c
> > > property 'svn:keywords' set on 'a.c'
> > > $ ls -l
> > > total 0
> > > -rw-r--r-- 1 accnt qa-others 0 Jul 25 13:47 a.c
> > > -rw-r--r-- 1 accnt qa-others 0 Jul 25 13:47 b.c
> > > $ svn commit -m "test commit"
> > > Adding a.c
> > > Adding b.c
> > > Transmitting file data ..done
> > > Committing transaction...
> > > Committed revision 1.
> > > $ svn patch /tmp/patch
> > > U a.c
> > > > applied hunk @@ -0,0 +1,1 @@ with offset 0
> > > U b.c
> > > > applied hunk @@ -0,0 +1,1 @@ with offset 0
> > >
> > > # After applying patch the permission on the file with property
> > > svn:keywords has changed.
> > > $ ls -l
> > > total 8
> > > -rw--- 1 accnt qa-others 11 Jul 25 13:49 a.c
> > > -rw-r--r-- 1 accnt qa-others 28 Jul 25 13:49 b.c
> > >
> > > $ umask
> > > 0022
> > >
> > > # The patch applied:
> > > $ cat /tmp/patch
> > > Index: a.c
> > > ===
> > > --- a.c (revision 1)
> > > +++ a.c (working copy)
> > > @@ -0,0 +1 @@
> > > +test patch
> > > Index: b.c
> > > ===
> > > --- b.c (revision 1)
> > > +++ b.c (working copy)
> > > @@ -0,0 +1 @@
> > > +test patch without keywords
> > >
> > > --
> > > *DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER
> > >
> > > T +1 925 396 1125
> > > *E* doug.robin...@wandisco.com
> > >
> >
> >
> > --
> > *DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER
> >
> > T +1 925 396 1125
> > *E* doug.robin...@wandisco.com
> >
> > --
> >
> >
> > * <http://wandisco.com>*
> >
> > **The LIVE DATA Company
> > *Find out more
> > *wandisco.com <http://wandisco.com/>*
> >
> >
> >
> >
> > <https://www.wandisco.com/welcome-live-data-world-video>
> > *
> >
> >
> > THIS MESSAGE
> > AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
> >
> > If
> > this message was misdirected, WANdisco, Inc. and its subsidiaries,
> > ("WANdisco") does not waive any confidentiality or privilege. If you are
> > not the intended recipient, please notify us immediately and destroy the
> > message without disclosing its contents to anyone. Any distribution, use
> or
> > copying of this email or the information it contains by other than an
> > intended recipient is unauthorized. The views and opinions expressed in
> > this email message are the author's own and may not reflect the views
> and
> > opinions of WANdisco, unless the author is authorized by WANdisco to
> > express such views or opinions on its behalf. All email sent to or from
> > this address is subject to electronic storage and review by WANdisco.
> > Although WANdisco operates anti-virus programs, it does not accept
> > responsibility for any damage whatsoever caused by viruses being passed.
>


-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* <http://wandisco.com>*

**The LIVE DATA Company
*Find out more 
*wandisco.com <http://wandisco.com/>*



 

Re: patch on files with svn:keywords ends up with 0600 perms

[Doug Robinson]

Gentle reminder.

On Fri, Jul 26, 2019 at 5:43 PM Doug Robinson 
wrote:

> Committers, et. al.:
>
> This was just sent to us by a customer.  We've verified on at 1.10.4.  I
> checked in JIRA and didn't find a matching bug.  Should I create a new JIRA?
> 
>
> $ svnadmin create test_repo
>
> $ svn co file:///tmp/test_repo accnt
> Checked out revision 0.
>
> $ cd accnt/
> $ touch a.c b.c
> $ svn add a.c b.c
> A a.c
> A b.c
>
> # Adding property only on a.c
> $ svn propset svn:keywords "Id Revision Date URL Author Header" a.c
> property 'svn:keywords' set on 'a.c'
> $ ls -l
> total 0
> -rw-r--r-- 1 accnt qa-others 0 Jul 25 13:47 a.c
> -rw-r--r-- 1 accnt qa-others 0 Jul 25 13:47 b.c
> $ svn commit -m "test commit"
> Adding a.c
> Adding b.c
> Transmitting file data ..done
> Committing transaction...
> Committed revision 1.
> $ svn patch /tmp/patch
> U a.c
> > applied hunk @@ -0,0 +1,1 @@ with offset 0
> U b.c
> > applied hunk @@ -0,0 +1,1 @@ with offset 0
>
> # After applying patch the permission on the file with property
> svn:keywords has changed.
> $ ls -l
> total 8
> -rw--- 1 accnt qa-others 11 Jul 25 13:49 a.c
> -rw-r--r-- 1 accnt qa-others 28 Jul 25 13:49 b.c
>
> $ umask
> 0022
>
> # The patch applied:
> $ cat /tmp/patch
> Index: a.c
> ===
> --- a.c (revision 1)
> +++ a.c (working copy)
> @@ -0,0 +1 @@
> +test patch
> Index: b.c
> ===
> --- b.c (revision 1)
> +++ b.c (working copy)
> @@ -0,0 +1 @@
> +test patch without keywords
>
> --
> *DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER
>
> T +1 925 396 1125
> *E* doug.robin...@wandisco.com
>


-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* <http://wandisco.com>*

**The LIVE DATA Company
*Find out more 
*wandisco.com <http://wandisco.com/>*



 
<https://www.wandisco.com/welcome-live-data-world-video>
*


THIS MESSAGE 
AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If 
this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

patch on files with svn:keywords ends up with 0600 perms

[Doug Robinson]

Committers, et. al.:

This was just sent to us by a customer.  We've verified on at 1.10.4.  I
checked in JIRA and didn't find a matching bug.  Should I create a new JIRA?


$ svnadmin create test_repo

$ svn co file:///tmp/test_repo accnt
Checked out revision 0.

$ cd accnt/
$ touch a.c b.c
$ svn add a.c b.c
A a.c
A b.c

# Adding property only on a.c
$ svn propset svn:keywords "Id Revision Date URL Author Header" a.c
property 'svn:keywords' set on 'a.c'
$ ls -l
total 0
-rw-r--r-- 1 accnt qa-others 0 Jul 25 13:47 a.c
-rw-r--r-- 1 accnt qa-others 0 Jul 25 13:47 b.c
$ svn commit -m "test commit"
Adding a.c
Adding b.c
Transmitting file data ..done
Committing transaction...
Committed revision 1.
$ svn patch /tmp/patch
U a.c
> applied hunk @@ -0,0 +1,1 @@ with offset 0
U b.c
> applied hunk @@ -0,0 +1,1 @@ with offset 0

# After applying patch the permission on the file with property
svn:keywords has changed.
$ ls -l
total 8
-rw--- 1 accnt qa-others 11 Jul 25 13:49 a.c
-rw-r--r-- 1 accnt qa-others 28 Jul 25 13:49 b.c

$ umask
0022

# The patch applied:
$ cat /tmp/patch
Index: a.c
===
--- a.c (revision 1)
+++ a.c (working copy)
@@ -0,0 +1 @@
+test patch
Index: b.c
===
--- b.c (revision 1)
+++ b.c (working copy)
@@ -0,0 +1 @@
+test patch without keywords

-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The LIVE DATA Company
*Find out more 
*wandisco.com *



 

*


THIS MESSAGE 
AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If 
this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: SVN 1.10 AuthZ file parsing too strict?!

[Doug Robinson]

Brane:

See below.

On Sat, Jan 19, 2019 at 15:12 Branko Čibej  wrote:

> On 19.01.2019 17:17, Branko Čibej wrote:
>
> Hi Doug!
>
> On 18.01.2019 23:07, Doug Robinson wrote:
>
> Honored committers (and the rest of us):
>
> It's come to my attention that if a group is defined in an AuthZ
> file without an associated account that SVN is, as of 1.10, generating
> an error and failing to allow the use of that AuthZ file.
>
> Example:
>
> [groups]
> goodGroup = acct1
> goodGroup2 = acct1, acct2
> badGroup =
>
> [repoName:/someplace]
> @badGroup = rw
>
> svnauthz: E220003: Error while parsing authz file: ...
> svnauthz: E220003: Access entry refers to undefined group ...
>
>
>
> Thanks for bringing this up. It's most definitely a bug ... the group is
> defined, it's just empty. If the parser accepts an empty group definition,
> it should also allow its use in rules. That ACE should just be ignored,
> since it has no effect.
>
> Emitting a warning from svnauthz would be a bonus, but I'm not sure
> offhand how to do that, as I don't think we have a warning callback in the
> parser; it might involve some API changes, but nothing drastic.
>
> Can you please write this up as a Jira issue and assign it to me?
>
> My thoughts:
>
> 1. From a compatibility standpoint it really should be a Warning,
> not an Error.  If there's no accounts then certainly it can have
> no impact on the security of the repository/ies.
>
>
> And further, if one generates the 'groups' file from LDAP, for example,
> some unintentional intermediate state could break Subversion authz even
> though there's nothing specifically wrong with it.
>
> 2. From a usability standpoint it really should simply be supported.
> The AuthZ file is a representation of a team structure.  There are
> times when teams will get reduced headcount down to zero and then
> back up again.  To deal with that use case with SVN 1.10 means
> either:
>
> a) stripping out all references to the team and losing all of the
>places where that team requires access
>
> b) configuring a dummy account for the team and hoping that the
>account will never be created
>
> c) leaving the team around and fixing SVN to allow an empty team
>
> My preference would be first 2c and, if not, then 1.  But that's
> me.
>
> Not sure about the history of why this change was made?  I'd like
> to better understand.
>
>
> It's an unintentional consequence of the parser rewrite. It appears that
> we don't have a test for this case, and code inspection didn't catch the
> change in semantics ... and so it landed in released code.
>
> This is about to change. :)
>
>
> Fixed in r1851687; I'll nominate this for backport to 1.10.x and 1.11.x.
>

Nice!


>
> Emitting a warning from svnauthz requires a public API change that can't
> be released before 1.12, so please do write that Jira issue.
>

Will do - on Monday!  Cheers!

Thank you again.

Doug


>
> -- Brane
>
> --
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* <http://wandisco.com>*

**The LIVE DATA Company
*Find out more 
*wandisco.com <http://wandisco.com/>*



 
<https://www.wandisco.com/welcome-live-data-world-video>
*


THIS MESSAGE 
AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If 
this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

SVN 1.10 AuthZ file parsing too strict?!

[Doug Robinson]

Honored committers (and the rest of us):

It's come to my attention that if a group is defined in an AuthZ
file without an associated account that SVN is, as of 1.10, generating
an error and failing to allow the use of that AuthZ file.

Example:

[groups]
goodGroup = acct1
goodGroup2 = acct1, acct2
badGroup =

[repoName:/someplace]
@badGroup = rw

svnauthz: E220003: Error while parsing authz file: ...
svnauthz: E220003: Access entry refers to undefined group ...

My thoughts:

1. From a compatibility standpoint it really should be a Warning,
not an Error.  If there's no accounts then certainly it can have
no impact on the security of the repository/ies.

2. From a usability standpoint it really should simply be supported.
The AuthZ file is a representation of a team structure.  There are
times when teams will get reduced headcount down to zero and then
back up again.  To deal with that use case with SVN 1.10 means
either:

a) stripping out all references to the team and losing all of the
   places where that team requires access

b) configuring a dummy account for the team and hoping that the
   account will never be created

c) leaving the team around and fixing SVN to allow an empty team

My preference would be first 2c and, if not, then 1.  But that's
me.

Not sure about the history of why this change was made?  I'd like
to better understand.

Cheers.

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The LIVE DATA Company
*Find out more 
*wandisco.com *



 

*


THIS MESSAGE 
AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If 
this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: Support character classes in glob authz rules

[Doug Robinson]

Brane:

I just read through this thread.  Your proposal makes a lot of sense.
To me, it's one of those things that should go into a new version (not a
patch).
And there should be a nit-picky script to point out "strange stuff" (like
the example
that Julian posed).

Cheers.

Doug

On Mon, Dec 3, 2018 at 10:31 AM Branko Čibej  wrote:

> On 03.12.2018 16:07, Michael Pilato wrote:
> > On 12/3/18 3:15 AM, Julian Foad wrote:
> >> It makes me uncomfortable to depart from standard parsing. What if
> >> users are relying on Python ConfigParser or other compatible parsing
> >> as part of their Subversion authz infrastructure?
> > We needn't keep this hypothetical.  ViewVC is using (a slightly
> > modified[*]) Python ConfigParser in this way.
> >
> > -- Mike
> >
> > [*] By default, ConfigParser (well, really the RawConfigParser it
> > subclasses) lowercases option names, which can cause username/group
> > matching to fail.  So ViewVC's code replaces the optionxform method of
> > ConfigParser with a noop lambda function.  (See
> >
> https://docs.python.org/2/library/configparser.html#ConfigParser.RawConfigParser.optionxform
> > for official docs.)
>
>
> Interesting. Of course, our ConfigParser-like implementation already has
> the option to treat section names as case-sensitive, and this option is
> used ... that's righjt, by the authz file parser.
>
> -- Brane
>
>

-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The LIVE DATA Company
*Find out more 
*wandisco.com *



 

*


THIS MESSAGE 
AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If 
this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: authz changes between 1.9 and 1.10

[Doug Robinson]

Brane:

I've decided that documenting the syntax of authz files at this level
> doesn't really belong in this document. So I started this:
>
> https://cwiki.apache.org/confluence/x/oYvQBQ
>
> and will refer to that page instead, pointing out the differences.
>

The statement "Section names are case-insensitive and case-preserving." is
deeply
concerning as it means that the case sensitive sub-repository paths cannot
be
properly represented in sections (as they are today).

As noted, in https://cwiki.apache.org/confluence/x/7IjQBQ , the SVN section
headers
became case sensitive at SVN 1.7.

Not sure why 2 documents?

Cheers.

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The LIVE DATA Company
*Find out more 
*wandisco.com *



 

*


THIS MESSAGE 
AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If 
this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: SVN binaries: build linking process

[Doug Robinson]

Julian:

Just one quick note:

On Fri, Sep 28, 2018 at 10:42 AM Julian Foad  wrote:

> >> I used to have such a tool in a past environment.  It was WONDERFUL.  I
> haven't seen hide nor hair of one for Linux... that would be ideal.
>
> >See the most-voted answer here:
> https://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary
> -- "patchelf"https://nixos.org/patchelf.html is available in the >Ubuntu
> 18.04 repositories at least.
>

Nice!  I searched for that a while back and didn't find it.  I'll give it
some fun-time!


>  The background is that we have a customer who wants to be able to
> relocate our stuff and one of the first things we'd need to do is to either
> rebuild with a specific path just for them, or rebuild with just the
> leafnames so taht LD_LIBRARY_PATH will work.
> >>>
> >>> The leafnames, plus perhaps some appropriate "rpath"-y configuration
> if you want a default location, sounds like the right way to go, unless
> there's already a tool that can modify .
> >>
> >> It's only the "right way to go" if the community does not have reason
> not to do so.  That's really why I asked.  And that's the key question.
>

> >Anyone?
>

That's really the question I'm after: I'd rather NOT go down a path that's
known to be "problematic"!

Cheers.

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The LIVE DATA Company
*Find out more 
*wandisco.com *



 

*


THIS MESSAGE 
AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If 
this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: Removal of spark buildbot

[Doug Robinson]

Stefan, et. al.:

Strangely, searching for Solaris brought this to my attention (I didn't see
it before today).  Do you still need a Spark/Solaris box for testing?  I'm
not sure what we've got but I can try to see if we've replaced the dead
machine (yet) and whether you could use it?

Cheers.

Doug

On Wed, Jan 10, 2018 at 9:27 AM, Stefan Sperling  wrote:

> On Wed, Jan 10, 2018 at 09:23:49PM +1100, Gavin McDonald wrote:
> > > On 10 Jan 2018, at 9:18 pm, Stefan Sperling  wrote:
> > > I am currently setting up a new OpenBSD/sparc64 buildbot.
> > > I'll send more info once I've got it completely set up.
> >
> > Good news!
> >
> > In the meantime this sparc box and config have been removed.
> >
> > Will be glad to assist in getting the new one attached to our master.
> >
> > Thanks
> >
> > Gav…
>
> Hey Gavin,
>
> I am almost ready to connect my new bot.
> Just now doing another test build after tweaking my scripts at
> https://svn.apache.org/repos/asf/subversion/trunk/tools/
> buildbot/slaves/bb-openbsd
>
> I've lost the buildslave password. Can you tell me what I could do to
> view the password or to get it changed?
>
> I suppose the final step would be to re-enable bb-openbsd in our slave
> config?
> Since I can access that file in SVN so I could do that myself, I guess.
>
> Thanks,
> Stefan
>



-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The LIVE DATA Company
*Find out more 
*wandisco.com *



 

*


THIS MESSAGE 
AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If 
this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: SVN working copy split DB vs. working area

[Doug Robinson]

Philip:

Thank you for responding!

On Wed, Apr 11, 2018 at 4:08 PM, Philip Martin <phi...@codematters.co.uk>
wrote:

> Doug Robinson <doug.robin...@wandisco.com> writes:
>
> > The general setup is that they want to have a working copy on a
> > Distributed File System (DFS, e.g. Lustre) and the DFS either is
> > very slow (when mounted with sufficient support for SQLite) or just
> > does not work due to a lack of support for SQLite - likely locking).
>
> If SQLite locking works at all then the client-side config option
>
>--config-option config:working-copy:exclusive-locking=true
>
> may help.  It makes SQLite take less granular locks which improves
> performance, particularly on network filesystems, by reducing the SQLite
> overhead.  The performance gain can be substantial.
>
>   https://sqlite.org/pragma.html#pragma_locking_mode
>
> Exclusive locking also reduces the concurrency of Subversion operations:
> generally only one Subversion operation can run on a working copy at any
> one time, but lots of users never notice this.
>

Neat!  I'll mention this to the folks where DFS was just too slow.
Won't help the folks where their DFS just didn't work at all.


> > Has this subject come up before?  Is there a way to link a ".svn"
> > area to the rest of the working copy?  In other words, keeping the
> > housekeeping area separate/split from the rest of the working copy?
>
> It's a bit tricky.  The .svn area also includes .svn/tmp/ where most
> files are created before being moved to their final destination.  Some
> of the moves are to .svn/pristine/, within the .svn/ area, while other
> moves are into the working copy itself.  Moves don't generally cross
> filesystem boundaries.
>
> If we start splitting a working copy across multiple filesystems then we
> may need per-filesystem temporary directories:
>
>  /local/wc/.svn/
>  /local/wc/.svn/pristine/
>  /local/wc/.svn/tmp-local/
>  /local/wc/.svn/tmp-remote -> /remote/wc/.svn-tmp/
>
>  /remote/wc/
>  /remote/wc/.svn -> /local/wc/.svn/
>  /remote/wc/.svn-tmp-remote/
>
> and then we would need to make every use of the temporary directory use
> the correct one based on the intended destination of the file.
>

Assuming that atomicity on rename() is required, good point.

I hope all is going well with you.

Cheers.

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* <http://wandisco.com>*

**The LIVE DATA Company
*Find out more 
*wandisco.com <http://wandisco.com/>*



 
<https://www.wandisco.com/welcome-live-data-world-video>
*


THIS MESSAGE 
AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If 
this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: SVN working copy split DB vs. working area

[Doug Robinson]

Brane:

Good to hear from you!

On Wed, Apr 11, 2018 at 2:57 PM, Branko Čibej <br...@apache.org> wrote:

> On 11.04.2018 20:27, Doug Robinson wrote:
> > I've now seen a request for this twice in as many days.  Once from
> > a customer and once from someone posting to a Subversion forum
> > here:
> >
> > https://www.svnforum.org/forum/opensource-subversion-
> forums/apache-subversion-1-8-support/80218-subversion-
> checkout-on-distrubuted-filesytem
> >
> > The general setup is that they want to have a working copy on a
> > Distributed File System (DFS, e.g. Lustre) and the DFS either is
> > very slow (when mounted with sufficient support for SQLite) or just
> > does not work due to a lack of support for SQLite - likely locking).
> >
> > One set of folks want to accelerate by doing parallel checkouts the
> > way they could do using SVN 1.6 (prior to the consolidated ".svn"
> > tree).  But SQLite locking will prevent that (unless I'm missing
> > something).
> >
> > Another set of folks is ok for having the ".svn" area on a local
> > file system (e.g. ext4) but want the rest of the working copy out
> > there on the DFS.
> >
> > NOTE: both sets of folks are experienced SVN users.  Both know and
> > have rejected "exporting" - they want a working copy.
> >
> > Has this subject come up before?  Is there a way to link a ".svn"
> > area to the rest of the working copy?  In other words, keeping the
> > housekeeping area separate/split from the rest of the working copy?
>
> One of the original design goals for the SQLite-based working copy was
> that the database could be hoisted out of the working copy proper and
> that multiple working copies could share the same database. However,
> there has been no real work done toward that goal.
>
> It's possible to move the .svn/wc.db database elsewhere and replace it
> with a symbolic link to the original database. However, I'm not too sure
> how that will help, since the SQLite journal files will still be created
> in .svn/. Also, this would have to be done manually for every external
> directory (which currently has its own, separate .svn/ directory).
>

Simple enough experiment for them to try - I'll suggest it to them.

Especially when I combine it with an observation made by Julian that a
WC with the .svn and zero other files can be tar'd up and copied and
then re-populated.  If the payback is large enough then perhaps...

Cheers!

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* <http://wandisco.com>*

**The LIVE DATA Company
*Find out more 
*wandisco.com <http://wandisco.com/>*



 
<https://www.wandisco.com/welcome-live-data-world-video>
*


THIS MESSAGE 
AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If 
this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

SVN working copy split DB vs. working area

[Doug Robinson]

Folks:

I've now seen a request for this twice in as many days.  Once from
a customer and once from someone posting to a Subversion forum
here:

https://www.svnforum.org/forum/opensource-subversion-forums/apache-subversion-1-8-support/80218-subversion-checkout-on-distrubuted-filesytem

The general setup is that they want to have a working copy on a
Distributed File System (DFS, e.g. Lustre) and the DFS either is
very slow (when mounted with sufficient support for SQLite) or just
does not work due to a lack of support for SQLite - likely locking).

One set of folks want to accelerate by doing parallel checkouts the
way they could do using SVN 1.6 (prior to the consolidated ".svn"
tree).  But SQLite locking will prevent that (unless I'm missing
something).

Another set of folks is ok for having the ".svn" area on a local
file system (e.g. ext4) but want the rest of the working copy out
there on the DFS.

NOTE: both sets of folks are experienced SVN users.  Both know and
have rejected "exporting" - they want a working copy.

Has this subject come up before?  Is there a way to link a ".svn"
area to the rest of the working copy?  In other words, keeping the
housekeeping area separate/split from the rest of the working copy?

Thoughts?

Cheers.

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The LIVE DATA Company
*Find out more 
*wandisco.com *



 

*


THIS MESSAGE 
AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If 
this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: Subversion 1.10 RC1?

[Doug Robinson]

On Wed, Dec 6, 2017 at 7:09 PM, Daniel Shahaf 
wrote:

> Evgeny Kotkov wrote on Wed, Dec 06, 2017 at 00:12:55 +0300:
> > 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.
>
> Isn't there some escaping syntax, «svn log --search "M^*"» or something
> along
> these lines?
>

Apparently not:
https://stackoverflow.com/questions/47512829/is-it-possible-to-quote-escape-command-line-arguments-on-windows-while-linking-s

-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


World Leader in Active Data Replication™
*Find out more wandisco.com *

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE 
PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: Subversion AuthZ Wildcards

[Doug Robinson]

Stefan:

[sorry for the delay]

On Thu, May 18, 2017 at 9:38 AM, Stefan Fuhrmann <stef...@apache.org> wrote:

> On 27.02.2017 17:05, Julian Foad wrote:
>
>> Doug Robinson wrote:
>>
>>> Folks:
>>>
>>> "Julian said Stefan said this could be useful."  :-)
>>>
>>> I really hope it is.  Best wishes and thank you all!
>>>
>>
>> Thank you very much, Doug!
>>
>
> Same here. Sadly, my talk wasn't admitted at ApacheCON
> (it seems very few were outside big data).
>

That's "unfortunate" - sorry.


> Doug, are we allowed to put that presentation into our Wiki?
> IMO, it covers the usual dos and donts very well.
>

Yes, I did the work necessary to enable you to put the work up on your
wiki.  Credit to WANdisco/me.


> Also, is there some experience with strategies / suggestions
> like "put generic access first" and "put generic restrictions last"?


I've been meaning to write up some guidance.  I'll try to find some time.


> Svn devs: the attachment is a presentation Doug had prepared for
>> explaining the Authz wilcard rules as implemented for WANdisco a couple of
>> years ago, which they have been using with svn 1.9.x, and which is a little
>> different from the 'authzperf' version that we have recently merged to
>> trunk for 1.10.
>>
> The behavior in /trunk is almost identical to WD-code.
> There are two main differences:
>
> * /trunk now uses are specialized parser for authz.
>   Some accidental features of the previously used
>   config parser are no longer available. In particular,
>   sections may no longer be repeated and there is
>   no support for value expansion.
>

Just checking: can there be 2 sections of:

 [/]
 * = r

 [/]
 accountA = rw
 accountB = rw

Or is this now going to fail?

Can you say more about the "value expansion"?


> * An edge-case or two has been fixed concerning
>   recursive access rights. Those are checked by new
>   authz tests introduced in r1774890 and r1764337.
>   Some of that may already be in the WD code.


We've gotten at least one fix - definitely!


> I suggested to Stefan2 that the one thing we're missing is clear
>> documentation of the new work, and to Doug that we might benefit from using
>> the content of his presentation as a starting point to create our own docs
>> for the new work.
>>
> Yes, a simple paragraph in the release notes will
> not do. Not sure though, when exactly I will find
> time and energy to write this.
>
> Doug is very keen that WD's version and our "official" version of wildcard
>> support should align in the long term, and in support of this, kindly
>> agreed to contribute this for us to use as we see fit.
>>
> Any feedback is greatly appreciated.
>

Again, sorry for the delay in replying.  I don't get time to peruse the Dev
list all the time.
Ping me directly if you need a reply (doug.robin...@wandisco.com)!

Cheers.

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


World Leader in Active Data Replication™
*Find out more wandisco.com <http://wandisco.com/>*

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE 
PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: wildcard authz docs question

[Doug Robinson]

Johan, et. al.:

Solid discussion - thank you.  As I said, I'll keep a watch as things
progress...

Cheers.

Doug

On Wed, May 10, 2017 at 5:37 PM, Johan Corveleyn <jcor...@gmail.com> wrote:

> On Wed, May 10, 2017 at 5:40 PM, Doug Robinson
> <doug.robin...@wandisco.com> wrote:
> >
> > Johan:
> >
> > Sorry for my sporadic replies... bin a bit hectic here.
> >
> > Reply buried deep below.
> >
> > On Fri, May 5, 2017 at 5:09 AM, Johan Corveleyn <jcor...@gmail.com>
> wrote:
> >>
> >> On Fri, May 5, 2017 at 12:49 AM, Doug Robinson
> >> <doug.robin...@wandisco.com> wrote:
> >> >
> >> > Johan:
> >> >
> >> > (sorry for the empty message - dwim failed)
> >> >
> >> > On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jcor...@gmail.com>
> wrote:
> >> >>
> >> >> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <
> d...@daniel.shahaf.name> wrote:
> >> >> > Doug Robinson wrote on Wed, May 03, 2017 at 15:54:50 -0400:
> >> >> ...
> >> >> >> Not seeing it - at least not yet.  In Perl the RE needed to handle
> >> >> >> this would be one of the duals, e.g. "/trunk/iota(|/.*)" - the
> >> >> >> either/or with nothing on the left and "/.*" on the right.  It
> really
> >> >> >> is a dual case.  I know of no better syntax.  Since we're working
> on
> >> >> >> this as a wildcard I don't see an alternative.
> >> >> >
> >> >> > Off the top of my head, we could have [/trunk/iota/***] and
> >> >> > [/trunk/iota/**] with different meanings (the former applies to
> >> >> > a /trunk/iota file, the latter doesn't).  Does anyone else
> (besides Doug
> >> >> > and I) have ideas here?
> >> >>
> >> >> Hmm, /*** doesn't look like something I'd remember easily, if I
> wanted
> >> >> to use that feature as an svn admin.
> >> >>
> >> >> I have only followed this discussion from a distance. If I understand
> >> >> correctly the remaining point is whether or not /iota/** would match
> >> >> with the file /iota or not. Speaking purely from my own intuition, I
> >> >> would say "no". I feel this pattern is intended to apply to the
> >> >> _subtree_ below iota, including iota itself (which is thus implied to
> >> >> be a directory, because we're talking about subtrees). In practice I
> >> >> think the admin configuring this rule will know whether iota is ever
> >> >> intended to be a file or a directory. A rule like that to me always
> >> >> implies that "the guy who configured it" expects iota to be a
> >> >> directory (why else would he put a "subtree rule" for it).
> >> >>
> >> >> TBH, I also don't really see the use case of "I want this rule to
> >> >> apply to the _namespace_ iota, i.e. to the file iota (if it's a file)
> >> >> and to directory iota and its subtree (if it's a directory)". In
> >> >> context, you always know whether it's meant to be a file or a
> >> >> directory.
> >> >
> >> >
> >> > The use case is exactly that some administrator wants to reserve
> >> > the namespace.  They do not want some sly person to create a file
> >> > where they will, at some point in the future, create a directory.  It
> will
> >> > be sad that we can't have a simple way to make this reservation, but,
> >> > as I noted above, short of the current "[:glob:/iota/**]" doing the
> job it
> >> > will take 2 stanzas.
> >> >
> >> >>
> >> >> Maybe we should just follow what most other implementations do?
> >> >> I've done a quick check in Atlassian FishEye / Crucible (searching
> for
> >> >> files). There /iota/** does not match file /iota (but it does match
> >> >> directory /iota).
> >> >
> >> >
> >> > The FishEye reference I found does not have a "**" operator - just a
> "*"
> >> > operator (https://confluence.atlassian.com/jiracoreserver073/search-
> syntax-for-text-fields-861257223.html).
> >> >
> >> > For all cases where a tool has a "*" operator this is semantically
> going
> >> > to "not match" this use case sinc

Re: wildcard authz docs question

[Doug Robinson]

Brane:

Right!  And this is likely why the AuthZ implementation today for
"/**" governs both the "file" and "directory" since it can't know.

Given this, I'd like to keep the current behavior (that's in the branch
for 1.8 and 1.9) as it "works".

Thank you.

Doug

On Fri, May 5, 2017 at 5:22 AM, Branko Čibej <br...@apache.org> wrote:

> On 05.05.2017 11:09, Johan Corveleyn wrote:
> > On Fri, May 5, 2017 at 12:49 AM, Doug Robinson
> > <doug.robin...@wandisco.com> wrote:
> >> Johan:
> >>
> >> (sorry for the empty message - dwim failed)
> >>
> >> On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jcor...@gmail.com>
> wrote:
> >>> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d...@daniel.shahaf.name>
> wrote:
> >>>> Doug Robinson wrote on Wed, May 03, 2017 at 15:54:50 -0400:
> >>> ...
> >>>>> Not seeing it - at least not yet.  In Perl the RE needed to handle
> >>>>> this would be one of the duals, e.g. "/trunk/iota(|/.*)" - the
> >>>>> either/or with nothing on the left and "/.*" on the right.  It really
> >>>>> is a dual case.  I know of no better syntax.  Since we're working on
> >>>>> this as a wildcard I don't see an alternative.
> >>>> Off the top of my head, we could have [/trunk/iota/***] and
> >>>> [/trunk/iota/**] with different meanings (the former applies to
> >>>> a /trunk/iota file, the latter doesn't).  Does anyone else (besides
> Doug
> >>>> and I) have ideas here?
> >>> Hmm, /*** doesn't look like something I'd remember easily, if I wanted
> >>> to use that feature as an svn admin.
> >>>
> >>> I have only followed this discussion from a distance. If I understand
> >>> correctly the remaining point is whether or not /iota/** would match
> >>> with the file /iota or not. Speaking purely from my own intuition, I
> >>> would say "no". I feel this pattern is intended to apply to the
> >>> _subtree_ below iota, including iota itself (which is thus implied to
> >>> be a directory, because we're talking about subtrees). In practice I
> >>> think the admin configuring this rule will know whether iota is ever
> >>> intended to be a file or a directory. A rule like that to me always
> >>> implies that "the guy who configured it" expects iota to be a
> >>> directory (why else would he put a "subtree rule" for it).
> >>>
> >>> TBH, I also don't really see the use case of "I want this rule to
> >>> apply to the _namespace_ iota, i.e. to the file iota (if it's a file)
> >>> and to directory iota and its subtree (if it's a directory)". In
> >>> context, you always know whether it's meant to be a file or a
> >>> directory.
> >>
> >> The use case is exactly that some administrator wants to reserve
> >> the namespace.  They do not want some sly person to create a file
> >> where they will, at some point in the future, create a directory.  It
> will
> >> be sad that we can't have a simple way to make this reservation, but,
> >> as I noted above, short of the current "[:glob:/iota/**]" doing the job
> it
> >> will take 2 stanzas.
> >>
> >>> Maybe we should just follow what most other implementations do?
> >>> I've done a quick check in Atlassian FishEye / Crucible (searching for
> >>> files). There /iota/** does not match file /iota (but it does match
> >>> directory /iota).
> >>
> >> The FishEye reference I found does not have a "**" operator - just a "*"
> >> operator (https://confluence.atlassian.com/jiracoreserver073/search-
> syntax-for-text-fields-861257223.html).
> >>
> >> For all cases where a tool has a "*" operator this is semantically going
> >> to "not match" this use case since the "*" operator that has been
> >> implemented in SVN (at least so far) does not span past a single
> >> directory entry.
> > Ah. No, I'm referring to this syntax in FishEye:
> > https://confluence.atlassian.com/fisheye/pattern-matching-
> guide-298976797.html
> >
> > Unfortunately the document does not specify the cases we're interested
> > in here. But I've tested them on our own FishEye instance :-). In this
> > case "/dir/**" does return /dir, but "/file/**" does not return /file.
> > But o

Re: wildcard authz docs question

[Doug Robinson]

Johan:

Sorry for my sporadic replies... bin a bit hectic here.

Reply buried deep below.

On Fri, May 5, 2017 at 5:09 AM, Johan Corveleyn <jcor...@gmail.com> wrote:

> On Fri, May 5, 2017 at 12:49 AM, Doug Robinson
> <doug.robin...@wandisco.com> wrote:
> >
> > Johan:
> >
> > (sorry for the empty message - dwim failed)
> >
> > On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jcor...@gmail.com>
> wrote:
> >>
> >> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d...@daniel.shahaf.name>
> wrote:
> >> > Doug Robinson wrote on Wed, May 03, 2017 at 15:54:50 -0400:
> >> ...
> >> >> Not seeing it - at least not yet.  In Perl the RE needed to handle
> >> >> this would be one of the duals, e.g. "/trunk/iota(|/.*)" - the
> >> >> either/or with nothing on the left and "/.*" on the right.  It really
> >> >> is a dual case.  I know of no better syntax.  Since we're working on
> >> >> this as a wildcard I don't see an alternative.
> >> >
> >> > Off the top of my head, we could have [/trunk/iota/***] and
> >> > [/trunk/iota/**] with different meanings (the former applies to
> >> > a /trunk/iota file, the latter doesn't).  Does anyone else (besides
> Doug
> >> > and I) have ideas here?
> >>
> >> Hmm, /*** doesn't look like something I'd remember easily, if I wanted
> >> to use that feature as an svn admin.
> >>
> >> I have only followed this discussion from a distance. If I understand
> >> correctly the remaining point is whether or not /iota/** would match
> >> with the file /iota or not. Speaking purely from my own intuition, I
> >> would say "no". I feel this pattern is intended to apply to the
> >> _subtree_ below iota, including iota itself (which is thus implied to
> >> be a directory, because we're talking about subtrees). In practice I
> >> think the admin configuring this rule will know whether iota is ever
> >> intended to be a file or a directory. A rule like that to me always
> >> implies that "the guy who configured it" expects iota to be a
> >> directory (why else would he put a "subtree rule" for it).
> >>
> >> TBH, I also don't really see the use case of "I want this rule to
> >> apply to the _namespace_ iota, i.e. to the file iota (if it's a file)
> >> and to directory iota and its subtree (if it's a directory)". In
> >> context, you always know whether it's meant to be a file or a
> >> directory.
> >
> >
> > The use case is exactly that some administrator wants to reserve
> > the namespace.  They do not want some sly person to create a file
> > where they will, at some point in the future, create a directory.  It
> will
> > be sad that we can't have a simple way to make this reservation, but,
> > as I noted above, short of the current "[:glob:/iota/**]" doing the job
> it
> > will take 2 stanzas.
> >
> >>
> >> Maybe we should just follow what most other implementations do?
> >> I've done a quick check in Atlassian FishEye / Crucible (searching for
> >> files). There /iota/** does not match file /iota (but it does match
> >> directory /iota).
> >
> >
> > The FishEye reference I found does not have a "**" operator - just a "*"
> > operator (https://confluence.atlassian.com/jiracoreserver073/search-
> syntax-for-text-fields-861257223.html).
> >
> > For all cases where a tool has a "*" operator this is semantically going
> > to "not match" this use case since the "*" operator that has been
> > implemented in SVN (at least so far) does not span past a single
> > directory entry.
>
> Ah. No, I'm referring to this syntax in FishEye:
> https://confluence.atlassian.com/fisheye/pattern-matching-
> guide-298976797.html
>
> Unfortunately the document does not specify the cases we're interested
> in here. But I've tested them on our own FishEye instance :-). In this
> case "/dir/**" does return /dir, but "/file/**" does not return /file.
> But okay, it's just one example.
>
> In the FishEye doc they say they're doing their pattern mathing "same
> as the pattern matching in Apache Ant". So I've checked ant as well.
> On this page:
>
> https://ant.apache.org/manual/dirtasks.html#patterns
>
> at the bottom of the table they say:
> **/test/** - Matches all files that have a test element in their
> path, including test as a filenam

Re: wildcard authz docs question

[Doug Robinson]

Johan:

(sorry for the empty message - dwim failed)

On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jcor...@gmail.com> wrote:

> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d...@daniel.shahaf.name>
> wrote:
> > Doug Robinson wrote on Wed, May 03, 2017 at 15:54:50 -0400:
> ...
> >> Not seeing it - at least not yet.  In Perl the RE needed to handle
> >> this would be one of the duals, e.g. "/trunk/iota(|/.*)" - the
> >> either/or with nothing on the left and "/.*" on the right.  It really
> >> is a dual case.  I know of no better syntax.  Since we're working on
> >> this as a wildcard I don't see an alternative.
> >
> > Off the top of my head, we could have [/trunk/iota/***] and
> > [/trunk/iota/**] with different meanings (the former applies to
> > a /trunk/iota file, the latter doesn't).  Does anyone else (besides Doug
> > and I) have ideas here?
>
> Hmm, /*** doesn't look like something I'd remember easily, if I wanted
> to use that feature as an svn admin.
>
> I have only followed this discussion from a distance. If I understand
> correctly the remaining point is whether or not /iota/** would match
> with the file /iota or not. Speaking purely from my own intuition, I
> would say "no". I feel this pattern is intended to apply to the
> _subtree_ below iota, including iota itself (which is thus implied to
> be a directory, because we're talking about subtrees). In practice I
> think the admin configuring this rule will know whether iota is ever
> intended to be a file or a directory. A rule like that to me always
> implies that "the guy who configured it" expects iota to be a
> directory (why else would he put a "subtree rule" for it).
>
> TBH, I also don't really see the use case of "I want this rule to
> apply to the _namespace_ iota, i.e. to the file iota (if it's a file)
> and to directory iota and its subtree (if it's a directory)". In
> context, you always know whether it's meant to be a file or a
> directory.
>

The use case is exactly that some administrator wants to reserve
the namespace.  They do not want some sly person to create a file
where they will, at some point in the future, create a directory.  It will
be sad that we can't have a simple way to make this reservation, but,
as I noted above, short of the current "[:glob:/iota/**]" doing the job it
will take 2 stanzas.


> Maybe we should just follow what most other implementations do?
> I've done a quick check in Atlassian FishEye / Crucible (searching for
> files). There /iota/** does not match file /iota (but it does match
> directory /iota).
>

The FishEye reference I found does not have a "**" operator - just a "*"
operator (
https://confluence.atlassian.com/jiracoreserver073/search-syntax-for-text-fields-861257223.html
).

For all cases where a tool has a "*" operator this is semantically going
to "not match" this use case since the "*" operator that has been
implemented in SVN (at least so far) does not span past a single
directory entry.

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


World Leader in Active Data Replication™
*Find out more wandisco.com <http://wandisco.com/>*

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE 
PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: wildcard authz docs question

[Doug Robinson]

Johan:

On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jcor...@gmail.com> wrote:

> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d...@daniel.shahaf.name>
> wrote:
> > Doug Robinson wrote on Wed, May 03, 2017 at 15:54:50 -0400:
> ...
> >> Not seeing it - at least not yet.  In Perl the RE needed to handle
> >> this would be one of the duals, e.g. "/trunk/iota(|/.*)" - the
> >> either/or with nothing on the left and "/.*" on the right.  It really
> >> is a dual case.  I know of no better syntax.  Since we're working on
> >> this as a wildcard I don't see an alternative.
> >
> > Off the top of my head, we could have [/trunk/iota/***] and
> > [/trunk/iota/**] with different meanings (the former applies to
> > a /trunk/iota file, the latter doesn't).  Does anyone else (besides Doug
> > and I) have ideas here?
>
> Hmm, /*** doesn't look like something I'd remember easily, if I wanted
> to use that feature as an svn admin.
>
> I have only followed this discussion from a distance. If I understand
> correctly the remaining point is whether or not /iota/** would match
> with the file /iota or not. Speaking purely from my own intuition, I
> would say "no". I feel this pattern is intended to apply to the
> _subtree_ below iota, including iota itself (which is thus implied to
> be a directory, because we're talking about subtrees). In practice I
> think the admin configuring this rule will know whether iota is ever
> intended to be a file or a directory. A rule like that to me always
> implies that "the guy who configured it" expects iota to be a
> directory (why else would he put a "subtree rule" for it).
>
> TBH, I also don't really see the use case of "I want this rule to
> apply to the _namespace_ iota, i.e. to the file iota (if it's a file)
> and to directory iota and its subtree (if it's a directory)". In
> context, you always know whether it's meant to be a file or a
> directory.
>


>
> Maybe we should just follow what most other implementations do?
> I've done a quick check in Atlassian FishEye / Crucible (searching for
> files). There /iota/** does not match file /iota (but it does match
> directory /iota).
>
> --
> Johan
>



-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


World Leader in Active Data Replication™
*Find out more wandisco.com <http://wandisco.com/>*

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE 
PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: wildcard authz docs question

[Doug Robinson]

Daniel:

On Mon, May 1, 2017 at 2:05 PM, Daniel Shahaf <d...@daniel.shahaf.name>
wrote:

> Doug Robinson wrote on Mon, May 01, 2017 at 14:20:16 +:
> > On Mon, Apr 17, 2017 at 21:13 Daniel Shahaf <d...@daniel.shahaf.name>
> wrote:
> > > Stefan Fuhrmann wrote on Mon, Apr 17, 2017 at 22:22:33 +0200:
> > > > On 15.03.2017 10:55, Daniel Shahaf wrote:
> > > > >>From the 1.10 draft release notes:
> > > > >
> > > > >>All wildcards apply to full path segments only, i.e. * never
> matches
> > > > >>/, except for the case where /**/ matches zero or more path
> segments.
> > > > >>For example, /*/**/* will match any path which contains at least
> > > > >>2 segments and is equivalent to /**/*/* as well as /*/*/**.
> > > > >Are «/*/**/*» «/**/*/*» «/*/*/**» really equivalent?  I would have
> > > > >expected the first two to match any node except / and /'s immediate
> > > > >children, but I wouldn't expect the third form to match /trunk/iota
> > > > >where iota is a file, since the pattern has a trailing slash after
> the
> > > > >non-optional second component.
> > > > How do you know that /trunk/iota is a file?
> > >
> > > I was reviewing the API docs as a black box, i.e., from a user
> > > (repository admin) perspective, not from an implementation perspective.
> > >
> > >  From that perspective, I would say that having a [/trunk/iota/**]
> > > stanza to apply to a /trunk/iota file violates the principle of least
> > > surprise.
> >
> >
> > From a very critical point of view I agree.
> >
> > However, the point of wildcards is to easily reserve a complete
> namespace.
>
> Sure, that's a valid use-case.
>
> I was envisioning that, if a [/trunk/iota/**] stanza were present, then
> an authz query for a /trunk/iota file would return either "No access" or
> a parse error.  This would reserve the namespace, wouldn't it?  Referring
> to your next paragraph, this logic would neither leak the contents of
> the file nor require multiple stanzas.
>

For an AuthZ check the answer is either Yes or No, not "parser error",
right?

And it really can't be a "parser error" (invalidating the AuthZ file
entirely) since
in some other revision that "file" could be a "directory".  So either the
stanza
gets skipped as "not applicable" (and therefore not reserving the namespace)
or it gets entered as if the file were a directory and we're back to the
behavior
that I am expecting.


> > If we do not apply that stanza apply to the file means requiring 2
> stanzas
> > to cover the space entirely. That's both expensive and brittle (2X
> stanzas
> > and requires remembering to treat them in pairs - both when adding and
> when
> > removing).
> >
> > And I think the "surprise" will be very short-lived if at all.
> >
> > From a cost/benefit standpoint I think it is extremely positive.
>
> Well, if a common task requires two stanzas, then _of course_ we'll find
> an easier way for users to spell it.  For example, we could invent some
> new "reserve prefix" stanza syntax, or pass to
> svn_repos_authz_check_access()
> the svn_node_kind_t of the path it checks access to, or any number of
> other solutions.
>
> In short: there might well be a design that meets both of our criteria:
> principle of least surprise _and_ namespace reservation.
>

Not seeing it - at least not yet.  In Perl the RE needed to handle this
would
be one of the duals, e.g. "/trunk/iota(|/.*)" - the either/or with nothing
on the left
and "/.*" on the right.  It really is a dual case.  I know of no better
syntax.  Since
we're working on this as a wildcard I don't see an alternative.

As I said, I think the surprise, if any (none if we document it well) will
be
very short-lived.

Cheers.

Doug

-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


World Leader in Active Data Replication™
*Find out more wandisco.com <http://wandisco.com/>*

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE 
PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: wildcard authz docs question

[Doug Robinson]

Daniel:

On Mon, Apr 17, 2017 at 21:13 Daniel Shahaf  wrote:

> Stefan Fuhrmann wrote on Mon, Apr 17, 2017 at 22:22:33 +0200:
> > On 15.03.2017 10:55, Daniel Shahaf wrote:
> > >>From the 1.10 draft release notes:
> > >
> > >>All wildcards apply to full path segments only, i.e. * never matches
> > >>/, except for the case where /**/ matches zero or more path segments.
> > >>For example, /*/**/* will match any path which contains at least
> > >>2 segments and is equivalent to /**/*/* as well as /*/*/**.
> > >Are «/*/**/*» «/**/*/*» «/*/*/**» really equivalent?  I would have
> > >expected the first two to match any node except / and /'s immediate
> > >children, but I wouldn't expect the third form to match /trunk/iota
> > >where iota is a file, since the pattern has a trailing slash after the
> > >non-optional second component.
> > How do you know that /trunk/iota is a file?
>
> I was reviewing the API docs as a black box, i.e., from a user
> (repository admin) perspective, not from an implementation perspective.
>
>  From that perspective, I would say that having a [/trunk/iota/**]
> stanza to apply to a /trunk/iota file violates the principle of least
> surprise.


>From a very critical point of view I agree.

However, the point of wildcards is to easily reserve a complete namespace.
If we do not apply that stanza apply to the file means requiring 2 stanzas
to cover the space entirely. That's both expensive and brittle (2X stanzas
and requires remembering to treat them in pairs - both when adding and when
removing).

And I think the "surprise" will be very short-lived if at all.

>From a cost/benefit standpoint I think it is extremely positive.

Doug



>
> > The problem is that the authz callback does not provide
> > enough context information to make that distinction.
> > We might extend the interface in the future - allowing
> > to restrict rules to exclusively match files or dirs only.
>
> Are you referring to svn_repos_authz_check_access()?  [which doesn't
> have an svn_fs_t handle or the information to open one]
>
> > But making that backward compatible adds quite a bit
> > of complexity that I don't want to pile on there in 1.10.
>
> I don't understand this sentence at all.  Why do we need to be backwards
> compatible (this is a new feature), and why is being back compat in
> this case necessarily expensive?
>
> Moreover, implementation considerations aside, there is still the
> question of what the documentation should say about this situation.
>
> Cheers,
>
> Daniel
>
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


World Leader in Active Data Replication™
*Find out more wandisco.com *

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE 
PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: wildcard authz docs question

[Doug Robinson]

Daniel:

On Tue, Mar 28, 2017 at 5:43 PM, Daniel Shahaf <d...@daniel.shahaf.name>
wrote:

> Doug Robinson wrote on Tue, Mar 28, 2017 at 09:05:53 -0400:
> > That said, in discussions I've had I think about the SVN regex "**"
> > differently than the zsh construct.  The way that I interpret "/**" is
> > "everything below and including slash" - so "**" is the moral equivalent
> of
> > Perl's ".*" wildcard.  It need not be followed by any terminal pattern to
> > match anything - since it matches them all.  If it was followed by
> > something then that something would be required.
> >
>
> Note that your terminology is backwards: "**" is a wildcard and ".*" is
> a regex.
>

Agreed - sort of.

I've been using them interchangeably: the  longer you use them the more that
you come to consider them the same.  I know that the shell calls them
wildcards
and that awk/sed/perl/et. al. call them regular expressions.  That said,
they're
doing the same thing in different contexts.

> So let me break the 3 patterns down:
> >
> > /*/*/**   This requires 2 directories. It will match all directories 2
> > levels down - and then everything in all of the rest of those trees
> however
> > deep.  It should not, however, match a file or symlink in a directory,
> e.g.
> > "/dirA/fileB".  Whereas it will match "/dirA/dirB" along with
> > "/dirA/dirB/fileC", etc.
>
> That's an interesting one.  Neither vim nor zsh matches dirA/dirB here —
> they only match dirents _under_ it — but it's certainly defensible to
> match it, exactly as you say.
>
> To clarify, if foo/bar is a symlink then it is not a directory, no
> matter what its target is and what else exists in the repository.  (In
> particular, if its target is "baz" and foo/baz/ exists, foo/bar is still
> not a directory.)
>

Agreed: symlinks are their own form of fun given their semantics on
various system calls.  But in the end they are just another type of
directory
entry and for the purposes of matching act more like a file than a
directory.
And I very much agree that it does not matter what they are pointing at.


> So, for example, [foo/bar/**] would apply to foo/bar/, iff it exists and
> is a directory.  That sounds good.
>
> > /*/**/*   This requires 1 directory and then something else.  It will
> match
> > "/dirA/fileB" or "/dirA/symlinkX" since "/**" can simply go to nothing.
> Or
> > perhaps a different way to look at it is that "/**" can match "/" which,
> in
> > its simplest will mean "/*/**/*" becomes "/*//*" and given that multiple
> > '/' always collapse to a single '/' in "path arithmetic" becomes "/*/*"
> for
> > its shortest match.
>
> Agreed.
>
> > /**/*/*   This requires 1 directory and then something else.  Pretty much
> > the same as the prior example and for the same reasons.
>
> Agreed.
>

Excellent!

Cheers!

Doug
-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com <http://www.wandisco.com/>*

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges <http://www.wandisco.com/hadoop/wd-fusion>

Listed on the London Stock Exchange: WAND 
<http://www.bloomberg.com/quote/WAND:LN>

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: wildcard authz docs question

[Doug Robinson]

Daniel:

Sorry for the delay - I missed the post.

And, I'm going to recant my original conclusion - my apologies for not
treating this with sufficient vigor the 1st time around.

Wow - it's been a long time since I played with zsh.  Yep, I see the
reference to "‘***/*’ is equivalent to ‘*(*/)#*’".  So, playing with this,
the zsh man page is a bit loose with the term "file" where they are really
talking about a "directory entry":

# ls -dl **/foo
drwxr-xr-x 2 root root 4096 Mar 28 14:32 a/b/c/foo
# ls -dl **/bar
-rw-r--r-- 1 root root 0 Mar 28 14:32 a/b/c/bar
# ls -dl **/baz
lrwxrwxrwx 1 root root 10 Mar 28 14:36 a/b/c/baz -> a/b/c/biff


That said, in discussions I've had I think about the SVN regex "**"
differently than the zsh construct.  The way that I interpret "/**" is
"everything below and including slash" - so "**" is the moral equivalent of
Perl's ".*" wildcard.  It need not be followed by any terminal pattern to
match anything - since it matches them all.  If it was followed by
something then that something would be required.

So let me break the 3 patterns down:

/*/*/**   This requires 2 directories. It will match all directories 2
levels down - and then everything in all of the rest of those trees however
deep.  It should not, however, match a file or symlink in a directory, e.g.
"/dirA/fileB".  Whereas it will match "/dirA/dirB" along with
"/dirA/dirB/fileC", etc.

/*/**/*   This requires 1 directory and then something else.  It will match
"/dirA/fileB" or "/dirA/symlinkX" since "/**" can simply go to nothing.  Or
perhaps a different way to look at it is that "/**" can match "/" which, in
its simplest will mean "/*/**/*" becomes "/*//*" and given that multiple
'/' always collapse to a single '/' in "path arithmetic" becomes "/*/*" for
its shortest match.

/**/*/*   This requires 1 directory and then something else.  Pretty much
the same as the prior example and for the same reasons.


Is this more along the lines of what you were thinking?

Thank you.

Doug


On Tue, Mar 21, 2017 at 12:36 PM, Daniel Shahaf <d...@daniel.shahaf.name>
wrote:

> Doug Robinson wrote on Tue, Mar 21, 2017 at 11:40:50 -0400:
> > Daniel:
> >
> > The shell's all treat ** as * and require that it match something.  So
> > "mkdir -p foo/bar/baz" would match.
> >
> > No command shell that I know of (sh,bash,zsh,tcsh,csh,ksh) has a
> > moral equivalent to "zero or more path components".  Perl, python,
> > et. al. do.
>
> zsh interprets ** as meaning "zero or more path components" when it's
> followed by a slash:
>
> % mkdir -p foo/bar
> % echo */**
> foo/bar
> % echo */**/
> foo/ foo/bar/
>
> I looked up the Python and Perl equivalents, but the Python one has
> a bug (the pattern '*/*/**' finds 'trunk/iota/' — with a trailing
> slash — even if trunk/iota is a file) and I found no Perl equivalent in
> its stdlib's File::Glob, so I couldn't compare against either of them.
>
> > I would expect "/*/**/*", "/**/*/*" and "/*/*/**" to all match exactly
> the
> > same sets of components.
>
> Then our expectations are different as to what */*/** should mean.  Can
> you give an example of a tool where ./*/*/** matches ./trunk/iota when
> iota is a file (not a directory)?  As I said in my previous mail,
> neither vim nor zsh — which, to clarify, both support a ** recursion
> operaetor — match ./trunk/iota in that situation.
>
> Thanks for jumping in.
>
> Cheers,
>
> Daniel
>
>
> > Cheers,
> >
> > Doug
> >
> > On Wed, Mar 15, 2017 at 5:55 AM, Daniel Shahaf <d...@daniel.shahaf.name>
> > wrote:
> >
> > > From the 1.10 draft release notes:
> > >
> > > > All wildcards apply to full path segments only, i.e. * never matches
> > > > /, except for the case where /**/ matches zero or more path segments.
> > > > For example, /*/**/* will match any path which contains at least
> > > > 2 segments and is equivalent to /**/*/* as well as /*/*/**.
> > >
> > > Are «/*/**/*» «/**/*/*» «/*/*/**» really equivalent?  I would have
> > > expected the first two to match any node except / and /'s immediate
> > > children, but I wouldn't expect the third form to match /trunk/iota
> > > where iota is a file, since the pattern has a trailing slash after the
> > > non-optional second component.
> > >
> > > Testing this in
> > > cd $(mktemp -d)
> > > mkdir -p foo/bar
> > > , I see that neither vim nor zsh finds 

Re: wildcard authz docs question

[Doug Robinson]

Daniel:

The shell's all treat ** as * and require that it match something.  So
"mkdir -p foo/bar/baz" would match.

I would expect "/*/**/*", "/**/*/*" and "/*/*/**" to all match exactly the
same sets of components.

No command shell that I know of (sh,bash,zsh,tcsh,csh,ksh) has a
moral equivalent to "zero or more path components".  Perl, python,
et. al. do.

Cheers,

Doug

On Wed, Mar 15, 2017 at 5:55 AM, Daniel Shahaf 
wrote:

> From the 1.10 draft release notes:
>
> > All wildcards apply to full path segments only, i.e. * never matches
> > /, except for the case where /**/ matches zero or more path segments.
> > For example, /*/**/* will match any path which contains at least
> > 2 segments and is equivalent to /**/*/* as well as /*/*/**.
>
> Are «/*/**/*» «/**/*/*» «/*/*/**» really equivalent?  I would have
> expected the first two to match any node except / and /'s immediate
> children, but I wouldn't expect the third form to match /trunk/iota
> where iota is a file, since the pattern has a trailing slash after the
> non-optional second component.
>
> Testing this in
> cd $(mktemp -d)
> mkdir -p foo/bar
> , I see that neither vim nor zsh finds any matches for */*/**, meaning
> they don't interpret ** as "zero or more" path components in this
> pattern.  I suppose they only treat ** in this way when it appears with
> slashes immediately before and after it.
>
> Cheers,
>
> Daniel
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: Suspected issue with "remove-zombie-locks.py"?

[Doug Robinson]

Daniel:

https://issues.apache.org/jira/browse/SVN-4674

Thank you.

Doug

On Mon, Mar 6, 2017 at 11:06 AM, Daniel Shahaf <d...@daniel.shahaf.name>
wrote:

> Doug Robinson wrote on Mon, Mar 06, 2017 at 10:15:04 -0500:
> >
> > Doug Robinson <doug.robin...@wandisco.com> wrote:
> > > Traceback (most recent call last):
> > >
> > >   File "hook-scripts/remove-zombie-locks.py", line 214, in 
> > >
> > > main()
> > >
> > >   File "hook-scripts/remove-zombie-locks.py", line 208, in main
> > >
> > > remover.run()
> > >
> > >   File "hook-scripts/remove-zombie-locks.py", line 138, in run
> > >
> > > self.unlock_nonexistent_files, self.pool)
> > >
> > >   File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/
> libsvn/fs.py",
> > > line 860, in svn_fs_get_locks2
> > >
> > > return _fs.svn_fs_get_locks2(*args)
> > >
> > > svn.core.SubversionException: 160034 - No username is currently
> associated
> > > with filesystem 'd52a5571-d2a3-4db8-a9e5-a081d6b4b455'
>
> I can reproduce this using the FS API only (without the contrib/ script):
>
> % python2
> >>> from svn.core import *
> >>> from svn.fs import *
> >>> from __future__ import print_function
> >>> fs = svn_fs_open("r/db", None)
> >>> svn_fs_get_locks2(fs, "", svn_depth_infinity, print)
> <libsvn.core.svn_lock_t; proxy of  0x7f4d83bb9660> > <libsvn.core.apr_pool_t; proxy of  'apr_pool_t *' at 0x7f4d83bb96c0> >
> >>> svn_fs_get_locks2(fs, "", svn_depth_infinity, (lambda lock, pool:
> svn_fs_unlock(fs, lock.path, lock.token, True, pool)))
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/libsvn/fs.py", line 876, in
> svn_fs_get_locks2
> return _fs.svn_fs_get_locks2(*args)
> svn.core.SubversionException: 160034 - No username is currently associated
> with filesystem 'a1257b00-ab15-4056-8430-3a7080d0ccfe'
>
> > I realize that the SHA1-collision issues are consuming most of the duty
> > cycles at this point.  Before I forget about this one - should I file a
> bug?
>
> Yes, please.
>
> Thanks,
>
> Daniel
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com <http://www.wandisco.com/>*

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges <http://www.wandisco.com/hadoop/wd-fusion>

Listed on the London Stock Exchange: WAND 
<http://www.bloomberg.com/quote/WAND:LN>

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: Suspected issue with "remove-zombie-locks.py"?

[Doug Robinson]

Folks:

I realize that the SHA1-collision issues are consuming most of the duty
cycles at this point.  Before I forget about this one - should I file a bug?

Cheers!

Doug

On Thu, Mar 2, 2017 at 8:19 AM, Doug Robinson <doug.robin...@wandisco.com>
wrote:

> Folks:
>
> The following commands were run on a CentOS 6.x, WANdisco Subversion
> 1.9.5, Python 2.7:
> 
> --
> # svn export https://svn.apache.org/repos/asf/subversion/trunk/con
> trib/hook-scripts
> # svnadmin create repo
> # svn co file:///path/to/repo wc
> # cd wc
> # touch wc/a; svn add wc/a; svn ci -mm wc
> # svn lock wc/a; svn rm wc/a; svn ci -mm --no-unlock wc
> # hook-scripts/remove-zombie-locks.py repo1 all
>
> Removing all zombie locks from repository at /root/repo
>
> This may take several minutes...
>
> /a
>
> Traceback (most recent call last):
>
>   File "hook-scripts/remove-zombie-locks.py", line 214, in 
>
> main()
>
>   File "hook-scripts/remove-zombie-locks.py", line 208, in main
>
> remover.run()
>
>   File "hook-scripts/remove-zombie-locks.py", line 138, in run
>
> self.unlock_nonexistent_files, self.pool)
>
>   File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/libsvn/fs.py",
> line 860, in svn_fs_get_locks2
>
> return _fs.svn_fs_get_locks2(*args)
>
> svn.core.SubversionException: 160034 - No username is currently associated
> with filesystem 'd52a5571-d2a3-4db8-a9e5-a081d6b4b455'
>
> 
> --
>
>
> Is this a known issue?  Or should I file a bug?
>
>
> Thank you.
>
>
> Doug
> --
> *DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER
>
> *T *925-396-1125
> *E* doug.robin...@wandisco.com
>
> *www.wandisco.com <http://www.wandisco.com/>*
>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com <http://www.wandisco.com/>*

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges <http://www.wandisco.com/hadoop/wd-fusion>

Listed on the London Stock Exchange: WAND 
<http://www.bloomberg.com/quote/WAND:LN>

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Suspected issue with "remove-zombie-locks.py"?

[Doug Robinson]

Folks:

The following commands were run on a CentOS 6.x, WANdisco Subversion 1.9.5,
Python 2.7:
--
# svn export https://svn.apache.org/repos/asf/subversion/trunk/
contrib/hook-scripts
# svnadmin create repo
# svn co file:///path/to/repo wc
# cd wc
# touch wc/a; svn add wc/a; svn ci -mm wc
# svn lock wc/a; svn rm wc/a; svn ci -mm --no-unlock wc
# hook-scripts/remove-zombie-locks.py repo1 all

Removing all zombie locks from repository at /root/repo

This may take several minutes...

/a

Traceback (most recent call last):

  File "hook-scripts/remove-zombie-locks.py", line 214, in 

main()

  File "hook-scripts/remove-zombie-locks.py", line 208, in main

remover.run()

  File "hook-scripts/remove-zombie-locks.py", line 138, in run

self.unlock_nonexistent_files, self.pool)

  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/libsvn/fs.py",
line 860, in svn_fs_get_locks2

return _fs.svn_fs_get_locks2(*args)

svn.core.SubversionException: 160034 - No username is currently associated
with filesystem 'd52a5571-d2a3-4db8-a9e5-a081d6b4b455'

--


Is this a known issue?  Or should I file a bug?


Thank you.


Doug
-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: Bug in "svnrdump" ?

[Doug Robinson]

Julian:

No need to drive it further at this time.

Thank you.

Doug

On Thu, Feb 23, 2017 at 9:15 AM, Julian Foad <julianf...@apache.org> wrote:

> Doug Robinson wrote:
>
>> https://issues.apache.org/jira/browse/SVN-4672
>>
>
> Thanks, Doug, that's great. Let me know if you need me to drive it
> further; I'm assuming not.
>
> Bert wrote:
>
>> That code is in the backing code for svn_ra_replay(), where it also
>> applies to authz, not on the client.
>>
>
> That makes sense. I believe both svnrdump and svnsync use this. I assumed
> both of them would support converting copies to adds...
>
> @Julian Foad Can we use svnsync in this scenario, or does that break in a
>> similar way?
>>
>
> ... but I haven't tested it.
>
> - Julian
>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com <http://www.wandisco.com/>*

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges <http://www.wandisco.com/hadoop/wd-fusion>

Listed on the London Stock Exchange: WAND 
<http://www.bloomberg.com/quote/WAND:LN>

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: Bug in "svnrdump" ?

[Doug Robinson]

Julian:

https://issues.apache.org/jira/browse/SVN-4672

Cheers!

Doug

On Wed, Feb 22, 2017 at 9:11 AM, Julian Foad <julianf...@apache.org> wrote:

> Doug Robinson wrote:
>
>> This has been reproduced on 1.9.5 and 1.8.16.  I've attached a dump of
>> the simple test case repo.
>>
>
> Thanks. I was hasty -- I see what's going on. This is dumping a subtree of
> the repo (/B/Trunk), and r2 was not dumped because it doesn't touch the
> subtree, and it fails on r3 corresponding to step 3. This feature (dump a
> subtree) is not possible with 'svnadmin dump'.
>
> So the bug is that svnrdump doesn't know how to handle a copy source
> that's outside the subtree being dumped.
>
> That's rather poor. I believe the desired behaviour would be to replace
> the 'copy' with a full 'add', and I believe that behaviour is implemented
> somewhere else -- is it in svndumpfilter and/or svnsync?
>
> If you could file a bug report that would be very helpful, thanks.
>
>
> - Julian
>
>
> If so then it has a reproducible bug:
>> --
>> 1. Add following files into an empty repo.
>>
>>A /A
>>
>>A /A/AA
>>
>>A /A/AA/a.txt
>>
>>A /A/AA/b.txt
>>
>> 2. Svn copy folder A to folder B, and then delete /B/AA/a.txt
>>
>>A /B (from /A:1)
>>
>>D /B/AA/a.txt
>>
>> 3. Copy folder B/AA to folder B/Trunk/AA
>>
>>A /B/Trunk
>>
>>A /B/Trunk/AA (from /B/AA:2)
>>
>> 4. run svnrdump command to dump B/Trunk folder.
>>
>> # svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump
>>
>> * Dumped revision 0.
>>
>> * Dumped revision 1.
>>
>> svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
>> --
>>
>> Is this known already?  Should I file a bug?
>>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com <http://www.wandisco.com/>*

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges <http://www.wandisco.com/hadoop/wd-fusion>

Listed on the London Stock Exchange: WAND 
<http://www.bloomberg.com/quote/WAND:LN>

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: Bug in "svnrdump" ?

[Doug Robinson]

Julian:

This has been reproduced on 1.9.5 and 1.8.16.  I've attached a dump of the
simple test case repo.

Thank you.

Doug

On Wed, Feb 22, 2017 at 8:50 AM, Julian Foad <julianf...@apache.org> wrote:

> Doug Robinson wrote:
>
>> Should "svnrdump" be able to dump everything that "svnadmin dump" is
>> capable of?
>>
>
> I'm pretty sure it should, and this isn't a known bug AFAIK (I just
> searched for "svnrdump copy" in Jira).
>
> Thanks for reporting it here.
>
> Can you paste the actual reproduction commands used please. (It isn't
> clear from your description where the commits are, for example. If one
> commit per numbered step, then presumably as it fails on dumping r2 then
> what are steps 3 and 4 for?)
>
> What svn version this is?
>
> - Julian
>
>
>
>> If so then it has a reproducible bug:
>> --
>> 1. Add following files into an empty repo.
>>
>>A /A
>>
>>A /A/AA
>>
>>A /A/AA/a.txt
>>
>>A /A/AA/b.txt
>>
>> 2. Svn copy folder A to folder B, and then delete /B/AA/a.txt
>>
>>A /B (from /A:1)
>>
>>D /B/AA/a.txt
>>
>> 3. Copy folder B/AA to folder B/Trunk/AA
>>
>>A /B/Trunk
>>
>>A /B/Trunk/AA (from /B/AA:2)
>>
>> 4. run svnrdump command to dump B/Trunk folder.
>>
>> # svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump
>>
>> * Dumped revision 0.
>>
>> * Dumped revision 1.
>>
>> svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
>> --
>>
>> Is this known already?  Should I file a bug?
>>
>> Thank you.
>>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com <http://www.wandisco.com/>*

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges <http://www.wandisco.com/hadoop/wd-fusion>

Listed on the London Stock Exchange: WAND 
<http://www.bloomberg.com/quote/WAND:LN>

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.


test.dump
Description: Binary data

Bug in "svnrdump" ?

[Doug Robinson]

Folks:

Should "svnrdump" be able to dump everything that "svnadmin dump" is
capable of?

If so then it has a reproducible bug:
--
1. Add following files into an empty repo.

   A /A

   A /A/AA

   A /A/AA/a.txt

   A /A/AA/b.txt

2. Svn copy folder A to folder B, and then delete /B/AA/a.txt

   A /B (from /A:1)

   D /B/AA/a.txt

3. Copy folder B/AA to folder B/Trunk/AA

   A /B/Trunk

   A /B/Trunk/AA (from /B/AA:2)

4. run svnrdump command to dump B/Trunk folder.

# svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump

* Dumped revision 0.

* Dumped revision 1.

svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
--

Is this known already?  Should I file a bug?

Thank you.

Doug
-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: FSFS instance-id and on-disk representation

[Doug Robinson]

Evgeny:

Thank you.

Doug

On Thu, Feb 16, 2017 at 4:40 PM, Evgeny Kotkov 
wrote:

> Julian Foad  writes:
>
> > == Question ==
> >
> > WANdisco would like to know that there will not be differences in the
> > repository on-disk data due to differences in instance-id (other than the
> > "db/uuid" itself, of course). I suggest we are talking about the
> lifetime of
> > FSFS format 7; of course the features of a future format are unknown.
> >
> > Can I tell them that that is the expectation, and we won't change that
> > situation without a good reason?
>
> The instance ID was added to handle a case when two repositories with
> the same UUID (say, one was hotcopied or dump/loaded from another) are
> opened within a single process.
>
> Without the instance ID, these repositories share internal data that should
> not be shared, such as the transaction list and mutexes.  This can result
> in various types of errors or deadlocks.  An instance ID makes it possible
> to distinguish the internal data for such near-duplicate repositories, and
> is not used anywhere else.
>
> Answering the question, it is safe to assume that an instance ID doesn't
> change what gets written to the disk (apart from the 'db/uuid' contents),
> and that this will not change in format 7.
>
> Hope this helps :)
>
>
> Regards,
> Evgeny Kotkov
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: RFE: API for an efficient retrieval of server-side mergeinfo data

[Doug Robinson]

Julian:

Given the required RA protocol changes, when could this change be shipped?
 What version of SVN?

Thank you.

Doug


On Wed, Feb 19, 2014 at 10:06 AM, Julian Foad julianf...@btopenworld.comwrote:

 Marc Strapetz wrote:
  Julian Foad wrote:
  It looks like we have an agreement in principle. Would you like to file
 an
  enhancement issue?
 
  Great. I've filed an issue now:
 
  http://subversion.tigris.org/issues/show_bug.cgi?id=4469
 
  Would you please review the various attributes (Subcomponent, ...)?

 That's great, thanks. I added a reference to this email thread, added
 myself to the CC list, and tweaked the type from 'feature' to 'enhancement'
 (just my personal interpretation) and schedule from '---' to 'unscheduled'
 (which just indicates I've thought about it and am stating that it's not
 currently tied to any particular release, it doesn't mean it has to stay
 that way).

 I talked with Brane about this and we discussed how it might make more
 sense to do a higher level API. Instead of asking what is the absolute
 difference in the mergeinfo representations? it could ask What merges and
 other interesting events have occurred in the lifetime of this path?.
 There are a couple of reasons.

 The API as sketched so far is pretty straightforward, but even so the
 effort needed to implement it is not trivial. It requires RA protocol
 changes as well as all the layers of API change. The mergeinfo
 representation is subject to change. It feels like a backward step to
 invest effort in adding more support that is tied specifically to the
 current format.

 SmartSVN and other front ends like to be able to draw a merge graph. Even
 the 'svn mergeinfo' command-line command now draws a little ASCII-art graph
 showing limited information about the most recent merge. At present they
 all have to interpret mergeinfo themselves, at a pretty low level, and the
 interpretation is subtle and poorly understood. (I don't understand the
 edge cases related to adds and deletes properly, and I've been working with
 it for years.)

 So it seems like a good idea to encapsulate the interpretation of
 mergeinfo a bit more, and expose data in a form that is geared specifically
 towards explaining the history in the way that users can understand it.
 Maybe think of it as an extended 'log' operation, adding a small number of
 new notification types such as:

   * there is a full merge into here, bringing in all the new changes
   from PATH up to REV;
   * there is a partial merge to here, bringing in some changes
   from PATH between REV1 and REV2;

 What do you think of that sort of interface? Does your code already
 calculate something like that?

 - Julian




-- 
Douglas B. Robinson | *Senior Product Manager*

WANdisco // *Non-Stop Data*

t. 925-396-1125
e. doug.robin...@wandisco.com

-- 
Listed on the London Stock Exchange: 
WANDhttp://www.bloomberg.com/quote/WAND:LN

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, (WANdisco) does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: Kidney blame's behaviour and edge cases

[Doug Robinson]

Daniel:

I think that simply enabling MN (where it is now an error) will create the
situation where the user makes a mistake, gets something they don't expect
and tries to interpret it based on their desire - leading to confusion.  I
believe MN should still be an error.  A new option (--reverse ?) should be
required to make it clear that the user wants the reverse blame walk.

Thank you.

Doug


On Thu, Jun 13, 2013 at 4:35 AM, Daniel Shahaf danie...@elego.de wrote:

 Definition: kidney blame == blame -r N:M with MN.  Currently it is
 an error (raised by svn_client_blame5()).

 By and large, it should do exactly what 'blame -r M:N' does: walk the
 revisions from before-the-colon revision to after-the-colon revision
 and then print the contents of the after the colon revision, with each
 line annotated by the revnum of the rightmost (that is: nearest to the
 revnum on the right of the colon) revision within the range that added
 that line.  In other words, if
 (iota@4, kappa@1), (iota@3, kappa@2), (iota@2, kappa@3), (iota@1, kappa@4)
 are pairs of byte-for-byte-identical files, then 'blame -r 1:4 kappa'
 and 'blame -r 4:1 iota' will output the same thing.

 Currently, the non-kidney blame checks one revision before the start ---
 that is, 'blame -r M:N' actually calls svn_ra_get_file_revs2(start=M-1,
 end=N).  The purpose of this is to differentiate lines added in rN
 from lines present since before rN.  That makes 'blame -r M:N'
 correspond to 'diff -r M-1:N' or 'diff -c M:N', in that it also shows
 changes made _by_ rM, not only _since_ rM.

 That behaviour cannot easily replicated for the -r N:M case since it's
 not possible to cheaply find the next interesting revision after rN,
 but in any case I think it shouldn't be: 'blame -r M:N' should not have
 automagically decremented M --- instead, if the user had wanted to see
 what lines were added in rM, as opposed to before it, the user should
 have specified M-1 as the start revision.  That way, 'blame -r M:N'
 would be consistent with 'diff -r M:N'.

 So I suggest that blame -r N:M not try to find the next change after
 rN (that's the analogous thing to what decrement M is in the '-r M:N'
 case).  That means -r M:N and -r N:M are assymetrical, and I propose we
 fix that by making -r M:N not decrement M --- which we can probably only
 do in 2.0.

 ---

 Another issue: what should 'blame -r 3:3' do?  Currently it is allowed,
 and prints '-' for lines added before r3 and '3' for lines added in r3.
 I am not sure whether that is intentional / by design, or just an
 accident of the fact that whoever added the 'end_rev  start_rev' check
 should have used the broader condition 'end_rev = start_rev' instead.
 (See r7438 - http://svn.apache.org/r847512).

 It seems to me it should ideally print '3' for every line, and the user
 should pass '-r 2:3' if he wants to distinguish added in r3 from
 added before r3.  It would be easy to preserve the current behaviour,
 though, of printing '-' rather than '2' (where '2' here is the youngest
 change to that line, for lines added before r3).

 ---

 Cheers,

 Daniel




-- 
Douglas B. Robinson | *Senior Product Manager*

WANdisco // *Non-Stop Data*

t. 925-396-1125
e. doug.robin...@wandisco.com

-- 
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, (WANdisco) does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: Using svnadmin freeze

[Doug Robinson]

Philip:

How do I subscribe to the dev list?  Not sure I really have time for
that... but perhaps.

Thank you.

Doug


On Fri, May 31, 2013 at 9:03 AM, Philip Martin
philip.mar...@wandisco.comwrote:

 Doug,

 I started a thread on the dev list and meant to cc you but forgot.
 Don't feel any obligation to promote the ideas but do feel free to
 contibute if you want to.

 Philip Martin phi...@codematters.co.uk writes:

  One of my colleagues at WANdisco asked some questions about using
  freeze.  The first thing he wanted to know is how to detect whether a
  freeze is running.  There are various approaches: look at running
  processes, look at processes with the lock file open, implement some
  external lock, etc. but none are reliable or portable.  The only
  reliable way to do it is for Subversion to provide some sort of
  implementation.
 
  A freeze query might be implemented by having a separate freeze lock.
  The freeze function itself would then take the freeze lock before taking
  the write lock, and the freeze query would try a non-blocking lock of
  the freeze lock.  This would probably go into the repos layer to avoid
  duplicate implementations.
 
  I think something like that would work but I'm unsure whether we should
  provide it.  I'm concerned that it would be making freeze special.
  Would we need to provide similar queries for upgrade, recover, pack,
  etc?
 
  A second point was about adding a timeout to freeze.  At present freeze
  blocks until it gets the write lock and will wait as long as it takes.
  There is no timeout in APR's file locking API so to implement a timeout
  we would need to either sit in a loop attempting non-blocking locks or
  use SIGALARM to cause EINTR.  I think that would work but again I'm
  unsure how useful this feature would be.
 
  A timeout leads on to a question was about error handling.  At present
  the return value of svnadmin freeze repository program is the return
  value of the external program provided freeze managed to run the
  program.  If freeze failed to run the program for some reason then the
  return value is generated by svnadmin directly.  There is no way to
  distinguish errors from 'program' from errors from 'svnadmin', they both
  return values in the range 0-255.  Success, zero, is unambiguous but any
  error is difficult to interpret.
 
  I don't see any easy way round this.  If we stop providing the 'program'
  error as the return value how else do we provide it?  Write it to
  standard output in some known form?  Invoke some post-freeze command and
  pass it as a parameter?
 
  --
  Philip
 

 --
 Certified  Supported Apache Subversion Downloads:
 http://www.wandisco.com/subversion/download




-- 
Douglas B. Robinson | *Senior Product Manager*

WANdisco // *Non-Stop Data*

t. 925-396-1125
e. doug.robin...@wandisco.com

-- 
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, (WANdisco) does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.