I have to agree. While it may make sense to be able create a dumpfile of a remote repository, I'm not so sure that /loading/ a dumpfile remotely is sensible. And it's the load that potentially requires a UUID change.
-- Brane On 06.08.2010 16:03, Greg Stein wrote: > Back up here. > > Why would an admin install a hook to allow changing a UUID? Why would > a UUID be allowed to change over time? If a UUID is supposed to be > changed, then why wouldn't that admin just do it himself? Why does > this have to be allowed remotely? > > I'm sorry, but this whole "feature" just seems misguided. The UUID is > supposed to be stable and unchanging. We use it to determine what > repository we're talking to. It isn't supposed to change from one day > to the next. > > -g > > On Fri, Aug 6, 2010 at 09:02, C. Michael Pilato <cmpil...@collab.net> wrote: > >> On 08/06/2010 04:30 AM, Daniel Shahaf wrote: >> >>> Yes, a pre-uuid-change hook (and disallowing a UUID change unless it exists) >>> is one option. >>> >>> But that means the logic lives in libsvn_repos, so you have to think how >>> 'svnadmin setuuid' would interact with it... >>> >> We just follow the pattern that already exists. By default, 'svnadmin >> setuuid' would bypass the hooks. (In generally, I think it is assumed that >> anyone who can run 'svnadmin' on a repository directly can also modify its >> hooks.) And then we add --use-pre-uuid-change-hook and >> --use-post-uuid-change-hook options. >> >> See 'svnadmin setrevprop' / svn_repos_fs_change_rev_prop3() and 'svnadmin >> load' / svn_repos_load_fs3() for prior art. >> >> -- >> C. Michael Pilato <cmpil...@collab.net> >> CollabNet <> www.collab.net <> Distributed Development On Demand >>