Stefan Sperling <[email protected]> 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*
