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

Betr.: Re: Betr.: how to avoid text and tree conflict

From: Jan Keirse <jan.keirse_at_tvh.be>
Date: Mon, 4 Apr 2011 17:37:19 +0200

su heng <ste.suheng_at_gmail.com> schreef op 04/04/2011 16:31:17:

> Hi Jan,
> Please kindly refer to my below comments.
> Regards,
> Su Heng
> On Mon, 2011-04-04 at 16:03 +0200, Jan Keirse wrote:
> > su heng <ste.suheng_at_gmail.com> schreef op 04/04/2011 15:41:38:
> >
> > > Hi,
> > >
> > > I read the SVN book, as there are three type conflicts: text, tree
> > > properties conflict. However, I wanna know why it is a conflict. For
> > > example, if there is a text conflict when I do merging code, I just
> > > there is an conflict but don't know why it is a conflict.
> > >
> > > So could u provide me some resource or hints what are the judge
> > > for SVN to address it is a conflict, in this case, I can avoid more
> > > conflict when I'm coding or merging. I concert the text and tree
> > > conflict more.
> > >
> >
> > Start version is A. B and C are changes to A.
> > Change B says line 3 is 'cool!'
> > Change C says line 3 is 'boring!'
> > If you want to merge change B and C there's a conflict, because one
> > says the opposite of the other.
> [suheng] : thanks, However, your example just covers one condition. Can
> you give me a basic conflict rule policy of SVN so I can conclude all
> conditions?
> As your example, can I thought whenever a low revision(C) merge to a
> high revision(when B merge to A, A will be A+1), a text conflict will be
> pop up whatever the line is changed?
> In your example, the precondition is file a is revision A, then the
> same file under change B is revision B = A + n(n>0), and same file under
> change C is revision C = B + n(n>0), when change B is merged to A, we
> must commit it firstly(at this time revision A will be rise to A+n > B
> && A+n > C, then do another merge I mean change C will be merged in A+n,
> then conflict out.
> I think if C is a branch of from revision B+n(n>1) but not A, when we
> merge C+n(n>1) won't involve conflict, right?
> Hmm...I think it has little confusing. you can ignore my explain, just
> suggest me the basic conflict policy is appreciated.^_^

Ok, you misunderstood, C has nothing to do with B, it does not come after
B. As a general rule: if you changed the same line there is a conflict.

I'll put it another way.
Imagine at some point velkswagen makes a car, and stores the information
about that car in a file, named possat.txt.
The file could have the following contents:


Now at some point VW decides there possat can be sold with another logo as
skida octevia. So they branch the file:

And the file becomes:

After a few more years they decide to sell the same car under the siat



Now a clever engineer at siat notices that a car does not have 4 tires but
5, in case you hit a nail along the road you get an extra one in the trunk
to get you home. So he changes tires to 5.
Now we have 3 files, possat, somesiat and octevia. They all share the same
origin, the possat is long out of production so we don't care about that
anymore, but we want the octevia fixed.
If you merge from somesiat to octevia, with the possat as mutual ancestor,
you're going to get a problem, not with the tires but with the brand and
model, because somesiat changed brand and model but octevia did as well,
who holds the truth, what brand and model should be in the octevia file?

Kind Regards,

ICT-AFDELING • software quality & systems • software engineer

**** DISCLAIMER ****


"This message is delivered to all addressees subject to the conditions
set forth in the attached disclaimer, which is an integral part of this
Received on 2011-04-04 17:37:50 CEST

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

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