You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "P.Marek" <pm...@cpan.org> on 2003/05/08 09:33:12 UTC
saving time stamps of files
Hello!
One of the main reasons I went to subversion
(from CVS) was that it promises to keep the
timestamps of the files.
I already voted for issue #1246
(http://subversion.tigris.org/issues/show_bug.cgi?id=1256)
but I'm afraid that post-1.0 is a bit late :-)
Now I found the discussion on
http://www.contactor.se/~dast/svn/archive-2002-12/index.shtml#346
and I'd like to propose a solution:
- the modification time of files is archived as a property, eg. svn:mtime
- it is used on checkout
- on update the newer of current and archived is taken
- if the property is set to "current", the current time is always taken,
and the property doesn't get changed on commit.
Comments?
When will that be finished? :-)
I'll be trying 0.22 now, as I had some problems with the
older revisions (issues 1284 and 1288).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: saving time stamps of files
Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> This saves the file's mtime when an 'svn add' command is run, but I
> can't see any point in doing this. A complete system for storing
> mtime is going to need to retrieve and store it when 'svn commit' is
> run, and once it is getting done at 'svn commit' it is pointless to do
> it at 'svn add'.
What he said.
/me nods in embarrassment at not having noticed the conceptual flaw
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: saving time stamps of files
Posted by Philip Martin <ph...@codematters.co.uk>.
"P.Marek" <pm...@cpan.org> writes:
> This just saves the mtime of the files in a new property, so this patch is
> trivial.
[...]
> 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 @@
> #include "svn_io.h"
> #include "svn_md5.h"
> #include "svn_xml.h"
> +#include "svn_time.h"
>
> #include "wc.h"
> #include "log.h"
> @@ -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,
> parent_access, pool));
> }
> +
> + /* 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));
> + }
> +
This saves the file's mtime when an 'svn add' command is run, but I
can't see any point in doing this. A complete system for storing
mtime is going to need to retrieve and store it when 'svn commit' is
run, and once it is getting done at 'svn commit' it is pointless to do
it at 'svn add'.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: saving time stamps of files - nearly finished, help still needed
Posted by Norbert Gruener <no...@MPA-Garching.MPG.DE>.
On Wed, Jun 18 2003, P.Marek wrote:
>
> > Does that mean that SVN did not save the old timestamps somewhere in
> > the background and all the old timestamps are lost ? This is not a
> > very encouraging answer :-( This will give me a hard time to convince
> > the CVS users at my site to convert to SVN.
>
> Well, AFAIK (from "svnadmin dump"), only the commit-time is saved, not the
> individual timestamps.
> But that is to change in the future :-)
>
> > I know that this was not your decision and I am not blaming you. Just
> > on the contrary I want to thank you that you are working on this
> > feature.
>
> I'll try to get commit working, maybe in an (internal) ugly way.
> Do you want to beta-test a patch if it's ready??
Yes, I would be happy to help you by testing your patches. So as soon
as you have anything to test, just let me know. At the moment I am
running subversion release 0.23.0.
Cheers,
Norbert
--
Ceterum censeo | PGP encrypted mail preferred.
Redmond esse delendam. | PGP Key at www.MPA-Garching.MPG.de/~nog/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: saving time stamps of files - nearly finished, help still needed
Posted by "P.Marek" <pm...@cpan.org>.
> I see. That means, this is nothing which will come in the near
> future.
Well, the support for add/import/export is there. I'll just have to find a way
to ship the mtimes on commit.
> Does that mean that SVN did not save the old timestamps somewhere in
> the background and all the old timestamps are lost ? This is not a
> very encouraging answer :-( This will give me a hard time to convince
> the CVS users at my site to convert to SVN.
Well, AFAIK (from "svnadmin dump"), only the commit-time is saved, not the
individual timestamps.
But that is to change in the future :-)
> I know that this was not your decision and I am not blaming you. Just
> on the contrary I want to thank you that you are working on this
> feature.
I'll try to get commit working, maybe in an (internal) ugly way.
Do you want to beta-test a patch if it's ready??
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: saving time stamps of files - nearly finished, help still needed
Posted by Norbert Gruener <no...@MPA-Garching.MPG.DE>.
On Thu, Jun 12 2003, P.Marek wrote:
> > Hi Philipp,
> >
> > on the "subversion" mailing archive I have read your thread about
> > "saving time stamps of files". I am very interested in that
> > {feature|option}.
> >
> ...
> > Do you have any information when your patch will be included ?
>
> I believe it will have to be completed before - I still experience some
> problems.
I see. That means, this is nothing which will come in the near
future.
> I posted a patch which did some things but didn't some other; most notably,
> the saving of timestamps on commit was missing.
Does that mean that SVN did not save the old timestamps somewhere in
the background and all the old timestamps are lost ? This is not a
very encouraging answer :-( This will give me a hard time to convince
the CVS users at my site to convert to SVN.
I know that this was not your decision and I am not blaming you. Just
on the contrary I want to thank you that you are working on this
feature.
Cheers,
Norbert
--
Ceterum censeo | PGP encrypted mail preferred.
Redmond esse delendam. | PGP Key at www.MPA-Garching.MPG.de/~nog/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: saving time stamps of files - nearly finished, help still needed
Posted by "P.Marek" <pm...@cpan.org>.
> Hi Philipp,
>
> on the "subversion" mailing archive I have read your thread about
> "saving time stamps of files". I am very interested in that
> {feature|option}.
>
...
> Do you have any information when your patch will be included ?
I believe it will have to be completed before - I still experience some
problems.
I posted a patch which did some things but didn't some other; most notably,
the saving of timestamps on commit was missing.
But the solution for that problem gave me some problems.
- A property update on commit, but the local property file may be empty, so
some io_read_-function (can't remember the name right now) died
- "svn status" says that properties have been modified, as I have to fake the
mtime for files which don't have this property.
- I thought that the best way to handle this behaviour would be to only
overwrite existing mtime-properties on commit. So everyone using svn on older
repositories would continue as before, and new imported (or added) files
would be tracked.
- I got a bit lost while trying to find a good interface for seperating the
os-specific properties (executable, acls, access rights, ...). The problem is
that I found too many places where these things are handled - so a function
which could insert all os-specifics into a apr_table couldn't handle a
apr_hash and so on - but different types are used in different places, so
there would have to be a multitude of handling functions.
For the first two problems I experimented some time by changing to
entry-properties (which are remembered in the Entries-file instead of the
/propbase/-directory, but that made things worse, as these properties are
AFAIK not saved in the repository.
So as I'm thinking of something the last patch is still current - it takes the
data on add and import and uses it on export (not update, due to the
dependencies problem).
I'm still thinking about a good solution for the commit problem regarding
m-time. (currently leaving all other os-specific properties aside). But I
could not find one yet.
Any help is appreciated :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: saving time stamps of files - nearly finished, help still needed
Posted by Norbert Gruener <no...@MPA-Garching.MPG.DE>.
Hi Philipp,
on the "subversion" mailing archive I have read your thread about
"saving time stamps of files". I am very interested in that
{feature|option}.
On Wed, May 19 2003, P.Marek wrote:
>
> This is a nearly finished version of my patch.
> It should do imports, commits, exports, ... you name it :-)
> BUT: I still don't know how to handle the commit case - where I have a
[snipped]
>
> Will that possibly be in 0.23 or 0.24? I'd like to have an "acknowledged"
> version, which preferable has all my bugs fixed :-)
Do you have any information when your patch will be included ?
Cheers,
Norbert
--
Ceterum censeo | PGP encrypted mail preferred.
Redmond esse delendam. | PGP Key at www.MPA-Garching.MPG.de/~nog/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: saving time stamps of files - nearly finished, help still needed
Posted by "P.Marek" <pm...@cpan.org>.
Hello everybody!
This is a nearly finished version of my patch.
It should do imports, commits, exports, ... you name it :-)
BUT: I still don't know how to handle the commit case - where I have a
item->wcprop_changes and have to insert/change a property. (please see point
marked as TODO in the patch).
I've had a look at the tests. But as I've never written python yet, I'm not
much help. (And no, I don't want to learn language #25. Sorry.)
Here's a basic log-message, and the formatting should be ok too (thanks for
the vi-script :-).
Issue #1256: Handling timestamps of files
* ./doc/book/book/ch06.xml,
./subversion/include/svn_io.h,
./subversion/include/svn_props.h,
./subversion/libsvn_client/commit.c,
./subversion/libsvn_client/commit_util.c,
./subversion/libsvn_client/export.c,
./subversion/libsvn_subr/io.c,
./subversion/libsvn_wc/adm_ops.c,
./subversion/libsvn_wc/props.c,
./subversion/libsvn_wc/update_editor.c
This patch allows saving and restoring of the files' modification timestamp.
The mtime is currently set only on export (see the various messages on the
mailing list regarding the build process for explanations).
Thank you for your help.
If there are any problems you see please tell me.
Will that possibly be in 0.23 or 0.24? I'd like to have an "acknowledged"
version, which preferable has all my bugs fixed :-)
Re: saving time stamps of files - HELP please
Posted by "P.Marek" <pm...@cpan.org>.
> > Regarding the patch:
> >
> > Can you write a log message (see HACKING, and run 'svn log' on the
> > Subversion repository to see examples)? Also, it's easier for us to
> > apply patches when they are relative to the top of the source tree.
>
> Oh, I forgot to say: if this is regarding a particular issue, please
> include the issue number in the log message (and maybe the subject
> line?).
I'll do what I can. I even wrote some lines in the doc/book/ch06.xml :-!
But for now I've got a problem. I'm not very familiar with subversion as I
started coding Friday.
In file subversion/libsvn_client/commit_util.c in function do_item_commit()
there I've inserted this:
if (ctx->cancel_func)
SVN_ERR (ctx->cancel_func (ctx->cancel_baton));
/* Validation. */
if (item->state_flags & SVN_CLIENT_COMMIT_ITEM_IS_COPY)
{
if (! copyfrom_url)
return svn_error_createf
(SVN_ERR_BAD_URL, NULL,
"Commit item '%s' has copy flag but no copyfrom url", url);
if (! SVN_IS_VALID_REVNUM (item->revision))
return svn_error_createf
(SVN_ERR_CLIENT_BAD_REVISION, NULL,
"Commit item '%s' has copy flag but an invalid revision", url);
}
/* Get the parent dir_baton. */
parent_baton = ((void **) db_stack->elts)[*stack_ptr - 1];
>>>> INSERT starts here
/* Save the new timestamp of files */
if (kind == svn_node_file)
{
apr_time_t tstamp;
svn_string_t time_str;
apr_pool_t *cpool = item->wcprop_changes->pool;
svn_prop_t *prop = apr_palloc (cpool, sizeof (*prop));
SVN_ERR (svn_io_file_affected_time (&tstamp, item->path, pool));
/* Maybe the new property value should be compared against the
old and only set if it changed?? */
time_str.data = svn_time_to_cstring (tstamp, pool);
time_str.len = strlen(time_str.data);
/* HELP please - is there a high level function like this one? */
SVN_ERR (svn_wc_prop_set (SVN_PROP_TEXT_TIME, &time_str, item->path,
parent_access, pool));
/* OR - won't work, is an array */
apr_hash_set (file_mods, item->url, APR_HASH_KEY_STRING, (void *)mod);
/* OR - won't work, would have to search for an existing property */
prop->name = apr_pstrdup (cpool, name);
prop->value = svn_string_ncreate (time_str.data, time_str.value,
cpool);
*((svn_prop_t **) apr_array_push (item->wcprop_changes)) = prop;
/* END HELP */
item->state_flags |= SVN_CLIENT_COMMIT_ITEM_PROP_MODS;
}
>>>> INSERT ends here
/* If a feedback table was supplied by the application layer,
describe what we're about to do to this item. */
if (ctx->notify_func)
{
My problem is: which is the recommended way to search the array for a property
and add/change the value? I don't think I'll have to code that by hand - I'm
pretty sure there is a function to do that, rrrright ???? :-)
As of now I've covered
- add finished
- export finished
- a note in doc/book/ch06.xml finished
- commit in progress
- on wc update the newer of the stamps is taken - which is mostly pointless,
as this file will be committed if it had changed locally and then it'll get
another timestamp.
- import is next
Note: when I say finished, I BELIEVE it's finished. You may disagree. That's
why I'll post a complete patch when I'm finished for review and possible
inclusion.
So: Is there something I've forgotten? (as of the list above)? I think holes
will be uncovered when my patch is posted, but is there something to be seen
now?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: saving time stamps of files
Posted by kf...@collab.net.
kfogel@collab.net writes:
> Regarding the patch:
>
> Can you write a log message (see HACKING, and run 'svn log' on the
> Subversion repository to see examples)? Also, it's easier for us to
> apply patches when they are relative to the top of the source tree.
Oh, I forgot to say: if this is regarding a particular issue, please
include the issue number in the log message (and maybe the subject
line?).
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: saving time stamps of files
Posted by kf...@collab.net.
"P.Marek" <pm...@cpan.org> writes:
> 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.
I think this behavior should treat all files the same. That's easiest
to explain and remember.
Regarding the patch:
Can you write a log message (see HACKING, and run 'svn log' on the
Subversion repository to see examples)? Also, it's easier for us to
apply patches when they are relative to the top of the source tree.
Comments follow:
> 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 @@
> #include "svn_io.h"
> #include "svn_md5.h"
> #include "svn_xml.h"
> +#include "svn_time.h"
>
> #include "wc.h"
> #include "log.h"
> @@ -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,
> parent_access, pool));
> }
> +
> + /* 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));
> + }
> +
> }
> }
Looks basically good, though please clean up the alignment so it's
easy to read! :-) (For example, "apr_time_t tstamp" above.)
Is there any way to write a regression test for this? That would be
very helpful.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: saving time stamps of files
Posted by "P.Marek" <pm...@cpan.org>.
> >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
trivial.
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:
> http://www.contactor.se/~dast/svn/archive-2002-12/index.shtml#346
>
> 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.
RE: saving time stamps of files
Posted by Jack Repenning <jr...@collab.net>.
> Note that using the commit time is quite sufficient for "make", even
if you
> have generated files in the repository; at worst, the source and the
> generated file would have exactly the same timestamp after an update.
Historically, "exactly the same time on source and generated" has had
indeterminate effect in various makes. I don't know if that's still an
issue--it started to pass away when one second (granularity of
filesystem timestamps) started to be "a really long time."
In any case, I don't see how using the commit timsestamp addresses the
interleaved operation problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: saving time stamps of files
Posted by Branko Čibej <br...@xbc.nu>.
P.Marek wrote:
>Hello!
>
>One of the main reasons I went to subversion
>(from CVS) was that it promises to keep the
>timestamps of the files.
>
>I already voted for issue #1246
>(http://subversion.tigris.org/issues/show_bug.cgi?id=1256)
>but I'm afraid that post-1.0 is a bit late :-)
>
>Now I found the discussion on
> http://www.contactor.se/~dast/svn/archive-2002-12/index.shtml#346
>and I'd like to propose a solution:
>
>- the modification time of files is archived as a property, eg. svn:mtime
>- it is used on checkout
>- on update the newer of current and archived is taken
>- if the property is set to "current", the current time is always taken,
> and the property doesn't get changed on commit.
>
I really don't like this idea. First of all, we already store the
check-in time of the whole revision. I don't think there's any reason to
store the modification times of individual files; yes, I do think that
when you "svn import", all of the imported files should get the same
commit time.
The question then becomes:
* should Subversion set the mtimes to the commit time on checkout
and update?
* should this be the default behaviour?
Note that using the commit time is quite sufficient for "make", even if
you have generated files in the repository; at worst, the source and the
generated file would have exactly the same timestamp after an update.
>Comments?
>When will that be finished? :-)
>
Whenever you write a patch. :-)
--
Brane Čibej <br...@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
Re: saving time stamps of files
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-05-08 at 05:33, P.Marek wrote:
> - the modification time of files is archived as a property, eg. svn:mtime
> - it is used on checkout
> - on update the newer of current and archived is taken
> - if the property is set to "current", the current time is always taken,
> and the property doesn't get changed on commit.
This seems like reasonable default behavior, although I'm not sure about
the real necessity of "current". I guess I'd be +0 on a patch which did
this. (I'm not +1 because it does introduce new complexity into
libsvn_wc, something we like to avoid.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: saving time stamps of files
Posted by "P.Marek" <pm...@cpan.org>.
> > - it is used on checkout
> > - on update the newer of current and archived is taken
>
> Isn't "current" (that is, the time when the update happens) *always*
> newer than any "archived"? I must be misunderstanding what you meant,
> here.
I meant not to use the current time but the current file mtime and the mtime
of the newer revision of the file.
I grant that it depends on the usage.
But saving the mtime, having options to checkout and update AND
per-file-properties specifying default behaviour should get all cases.
Maybe setting a directory-property which is used by all files and
subdirectories below could do the trick - but I have a feeling that this
isn't the simplest (as in KISS) solution.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: saving time stamps of files
Posted by Jack Repenning <jr...@collab.net>.
> - the modification time of files is archived as a property, eg.
svn:mtime
> - it is used on checkout
> - on update the newer of current and archived is taken
Isn't "current" (that is, the time when the update happens) *always*
newer than any "archived"? I must be misunderstanding what you meant,
here.
> - if the property is set to "current", the current time is always
taken,
> and the property doesn't get changed on commit.
I'm -0 on this handling (don't think it's the right thing, but don't
object so long as it can be overridden). I think the choice between
whether to use current or archived has to do with what you plan to do
with the files once the update finishes, and perhaps what you suspect
has happened in the repo while you were working out at your desk. For
this reason, it should be controlled by a flag to "update."
The use case that drives the common behavior of setting "current" at
update goes like this:
T1: userA performs checkout of the project
T2: userB commits a change to foo.c
T3: userA runs a build
T4: userA updates, receiving userB's changes to foo.c
T5: userA runs another build
At this point, userA's existing foo.o is newer than the archived
timestamp on his fresh foo.c, and a time-based build tool will choose
not to rebuild. But this is of course wrong: it should rebuild, because
foo.c has changed. So this use case definitely wants the current time
stamp on the updated foo.c.
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:
http://www.contactor.se/~dast/svn/archive-2002-12/index.shtml#346
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org