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

Look, I wasn't even interested in this issue until Daniel mentioned on IRC that some automated behavior was new in 1.7 that we might be able to use. That explains my drive towards an answer- one that I now understand won't work with existing clients. That is fine with me, and I'm happy that now that we're all on the same page.  Groovy. I do get different behavior out of 1.7 clients, and it may be that my current solution really only "works" (in terms of generating a proper err msg) for 1.7 + neon. Technically the Location header you should have gotten was meant to include trunk- I don't know at this point why you got the parent url other than my REPORT processing in the module is very naive. >________________________________ > 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 5:16 PM >Subject: Re: Coniguring 301/302 redirects to track an fspath rename > >On 02/05/2013 04:56 PM, Joe Schaefer wrote: >> 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: > >So, I think the disconnect stems from my (apparent) misunderstanding that >you were seeking an automated solution that was available *today* to this >very incubator graduate.  Something that would allow the users of that >codebase to effectively not even really notice that the project has been >moved elsewhere in the repository.  Sorry for not noticing that the thread >had shifted into a consideration of some as-yet-uncharted future. > >> % 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. > >Well, I see this (using an 1.8.0-dev Subversion client): > >{{{ >$ svn co http://svn.apache.org/repos/asf/incubator/openmeetings/trunk@1400000 >A    trunk/singlewebapp >A    trunk/singlewebapp/test >A    trunk/singlewebapp/test/filename1.wml >A    trunk/debian_package/etc/init.d >A    trunk/debian_package/etc/init.d/ooomeetings >A    trunk/debian_package/etc/init.d/red5-openmeetings >Checked out revision 1400000. >$ cd trunk/ >$ svn up >Updating '.': >subversion/svn/update-cmd.c:175: (apr_err=175011) >subversion/libsvn_client/update.c:625: (apr_err=175011) >subversion/libsvn_client/update.c:565: (apr_err=175011) >subversion/libsvn_client/update.c:381: (apr_err=175011) >subversion/libsvn_client/iprops.c:273: (apr_err=175011) >subversion/libsvn_client/iprops.c:217: (apr_err=175011) >subversion/libsvn_ra/ra_loader.c:1323: (apr_err=175011) >subversion/libsvn_ra/compat.c:914: (apr_err=175011) >subversion/libsvn_ra_serf/serf.c:1081: (apr_err=175011) >subversion/libsvn_ra_serf/property.c:694: (apr_err=175011) >subversion/libsvn_ra_serf/property.c:670: (apr_err=175011) >subversion/libsvn_ra_serf/util.c:2376: (apr_err=175011) >svn: E175011: Repository moved permanently to '(null)'; please relocate >$ >}}} > >But I suspect that's not precisely what you see. > >From this I gather the server has issued a Redirect.  Indeed, from a >wireshark trace, I see the Redirect was of the 301 variety and contains this >header: > >  Location: http://svn.apache.org/repos/asf/openmeetings > >So, looks good so far.  It seems the client has a problem properly parsing >the header -- something we need to fix if that hasn't been done already. > >> 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. > >Oh, I'm not saying that it can't be done using some future version of >Subversion that chooses switch or relocate as needed.  (See >"misunderstanding" above.) > >> 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. > >Agreed. > >-- >C. Michael Pilato <cmpilato@collab.net> >CollabNet  <>  www.collab.net  <>  Enterprise Cloud Development > > > >
Received on 2013-02-05 23:24:09 CET