On 8/19/05, Philip Martin <philip@codematters.co.uk> wrote:
> "Svante Seleborg" <svante@axantum.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
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.
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:18:05 2005