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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature