> >When will that be finished? :-)
> Whenever you write a patch. :-)
Well, here is part 1.
This just saves the mtime of the files in a new property, so this patch is
As for part 2 - restoring the time stamps:
Jack Repenning wrote:
> OTOH, if your update is for the purpose of capturing a certain snapshot
> of the repo itself, then the archive date has some significance (it
> should, at least, be preserved until the point of use of the snapshot,
> where the final determination can be made). And especially so, if
> you've been versioning generated files as well as sources; this is the
> automake case discussed in your reference:
> It seems to me that a team of developers working actively on the product
> would want "current" behavior when they update sources for work, and yet
> "archived" behavior when the update the distribution copy--same files,
> different behavior, depending on intent.
With this in mind I'd propose that
- export uses the archived time stamps, ie. the mtime of the files.
- update uses the current time
- both get switches to override this default behaviour.
In my first try for part 2 there won't be another property for specifying the
default (use saved time or current), although in my patch I've already
reserved a property name.
Could I please get some other opinions to a new question which arrived in my
head: should binary files be treated the same as text-files?
The reason I ask this is because binary files tend (at least in my usual usage
patterns) to be the end-product of some process, and they are seldom used as
dependencies for other programs. This is to say, the .o-files are mostly not
archived in a versioning system, the output files are endpoints and do not
present dependencies of other files, etc.
Of course I think about the use of eg pictures, which are linked into a binary
... but is this a very common case?
I do not argue that this cases should be forbidden. I think about whether the
default behaviour for mtime restoring should be on for binary and off for
text files, with the command line switches able to override that, and
possibly (but as mentioned not in the first patch) to still have a
per-file-property as last resort.
diff -urN subversion-0.22.0_origin/subversion/include/svn_props.h subversion-0.22.0/subversion/include/svn_props.h
--- subversion-0.22.0_origin/subversion/include/svn_props.h Fri May 16 10:43:09 2003
+++ subversion-0.22.0/subversion/include/svn_props.h Fri May 16 11:00:44 2003
@@ -145,6 +145,14 @@
/** The mime-type of a given file. */
#define SVN_PROP_MIME_TYPE SVN_PROP_PREFIX "mime-type"
+/** The (m)time of a given file. */
+#define SVN_PROP_TEXT_TIME SVN_PROP_PREFIX "text-time"
+/** The (m)time-handling of a given file. currently allowed:
+ none to use current behaviour
+ "text-time" to use that. */
+#define SVN_PROP_TEXT_TIME_HANDLING SVN_PROP_PREFIX "text-time-handling"
/** The ignore patterns for a given directory. */
#define SVN_PROP_IGNORE SVN_PROP_PREFIX "ignore"
diff -urN subversion-0.22.0_origin/subversion/libsvn_wc/adm_ops.c subversion-0.22.0/subversion/libsvn_wc/adm_ops.c
--- subversion-0.22.0_origin/subversion/libsvn_wc/adm_ops.c Thu May 8 05:03:37 2003
+++ subversion-0.22.0/subversion/libsvn_wc/adm_ops.c Fri May 16 12:41:36 2003
@@ -41,6 +41,7 @@
@@ -965,8 +966,9 @@
if (kind == svn_node_file)
/* If this is a new file being added instead of a file copy,
- then try to detect the mime-type of this file and set
- svn:executable if the file is executable. Otherwise, use the
+ then try to detect the mime-type of this file, set
+ svn:executable if the file is executable, and
+ save the mtime. Otherwise, use the
values in the original file. */
if (! copyfrom_url)
@@ -990,6 +992,20 @@
SVN_ERR (svn_wc_prop_set (SVN_PROP_EXECUTABLE, &emptystr, path,
+ /* set svn:text-time from the current mtime */
+ svn_string_t time_str;
+ apr_time_t tstamp;
+ SVN_ERR (svn_io_file_affected_time (&tstamp, path, pool));
+ time_str.data = svn_time_to_cstring (tstamp, pool);
+ time_str.len = strlen(time_str.data);
+ SVN_ERR (svn_wc_prop_set (SVN_PROP_TEXT_TIME, &time_str, path,
+ parent_access, pool));
else /* scheduling a directory for addition */
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri May 16 13:07:27 2003