Proposal: Change repository's UUID over RA layer

[Ramkumar Ramachandra <ar...@gmail.com>]

Hi,

I've found that I need the functionality to change a repository's UUID
over the RA layer in 'svnrdump load' (see my recently committed tests
to see why). I initially planned to put this off until functionality
until someone thinks I'm capable of handling this and gets me commit
access to libsvn_ra. However, Daniel asked me not to expect this and
start working on a branch instead after notifying the list- I've
therefore started a new ra-uuid branch for this (see r981164). Expect
to see some commits soon :)

Thanks!

-- Ram

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

[Daniel Shahaf <d....@daniel.shahaf.name>]

Greg Hudson wrote on Fri, Aug 06, 2010 at 10:49:27 -0400:
> The philosophical question here isn't whether the ID is "universally
> unique" but what it's identifying.  Is it identifying the repository
> content or the the container in which the content is held?

The former, if I remember correctly a discussion I participated in (on this
list) a few years ago.

And even so, we might decide that the admin should setuuid out-of-band of
the RA layer.  It it isn't unreasonable, given that it's an operation needed
exactly once over the lifetime of any repository^Wcontainer instance.

Daniel
(possibly the discussion was even before I became a committer)

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

[Greg Hudson <gh...@MIT.EDU>]

When I've mirrored repositories with the intent of keeping them in sync,
I've typically given them the same UUID.  I don't know if that has much
impact in practice, since I think working copies tend to stick to one of
the mirrors (either the RW master or the RO slave).

The philosophical question here isn't whether the ID is "universally
unique" but what it's identifying.  Is it identifying the repository
content or the the container in which the content is held?

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

[Branko Čibej <br...@xbc.nu>]

On 06.08.2010 19:26, Justin Erenkrantz wrote:
> On Fri, Aug 6, 2010 at 7:34 AM, Branko Čibej <br...@xbc.nu> wrote:
>   
>> Ahem. You guys have forgotten about Justin's RW-master/RO-slave
>> replication hack, which *requires* the slave repositories to have the
>> same UUID as the master. And that 'svnadmin load' has both --ignore-uuid
>> and --force-uuid.
>>     
> When doing any master/slave initial configuration, doing a local
> 'svnadmin setuuid' should be sufficient.  IOW, I don't see that use
> case as driving this need.  -- justin
>   

Exatly. And while that's being done locally, one might just as well do
the whole 'svnadmin load' which can implicitly set the UUID. Which means
we don't need an 'svnadmin setuuid' since loading a dump is pretty much
the only time one might reasonably want to change the repository UUID, IMHO.

-- Brane

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

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Fri, Aug 6, 2010 at 7:34 AM, Branko Čibej <br...@xbc.nu> wrote:
> Ahem. You guys have forgotten about Justin's RW-master/RO-slave
> replication hack, which *requires* the slave repositories to have the
> same UUID as the master. And that 'svnadmin load' has both --ignore-uuid
> and --force-uuid.

When doing any master/slave initial configuration, doing a local
'svnadmin setuuid' should be sufficient.  IOW, I don't see that use
case as driving this need.  -- justin

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

[Branko Čibej <br...@xbc.nu>]

On 06.08.2010 16:30, Hyrum K. Wright wrote:
> On Fri, Aug 6, 2010 at 9:24 AM, Greg Stein <gs...@gmail.com> wrote:
>   
>> On Fri, Aug 6, 2010 at 10:15, Ramkumar Ramachandra <ar...@gmail.com> wrote:
>>     
>>> Hi Greg,
>>>
>>> Greg Stein writes:
>>>       
>>>> 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?
>>>>         
>>> Agreed- this feature has a very narrow usecase. Anyway, since I
>>> started the thread, let me explain the motivation for this feature. It
>>> derives from `svnrdump` -- Anybody without administrative priviliges
>>> can actually mirror a complete Subversion repository using `svnrdump
>>> dump | svnrdump load` quite efficiently. Let's say some sponsor wants
>>> to provide a mirroring service- with the proposed feature the person
>>> will simply have to create a blank repository and enable
>>> pre-revprop-change/ pre-uuid-change on and wait for someone to load
>>> the content into that repository. After the intial mirroring is done,
>>> he can always turn off the pre-uuid-change. It's probably a
>>> "dangerous" feature, and I don't know if it's worth the trouble.
>>>       
>> I disagree that the UUID should be mirrored. You're loading a *NEW*
>> repository. Thus, it should not have the same UUID as the original.
>> The original continues to exist. Having two repositories with the same
>> UUID is just wrong. That is contrary to the entire design principle..
>>     
> Agreed.  *Universally Unique* Identifier.
>   

Ahem. You guys have forgotten about Justin's RW-master/RO-slave
replication hack, which *requires* the slave repositories to have the
same UUID as the master. And that 'svnadmin load' has both --ignore-uuid
and --force-uuid.

-- Brane

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

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Fri, Aug 6, 2010 at 9:24 AM, Greg Stein <gs...@gmail.com> wrote:
> On Fri, Aug 6, 2010 at 10:15, Ramkumar Ramachandra <ar...@gmail.com> wrote:
>> Hi Greg,
>>
>> Greg Stein writes:
>>> 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?
>>
>> Agreed- this feature has a very narrow usecase. Anyway, since I
>> started the thread, let me explain the motivation for this feature. It
>> derives from `svnrdump` -- Anybody without administrative priviliges
>> can actually mirror a complete Subversion repository using `svnrdump
>> dump | svnrdump load` quite efficiently. Let's say some sponsor wants
>> to provide a mirroring service- with the proposed feature the person
>> will simply have to create a blank repository and enable
>> pre-revprop-change/ pre-uuid-change on and wait for someone to load
>> the content into that repository. After the intial mirroring is done,
>> he can always turn off the pre-uuid-change. It's probably a
>> "dangerous" feature, and I don't know if it's worth the trouble.
>
> I disagree that the UUID should be mirrored. You're loading a *NEW*
> repository. Thus, it should not have the same UUID as the original.
> The original continues to exist. Having two repositories with the same
> UUID is just wrong. That is contrary to the entire design principle..

Agreed.  *Universally Unique* Identifier.

-Hyrum

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

[Greg Stein <gs...@gmail.com>]

On Fri, Aug 6, 2010 at 10:15, Ramkumar Ramachandra <ar...@gmail.com> wrote:
> Hi Greg,
>
> Greg Stein writes:
>> 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?
>
> Agreed- this feature has a very narrow usecase. Anyway, since I
> started the thread, let me explain the motivation for this feature. It
> derives from `svnrdump` -- Anybody without administrative priviliges
> can actually mirror a complete Subversion repository using `svnrdump
> dump | svnrdump load` quite efficiently. Let's say some sponsor wants
> to provide a mirroring service- with the proposed feature the person
> will simply have to create a blank repository and enable
> pre-revprop-change/ pre-uuid-change on and wait for someone to load
> the content into that repository. After the intial mirroring is done,
> he can always turn off the pre-uuid-change. It's probably a
> "dangerous" feature, and I don't know if it's worth the trouble.

I disagree that the UUID should be mirrored. You're loading a *NEW*
repository. Thus, it should not have the same UUID as the original.
The original continues to exist. Having two repositories with the same
UUID is just wrong. That is contrary to the entire design principle..

Cheers,
-g

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

[Peter Samuelson <pe...@p12n.org>]

[Ramkumar Ramachandra]
> Let's say some sponsor wants to provide a mirroring service- with the
> proposed feature the person will simply have to create a blank
> repository and enable pre-revprop-change/ pre-uuid-change on and wait
> for someone to load the content into that repository.

Here's another -1 vote.

I think whoever runs 'svnadmin create' can also run 'svnadmin setuuid'.
And in fact this is easier than adding and removing a hook.

Peter

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

[Ramkumar Ramachandra <ar...@gmail.com>]

Hi Greg,

Greg Stein writes:
> 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?

Agreed- this feature has a very narrow usecase. Anyway, since I
started the thread, let me explain the motivation for this feature. It
derives from `svnrdump` -- Anybody without administrative priviliges
can actually mirror a complete Subversion repository using `svnrdump
dump | svnrdump load` quite efficiently. Let's say some sponsor wants
to provide a mirroring service- with the proposed feature the person
will simply have to create a blank repository and enable
pre-revprop-change/ pre-uuid-change on and wait for someone to load
the content into that repository. After the intial mirroring is done,
he can always turn off the pre-uuid-change. It's probably a
"dangerous" feature, and I don't know if it's worth the trouble.

-- Ram

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

[Branko Čibej <br...@xbc.nu>]

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 <cm...@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 <cm...@collab.net>
>> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
>>     

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

[Greg Stein <gs...@gmail.com>]

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 <cm...@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 <cm...@collab.net>
> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
>
>

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

["C. Michael Pilato" <cm...@collab.net>]

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 <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

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

[Daniel Shahaf <d....@daniel.shahaf.name>]

Ramkumar Ramachandra wrote on Fri, Aug 06, 2010 at 13:40:17 +0530:
> Hi Daniel,
> 
> Daniel Shahaf writes:
> > The implementation should be trivial (over ra_local and ra_svn; probably
> > over ra_dav too but I don't know that one as well).  But what about authz
> > concerns?
> > 
> > Do you want to allow any authenticated user to change the repository UUID?
> 
> No, this doesn't make sense.
> 

Right.  So when *would* a UUID change be permitted?  When the hook says yes?
Or do you want to extend the existing ("read"/"write"/"none") authz schemes?

> > Do you want UUID changing to be disallowed by default (unless the server
> > admin took an explicit action)?
> 
> Yeah. Maybe something like the pre-revprop-change hook?
> 

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...

Daniel

> -- Ram

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

[Ramkumar Ramachandra <ar...@gmail.com>]

Hi Daniel,

Daniel Shahaf writes:
> The implementation should be trivial (over ra_local and ra_svn; probably
> over ra_dav too but I don't know that one as well).  But what about authz
> concerns?
> 
> Do you want to allow any authenticated user to change the repository UUID?

No, this doesn't make sense.

> Do you want UUID changing to be disallowed by default (unless the server
> admin took an explicit action)?

Yeah. Maybe something like the pre-revprop-change hook?

-- Ram

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

[Daniel Shahaf <d....@daniel.shahaf.name>]

Ramkumar Ramachandra wrote on Fri, Aug 06, 2010 at 07:54:36 +0530:
> Hi Daniel,
> 
> Daniel Shahaf writes:
> > Ramkumar Ramachandra wrote on Sun, Aug 01, 2010 at 11:47:51 +0530:
> > > However, Daniel asked me not to expect this and start working on a branch
> > > instead after notifying the list-
> > 
> > No, I didn't ask you to "notify" the list;  I asked you to start a design
> > discussion on the list.  That's a different beast.
> > 
> > You should not just tell us "Hey, I started a branch for feature X"; you
> > should also discuss the plans --- the UI (both for users and admins) and the
> > implementation --- and solicit feedback.
> 
> Sounds good in theory, but I don't know enough about the
> infrastructure to sketch out any concrete design plans- the moment I
> start studying it in this detail, I'll have a mock implementation
> ready- when I'm there, I think I'll post the RFC patch to the list and
> wait for feedback.
> 

The implementation should be trivial (over ra_local and ra_svn; probably
over ra_dav too but I don't know that one as well).  But what about authz
concerns?

Do you want to allow any authenticated user to change the repository UUID?

Do you want UUID changing to be disallowed by default (unless the server
admin took an explicit action)?

> Thanks.
> 
> -- Ram

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

[Ramkumar Ramachandra <ar...@gmail.com>]

Hi Daniel,

Daniel Shahaf writes:
> Ramkumar Ramachandra wrote on Sun, Aug 01, 2010 at 11:47:51 +0530:
> > However, Daniel asked me not to expect this and start working on a branch
> > instead after notifying the list-
> 
> No, I didn't ask you to "notify" the list;  I asked you to start a design
> discussion on the list.  That's a different beast.
> 
> You should not just tell us "Hey, I started a branch for feature X"; you
> should also discuss the plans --- the UI (both for users and admins) and the
> implementation --- and solicit feedback.

Sounds good in theory, but I don't know enough about the
infrastructure to sketch out any concrete design plans- the moment I
start studying it in this detail, I'll have a mock implementation
ready- when I'm there, I think I'll post the RFC patch to the list and
wait for feedback.

Thanks.

-- Ram

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

[Daniel Shahaf <d....@daniel.shahaf.name>]

Ramkumar Ramachandra wrote on Sun, Aug 01, 2010 at 11:47:51 +0530:
> However, Daniel asked me not to expect this and start working on a branch
> instead after notifying the list-

No, I didn't ask you to "notify" the list;  I asked you to start a design
discussion on the list.  That's a different beast.

You should not just tell us "Hey, I started a branch for feature X"; you
should also discuss the plans --- the UI (both for users and admins) and the
implementation --- and solicit feedback.

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

[Ramkumar Ramachandra <ar...@gmail.com>]

Hi Hyrum,

Hyrum K. Wright writes:
> On Sun, Aug 1, 2010 at 1:17 AM, Ramkumar Ramachandra <ar...@gmail.com> wrote:
> > Hi,
> >
> > I've found that I need the functionality to change a repository's UUID
> > over the RA layer in 'svnrdump load' (see my recently committed tests
> > to see why). I initially planned to put this off until functionality
> > until someone thinks I'm capable of handling this and gets me commit
> > access to libsvn_ra. However, Daniel asked me not to expect this and
> > start working on a branch instead after notifying the list- I've
> > therefore started a new ra-uuid branch for this (see r981164). Expect
> > to see some commits soon :)
> 
> It looks like this idea has been discussed, but probably won't go
> forward.  It's probably time to remove the branch.

Indeed. Thanks for the reminder. Branch removed in r986566.

-- Ram

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

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Sun, Aug 1, 2010 at 1:17 AM, Ramkumar Ramachandra <ar...@gmail.com> wrote:
> Hi,
>
> I've found that I need the functionality to change a repository's UUID
> over the RA layer in 'svnrdump load' (see my recently committed tests
> to see why). I initially planned to put this off until functionality
> until someone thinks I'm capable of handling this and gets me commit
> access to libsvn_ra. However, Daniel asked me not to expect this and
> start working on a branch instead after notifying the list- I've
> therefore started a new ra-uuid branch for this (see r981164). Expect
> to see some commits soon :)

It looks like this idea has been discussed, but probably won't go
forward.  It's probably time to remove the branch.

-Hyrum