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

Re: timestamp preservation design (issue 1256)

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-06-20 22:54:19 CEST

P.Marek wrote:

>>P.Marek wrote:
>>>A versioning system is about *conserving*
>>>information, not losing it. Ideally *all* file information should be saved
>>>- unix rights, NT acl's, ... I believe a hash of the file is stored now.
>>Heh. What happens to ACLs if you commit on NT and check out on Unix?
>>What happens to Unix rights if the committer is 'root' but 'luser' wants
>>to check out a setuid file? There are probably hundreds of such interop
>>problems with this idea, which is mainly why we didn't implement it
>>(yes, we _did_ discuss it).
>>Conserving information is not the same as being a cross between a magpie
>>and a packrat. Some things are better forgotten. :-)
>I'd suggest simply stating *which* os this property is for, eg
>svn:volatile:Win32:NTFS:acls, and ignoring them on other platforms.
>So everyone using unix may get the access rights (which could fold the
>svn:executable into them), but a export on windows would just ignore them.
>And if the user doesn't have enough right to export a setuid-binary ... either
>dump an error or write it non-setuid.
>Although, to be honest, if the user makes changes to that file and commits it
>afterwards, the setuid bit would be lost if it was just read off the
>filesystem and written back to the repository.
And this doesn't scare you? Having a version control system in which
metadata can softly and silently vanish away if you don't happen to have
the right privileges or the right platform is, I think, "almost but not
quite exactly unlike" what we're aiming for here.

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 20 22:55:17 2003

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.