Re: Coniguring 301/302 redirects to track an fspath rename

Telling me this is a dead-end task without explanation does not exactly instill me with confidence in your opinion- I'd like to see you explain why the software I wrote and am now using in production cannot possibly work as intended.  Again do me a favor and test it if you cannot figure out how it works from source: % svn co http://svn.apache.org/repos/asf/incubator/openmeetings/trunk@1400000 % cd trunk % svn up Post the output if you do not understand what our server is trying to convey when you issue those commands. Again the source code for my module is at https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path As I said earlier, the reason we are bandying about relocate is because that's how you coded up the solution to Jon's ticket.  I again don't see the difficulty in interrogating the target server's UUID on a 301 and determining whether or not a relocate is warranted over a simple svn switch- please enlighten me on the difficulties. Let's move forward with an honest technical discussion based on actual research on existing solution instead of arguing from authority and continuing to discuss social failings instead of technical ones. Thx in advance. >________________________________ > From: C. Michael Pilato <cmpilato@collab.net> >To: Joe Schaefer <joe_schaefer@yahoo.com> >Cc: Branko Čibej <brane@wandisco.com>; "dev@subversion.apache.org" <dev@subversion.apache.org> >Sent: Tuesday, February 5, 2013 4:46 PM >Subject: Re: Coniguring 301/302 redirects to track an fspath rename > >Uh... I'm not sure what I said that put me on a "high horse".  That is, >unless my trying to save you spending additional energy on what is (from my >perspective) a dead-end task somehow qualifies. > >At any rate, if I was emitting negativity, it wasn't aimed at you, but at >the fact that the related thread had somehow been allowed to continue for so >long before someone realized that "relocate" isn't even the right action for >the job.  That's not a fault of yours, by any stretch -- we devs are >*supposed* to be the experts here, but seemingly failed to notice this >little detail. > >All that said, I suspect you understand the world well enough to figure out >that just because civility starts to degrade (or appears to start degrading) >doesn't mean that you are compelled to accelerate its decline.  Please don't >bring poisonous name-slinging into this community -- it is quite unwelcome. > >-- C-Mike > >On 02/05/2013 02:04 PM, Joe Schaefer wrote: >> It was civil until CMike got on his high horse- you need to police >> yourselves a bit better before you start accusing outsiders of >> misbehavior- that's how civility starts degrading in a project. >> >> The fact is that a robust solution involves coding thisup as part of the >> generic exception handlingmechanics for whatever svn ops can deal >> with301s.  What's currently in 1.7 that we're pretendingautomates the >> redirect problem is inadequate forany serious svn http server >> administrator trying to track moves.  This is not an idle question- >> Daniel actually tried putting a Redirect block in for the openejb -> >> tomee rename and all it wound up doing is destroying any attempts to >> crawl the project's pre-move history.  We had to back out the change just >> to let our git-svn mirror pick up the new tomee location and DTRT with >> the history. >> >> Please go ahead and test the current server behavior for svn.apache.org >> to see how existing svn clients respond pre-and-post podling graduation. >> The server support and the client-side error reporting are already >> there. >> >> ---------------------------------------------------------------------------- >> >> >*From:* Branko Čibej <brane@wandisco.com> >> *To:* "dev@subversion.apache.org" <dev@subversion.apache.org> *Sent:* >> Tuesday, February 5, 2013 1:52 PM *Subject:* Re: Coniguring 301/302 >> redirects to track an fspath rename >> >> a) I know it's not a call for infra to make b) if you can't lead a civil >> conversation, you may as well send it to /dev/null for all the good it'll >> do. >> >> -- Brane >> >> On 05.02.2013 18:36, Joe Schaefer wrote: >>> 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@yahoo.com >> <mailto:joe_schaefer@yahoo.com>> >>> *To:* Branko Čibej <brane@wandisco.com <mailto:brane@wandisco.com>>; >>> "dev@subversion.apache.org <mailto:dev@subversion.apache.org>" >> <dev@subversion.apache.org <mailto:dev@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@wandisco.com >> <mailto:brane@wandisco.com>> >>> *To:* dev@subversion.apache.org <mailto:dev@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 >> <http://www.wandisco.com/> >>> <http://www.wandisco.com/> >>> >>> >>> >>> >>> >> >> >> -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com >> >> >> > > >-- >C. Michael Pilato <cmpilato@collab.net> >CollabNet  <>  www.collab.net  <>  Enterprise Cloud Development > > > >
Received on 2013-02-05 22:56:41 CET