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

And again to explain a typical use case that would make infra's life easier- let me tell you briefly about CMS sites.  The Apache CMS is basically a CI service for websites, with a simple webgui that wraps common svn client commands on serve-side checkouts of a project's website sources in svn.  There are several associated checkouts sitting in a zfs filesystem associated with the webgui, and when a project graduates right now those working copies and the associated zfs filesystem all need to be destroyed and repopulated based on the new location of the site's sources in svn.  Ditto for the buildbot CI checkout of the site.  While we could go in an do some svn switch surgery ourselves, it is easier for administrative purposes to nuke the entire zfs filesystem and buildbot wc and start over. Needless to say this is a cumbersome process that people like Daniel are trying to simplify with some generic admin-use scripting.  However, if we svn devs ever release a client that allows an admin to bless an svn client to intelligently follow a 301 on a working copy update operation, all of Daniel's scripting efforts can be eradicated when it comes to the CMS-  the CMS would no longer require ANY administrative changes to support podling graduations, it would just continue to work right out of the box. >________________________________ > From: Joe Schaefer <joe_schaefer@yahoo.com> >To: C. Michael Pilato <cmpilato@collab.net> >Cc: Branko Čibej <brane@wandisco.com>; "dev@subversion.apache.org" <dev@subversion.apache.org> >Sent: Wednesday, February 6, 2013 1:34 PM >Subject: Re: Coniguring 301/302 redirects to track an fspath rename > > >I'd like to try to make the case that this kind >of support on the server side is actually undesirable >to bake in to mod_dav_svn, because the typical >copy + delete semantics of a move are entirely >satisfactory for moves within the confines of >someone's working copy.  It's only when we start >moving around entire projects (or even entire >repositories) that having some redirect support >becomes useful to http admins. > > > > > > >>________________________________ >> From: Joe Schaefer <joe_schaefer@yahoo.com> >>To: C. Michael Pilato <cmpilato@collab.net> >>Cc: Branko Čibej <brane@wandisco.com>; "dev@subversion.apache.org" <dev@subversion.apache.org> >>Sent: Tuesday, February 5, 2013 5:23 PM >>Subject: 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-06 20:08:48 CET