On 8/19/05, Svante Seleborg <svante@axantum.com> wrote:
> (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...
>
You asked for a case where keeping the latest property value would be bad.
There were two copies of the file with identical timestamps, then the one on
the trunk is changed causing its timestamp to update. This change is then
merged into the branch causing that file to change and its timestamp to
update. However, when merged back into the trunk the two files are identical
except for the timestamps.
In the current case nothing is done since the timestamp is ignored, but if it
is being preserved then there is a "conflict" since the two values
differ. In the
use case I describe you would want the earlier (not latest) version of the time
stamp b/c you are concerned with changes to the content.
Yes the obvious thing is to keep the older one, but this is not specified in
your design, that's the only issue. If the consensus is to keep the older
one, then that's fine it just needs to be explicit in the design. It's not an
argument for or against the feature, just a design detail that should be
resolved prior to implementation.
Josh
---------------------------------------------------------------------
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:52:44 2005