[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Proposal: Change repository's UUID over RA layer

From: Branko ─îibej <brane_at_xbc.nu>
Date: Fri, 06 Aug 2010 16:14:48 +0200

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.