[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: P.Marek <pmarek_at_users.sourceforge.net>
Date: 2003-06-23 08:17:26 CEST

> >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.
No, it doesn't. Because if I'm working on a Win32-Platform the Unix-specific
properties will not be touched, and vice-versa.
Furthermore, if the restauration of some data didn't work (because of missing
rights etc.) I'd set an entry-property which says, "don't change this and
this property although it is different from the repository".

But that is not the case here.
Here we've got a timestamp, which was supported even on my old CPM (on a
Commodore 128 :-) and which, to the best of my knowledge, is available
everywhere where svn is supposed to work. And if a platform doesn't support
the mtime, the build tools have a bigger problem than svn :-)

Well, this discussion moves in a direction not directly related to the
problem, I'm afraid. It *won't* be possible to restore *all* metadata - cp,
tar, zip, etc. all have this problem and cope with it by ignoring on other
platforms.

Please, some comments on the way this should be implemented??

Thank you all.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 23 08:18:26 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.