[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Useless explicit mergeinfo records

From: Danil Shopyrin <danil_at_visualsvn.com>
Date: Wed, 3 Sep 2008 16:08:47 +0400

> How could merge tracking be merge tracking if it does not do this? It
> has to scan the working copy to find out if you have any subtree
> mergeinfo.

I don't agree. The authz-blocked path isn't somehow touched in the
merging branch and it's surprising behavior when the user-visible
properties of the file are changed. And it's unacceptable that commit
is blocked because of this.

As stated in $/www/merge-tracking/summit.html:
[[
...Users are often very average developers/maintenance programmers.
]]
(I agree with that statement). The discussed behavior isn't a critical
problem for an experienced developer but it can be critical for a
junior. And merge tracking supposed to simplify things for juniors.

> I do not think it makes sense to try and change this. If we really
> implement a new WC, this checking will become trivial as it will no
> longer be crawling the WC to find this information. That seems like a
> better solution given that the code is working as intended.

From my point of view, the whole Subversion usability is seriously
damaged since merge tracking was released in 1.5. I work with
Subversion for several years and I was really disappointed by released
behavior (and most of my friends too). Looks like a big broken window.

That's why I think it's a good job to make merge tracking better in 1.5.x.

--
With best regards,
Danil Shopyrin
VisualSVN Team
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-03 14:09:04 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.