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

Re: tree conflicts with replace

From: Mark Phippard <markphip_at_gmail.com>
Date: Sat, 15 Aug 2009 11:18:43 -0400

On Sat, Aug 15, 2009 at 10:40 AM, Stefan Sperling<stsp_at_elego.de> wrote:
>> What are we discussing, again?
> I don't know. I just stumbled into this discussion because for some
> reason what I read here made me realise that the above problem exists.
> When people hit this, and don't understand how the mergeinfo stuff
> and 'svn revert' work, they will probably not realise that the real
> problem is that they don't understand enough of the internal workings
> of the tool and lack the corresponding insights into the tool's limitations
> to be capable of dealing with the limitation they just hit.
> And then they will [rightfully] blame Subversion for the problem,
> i.e. they will blame us for not having fixed this limitation.

I do not buy into this at all. There is no question that revert
should also remove any mergeinfo changes on the target. If it didn't,
then that would mean you could not revert ANY merge.

I also fail to see how this is confusing. If your normal merge patten
is to merge all unmerged revisions (which is the basic scenario you
are describing), then it makes perfect sense that you would need to
use --record-only if there is a revision that you need to revert but
do not want to keep merging in the future. I do not see any signs
that users are confused by this part of merge.

Mark Phippard
Received on 2009-08-15 17:19:19 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.