su heng <ste.suh...@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.suh...@gmail.com> schreef op 04/04/2011 15:41:38:
> >
> > > Hi,
> > >
> > > I read the SVN book, as there are three type conflicts: text, tree
and
> > > 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
know
> > > 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
rules
> > > 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
change
> > 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:
---------------
brand=vw
model=possat
tires=4
engine=1900
horsepower=110
---------------
Now at some point VW decides there possat can be sold with another logo as
skida octevia. So they branch the file:
octevia
/
possat
And the file becomes:
---------------
brand=skida
model=octevia
tires=4
engine=1900
horsepower=110
---------------
After a few more years they decide to sell the same car under the siat
Brand:
octevia
/
possat
\
somesiat
---------------
brand=siat
model=somesiat
tires=4
engine=1900
horsepower=110
---------------
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,
JAN KEIRSE
ICT-AFDELING • software quality & systems • software engineer
**** DISCLAIMER ****
http://www.tvh.com/newen2/emaildisclaimer/default.html
"This message is delivered to all addressees subject to the conditions
set forth in the attached disclaimer, which is an integral part of this
message."
