Preserving modification date/time (not commit date/time) is one of my
hot button issues.
It's one of my few beefs against Subversion.
I agree permission/ownership/ACLs aren't portable. I believe
modification times are portable.
I don't know exactly what CVS does with file modification times (whether
they are maintained).
At least Visual Source Safe has the following option:
Set date/time on local files: Current/Modification/Check-in
The configuration option "use-commit-times=yes" is equivalent to the
"Check-in" value above.
There are at least two problems with not saving (and giving the option
to restore) modification time
as meta data:
1) Information (when the file was last modified) is lost
2) It makes it more difficult to compare files and directories
Putting something under Subversion source control should ideally not
have to modify it at all - just
make a copy of each file and directory and then keep track of the
changes from that point on.
Giving people options as to what date/time to set on a file for
check-out and can either preserve/restore
information (the last modification or check-in time) or it can be set to
the current time to force a rebuild
with that file.
I hope this feature (to save/restore file modification times as built-in
meta data) will be added to
a future version of Subversion.
Thanks,
Chuck
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Thursday, September 09, 2004 2:21 PM
To: Harald Dunkel
Cc: users@subversion.tigris.org
Subject: Re: preserve modification date on co?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 9 22:12:14 2004