(snip)
> > > Could you elaborate on that, give an example where the
> latest is not
> > > the natural choice? (For the time-stamps obviously - not
> the contents).
> >
> > The value of the timestamp property doesn't matter as far
> as the next
> > commit is concerned, only the presence of the property matters. If
> > you resolve conflicts to the latest time value that will probably
> > cause the properties to show up as modified in the status output, I
> > don't think that useful.
> >
> > I suspect that merge should add/delete the property but
> should never
> > change its value.
>
> Say someone makes a branch to add a new feature, BranchA, the
> someone changes trunk/Whatever. If the branch is long lived
> then the trunk merge in Whatever will get merged into BranchA
> and commited. This would create a new revision with a changed
> time in file Whatever in BranchA. Now, once BranchA's
> Whatever gets merged back into the trunk, it will have a
> newer timestamp than the trunk version. Keeping the latest
> would cause you to show a changed timestamp, but no
> corresponding contents change. (That was probably more to
> make sure I'm talking about the same thing, than explaining).
>
> One of the common use cases for this type of functionality is
> using rsync or some external tool to update an external copy
> of the data(e.g. a web site) using rsync or some other
> external tool. If the change in the branch was small, but a
> lot of changes were merged from the trunk, then this would
> cause a huge update and force all those unchanged files to be
> sent up the pipeline.
I don't get it. Why would files get different timestamps without any
modifications in this scenario? On the contrary, I'd say that the current
default behavior of Subversion would cause such problems, but the proposed
design would solve them.
As long as we stay away from unusual scenarios with manual changes to just
the file system or repository timestamps, the true preservation of timetamps
in the repository will ensure that such things such as timestamp based sync
actually does work as intended.
Or are you arguing for the case of preserving file system timestamps for
this very reason? Sorry, I must be dense and it's getting far to late....
I'll check in on this thread tomorrow...
Svante
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 19 23:35:31 2005