RE: Subversion on RedHat

[Cedric J.F. Blomart (MINFIN)]

The reason presented by redhat for not supporting more recent version of 
subversion is explained in the bellow link:
https://access.redhat.com/solutions/646783


So basically RedHat won't support subversion 1.9 in current realeases but is 
tracking a proposal to support a newer version in #Bug 1162551 (in RHSCL). So 
they are investingating but no promises.

Multiple reasons are given for this non upgrade, manly that upgrade would be 
impacting for customer:
For RHEL6: upgrade from 1.6 to 1.7 needing an upgrade (svn upgrade) if not done 
automated system will be blocked. Plus issues with shared file system needing 
an upgrade of clients.
For RHEL7: impacting as working copy changed in 1.8

I tought having a few information for those under RHEL subscription might help.

-Message d'origine-
De : Nico Kadel-Garcia [mailto:nka...@gmail.com] 
Envoyé : Tuesday, May 23, 2017 6:01 AM
À : Robert Heller 
Cc : Cedric J.F. Blomart (MINFIN) ; 
users@subversion.apache.org
Objet : Re: Subversion on RedHat

On Mon, May 22, 2017 at 7:39 AM, Robert Heller  wrote:
> At Sat, 20 May 2017 09:55:45 + "Cedric J.F. Blomart (MINFIN)" 
>  wrote:
>
>>
>>
>> Hello,
>>
>> Dumb question maybe.
>>
>> What is the situation with RedHat?
>>
>> They do deliver Subversion 1.7 in their repositories but latest 
>> releases of Subversion (1.9) states that the 1.7 version will not 
>> accept any more bug report.
>
> You file bug reports with RedHat (bugzilla.redhat.com) and RedHat 
> backports bug and security fixes from Subversion 1.9 (or whatever is 
> the current version).
>
> This is basicly what you do with all of the software RedHat packages 
> for EL 6 and 7, when the RH "version" is no longer supported by the 
> original upstream authors.

RPMforge used to publish compatible updates of these packages for RHEL based 
systems. I wrote the last few sets of Subversion RPMs published there, but have 
basically thrown in the towel as increasing new build requirements required 
maintaining more and more updated, unsupported from upstream versions of 
libraries. And I'm fraid that RPMforge seems to be moribund. I'd talk to 
Wandisco about getting their up-to-date builds for RHEL 7 or compatible 
operating systems.

Re: Subversion on RedHat

[Nico Kadel-Garcia]

On Mon, May 22, 2017 at 7:39 AM, Robert Heller  wrote:
> At Sat, 20 May 2017 09:55:45 + "Cedric J.F. Blomart (MINFIN)" 
>  wrote:
>
>>
>>
>> Hello,
>>
>> Dumb question maybe.
>>
>> What is the situation with RedHat?
>>
>> They do deliver Subversion 1.7 in their repositories but latest releases of
>> Subversion (1.9) states that the 1.7 version will not accept any more bug
>> report.
>
> You file bug reports with RedHat (bugzilla.redhat.com) and RedHat backports
> bug and security fixes from Subversion 1.9 (or whatever is the current
> version).
>
> This is basicly what you do with all of the software RedHat packages for EL 6
> and 7, when the RH "version" is no longer supported by the original upstream
> authors.

RPMforge used to publish compatible updates of these packages for RHEL
based systems. I wrote the last few sets of Subversion RPMs published
there, but have basically thrown in the towel as increasing new build
requirements required maintaining more and more updated, unsupported
from upstream versions of libraries. And I'm fraid that RPMforge seems
to be moribund. I'd talk to Wandisco about getting their up-to-date
builds for RHEL 7 or compatible operating systems.

RE: Error running make for subversion

[Joseph, Anselm]

Hello All,
I have been running in circles trying to fix this issue. Nothing seems to work. 
If you could take a couple of minutes to give some direction, it would be 
greatly appreciated.
Thank You

-Original Message-
From: Joseph, Anselm 
Sent: Thursday, May 18, 2017 3:07 PM
To: 'Ryan Schmidt'; Daniel Shahaf
Cc: Subversion Users
Subject: RE: Error running make for subversion

Thank you both for responding.
When I run configure --without-apxs, make install completes cleanly. But my 
problem is that mod_dav_svn.so is not building . I tried different options and 
still cannot get  mod_dav_svn.so to build. 
When I run .configure with-apxs= /opt/eai/ci/httpd-2.2.32/apache/bin/apxs
make install fails as follows:
if true ; then cd subversion/mod_dav_svn ; 
/opt/eai/ci/subversion/build/install-sh -c -d 
"/opt/eai/ci/subversion-1.9.5/svn/libexec" ; 
/opt/eai/ci/httpd-2.2.32/apache/bin/apxs -i -S 
LIBEXECDIR="/opt/eai/ci/subversion-1.9.5/svn/libexec" -a -n dav_svn 
mod_dav_svn.la ; fi /opt/eai/ci/httpd-2.2.32/apache/build/instdso.sh 
SH_LIBTOOL='/opt/freeware/lib/apr-1/build/libtool' mod_dav_svn.la 
/opt/eai/ci/subversion-1.9.5/svn/libexec
rm -f /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so
/opt/freeware/lib/apr-1/build/libtool --mode=install cp mod_dav_svn.la 
/opt/eai/ci/subversion-1.9.5/svn/libexec/
libtool: install: warning: relinking `mod_dav_svn.la'
libtool: install: (cd /opt/eai/ci/subversion/subversion/mod_dav_svn; /bin/sh 
"/opt/eai/ci/subversion/libtool"  --tag CC --silent --mode=relink gcc -shared 
-g -O2 -g -O2 -pthread -L/opt/freeware/lib -rpath 
/opt/eai/ci/subversion-1.9.5/svn/libexec -avoid-version -module -o 
mod_dav_svn.la activity.lo authz.lo deadprops.lo liveprops.lo lock.lo merge.lo 
mirror.lo mod_dav_svn.lo posts/create_txn.lo reports/dated-rev.lo 
reports/deleted-rev.lo reports/file-revs.lo reports/get-location-segments.lo 
reports/get-locations.lo reports/get-locks.lo reports/inherited-props.lo 
reports/log.lo reports/mergeinfo.lo reports/replay.lo reports/update.lo 
repos.lo status.lo util.lo version.lo 
../../subversion/libsvn_repos/libsvn_repos-1.la 
../../subversion/libsvn_fs/libsvn_fs-1.la 
../../subversion/libsvn_delta/libsvn_delta-1.la 
../../subversion/libsvn_subr/libsvn_subr-1.la )
libtool: install: cp .libs/mod_dav_svn.aT 
/opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.a
libtool: install: cp .libs/mod_dav_svn.lai 
/opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.la
chmod 755 /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so
chmod: /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so: A file or 
directory in the path name does not exist.
apxs:Error: Command failed with rc=65536 .
make: 1254-004 The error code from the last command is 1.


Stop.

-Original Message-
From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com]
Sent: Wednesday, May 17, 2017 8:42 PM
To: Daniel Shahaf
Cc: Joseph, Anselm; Subversion Users
Subject: Re: Error running make for subversion

CAUTION - EXTERNAL EMAIL



> On May 17, 2017, at 19:41, Ryan Schmidt  
> wrote:
>
>
>> On May 16, 2017, at 17:18, Daniel Shahaf  wrote:
>>
>> Joseph, Anselm wrote on Tue, May 16, 2017 at 21:04:57 +:
>>> chmod: /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so: A file or 
>>> directory in the path name does not exist.
>>> apxs:Error: Command failed with rc=65536
>>
>> Note that if you use svn:// or svn+ssh://, you don't need mod_dav_svn 
>> and can disable building it with --without-apxs to configure.
>
> You mean http:// and https://. mod_dav_svn isn't involved with svn:// or 
> svn+ssh://.
>

And, sorry, I mis-parsed your sentence. Never mind.

Re: 回复： [wait on line]about svnsync

[Daniel Shahaf]

Dummy wrote on Mon, 22 May 2017 16:48 +0800:
> dear Eric
>   exactly as you said，thank you，i  am so happy
>   but，i can't understand why ，i used pre-revprop-change.bat on windows 
> server 2003，it works
>   Should not it ends in ".sh" on a linux(rh)?
>   anyway ,thanks again.  my name is Yuping Tan

Windows automatically adds extensions; Linux does not.  Subversion always tries
to execute a file called "pre-revprop-change" with no extension.

Re: Subversion on RedHat

[Robert Heller]

At Sat, 20 May 2017 09:55:45 + "Cedric J.F. Blomart (MINFIN)" 
 wrote:

> 
> 
> Hello,
> 
> Dumb question maybe.
> 
> What is the situation with RedHat?
> 
> They do deliver Subversion 1.7 in their repositories but latest releases of
> Subversion (1.9) states that the 1.7 version will not accept any more bug
> report.

You file bug reports with RedHat (bugzilla.redhat.com) and RedHat backports
bug and security fixes from Subversion 1.9 (or whatever is the current
version).

This is basicly what you do with all of the software RedHat packages for EL 6 
and 7, when the RH "version" is no longer supported by the original upstream 
authors.

> 
> Cédric
> 
>   

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services

   

RE: "svn pget svn:externals -r . -R" dramatically slow

[Bert Huijben]

> -Original Message-
> From: Branko Čibej [mailto:br...@apache.org]
> Sent: donderdag 18 mei 2017 15:19
> To: users@subversion.apache.org
> Cc: Andrey 
> Subject: Re: "svn pget svn:externals -r  . -R" dramatically slow
> 
> On 18.05.2017 13:51, Andrey wrote:
> > Branko Čibej  писал(а) в своём письме Thu, 18 May
> > 2017 14:41:17 +0300:
> >
> >>> However, I don't want to revert anything, i am talking about
> >>> possibility of forget to add files because they are obscured by the
> >>> deletion state in the status.
> >>
> >> So what do you suggest we do instead?
> >>
> >> There's a file named 'foo' that was deleted with 'svn rm' but not
> >> committed, and also a file named 'foo' that you created on disk before
> >> committing the deletion (or rename). What do you propose  'svn status'
> >> should show?
> > may be add file content hash to represent 2 statuses of the same file
> > paths? At least it will protect file from accidental remove and miss
> > of add to commit?
> 
> There will be no accidental remove; when you commit, your new file will
> remain unversioned in the working copy:
> 
> brane@zulu:~/test/wc$ svn mv foo bar
> A bar
> D foo
> brane@zulu:~/test/wc$ echo foo > foo
> brane@zulu:~/test/wc$ svn st
> A  +bar
> > moved from foo
> D   foo
> > moved to bar
> brane@zulu:~/test/wc$ svn ci -mm
> Adding bar
> Deleting   foo
> Committing transaction...
> Committed revision 2.
> brane@zulu:~/test/wc$ svn st
> ?   foo
> 
> So far, this is what you reported. Now see what happens when you
> actually run 'svn add' to replace the deleted file:
> 
> brane@zulu:~/test/wc$ touch qux
> brane@zulu:~/test/wc$ svn add qux
> A qux
> brane@zulu:~/test/wc$ svn ci -mm
> Adding qux
> Transmitting file data .done
> Committing transaction...
> Committed revision 3.
> brane@zulu:~/test/wc$ svn mv qux baz
> A baz
> D qux
> brane@zulu:~/test/wc$ echo qux > qux
> brane@zulu:~/test/wc$ svn add qux
> A qux
> brane@zulu:~/test/wc$ svn st
> A  +baz
> > moved from qux
> ?   foo
> R   qux
> > moved to baz
> brane@zulu:~/test/wc$ svn ci -mm
> Adding baz
> Replacing  qux
> Transmitting file data .done
> Committing transaction...
> Committed revision 4.
> brane@zulu:~/test/wc$ svn st
> ?   foo
> 
> 
> In the first case, I suppose we could display something like the following:
> 
> D  +foo
> > moved to bar
> 
> or:
> 
> D  ?foo
> > moved to bar
> 
> 
> to indicate that the file was deleted, but still exists on disk.
> 
> The more interesting question is how, if at all, this would affect the
> Subversion API.

The api already has this information, as there is some on-disk info in the 
status api that isn't reported by 'svn' (but is used by other clients).

Note that 'svn rm --keep-local Q' is the only thing necessary to trigger this 
case. And before 1.7 (pre WC-NG) we always had to keep deleted directories 
until after they were committed, but we didn't want to report these as still 
existing. That is probably why nobody bothered adding UI for this to 'svn' yet.


Bert

RE: Subversion on RedHat

[Grierson, David]

Red Hat have a ABI (application binary interface) consistency policy within 
their major revisions. For example RHEL 6 distributes Apache httpd-2.2.15 - and 
will only ever include httpd-2.2.15.

This is good because it allows users of RHEL6 to have a consistent software 
version that they know will not shift in functionality, configuration or 
behaviour.

You will notice though that the patch level shifts - (RHEL6.4 includes 
httpd-2.2.15-28) this is due to Red Hat backporting patches into their version 
of the package.

The same is true of the Subversion packages distributed by Red Hat - the 
version distributed with RHEL will be lower version number than that supported 
by the Subversion community - however since you're using RHEL you should have a 
support contract with Red Hat where you can submit bug-reports related to the 
version on your platform.

However as Zdenek states if you're interested in using the features of a more 
modern version then you can use the WANDisco or CollabNet RPM's - however you 
should then expect the level of support that you're paying for from those 
vendors.

Dg.

From: Cedric J.F. Blomart (MINFIN) [mailto:cedric.blom...@minfin.fed.be]
Sent: 20 May 2017 10:56
To: users@subversion.apache.org
Subject: Subversion on RedHat

Hello,

Dumb question maybe.

What is the situation with RedHat?

They do deliver Subversion 1.7 in their repositories but latest releases of 
Subversion (1.9) states that the 1.7 version will not accept any more bug 
report.

Cédric

Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views expressed 
may not be official policy, but the personal views of the originator. If you 
have received it in error, please notify the sender by return e-mail and delete 
it from your system. You should not reproduce, distribute, store, retransmit, 
use or disclose its contents to anyone. Please note we reserve the right to 
monitor all e-mail communication through our internal and external networks. 
SKY and the SKY marks are trademarks of Sky plc and Sky International AG and 
are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited 
(Registration No. 2067075) and Sky Subscribers Services Limited (Registration 
No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 
2247735). All of the companies mentioned in this paragraph are incorporated in 
England and Wales and share the same registered office at Grant Way, Isleworth, 
Middlesex TW7 5QD.

?????? [wait on line]about svnsync

[Dummy]

dear Eric
  exactly as you said??thank you??i  am so happy
  but??i can't understand why ??i used pre-revprop-change.bat on windows 
server 2003??it works
  Should not it ends in ".sh" on a linux(rh)?
  anyway ,thanks again.  my name is Yuping Tan


Best wishes for you
--  --
??: "Eric Johnson";;
: 2017??5??20??(??) 0:15
??: "Dummy"<3295285...@qq.com>; 
: "users"; 
: Re: [wait on line]about svnsync



As best I can tell, the problem is that your hook scripts end in ".sh". The 
file name should just be "pre-revprop-change".

Eric.


On Thu, May 18, 2017 at 11:39 PM, Dummy <3295285...@qq.com> wrote:
dear subversion:when i exec : svnsync init svn://192.168.5.32/CMMI-mirror  
http://192.168.9.222/CMMI
i was given a error : please create a pre-revprop-change hook, but i already 
have one and it works by hand
i tried many solutions,but they  are  not available
so i need help o(?s???t)o  , could you please  point out what the problem is?


here is the problem:

9422EF3B@C97C540F.E5A52259
Description: Binary data

Re: On the subversion I have a question to confirm

[Daniel Shahaf]

shen...@snail.com wrote on Mon, 22 May 2017 11:40 +0800:
> Hello, everyone:
> In the process of using Subversion, there are several questions that I hope 
> someone can help to confirm, get the exact answer or official note
> 1, Subversion can not modify the version number under the premise of 
> modifying the historical version of the content?

People who can commit cannot change the contents of previous revisions; they 
can only add new revisions.

The contents of old revisions can be changed by the repository administrator.  
This cannot be prevented by any system.  It is not easy, but it is possible.

> 2, if you can make changes, please provide the appropriate changes or 
> feasible recommendations; Also modified after the existence of the repository 
> is not available, etc. Please give instructions, modify the historical 
> version of the information is retained operating log?

By default, modifying history is not possible.  If the repository administrator 
enables history editing, the repository administrator needs to arrange for 
records to be kept.

Keeping records of commits that create new revisions is possible with the 
built-in logging features (access log and operational log).

> 3, hope to get the Subversion project official email or official authorized 
> reply, thank you for the help!

You're welcome.

Daniel

Re: Subversion on RedHat

[Zdenek Sedlak]

Den 2017-05-20 kl. 11:55, skrev Cedric J.F. Blomart (MINFIN):
>
> Hello,
>
>  
>
> Dumb question maybe.
>
>  
>
> What is the situation with RedHat?
>
>  
>
> They do deliver Subversion 1.7 in their repositories but latest
> releases of Subversion (1.9) states that the 1.7 version will not
> accept any more bug report.
>
>  
>
> Cédric
>
>  
>
I would not expect anything newer before RHEL8 comes.

You have some options:
1. Use something like WANdisco - they generate RPM and DEB from upstream
2. Build own RPMs
3. Send a RFE to Red Hat to include newer Subversion releases in their SCL

//Zdenek