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: List-Subscribe: List-Archive: List-Post: List-Help: , 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: <52890843 DOT 90903 AT acm DOT org> Date: Tue, 19 Nov 2013 02:18:32 +0800 Message-ID: Subject: Re: Fwd: Subversion packages From: Kevin Connor Arpe To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=UTF-8 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 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