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

Re: Stop creating mergeinfo on COPY (was: Problems reintegrating the issue-2843-dev branch)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 12 Nov 2008 09:59:58 -0500

Mark Phippard wrote:
> On Fri, Nov 7, 2008 at 7:10 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>> Stopping all the WC-to-WC production of needless explicit mergeinfo
>> would go a longggg way to avoiding this, but that doesn't help those
>> (including us) with lots of historical subtree mergeinfo. More and
>> more I think that copy and move (all, not just WC-to-WC) should never
>> produce mergeinfo on the destination *unless* the source has it. It
>> can't be worse than what we deal with now...
> I propose we just do this ... now. Let's just rip this code out of WC
> to WC copy. Do not create mergeinfo when copying stuff. Forget about
> making it smarter, let's just stop doing it. The problems we have
> created by doing this are far worse than the theoretical problems we
> could prevent by getting it right.
> Ripping this out will make our product better now and reduce user
> frustration. If the theoretical problems turn into real problems and
> if someone is motivated enough to put this code back then they can do
> so in a way that gets it right.
> Let's stop the madness. If this one feature had not been put into
> 1.5, then most of the problems relating to mergeinfo handling we
> complain about would not even exist.

At the risk of having you show up on my doorstep in a few hours wielding a
battle axe, I'd suggest:

   1. making 'svn copy WC WC' be mergeinfo-ignorant,
   2. having that type of invocation print a warning about the fact
      that mergeinfo wasn't honored, and
   3. add -g as the flag to calculate mergeinfo *with full repository

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-11-12 16:00:08 CET

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.