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

Re: [BUG] Data loss when committing a new file which is a target of multiple merges

From: Lieven Govaerts <lgo_at_mobsol.be>
Date: 2006-07-12 20:13:51 CEST

Daniel Rall wrote:
> On Wed, 12 Jul 2006, Lieven Govaerts wrote:
>> Philip Martin wrote:
>>> The copyfrom revision is more of a problem. I suppose the ranges A:B
>>> and B:C could combine to give A:C, but what about A:B and C:D when
>>> B!=C and none of the revisions between B:C affect the target? What if
>>> C<B but none of the duplicate revisions affect the target? If we do
>>> decide to update the copyfrom data it's not as simple as just updating
>>> the revision, the text-base will also need to be updated
>> Can you give me a (high-level) scenario and which the user experiences
>> this problem?
> The "Steps to reproduce" in my original mail describes the specific
> steps. Given Philip's findings, in practice this problem would only
> be triggered by by a programmatic operation, likely some type of
> quickly-executing VC/SCM automation which doesn't do any range
> combining when applying merges to a WC (e.g. automated merging for an
> integration branch).
While my test passes on my machine (it's probably slow enough) I also
see that the copyfrom revision is filled in incorrectly. So my question
is, given the fact that the copyfrom revision is filled in incorrectly,
what problems can this give for the user? That way I can add such a
problem scenario to the test, mark it as XFAIL and commit it to the


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 12 20:13:50 2006

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.