Fwd: Subversion packages

Fwd: Subversion packages

[Kevin Connor Arpe]

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.

Please share you thoughts on this matter.

Kind regards,
Kevin Connor ARPE
Hongkong

--
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

Re: Fwd: Subversion packages

[marco atzeri]

Il 11/17/2013 11:30 AM, Kevin Connor Arpe ha scritto:
> 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.
>
> Please share you thoughts on this matter.
>
> Kind regards,
> Kevin Connor ARPE
> Hongkong
>

In principal no objection to have more variants, we have for some
other programs. In practice how do you avoid collision with the
other subversion versions ?

The program seems not thought with that need in mind.
Current maintainer, David Rothenberger, could have suggestion
or proposal on the matter, but the fact that he is using
current and prev to support 1.8.x and 1.7.x series
at the same time looks bad for your wish.

Have you checked what Fedora, Debian are doing for that need ?

Additional, please look at guidance for package maintainer
http://cygwin.com/setup.html
for maintainer guidelines.

Regards
MArco


--
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

Re: Fwd: Subversion packages

[David Rothenberger]

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@acm.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

Re: Fwd: Subversion packages

[Christopher Faylor]

On Sun, Nov 17, 2013 at 10:17:39AM -0800, David Rothenberger wrote:
>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.

FWIW, I can only get one version of subversion on my gentoo system too:
1.7.13.  On Fedora I can get 1.7.11.  I could probably cast around and
try to find older versions if I wanted to but it doesn't seem like this
is something that those distributions handle seamlessly so it doesn't
seem like this is something that Cygwin should really have to worry
about either.

cgf

--
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

Re: : Subversion packages

[Andrey Repin]

Greetings, Christopher Faylor!

>>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.

> FWIW, I can only get one version of subversion on my gentoo system too:
> 1.7.13.  On Fedora I can get 1.7.11.  I could probably cast around and
> try to find older versions if I wanted to but it doesn't seem like this
> is something that those distributions handle seamlessly so it doesn't
> seem like this is something that Cygwin should really have to worry
> about either.

Normally, you can expect Subversion to transparently operate across different
mix of client and server versions, but they've made a... change[1]... back in
the days, that made working directories illegible in newer (1.7+) clients.
The 1.7 client has the means of converting 1.6 working directories to a new
format. I'm unsure, if 1.8 still have this ability.

[1] http://subversion.apache.org/docs/release-notes/1.7.html#single-db


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 18.11.2013, <01:01>

Sorry for my terrible english...


--
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

Re: : Subversion packages

[David Stacey]

On 17/11/13 21:11, Andrey Repin wrote:
> Normally, you can expect Subversion to transparently operate across different
> mix of client and server versions, but they've made a... change[1]... back in
> the days, that made working directories illegible in newer (1.7+) clients.
> The 1.7 client has the means of converting 1.6 working directories to a new
> format. I'm unsure, if 1.8 still have this ability.

You are correct - you can mix different versions of the svn client and 
server. For instance, I have used svn-1.7 and svn-1.8 clients with a 
svn-1.6 server without any difficulty. However, if the server is an 
earlier release than the client then you may not enjoy some of the new 
benefits that the client offers.

Escaping the svn-1.6 client can be quite tricky, as it is embedded into 
many different development products and plugins. However it is worth the 
effort, and I would encourage the OP to upgrade if possible. The fact 
that svn-1.6 is no longer supported will be an incentive for most companies.

If anyone is genuinely unable to upgrade and desperate for a Cygwin 
svn-1.6 client then there is always the Cygwin Time Machine - surely 
this is preferable to the considerable effort of maintaining parallel 
svn installations.

Regarding you second point: The svn-1.7 client introduced a new working 
copy format, and you had to 'svn upgrade' your old svn-1.6 working 
copies. Once a working copy has been upgraded, it can then only be used 
with a svn-1.7 client. The same is true when upgrading the client from 
svn-1.7 to svn-1.8: the working copy must be upgraded again, and once 
upgraded the working copy can only be used with a svn-1.8 client. All of 
this is independent of the server version.

In theory, it is possible for a svn-1.8 client to upgrade a svn-1.6 
working copy, although I've not attempted this personally.

Dave.


--
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

Re: : Subversion packages

[Andrey Repin]

Greetings, David Stacey!

> Regarding you second point:

My second point is that I can't tell from looking at a directory, if I'm
inside a working copy or not. Launching any additional tools to do simple
telling is not an option.
This is a major drawback for me, and I'm not upgrading.

> The svn-1.7 client introduced a new working
> copy format, and you had to 'svn upgrade' your old svn-1.6 working 
> copies. Once a working copy has been upgraded, it can then only be used 
> with a svn-1.7 client. The same is true when upgrading the client from 
> svn-1.7 to svn-1.8: the working copy must be upgraded again, and once 
> upgraded the working copy can only be used with a svn-1.8 client. All of 
> this is independent of the server version.

> In theory, it is possible for a svn-1.8 client to upgrade a svn-1.6 
> working copy, although I've not attempted this personally.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 18.11.2013, <03:20>

Sorry for my terrible english...


--
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

Re: : Subversion packages

[Conrad Halling]

On 11/17/13, 6:28 PM, Andrey Repin wrote:
> Greetings, David Stacey!
>
>> Regarding you second point:
> My second point is that I can't tell from looking at a directory, if I'm
> inside a working copy or not. Launching any additional tools to do simple
> telling is not an option.
> This is a major drawback for me, and I'm not upgrading.
>
>
Navigate to the directory of interest and use the "svn info" command to 
determine if you're in a working directory or not. I use the Cygwin 
1.8.x client with a Subversion 1.6 server with no problems whatsoever.

--
Conrad Halling
bacon@sphaerula.com


--
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

Re: Fwd: Subversion packages

[Kevin Connor Arpe]

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@acm.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@acm.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

Re: Fwd: Subversion packages

[David Rothenberger]

Kevin Connor Arpe wrote:
> 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.

I'm strongly against statically linking the binaries. It produces
very large binaries and will require recreating the binaries any
time a bug is fixed in any of the many dependent libraries. It also
does not address the API bindings which require DLLs to function,
for example the Perl binding used by git-svn. There is also the
Apache module to consider.

I suppose you could have a system where the versioned svn packages
provide only a statically linked binaries and none of the other
libraries, while the unversioned Subversion packages provide
dynamically linked binaries and all the libraries.

I know of no other Linux distribution that supports multiple
installed versions of Subversion. I don't think it's a good idea.
But if you want to pursue this further, I suggest the following:

 * Make sure you can build the subversion packages from the cygport
   files for both 32-bit and 64-bit Cygwin.
 * Make sure you can build the dependency libraries I currently
   support (libapr1, libaprutil1, serf, and scons), again for 32-bit
   and 64-bit. Make sure you are willing to adopt them. I might be
   persuaded to continue to maintain them, but since I do so solely
   for Subversion, I'd rather you took them over as well.
 * Produce a cygport file for a statically linked svn_1.6 package.
 * Provide a detailed proposal include the cygport file on the
   cygwin-apps mailing list.

Prior to all that, though, I suggest you ask the Cygwin maintainers
and other packagers for their thoughts. There may be resistence to
this from the project as a whole. I'm not sure if this list or
cygwin-apps is best for that discussion, though.

-- 
David Rothenberger  ----  daveroth@acm.org

The world really isn't any worse.  It's just that the news coverage
is so much better.

--
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

Re: Fwd: Subversion packages

[Christopher Faylor]

On Mon, Nov 18, 2013 at 10:35:58AM -0800, David Rothenberger wrote:
>I know of no other Linux distribution that supports multiple
>installed versions of Subversion. I don't think it's a good idea.

And, as I said, neither do I.

I'm vetoing this idea.  I don't think it's something that we want for
the project.

cgf

--
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

Re: Fwd: Subversion packages

[Yaakov (Cygwin/X)]

On 2013-11-18 12:35, David Rothenberger wrote:
> Kevin Connor Arpe wrote:
>> 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.
>
> I'm strongly against statically linking the binaries. It produces
> very large binaries and will require recreating the binaries any
> time a bug is fixed in any of the many dependent libraries. It also
> does not address the API bindings which require DLLs to function,
> for example the Perl binding used by git-svn. There is also the
> Apache module to consider.

There are also a number of svn-dependent components in Ports which link 
against libsvn*-1, so the shared libraries cannot simply go away.

> I suppose you could have a system where the versioned svn packages
> provide only a statically linked binaries and none of the other
> libraries, while the unversioned Subversion packages provide
> dynamically linked binaries and all the libraries.

*Iff* supporting multiple versions is deemed necessary, this would be 
the way to go.

> I know of no other Linux distribution that supports multiple
> installed versions of Subversion. I don't think it's a good idea.

Me neither, but given the recent sqlite3 locking discussion, I won't be 
surprised if compatibility with native Windows clients trumps that.


Yaakov


--
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

Re: Fwd: Subversion packages

[David Stacey]

On 18/11/13 18:18, Kevin Connor Arpe wrote:
> 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.

This is just the kind of problem that the Cygwin Time Machine [1] solves 
really nicely. Using said Time Machine you can install svn-1.6.17-1 from 
Cygwin's dim and distant past, which (I'm guessing) is just what you need.

Given that we have the Time Machine, I'm not convinced of the merits of 
adding parallel svn installations to Cygwin - especially as no Linux 
distro offers this.

Dave.

[1] http://www.fruitbat.org/Cygwin/#cygwintimemachine


--
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

Re: : Subversion packages

[Andrey Repin]

Greetings, Kevin Connor Arpe!

> 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 using native Subversion client. 1.6, yes.
For a simple fact I can't be arsed to launch svn tool each time I want to
know, if I'm located in working directory or not.

Do you have any hard reason to use Cygwin port?


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 17.11.2013, <22:45>

Sorry for my terrible english...


--
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

Re: : Subversion packages

[Christopher Faylor]

On Sun, Nov 17, 2013 at 10:48:23PM +0400, Andrey Repin wrote:
>Greetings, Kevin Connor Arpe!
>>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 using native Subversion client.  1.6, yes.  For a simple fact I
>can't be arsed to launch svn tool each time I want to know, if I'm
>located in working directory or not.
>
>Do you have any hard reason to use Cygwin port?

Suggesting that someone not use Cygwin tools in the Cygwin mailing list
would seem to be rather obviously off-topic.

--
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