Rolling back to 1.6.x Subversion

Rolling back to 1.6.x Subversion

[Sean LeBlanc]

I've accidentally updated Subversion to 1.7.x on Cygwin.

Is there a way to get an older package of Subversion installed?


--
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: Rolling back to 1.6.x Subversion

[Jeremy Bopp]

On 11/15/2011 15:47, Sean LeBlanc wrote:
> I've accidentally updated Subversion to 1.7.x on Cygwin.
> 
> Is there a way to get an older package of Subversion installed?

It looks like you'll need to check out the Cygwin Time Machine
(http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine) if you
want to go back to version 1.6.

That whole process is going to be unsupported here though, so is there
some reason you must remain on such an old release of subversion?

-Jeremy

--
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: Rolling back to 1.6.x Subversion

[David Rothenberger]

On 11/16/2011 7:18 AM, Jeremy Bopp wrote:
> On 11/15/2011 15:47, Sean LeBlanc wrote:
>> I've accidentally updated Subversion to 1.7.x on Cygwin.
>>
>> Is there a way to get an older package of Subversion installed?
> 
> It looks like you'll need to check out the Cygwin Time Machine
> (http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine) if you
> want to go back to version 1.6.

The 1.6.17-1 release is still on the mirrors, you'll just have to
download it manually.

Or, you can wait for a day or two. I'll try to get the 1.6.17-1 version
restored as the "previous" version for easier installation through the
installer.

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

I'll burn my books.
                -- Christopher Marlowe

--
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: Rolling back to 1.6.x Subversion

[Andrey Repin]

Greetings, Jeremy Bopp!

>> I've accidentally updated Subversion to 1.7.x on Cygwin.
>> 
>> Is there a way to get an older package of Subversion installed?

> It looks like you'll need to check out the Cygwin Time Machine
> (http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine) if you
> want to go back to version 1.6.

> That whole process is going to be unsupported here though, so is there
> some reason you must remain on such an old release of subversion?

It's not "such an old", it's a release you need to migrate your working copies
to 1.17 without checking them out anew.
Or if you want to tell at a glance, if a directory you're working with is a
versioned one... which is not possible for 1.17 :/


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 17.11.2011, <02:18>

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: Rolling back to 1.6.x Subversion

[David Rothenberger]

On 11/16/2011 2:20 PM, Andrey Repin wrote:
> Greetings, Jeremy Bopp!
> 
>>> I've accidentally updated Subversion to 1.7.x on Cygwin.
>>>
>>> Is there a way to get an older package of Subversion installed?
> 
>> It looks like you'll need to check out the Cygwin Time Machine
>> (http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine) if you
>> want to go back to version 1.6.
> 
>> That whole process is going to be unsupported here though, so is there
>> some reason you must remain on such an old release of subversion?
> 
> It's not "such an old", it's a release you need to migrate your working copies
> to 1.17 without checking them out anew.
> Or if you want to tell at a glance, if a directory you're working with is a
> versioned one... which is not possible for 1.17 :/

(1.7, not 1.17).

I agree, Andrey, there are good reasons not to be able to update to 1.7
right now. The Cygwin installer should be able to install the latest 1.6
release by cycling through the versions. The change was just made, so it
may take a little time for the mirrors to catch up.

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

Harrison's Postulate:
        For every action, there is an equal and opposite criticism.

--
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: Rolling back to 1.6.x Subversion

[Warren Young]

On 11/16/2011 3:20 PM, Andrey Repin wrote:
>
> it's a release you need to migrate your working copies
> to 1.17 without checking them out anew.

Are you sure?

After I got svn 1.7 via setup.exe, svn commands began failing in 
preexisting checkout directories, telling me I needed to "svn upgrade" 
them.  Running that command fixed the symptom.

Does this not work for you, or is this what you mean by "checking them 
out anew"?

> Or if you want to tell at a glance, if a directory you're working with is a
> versioned one... which is not possible for 1.17 :/

$ ls -d .svn

--
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: Rolling back to 1.6.x Subversion

[Andrey Repin]

Greetings, Warren Young!

> On 11/16/2011 3:20 PM, Andrey Repin wrote:
>>
>> it's a release you need to migrate your working copies
>> to 1.17 without checking them out anew.

> Are you sure?

As far as I understand the release notes, you need to run "svn cleanup" with
earlier version, before running "svn upgrade" with current one.

> After I got svn 1.7 via setup.exe, svn commands began failing in 
> preexisting checkout directories, telling me I needed to "svn upgrade" 
> them.  Running that command fixed the symptom.

> Does this not work for you, or is this what you mean by "checking them 
> out anew"?

>> Or if you want to tell at a glance, if a directory you're working with is a
>> versioned one... which is not possible for 1.17 :/

> $ ls -d .svn

1.7 working copy do not have .svn dirs in nested directories.
http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 18.11.2011, <02:24>

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: Rolling back to 1.6.x Subversion

[Warren Young]

On 11/17/2011 3:42 PM, Andrey Repin wrote:
>> On 11/16/2011 3:20 PM, Andrey Repin wrote:
>>>
>>> it's a release you need to migrate your working copies
>>> to 1.17 without checking them out anew.
>
>> Are you sure?
>
> As far as I understand the release notes, you need to run "svn cleanup" with
> earlier version, before running "svn upgrade" with current one.

I've done three successful tree upgrades with just an "svn upgrade".

Perhaps the "cleanup" is only needed in uncommon cases?

>> $ ls -d .svn
>
> 1.7 working copy do not have .svn dirs in nested directories.
> http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng

Sorry, I remembered that too late.

How about "svn st -q ."?

--
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: Rolling back to 1.6.x Subversion

[Andrey Repin]

Greetings, Warren Young!

>>> $ ls -d .svn
>>
>> 1.7 working copy do not have .svn dirs in nested directories.
>> http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng

> Sorry, I remembered that too late.

> How about "svn st -q ."?

I can't call it "at a glance".


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 18.11.2011, <13:40>

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: Rolling back to 1.6.x Subversion

[Csaba Raduly]

On 11/18/11, Warren Young  wrote:
> On 11/17/2011 3:42 PM, Andrey Repin wrote:
>>> On 11/16/2011 3:20 PM, Andrey Repin wrote:
>>>>
>>>> it's a release you need to migrate your working copies
>>>> to 1.17 without checking them out anew.
>>
>>> Are you sure?
>>
>> As far as I understand the release notes, you need to run "svn cleanup"
>> with
>> earlier version, before running "svn upgrade" with current one.
>
> I've done three successful tree upgrades with just an "svn upgrade".
>
> Perhaps the "cleanup" is only needed in uncommon cases?
>
>>> $ ls -d .svn
>>
>> 1.7 working copy do not have .svn dirs in nested directories.
>> http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng
>
> Sorry, I remembered that too late.
>
> How about "svn st -q ."?

That prints nothing if the folder is up to date.
Did you mean    "svn st -u ."   ?

-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
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: Rolling back to 1.6.x Subversion

[Dave Korn]

On 18/11/2011 14:24, Csaba Raduly wrote:
> On 11/18/11, Warren Young  wrote:
>> On 11/17/2011 3:42 PM, Andrey Repin wrote:
   [ one level of attribution lost here ]
>>>> $ ls -d .svn
>>> 1.7 working copy do not have .svn dirs in nested directories.
>>> http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng
>> Sorry, I remembered that too late.
>>
>> How about "svn st -q ."?
> 
> That prints nothing if the folder is up to date.
> Did you mean    "svn st -u ."   ?

  How about the quicker (because non-recursively-scanning-the-whole-tree) "svn
info ."?

    cheers,
      DaveK



--
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: Rolling back to 1.6.x Subversion

[Warren Young]

On 11/18/2011 7:24 AM, Csaba Raduly wrote:
> On 11/18/11, Warren Young  wrote:
>>
>> How about "svn st -q ."?
>
> That prints nothing if the folder is up to date.

Yes.  And in the case the OP was concerned with, svn will complain 
bitterly if the folder isn't versioned.

The worst side effect of doing it this way is that svn can be noisy if 
there's a lot of stuff changed in the folder at the time.

--
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: Rolling back to 1.6.x Subversion

[Andrey Repin]

Greetings, Jeremy Bopp!

> Thank you for confirming my memory regarding these format changes.
> Still, while it makes sense for the project to make backward
> incompatible changes at times, it still seems odd that the new clients
> wouldn't support using the working copies from at least 1 minor version
> back in order to ease interoperability between SVN client implementations.

Unfortunatelly, changes in WC format for 1.7 was QUITE drastic...
As said, you can find more info on http://subversion.apache.org/
This is the wrong mailing list to discuss them.

> I could see that the new clients wouldn't *create* older version working
> copies in order to encourage adoption of the changes, but it wouldn't
> seem too hard on the face of it to keep around a compatibility layer
> from the last minor version in order to *use* an older working copy.
> It's the maintainers' decision how they build their project, of course.
>  I just find this aspect surprising.


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 17.11.2011, <22:50>

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: Rolling back to 1.6.x Subversion

[Andrey Repin]

Greetings, Andy Koppe!

> Can one use different svn clients on the same working copy, even if
> they are the same version?

You can even use them (literally) simultaneously. Subversion introduced an
appropriate locking mechanics to ensure as much as possible that all
transactions are atomic.
But, as you pointed out, they all must be of the same version.

> I've always been wary of that due to fear
> of subtle differences in working copy format.

Working copy format is dictated by the Subversion client layer http://svnbook.red-bean.com/en/1.7/svn.developer.layerlib.html#svn.developer.layerlib.client
not by a program or moon phase.

> Character encoding and line endings are two possible trouble spots that come
> to mind. 

Subversion on inside using UTF-8. But this could be a problem when dealing
with files outside Subversion.

> I've certainly seen problems with CVS: Windows CVS clients often
> convert to Windows line endings on checkout, whereas Cygwin CVS
> doesn't, so if you check out with one and then do a 'cvs diff' with
> the other, it says that every line has changed.

This could only happen, if you intentionally set svn:eol-style to "native".
Otherwise, it will preserve line endings, or even convert them to the desired
format upon submission.


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 17.11.2011, <22:52>

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: Rolling back to 1.6.x Subversion

[Jeremy Bopp]

On 11/17/2011 10:09, Jon Clugston wrote:
> On Thu, Nov 17, 2011 at 10:37 AM, Jeremy Bopp <jeremy@bopp.net> wrote:
>> I want to think that they only change the working copy format when the
>> minor version changes, but I also think that they have done that with
>> every minor version transition since at least 1.4.  I know I remember
>> seeing the client request to upgrade my working copies at least once
>> before anyway.  Whether or not that upgrade was required, I can't say.
> 
> This is all explained quite clearly in the documentation on the
> Subversion web site.  Each minor release is allowed to change the
> working copy format in a non-compatible way (the lower numbered
> clients can't safely use it).  This simplifies the development of
> Subversion but causes a (to me at least) very minor annoyance that all
> clients that will use the same working copy must be at the same minor
> release.  This, however, doesn't stop anyone else who writes
> Subversion clients from transparently supporting multiple client
> versions simultaneously (and dealing with the complexity that
> creates).

Thank you for confirming my memory regarding these format changes.
Still, while it makes sense for the project to make backward
incompatible changes at times, it still seems odd that the new clients
wouldn't support using the working copies from at least 1 minor version
back in order to ease interoperability between SVN client implementations.

I could see that the new clients wouldn't *create* older version working
copies in order to encourage adoption of the changes, but it wouldn't
seem too hard on the face of it to keep around a compatibility layer
from the last minor version in order to *use* an older working copy.
It's the maintainers' decision how they build their project, of course.
 I just find this aspect surprising.

-Jeremy

--
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: Rolling back to 1.6.x Subversion

[Jeremy Bopp]

On 11/17/2011 05:12, Csaba Raduly wrote:
> On 11/17/11, Andy Koppe  wrote:
>> Can one use different svn clients on the same working copy, even if
>> they are the same version? I've always been wary of that due to fear
>> of subtle differences in working copy format. Character encoding and
>> line endings are two possible trouble spots that come to mind.
> 
> I regularly use Cygwin's SVN and Subclipse in a Windows version of
> Eclipse and never had any problems. I had to postpone upgrading to the
> Subversion 1.7 Cygwin package until Subclipse 1.8 came out, which
> supports the 1.7 working copy format.

One of the really smart things that the SVN project has done is insulate
the working copy from most of the horrors of line ending differences.
The administrative files appear to either have a strict line ending
definition for all platforms or (more likely) clients are expected to be
flexible regarding line ending handling within the files.  The use of
the svn:eol-style property on source files allows for a great deal of
flexibility regarding management of line endings within the working copy.

Ultimately, any problems boil down to the text editors in use and not
the various SVN clients.  As far as I can see, only the combination of
setting svn:eol-style to native and using a crummy text editor could
expose unexpected problems when mixing Cygwin and Windows SVN clients
within a single working copy.  Those problems would really only be in
the text editor and not SVN however since the text editor could receive
a file with unsupported line endings if the Cygwin client checked the
file out.  Either SVN client would do the right thing with the file upon
commit regardless of the line endings it ended up having after editing.

There can't be very many users out there mixing both Cygwin and Windows
SVN clients with a text editor that completely chokes on Unix line
endings. :-)  I've been really impressed with how gracefully SVN handles
this whole line ending issue.

-Jeremy

--
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: Rolling back to 1.6.x Subversion

[Jon Clugston]

On Thu, Nov 17, 2011 at 10:37 AM, Jeremy Bopp <jeremy@bopp.net> wrote:
> On 11/17/2011 01:39, Andrey Repin wrote:
>> Greetings, Jeremy Bopp!
>>
>>> All I really wanted to know was why it was important to hang back from the
>>> latest available version when getting the older one was less than trivial.
>>> Not using anything more than the command line for svn (infrequently at that)
>>> made me forget how often that project changes formats in the working copies
>>> and the ramifications of that behavior.
>>
>> On my memory, it wasn't changed even once in four years. Or all changes were
>> transparent.
>> The main problem with 1.7 I see myself, I described earlier: No way to tell at
>> a glance, if the directory you're working with is versioned or not.
>
> I want to think that they only change the working copy format when the
> minor version changes, but I also think that they have done that with
> every minor version transition since at least 1.4.  I know I remember
> seeing the client request to upgrade my working copies at least once
> before anyway.  Whether or not that upgrade was required, I can't say.

This is all explained quite clearly in the documentation on the
Subversion web site.  Each minor release is allowed to change the
working copy format in a non-compatible way (the lower numbered
clients can't safely use it).  This simplifies the development of
Subversion but causes a (to me at least) very minor annoyance that all
clients that will use the same working copy must be at the same minor
release.  This, however, doesn't stop anyone else who writes
Subversion clients from transparently supporting multiple client
versions simultaneously (and dealing with the complexity that
creates).

>
> Regardless of the time period between minor version bumps, that rate of
> change in working copies seems excessive to me given the relative
> stability of other SCM tools, but that's just my likely ignorant
> opinion. ;-)
>
> Maybe like you say, the other transitions allowed for some backward
> compatible support.  It's odd then that they wouldn't allow for that in
> the 1.7 client.  I would expect the 1.7 client to at least support
> *using* existing version 1.6 working copies in order to avoid exactly
> this sort of interoperability issue, but it sounds like it does not.
> That's very unfortunate if true.
>
> If true, maybe it would make sense to allow for parallel installation of
> svn versions that differ by minor number and use the alternatives system
> to allow the user to select a particular one if they decided to install
> both.  In other words, it would be handy to offer something like
> subversion16 and subversion17 packages as well as an alias package named
> just subversion that would pull in the latest version.  That's probably
> more work than it's worth though given the number of sub-packages also
> offered with subversion.
>
> -Jeremy
>
> --
> 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: Rolling back to 1.6.x Subversion

[Jeremy Bopp]

On 11/17/2011 01:39, Andrey Repin wrote:
> Greetings, Jeremy Bopp!
> 
>> All I really wanted to know was why it was important to hang back from the
>> latest available version when getting the older one was less than trivial.
>> Not using anything more than the command line for svn (infrequently at that)
>> made me forget how often that project changes formats in the working copies
>> and the ramifications of that behavior.
> 
> On my memory, it wasn't changed even once in four years. Or all changes were
> transparent.
> The main problem with 1.7 I see myself, I described earlier: No way to tell at
> a glance, if the directory you're working with is versioned or not.

I want to think that they only change the working copy format when the
minor version changes, but I also think that they have done that with
every minor version transition since at least 1.4.  I know I remember
seeing the client request to upgrade my working copies at least once
before anyway.  Whether or not that upgrade was required, I can't say.

Regardless of the time period between minor version bumps, that rate of
change in working copies seems excessive to me given the relative
stability of other SCM tools, but that's just my likely ignorant
opinion. ;-)

Maybe like you say, the other transitions allowed for some backward
compatible support.  It's odd then that they wouldn't allow for that in
the 1.7 client.  I would expect the 1.7 client to at least support
*using* existing version 1.6 working copies in order to avoid exactly
this sort of interoperability issue, but it sounds like it does not.
That's very unfortunate if true.

If true, maybe it would make sense to allow for parallel installation of
svn versions that differ by minor number and use the alternatives system
to allow the user to select a particular one if they decided to install
both.  In other words, it would be handy to offer something like
subversion16 and subversion17 packages as well as an alias package named
just subversion that would pull in the latest version.  That's probably
more work than it's worth though given the number of sub-packages also
offered with subversion.

-Jeremy

--
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: Rolling back to 1.6.x Subversion

[Csaba Raduly]

On 11/17/11, Andy Koppe  wrote:
> Can one use different svn clients on the same working copy, even if
> they are the same version? I've always been wary of that due to fear
> of subtle differences in working copy format. Character encoding and
> line endings are two possible trouble spots that come to mind.

I regularly use Cygwin's SVN and Subclipse in a Windows version of
Eclipse and never had any problems. I had to postpone upgrading to the
Subversion 1.7 Cygwin package until Subclipse 1.8 came out, which
supports the 1.7 working copy format.

-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
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: Rolling back to 1.6.x Subversion

[Andy Koppe]

On 16 November 2011 23:06, Jim Garrison wrote:
>> -----Original Message-----
>> On Behalf Of Jeremy Bopp
>> Sent: Wednesday, November 16, 2011 9:18 AM
>> Subject: Re: Rolling back to 1.6.x Subversion
>>
>> That whole process is going to be unsupported here though, so is there
>> some reason you must remain on such an old release of subversion?
>
> Consider users who depend on clients (SVNKit) that don't
> yet have 1.7 native support (i.e. Subclipse).  We have to stay on
> 1.6 until ALL our clients support 1.7 due to the working copy
> restructuring.

Can one use different svn clients on the same working copy, even if
they are the same version? I've always been wary of that due to fear
of subtle differences in working copy format. Character encoding and
line endings are two possible trouble spots that come to mind.

I've certainly seen problems with CVS: Windows CVS clients often
convert to Windows line endings on checkout, whereas Cygwin CVS
doesn't, so if you check out with one and then do a 'cvs diff' with
the other, it says that every line has changed.

Andy

--
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: Rolling back to 1.6.x Subversion

[Andrey Repin]

Greetings, Jeremy Bopp!

> All I really wanted to know was why it was important to hang back from the
> latest available version when getting the older one was less than trivial.
> Not using anything more than the command line for svn (infrequently at that)
> made me forget how often that project changes formats in the working copies
> and the ramifications of that behavior.

On my memory, it wasn't changed even once in four years. Or all changes were
transparent.
The main problem with 1.7 I see myself, I described earlier: No way to tell at
a glance, if the directory you're working with is versioned or not.


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 17.11.2011, <11:06>

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: Rolling back to 1.6.x Subversion

[Jeremy Bopp]

Jim Garrison <jim.garrison@troux.com> wrote:

>> -----Original Message-----
>> On Behalf Of Jeremy Bopp
>> Sent: Wednesday, November 16, 2011 9:18 AM
>> Subject: Re: Rolling back to 1.6.x Subversion
>> 
>> That whole process is going to be unsupported here though, so is
>there
>> some reason you must remain on such an old release of subversion?
>
>Um... 1.7 just came out in the last few months, 1.6.17 isn't "such an
>old
>release".  Consider users who depend on clients (SVNKit) that don't
>yet have 1.7 native support (i.e. Subclipse).  We have to stay on 
>1.6 until ALL our clients support 1.7 due to the working copy 
>restructuring.  When 1.7 came out I saved a copy of the 1.6.17 
>distribution locally.

Seems that I stepped on some nerves due to my poor choice of wording. Sorry about that.

All I really wanted to know was why it was important to hang back from the latest available version when getting the older one was less than trivial. Not using anything more than the command line for svn (infrequently at that) made me forget how often that project changes formats in the working copies and the ramifications of that behavior.

Thanks for enlightening me. :-)

-Jeremy

--
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: Rolling back to 1.6.x Subversion

[Jim Garrison]

> -----Original Message-----
> On Behalf Of Jeremy Bopp
> Sent: Wednesday, November 16, 2011 9:18 AM
> Subject: Re: Rolling back to 1.6.x Subversion
> 
> That whole process is going to be unsupported here though, so is there
> some reason you must remain on such an old release of subversion?

Um... 1.7 just came out in the last few months, 1.6.17 isn't "such an old
release".  Consider users who depend on clients (SVNKit) that don't
yet have 1.7 native support (i.e. Subclipse).  We have to stay on 
1.6 until ALL our clients support 1.7 due to the working copy 
restructuring.  When 1.7 came out I saved a copy of the 1.6.17 
distribution locally.


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