Joshua Varner <email@example.com> writes:
> On 8/19/05, Philip Martin <firstname.lastname@example.org> wrote:
>> "Svante Seleborg" <email@example.com> writes:
>> > (snip)
>> >> >> Merge is likely to cause conflicts in the new properties, is that
>> >> >> acceptable? Should Subversion automatically "resolve"
>> >> >> such conflicts?
>> >> >
>> >> > Conflict is naturally resolved by having the latest win.
>> >> I suspect the conflicts should be resolved, I'm not sure that
>> >> the latest is the natural choice.
>> > 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
I don't think you understand how it works.
Merge changes the text of files, it also changes the timestamps of
those files. That's the timestamp on the physical filesystem, not the
When the merge is committed the physical timestamp value gets written
into the timestamp property, it makes no difference whether the
timestamp property was modified or unmodified. After the commit the
pysical timestamp and the timestamp property value are the
same. (Things get a little complicated if the commit has to rewrite
the file, for keyword expansion say, since that can only happen after
the commit has completed, so the files physical timestamp will have to
be reset to match the timestamp property value.)
The question that remains unaswered is how does merge affect the
timestamp property values. If treated as a simple property the three
values will probably generate a property conflict. That seems
undesirable since it would mean that most files that get merged end up
Another option is that the property is "magic" and the value gets
changed, but does not produce a conflict. That also seems undesirable
since it would mean that most files that get merged end up with
Another option is that the property is "magic" and the value doesn't
get changed, only adds/deletes get through. Then the merge looks like
a normal modification, no conflicts or property modifications show up,
the physical timestamp gets recorded at the next commit, the usual
timestamp difference detection (whatever that is) works, etc. A
varinat is that the property is "magic" and property modifications are
ignored. Then merge can change the value and so long as a conflict is
not generated things work well.
> 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 see how that helps answer the question about the value of
timestamp properties after a merge.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Aug 19 23:50:36 2005