delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2013/11/18/13:19:17

X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:mime-version:in-reply-to:references:date
:message-id:subject:from:to:content-type; q=dns; s=default; b=FM
ZLnqOow+/eFQNiCvf8EkMj8UcifQ9uPwAFrd5YUBNdYujaciX0KLKfI7U5MAA32d
qKnVgdV1Qi8gRvoHmEcHwvKFCnefNR/p6mms6IiJcmtxvHiEmB4OY9k2prHetbZd
j4C7KKvMFYafaBQfoN7IDqKbMvp3IyHY8baZ//gnM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:mime-version:in-reply-to:references:date
:message-id:subject:from:to:content-type; s=default; bh=SpX/jImm
7rGx2DicgKNQA5PQpzk=; b=MPZMaETf955zqPw8s5HeltSo1gktn/mwqA9lRfYG
YggFfuLg/RmNvU2TkVaUOLeZTTGxEHaZCHwFLdTvTYCwDE/ZgOzdB3iLQPyt1SqX
S/pTH/mFQk88jI6a6jBwnhSkhoNoUucXTvteawJqH9fRhxkaaGvjYHFwVpWv59WC
PtY=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: Yes, score=5.7 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2
X-HELO: mail-we0-f178.google.com
MIME-Version: 1.0
X-Received: by 10.180.108.97 with SMTP id hj1mr4138870wib.59.1384798713043; Mon, 18 Nov 2013 10:18:33 -0800 (PST)
In-Reply-To: <52890843.90903@acm.org>
References: <CAFMYRRMFGxJhMKNKVgUEs45Lb5dLCf-5vq+Rp5s0H=Eg1yB5kw AT mail DOT gmail DOT com> <CAFMYRRPZWqSJWZVVGDQLLZ55ZOcD_H9q7UgPr4iZyKw9vr2TbQ AT mail DOT gmail DOT com> <52890843 DOT 90903 AT acm DOT org>
Date: Tue, 19 Nov 2013 02:18:32 +0800
Message-ID: <CAFMYRRPt+9U_GcrRwQoOPn4OxpqmW44uy4stp-auX+KYg4pr8w@mail.gmail.com>
Subject: Re: Fwd: Subversion packages
From: Kevin Connor Arpe <kevinarpe AT gmail DOT com>
To: cygwin AT cygwin DOT com
X-IsSubscribed: yes

David,

Thanks for your response.  I have one more important point to add.  I
feel most hard-core UNIX hackers will laugh when I explain.  I use
IntelliJ at work which is a Java IDE.  It depends upon SVNKit for its
Subversion functionality.  SVNKit is a Pure Java implementation of the
SVN protocol.  Unfortunately, SVNKit usually lags SVN releases by 2-3
months, plus IDEs are even slower to upgrade.  Prior, I was an Eclipse
user.  The SVN/Eclpise community is full of complaints about SVNKit.
Easy to integrate with Pure Java code, but nearly always behind
compared to native libraries.  "Blah, blah, blah", I say.  So what?
At my office, due to license costs/issues, I am limited to using a
version that only supported SVN 1.6.x series.  This forces me to limit
all of my SVN tools to 1.6.x.  Blarg, truly.

When I searched in Google for this issue, I was surprised to see a
number of other people with the same issue.  No on had a simple
solution, but many were wishing for more precise version control in
Subversion-space.

Yes, I an interested to take ownership of the official Subversion
packages for Cygwin.

I was thinking about this type of SVN package setup:
* 1.6.x (svn_1.6)
* 1.7.x (svn_1.7)
* 1.8.x (svn_1.8)
* svn (latest -- currently svn_1.8)

I could create statically linked binaries that can live side-by-side,
e.g., /usr/bin/svn1.6, svn1.7, svn1.8 and plain old "svn" which is the
latest.

Please share your thoughts.

Thanks,
Arpe

On Mon, Nov 18, 2013 at 2:17 AM, David Rothenberger <daveroth AT acm DOT org> wrote:
> On 11/17/2013 2:30 AM, Kevin Connor Arpe wrote:
>> Hello,
>>
>> Cygwin currently offerers two Subversion packages.  One from 1.7.x
>> series and another from 1.8.x series.
>>
>> Subversion version series are important because local repositories
>> created by each series (1.6.x, 1.7.x, 1.8.x) are incompatible.  In
>> short, if you do "svn checkout" with svn 1.6.x, you cannot do "svn
>> update" with svn 1.7.x or 1.8.x.  For a variety of reasons, at my
>> office, I am forced to use svn 1.6.x series.  This precludes me from
>> using standard pre-built Cygwin packages for Subversion work.  I'm
>> always jumping back to a IDE or DOS box to manage my svn local repos.
>>
>> I'm not here to complain about this "feature" of Subversion.  AFAIK:
>> Cygwin seems to normally provide at least two versions of any package.
>>  That's great, and usually helps.  However, this situation is a bit
>> rare.  I would like to help make each series available in Cygwin.
>> I've done some googling on this matter and noticed a few others asking
>> on mailing lists (not Cygwin, I think) about how to get svn 1.6.x on
>> the latest Cygwin.  Frankly, there were no satisfying answers.
>>
>> As a starter, I am happy to volunteer to create a specific Cygwin
>> package for Subversion 1.6.x.  Additionally, I already built my own
>> copy of Subversion 1.6.x using Cygwin build toolchain.
>
> The problem is that the Cygwin installer does not provide a mechanism
> for having more than two versions of the same package. I currently
> provide (a somewhat out-of-date) 1.7 version as "prev" and the latest
> 1.8 as "curr". I can see no way to also provide 1.6.
>
> We could make another package (subversion_1_6 or something), but users
> could not have both that and the "subversion" package installed at the
> same time. I really don't think that's a great packaging decision.
>
> Upstream makes no provisions for having multiple installed versions
> coexist. Packaging subversion for Cygwin already involves quite a few
> local patches; I'm not interested in developing and maintaining patches
> to allow multiple versions to coexist.
>
> The newer versions are able to communicate with older servers. Why can't
> you just upgrade to 1.7 or 1.8 for the client? If there is some real
> reason you cannot, I suspect your effort would be better spent trying to
> change that reason instead of packaging 1.6. Especially since even
> upstream no longer supports 1.6. However, if you really want to make
> this work and are willing to take over packaging of all versions of
> subversion and its dependencies, I'm happy to relinquish the
> maintainership to you. I've almost completely switch to git myself anyway.
>
> --
> David Rothenberger  ----  daveroth AT acm DOT org
>
> divorce, n:
>         A change of wife.
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019