Re: Fwd: [Linux] Hook hashbang hardships

[Branko Čibej]

[switching back to users@]

On 12.10.2016 12:04, Dario Niedermann wrote:
> Il 12/10/2016 alle 11:29, Stefan ha scritto:
>
>> Forwarding messages to the dev list is not really considered good
>> practice.
> The community guide on Subversion's website says it's OK to ask on
> dev@ if a report on a possible issue with svn doesn't goes unanswered
> on users@. Considering that the only reply I got on users@ was from
> someone who completely misread the problem, it seemed to me that the
> last-ditch attempt before opening an issue was to report it is dev@.
>
> Returning to the original topic, and just to be even clearer: this is
> about Subversion NOT RUNNING a script because it has a FLAG FOR THE
> SHELL in its SHEBANG LINE. Not because I got the path to bash wrong or
> because there is some other error in my script (as should be *OBVIOUS*
> from my very first email).

How do you know the script isn't running? On the contrary, your report
implies that the script /is/ running and exits with an error code; when
you modified it, it stopped exiting with an error.


> I was asking if not running a script under these circumstances is
> INTENDED BEHAVIOUR for svn or if it might be a BUG IN SUBVERSION.

It has nothing to do with Subversion. Subversion is not responsible for
interpreting the #! line at the beginning of the script; the kernel does
that.

-- Brane

Re: download link of CollabNet Subversion 1.8.14

[Ryan Schmidt]

> On Oct 11, 2016, at 9:18 PM, Zhao, Linda  wrote:
> 
> Hi friend,
> Could you send me the download link of CollabNet Subversion 1.8.14?
> I can’t find it in the internet.

Using Google, I was able to find that downloads for CollabNet Subversion 1.8.16 
are here:

http://www.collab.net/downloads/svn-other

I'm not sure if downloads for 1.8.14 are still available. If you think you 
require 1.8.14, please let us know why 1.8.16 won't work.

Re: download link of CollabNet Subversion 1.8.14

[Mark Phippard]

On Wed, Oct 12, 2016 at 1:33 PM, Ryan Schmidt <
subversion-2...@ryandesign.com> wrote:

>
> > On Oct 11, 2016, at 9:18 PM, Zhao, Linda  wrote:
> >
> > Hi friend,
> > Could you send me the download link of CollabNet Subversion 1.8.14?
> > I can’t find it in the internet.
>
> Using Google, I was able to find that downloads for CollabNet Subversion
> 1.8.16 are here:
>
> http://www.collab.net/downloads/svn-other
>
> I'm not sure if downloads for 1.8.14 are still available. If you think you
> require 1.8.14, please let us know why 1.8.16 won't work.
>


Once you are on that page, you can right-click on the Download link for the
package you want and copy it to your clipboard.  Then when you paste it,
just change the version number of the download URL from 1.8.16 to 1.8.14
and it will work.  Same is true for pretty much any SVN version as we have
used the same naming system since at least the 1.5.x releases.

For example, this is the link to current 1.9.x version:

http://www.collab.net/servlets/OCNDirector?id=CSVN1.9.4WINC64

Change the 1.9.4 to 1.8.14 and it would give you the 1.8.14 version of that
package which is the Windows 64-bit client.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Cannot add files due to hierarchical RDC svn:auto-props when matching rules merge properties between text and binary file types

[Rob Hofer]

We have a rather common use case where we have an svn:auto-props rule set
globally (set on root of repository) to define source code files as text
based, but also have some files provided by 3rd parties which compress or
encrypt similar files with the same file extension (which we have no
control over), and hence we want to set an svn:auto-props rule locally on
those directories to make those files binary type. But the hierarchical
svn:auto-props rules add properties from multiple definitions of the same
match filter (*.v), and result is a conflicting set of properties that
block the add at the client (eol-style with mime-type=octet-stream).

For example, a binary and text based Verilog file (*.v):
%> file binary.v
binary.v: gzip compressed data, was "binary.v", from Unix, last modified:
Mon Feb 18 19:44:25 2013, max compression
%> file text.v
text.v: ASCII text

The RDC auto-props for this directory shows these Verilog and VHDL types
(local directory expects binary types, global are source-code text files).
%> svn propget svn:auto-props --show-inherited-props .
http://crsvn/gsadc - *.v  = svn:eol-style=LF;svn:keywords=Id Revision
Date Author URL;svn:mime-type=text/x-verilog
. - *.v   = svn:needs-lock;svn:mime-type=application/octet-stream

Adding the files to SVN control fails, unless --no-auto-props is used
(undesirable work around):
%> svn add binary.v
svn: E29: Can't set 'svn:eol-style': file '/module/lay/binary.v' has
binary mime type property
%> svn add --no-auto-props binary.v
A  (bin)  binary.v
%> svn add text.v
svn: E29: Can't set 'svn:eol-style': file '/module/lay/text.v' has
binary mime type property
%> svn add --no-auto-props text.v
A text.v

Subversion auto-detects the binary file and at least sets the mime-type,
but other properties are missing because --no-auto-props is the only way to
add the files without error.
%> svn proplist -v binary.v
Properties on 'binary.v':
  svn:mime-type
application/octet-stream
%> svn proplist -v text.v

%> svn --version
svn, version 1.9.4 (r1740329)
   compiled May 18 2016, 12:05:49 on x86_64-unknown-linux-gnu

(Incidentally, the commit will fail because our hook is checking these
svn:auto-props rules and the file must match the binary rules or the text
rule, based on the mime-type). So the only way today to add these files to
SVN is to use --no-auto-props on add, and go into the server and disable
the pre-commit hook during the commit, then put the pre-commit hook back.
Since a pre-commit hook is the only way to enforce the use of auto-props
correctly, disabling the hook is not an optimal solution. Once added to
SVN, the issue never comes up again because the properties do not change,
and the pre-commit hook checks the modifications on future commits based
upon the mime-type (binary or text rules). The issue is only during the
initial add to SVN due to conflicting properties being applied to the file
based on how the svn:auto-props definitions are being interpreted.

Proposed solution:
1. Make lower level svn:auto-props rules completely override upstream ones,
rather than additively merging properties, for rules with same exact match
filter (local *.v redefines upstream *.v completely).
2. Make SVN ignore properties such as eol-style and keywords when the
mime-type is a binary type rather than issue a fatal error to the
user/client (warning instead that some properties are being ignored).
3. Provide a subtractive property rule to undo an upstream property. E.g.,
svn:eol-style=none, or svn:keyword=none, such that a lower level rule can
unset a property defined upstream (and make svn:eol-style=none behave same
as if svn:eol-style was not applied at all).

Note: Before RDC svn:auto-props (pre 1.8), this use case required having
two entries in the ~/.subversion/config, with one always commented out.
When encountering one type or the other (text or binary), user would have
to uncomment/comment the proper auto-props rule in their config file before
the add, and then change their config back for the normal case. This was
very unwieldly and required careful synchronization of all user runtime
config files and hook scripts and manual intervention by the user during
adds.  Hierarchical RDC properties should eliminate this problem, but it
falls a little short because of how hierarchical RDC svn:auto-props rules
merge mutually exclusive properties together. I believe this is very
similar to multiple matches in the ~/.subversion/config runtime file, for
example a *.v rule and a *-rtl.v rule could collide, except now it is
possible to have the very same rule filter (*.v) defined in more than one
location in the subversion hierarchy. See proposed solution #1 as my
desired behavior from the SVN client.

Sincerely,
Rob


*--Rob HoferSenior Electrical EngineerGS Communication Products
fpga319-295-4541rob.ho...@rockwellcollins.com
rockwellcollins.com
*

Any Export License Required Information and License Restricted
Third P

Re: Cannot add files due to hierarchical RDC svn:auto-props when matching rules merge properties between text and binary file types

[Eric Johnson]

Your constraints, as currently specified, seem to require actual logic

Thoughts follow your email.

On 10/12/16 1:44 PM, Rob Hofer wrote:
We have a rather common use case where we have an svn:auto-props rule 
set globally (set on root of repository) to define source code files 
as text based, but also have some files provided by 3rd parties which 
compress or encrypt similar files with the same file extension (which 
we have no control over), and hence we want to set an svn:auto-props 
rule locally on those directories to make those files binary type. But 
the hierarchical svn:auto-props rules add properties from multiple 
definitions of the same match filter (*.v), and result is a 
conflicting set of properties that block the add at the client 
(eol-style with mime-type=octet-stream).


For example, a binary and text based Verilog file (*.v):
%> file binary.v
binary.v: gzip compressed data, was "binary.v", from Unix, last 
modified: Mon Feb 18 19:44:25 2013, max compression

%> file text.v
text.v: ASCII text

The RDC auto-props for this directory shows these Verilog and VHDL 
types (local directory expects binary types, global are source-code 
text files).

%> svn propget svn:auto-props --show-inherited-props .
http://crsvn/gsadc - *.v  = svn:eol-style=LF;svn:keywords=Id 
Revision Date Author URL;svn:mime-type=text/x-verilog

. - *.v   = svn:needs-lock;svn:mime-type=application/octet-stream

Adding the files to SVN control fails, unless --no-auto-props is used 
(undesirable work around):

%> svn add binary.v
svn: E29: Can't set 'svn:eol-style': file '/module/lay/binary.v' 
has binary mime type property

%> svn add --no-auto-props binary.v
A  (bin)  binary.v
%> svn add text.v
svn: E29: Can't set 'svn:eol-style': file '/module/lay/text.v' has 
binary mime type property

%> svn add --no-auto-props text.v
A text.v

Subversion auto-detects the binary file and at least sets the 
mime-type, but other properties are missing because --no-auto-props is 
the only way to add the files without error.

%> svn proplist -v binary.v
Properties on 'binary.v':
  svn:mime-type
application/octet-stream
%> svn proplist -v text.v

%> svn --version
svn, version 1.9.4 (r1740329)
   compiled May 18 2016, 12:05:49 on x86_64-unknown-linux-gnu

(Incidentally, the commit will fail because our hook is checking these 
svn:auto-props rules and the file must match the binary rules or the 
text rule, based on the mime-type). So the only way today to add these 
files to SVN is to use --no-auto-props on add, and go into the server 
and disable the pre-commit hook during the commit, then put the 
pre-commit hook back.  Since a pre-commit hook is the only way to 
enforce the use of auto-props correctly, disabling the hook is not an 
optimal solution. Once added to SVN, the issue never comes up again 
because the properties do not change, and the pre-commit hook checks 
the modifications on future commits based upon the mime-type (binary 
or text rules). The issue is only during the initial add to SVN due to 
conflicting properties being applied to the file based on how the 
svn:auto-props definitions are being interpreted.


Proposed solution:
1. Make lower level svn:auto-props rules completely override upstream 
ones, rather than additively merging properties, for rules with same 
exact match filter (local *.v redefines upstream *.v completely).
2. Make SVN ignore properties such as eol-style and keywords when the 
mime-type is a binary type rather than issue a fatal error to the 
user/client (warning instead that some properties are being ignored).
3. Provide a subtractive property rule to undo an upstream property. 
E.g., svn:eol-style=none, or svn:keyword=none, such that a lower level 
rule can unset a property defined upstream (and make 
svn:eol-style=none behave same as if svn:eol-style was not applied at 
all).


Note: Before RDC svn:auto-props (pre 1.8), this use case required 
having two entries in the ~/.subversion/config, with one always 
commented out. When encountering one type or the other (text or 
binary), user would have to uncomment/comment the proper auto-props 
rule in their config file before the add, and then change their config 
back for the normal case. This was very unwieldly and required careful 
synchronization of all user runtime config files and hook scripts and 
manual intervention by the user during adds.  Hierarchical RDC 
properties should eliminate this problem, but it falls a little short 
because of how hierarchical RDC svn:auto-props rules merge mutually 
exclusive properties together. I believe this is very similar to 
multiple matches in the ~/.subversion/config runtime file, for example 
a *.v rule and a *-rtl.v rule could collide, except now it is possible 
to have the very same rule filter (*.v) defined in more than one 
location in the subversion hierarchy. See proposed solution #1 as my 
desired behavior from the SVN client.



Only a few options I see:

 - different rep

Re: download link of CollabNet Subversion 1.8.14

[Nico Kadel-Garcia]

On Wed, Oct 12, 2016 at 1:39 PM, Mark Phippard  wrote:
> On Wed, Oct 12, 2016 at 1:33 PM, Ryan Schmidt
>  wrote:
>>
>>
>> > On Oct 11, 2016, at 9:18 PM, Zhao, Linda  wrote:
>> >
>> > Hi friend,
>> > Could you send me the download link of CollabNet Subversion 1.8.14?
>> > I can’t find it in the internet.
>>
>> Using Google, I was able to find that downloads for CollabNet Subversion
>> 1.8.16 are here:
>>
>> http://www.collab.net/downloads/svn-other
>>
>> I'm not sure if downloads for 1.8.14 are still available. If you think you
>> require 1.8.14, please let us know why 1.8.16 won't work.
>
>
>
> Once you are on that page, you can right-click on the Download link for the
> package you want and copy it to your clipboard.  Then when you paste it,
> just change the version number of the download URL from 1.8.16 to 1.8.14 and
> it will work.  Same is true for pretty much any SVN version as we have used
> the same naming system since at least the 1.5.x releases.
>
> For example, this is the link to current 1.9.x version:
>
> http://www.collab.net/servlets/OCNDirector?id=CSVN1.9.4WINC64
>
> Change the 1.9.4 to 1.8.14 and it would give you the 1.8.14 version of that
> package which is the Windows 64-bit client.

This sort of requirement to obtain legacy versions of software, is, of
course, crazed. A simple web page with actual content listings would
be trivial to activate for Collabnet, though it might reduce the
likelihood of potential users and clients using only the latest
published versoin.