Re: svn commit: r1547873 - /subversion/trunk/subversion/libsvn_subr/sqlite.c

Stefan Sperling <stsp_at_elego.de> writes:

> I think a hotcopy should be a drop-in replica in most respects,
> so it can be used easily in case the original repository is lost.
> If people want to change access permissions they should do so explicitly.

I think hotcopy should respect umask.

> So copying permissions for directories as well seems like a good idea.
> However, it would probably be wise to make any errors encountered while
> copying permissions non-fatal, even for files.
>
> A related questions is whether uid/gid should be preserved. I do believe
> we we want the copy owned by the uid/gid that performs the hotcopy,

We don't really have a choice, only root can change the uid/gid.

> because trying to change the uid/gid of copy destination might interfere
> with some backup processes, and could cause surprises with some filesystems
> such as NFS where UIDs can vary between systems if no central user
> database is used.

I think hotcopy is different from normal repository access. Hotcopy may
use the same owner/group/umask as ordinary access but it could equally
use a different set. Repositories with group write access are used but
I don't think we should be giving group write access to hotcopies if
that overrides the umask of the hotcopy process.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*