Doug:
Mostly we are interested in the client-side merge improvements. We occasionally run into some weird merge errors/conflicts that require us to manually merge eligible revisions from one branch to another.
Alfred
> On Apr 12, 2017, at 16:59, Doug Robinson <doug.robinson_at_wandisco.com> wrote:
>
> Alfred:
>
> One last question: are there any specific Subversion bugs that you need fixed? What I'm getting at is that sitting on an old OS platform comes with some costs. And, for the most part, unless you're being burned by a specific Subversion bug, why upgrade?
>
> Cheers:
>
> Doug
>
> On Tue, Apr 11, 2017 at 9:17 AM, Alfred von Campe <alfred_at_von-campe.com <mailto:alfred_at_von-campe.com>> wrote:
> Hi Doug:
>
> The reason is pretty simple: we develop embedded software for a 32-bit platform and compile for both the target (using a cross compiler) and also natively so we can run unit and integration tests on our CentOS workstations. Our application is not (yet) 64-bit compatible. Now I know I can run a 32-bit compiler on a 64-bit host OS, but we also need to support a bunch of older projects on our 32-bit infrastructure and we haven’t taken the time to qualify them all on x86_64. I’m in the process of automating the CentOS 7 x86_64 installation but have hit a few snags along the way. Eventually (3-6 months) we will be moving to 64-bit CentOS 7 (or possibly 64-bit Ubuntu), but until then we will continue to use 32-bit CentOS 6. So if it’s not too much of a hassle, I would really appreciate if you can turn the 32-bit CentOS 6 builds back on.
>
> Thanks,
> Alfred
>
>
>> On Apr 11, 2017, at 8:26, Doug Robinson <doug.robinson_at_wandisco.com <mailto:doug.robinson_at_wandisco.com>> wrote:
>>
>> Alfred:
>>
>> You can blame me for the decision to prune out the 32-bit platform support from WANdisco.
>>
>> I can easily admit to being premature, but I'm finding less demand for 32-bit and really
>> question why anyone would continue to run 32-bit at this time? If you could help me understand
>> then perhaps I can reverse that decision...
>>
>> Thank you.
>>
>> Doug
>>
>> On Mon, Apr 10, 2017 at 10:21 AM, Alfred von Campe <alfred_at_von-campe.com <mailto:alfred_at_von-campe.com>> wrote:
>> We are not quite ready to move to CentOS 7 yet, but hopefully will soon.
>> However, I don’t understand why the dependencies are different for i686
>> and x86_64 on the same CentOS 6 platform for Subversion 1.9.X. Up to
>> version 1.9.4-1, WANdisco provided binaries for both architectures.
>>
>> Alfred
>>
>>
>> > On Apr 7, 2017, at 20:46, Nico Kadel-Garcia <nkadel_at_gmail.com <mailto:nkadel_at_gmail.com>> wrote:
>> >
>> > On Fri, Apr 7, 2017 at 9:57 AM, Alfred von Campe <alfred_at_von-campe.com <mailto:alfred_at_von-campe.com>> wrote:
>> >> Does anyone on this list have a pointer to a repo that hosts the latest 32-bit (i686) Subversion binaries for RHEL 6? I’ve been using the WANdisco SVN Repo 1.9 (http://opensource.wandisco.com/centos/6/svn-1.9/RPMS <http://opensource.wandisco.com/centos/6/svn-1.9/RPMS>), but it only has version 1.9.5-1 for 64-bit (x86_64). The latest 32-bit binaries in that repo are for version 1.9.4-1, which are almost a year old.
>> >>
>> >> Thanks,
>> >> Alfred
>> >
>> > I tried, some time back, to publish SRPM building tools for
>> > subersion-1.9.x and 1.8.x over at https://github.com/nkadel/ <https://github.com/nkadel/>. I
>> > eventually had to throw in the towel as the component dependencies for
>> > compiling the latest Subversion exceeded my time to backport and
>> > provide separate, system compatible builds of various libraries. But
>> > you're welcome to poke them and take a shot at getting it to RHEL 6.
>> >
>> > I also admit that with RHEL 5 and CentOS 5 obsolete, CentOS 6 has also
>> > gotten quite long in the tooth. Can you update to CentOS 7?
>>
>>
>>
>>
>> --
>> DOUGLAS B ROBINSON SENIOR PRODUCT MANAGER
>>
>> T +1 925 396 1125 <>
>> E doug.robinson_at_wandisco.com <mailto:doug.robinson_at_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.
>>
>
>
>
>
> --
> DOUGLAS B ROBINSON SENIOR PRODUCT MANAGER
>
> T +1 925 396 1125 <>
> E doug.robinson_at_wandisco.com <mailto:doug.robinson_at_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.
>
Received on 2017-04-12 23:08:08 CEST