On Thu, 2004-09-09 at 12:57, Harald Dunkel wrote:
> > You can't. svn doesn't preserve ownership or perms, other than a
> > generic 'executable' concept.
> >
>
> Destroying information without need doesn't seem very
> unix-like to me.
Subversion is not designed to "create a perfect snapshot of every bit of
data and metadata that can possibly exist". It versions pathnames and
directory contents. It also versions metadata, but only metadata that
*it* considers relevant: the last time a file was committed, by whom,
and so on. It makes no promises that its own metadata will conceivably
cover and capture every bit of metadata in existence on every filesystem
implementation. By your argument, I suppose it's also not very "windows
like" to lose ACL metadata when importing files into Subversion.
Subversion manages metadata that is portable and important to version
control. Permissions/ownership/ACLs are not portable, and their
non-existence has no real negative effect on version control or the
ability to collaborate through the svn tool.
>
> > 'svn co/up' touches each file with 'now', so that tools like 'make' work
> > correctly.
>
> Who said that make works better if SVN breaks the modification
> date of all files? Don't you assume here that the make target
> (e.g. a library or a lex header file) is not checked in? This
> would be a very severe restriction.
That's a pretty universal assumption. Almost anyone you ask will agree
that versioning derived objects in a CVS or SVN-like system is a *bad*
idea. Clearcase is the exception, because it has its own build tools
and actively encourages the sharing of derived objects. CVS and SVN
assume that a standard build tool like 'ant' or 'make' pay attention to
timestamps. When you run 'svn up', you want 'make' to just do the right
thing.
> > Your other option is to look in ~/.subversion/config and set
> > 'use-commit-times=yes', which will force your working-copy files to have
> > the timestamp of the last time each file changed in the *repository*.
> >
>
> It worked. But it would be nice to get a command line flag
> with the same effect. No reason to change the default.
Definitely. I think there may already be an issue filed to add a
commadline flag. It would be nice.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 9 20:23:52 2004