On 05/28/2010 09:33 AM, Johan Corveleyn wrote:
Please don't reduce the issue of "rename tracking" (or whatever you
want to call it) to merging. It's just as relevant for updating (cf.
tree conflicts of "local edit, incoming delete" and "local delete,
incoming edit", etc., which you can just as easily get with a normal
update). When there is proper rename tracking, I fully expect these
kinds of tree conflicts to be resolvable automatically (most of the
time). Whether it's a merge or a regular update.
Unless you consider an update a special kind of merge. However, I
don't think that's the case in the mind of users (at least in my head,
as a user, the two are quite different, I use them in totally
different contexts). That's why I think "Branch-relative renames" is
not such a good term. It couples the rename issue to
branching/merging... It's more than that.
It may depend on the user. For myself, any 3-way merge (or better) that
takes changes on one side and applies them to the other, is a merge. The
"svn update" operation is by definition a merge, as it takes the changes
made in the repository and applies it against the changes made in the
workspace.
I have noticed that Subversion merge capabilities seem slightly
different between "merge to workspace" and "merge to branch". Note,
though, that this difference perplexed and confused me. Why should "svn
update" be smarter or not as smart as "svn merge" when presented with
the same amount of merge context, the same "base version", the same
resulting context for a "source version", and the same resulting context
for a "target version". I recall playing with what most people here are
calling "tree conflicts", and I stumbled upon a situation that work fine
with "svn update", but then failed with "svn merge". Augh! :-)
In any case - you can define it however you wish - but as a user, I
expect "rename commit plus file content commit" to be equally mergeable
to both another branch and the local workspace. One day. :-)
Thanks,
mark
--
Mark Mielke<m...@mielke.cc>
