subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "C. Michael Pilato" <cmpil...@collab.net>
Subject Re: Coniguring 301/302 redirects to track an fspath rename
Date Thu, 07 Feb 2013 16:16:30 GMT
On 02/06/2013 02:08 PM, Joe Schaefer wrote:
> 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.

I'd like to suggest that the correct long-term way to deal with this is not
with a 301 at all, but with mod_dav_svn being smart enough to say (in
response to "I want to update my working copy of /some/path") simply, "Sure,
here's your update -- but please note that it's being pulled from
/another/path now."  In other words, there shouldn't be any administrator
action required here.

The way I've long envisioned this working is that the server, upon being
asked to update a working copy based on some repository location which
doesn't exist in REVISION-TO-WHICH-ITS-UPDATING, can trace node ancestry to
find one or more suitable alternate locations the client might try, and
presents those to the client as options.  If there's more than one (due to
the original source being copied multiple times to new locations), the user
gets a choice.  If there's only one option, maybe the user is queried or
maybe stuff moves on automatically -- I dunno.  One downside of all of this
is that the server today is simply too stupid to even make such a
recommendation.

Also, the more I think about it, the less I'm convinced that the client's
current 'svn switch' mechanics are sufficient for this.  An 'svn update' of
a working copy that has switched subtrees will maintain those switches,
while an 'svn switch' of such a working copy will effectively un-switch
those subtrees as part of switching their parent tree.  I'll grant that this
particular detail is disinteresting to the CMS situation, but it is
interesting in the general sense.  (Easy solution:  when automatically
transforming an 'svn update' to an 'svn switch', the client queries the
working copy for switched subtrees, and, if it finds some, errors out with a
message saying that automation isn't an option and the working copy needs to
be manually switched.)

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development


Mime
View raw message