Re: Coniguring 301/302 redirects to track an fspath rename
From: Joe Schaefer <joe_schaefer_at_yahoo.com>
Date: Tue, 5 Feb 2013 09:36:23 -0800 (PST)
AFAICT if I really wanted this feature myself
I could write a perl script that wraps svn client calls
and DTRT with the error message in less than 20 LOC.
You don't have to act like dicks towards people
who are trying to take advantage of newer features
you ostensibly support- the only reason we're discussing
relocation features is because that's all you currently
offer. If you start supporting in-repo switch ops,
hallelujah.
>________________________________
> From: Joe Schaefer <joe_schaefer_at_yahoo.com>
>To: Branko Čibej <brane_at_wandisco.com>; "dev_at_subversion.apache.org" <dev_at_subversion.apache.org>
>Sent: Tuesday, February 5, 2013 12:08 PM
>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>
>
>1) that's not a decision for infra to make.
>2) the svn client even with 1.6 now reports
>the proper error message indicating the location
>of the new url. All infra needs is for the svn client
>to provide a config option to actually interpret
>the error status and take meaningful action itself.
>This doesn't sound like rocket science to me,
>no matter how screwed up the current level of
>support for redirects may be.
>
>
>
>
>
>
>>________________________________
>> From: Branko Čibej <brane_at_wandisco.com>
>>To: dev_at_subversion.apache.org
>>Sent: Tuesday, February 5, 2013 11:50 AM
>>Subject: Re: Coniguring 301/302 redirects to track an fspath rename
>>
>>On 05.02.2013 16:07, C. Michael Pilato wrote:
>>> So, I hate to be the bearer of bad tidings, but this entire exercise
>>> is a giant waste of time and energy.
>>
>>I was going to say it'd be much better overall to create podling trees
>>in SVN in the location they'd have when they graduate, as has already
>>been half-way done with mailing lists.
>>
>>-- Brane
>>
>>--
>>Branko Čibej
>>Director of Subversion | WANdisco | www.wandisco.com
>>
>>
>>
>>
>
>
|
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.