(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.
No, the timestamps are identical.
Someone updates a working copy, and commits to the trunk. This working copy
and the trunks metadata timestamp are now identical.
The change is merged into the branch, causing that file to change and it's
timstamp updated to the the same value as the other representations of the
file. The same timestamp is now present in three places - all identical.
>
> 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.
I think the problem here is that you think that repository-driven changes to
the file should be represented by it's time in the timestamp. That's the
whole problem here, the timestamp should reflect what happens in the working
copies - just like the contents. Otherwise we get to the recursive resoning
that since the repository action has changed the file, we updated the
timestamp, but that update changed the file, so we update the timestamp, but
that updadate changed the file, so we updated...
Just as keyword expansion is a repository action that should not be
reflected in the timestamp (i.e. if I modify a file, and then commit it, the
timestamp both in the repository and the file system should reflect the time
that I did the modification on the working copy - not when the repository
did it's thing), other actions in the repository should not create a "new"
timestamp.
That's why I say latest wins in the case of conflict. Person A and person B
both have a working copy. Person A edits the file. Person B edits the file
and commits. Person A commits the same file and the conflict is resolved.
The timestamp now reflects the time Person B edited the file in all three
places.
>
> 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 Sat Aug 20 10:41:10 2005