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 <cmpilato_at_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 <cmpilato_at_collab.net>
>> CollabNet <> www.collab.net <> Distributed Development On Demand
>>
Received on 2010-08-06 16:15:33 CEST