You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by su heng <st...@gmail.com> on 2011/04/04 15:41:38 UTC
how to avoid text and tree conflict
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.
Regards,
Su Heng
--
QQ : 49757862
MSN: suh.steven@hotmail.com
Mobile: (0512)60780554
RE: how to avoid text and tree conflict
Posted by Bob Archer <Bo...@amsi.com>.
> On Mon, 2011-04-04 at 10:26 -0400, Bob Archer wrote:
> > > 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.
> >
> > It is a conflict because two people changed the same line of
> code. So, the software can't know which line of code you want to
> remain after it merges them... you have to tell it. You could
> choose one line, the other line, or even combine them in some way.
> >
> > BOb
> >
> >
> >
> > >
> > > 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.
> > >
> > > Regards,
> > > Su Heng
> > >
> > > --
> > > QQ : 49757862
> > > MSN: suh.steven@hotmail.com
> > > Mobile: (0512)60780554
> > >
> >
>
> Hi Bob,
>
> What about different lines?
> trunk file node@r1
> node:
> -----
> line1
> -----
>
> create branch node1(node@r2), node2(node@r3)
>
> edit node@r2 under branch node1
> -----
> line1
> line2
> -----
> submit and get node@r3
>
> edit node@r3 under branch node2
> -----
> line1
>
> line3
> -----
> submit and get node@r4
>
> edit node@r1(or merge branch node1) under trunk
> -----
> line1
> line2
> -----
> submit and get node@r5
>
> finally, merge branch node2@r4 to trunk can get conflict.
>
> <<<<<<< .working
> line1
> line2=======
> line1
>
> line3>>>>>>> .merge-right.r4
>
>
> I though node2@r4 will be merged to node@r5 like this:
> -----
> line1
> line2
> line3
> -----
>
> but not.
>
Because...
...in the node1 branch you modified line2 making it read "line2".
...in the node2 branch you modified line2 making it "" and line 3 making it "line3"
When you try to bring these together svn is going to look at the base (r1) of each file. It is going to see that line2 is different from base in both the merge target and the merge source. It also sees that those changes are different. That is a conflict. svn doesn't know whether to use the "line2" content from node1 branch or the "" content from node2.
It may seem obvious to you that you don't want the blank like and you want it to say "line2"... but svn has no way to know this. Perhaps the blank line is what you want in the result.
BTW: This happens even in normal use... since an update it also essentially a merge.
Let's assume we have a file call it test.txt in a repository with the following lines:
line1
line2
line3
line4
We each have it checked out to our working copies.
I make a change to the file so it looks like this, and check it in:
line1
line3
line4
(I have blanked line2, well really it contains a line feed).
You make a change to the file so it looks like this:
line1
line2a
line3
line4
You try to commit and you get an error that it is out of date. So you do an update. svn sees that you changed line2 as did the latest HEAD version be comparing them to the common base. This is a conflict... a person has to resolve it. svn can just assume, oh a line with text is more important (or correct) than a line with just a line feed. And if it did do this you would not be very happy.
That all said, we have found in our day to day use of svn we rarely see conflicts like this.
Of course, the above is different than tree conflicts which occur for path change reasons rather than file content reasons.
BOb
RE: how to avoid text and tree conflict
Posted by su heng <st...@gmail.com>.
On Mon, 2011-04-04 at 10:26 -0400, Bob Archer wrote:
> > 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.
>
> It is a conflict because two people changed the same line of code. So, the software can't know which line of code you want to remain after it merges them... you have to tell it. You could choose one line, the other line, or even combine them in some way.
>
> BOb
>
>
>
> >
> > 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.
> >
> > Regards,
> > Su Heng
> >
> > --
> > QQ : 49757862
> > MSN: suh.steven@hotmail.com
> > Mobile: (0512)60780554
> >
>
Hi Bob,
What about different lines?
trunk file node@r1
node:
-----
line1
-----
create branch node1(node@r2), node2(node@r3)
edit node@r2 under branch node1
-----
line1
line2
-----
submit and get node@r3
edit node@r3 under branch node2
-----
line1
line3
-----
submit and get node@r4
edit node@r1(or merge branch node1) under trunk
-----
line1
line2
-----
submit and get node@r5
finally, merge branch node2@r4 to trunk can get conflict.
<<<<<<< .working
line1
line2=======
line1
line3>>>>>>> .merge-right.r4
I though node2@r4 will be merged to node@r5 like this:
-----
line1
line2
line3
-----
but not.
--
Regards,
Su Heng
MSN: suh.steven@hotmail.com
RE: how to avoid text and tree conflict
Posted by Bob Archer <Bo...@amsi.com>.
> 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.
It is a conflict because two people changed the same line of code. So, the software can't know which line of code you want to remain after it merges them... you have to tell it. You could choose one line, the other line, or even combine them in some way.
BOb
>
> 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.
>
> Regards,
> Su Heng
>
> --
> QQ : 49757862
> MSN: suh.steven@hotmail.com
> Mobile: (0512)60780554
>
Re: Betr.: Re: Betr.: how to avoid text and tree conflict
Posted by su heng <st...@gmail.com>.
On Mon, 2011-04-04 at 17:37 +0200, Jan Keirse wrote:
> su heng <st...@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 <st...@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."
Hi Jan,
I just try the example which you provided to me. Please refer to my
flow:
###############
step 1
submit one file possat:
--------------
brand=vw
model=possat
tires=4
engine=1900
horsepower=110
---------------
file name:possat(possat@r159)
################
step 2
create branch octevia(possat@r160) and somesiat(possat@r161) base on
file possat
################
step 3
change file possat under somesiat branch (possat@r161)
--------------------
brand=siat
model=somesiat
tires=4
engine=1900
horsepower=110
---------------------
and submit can get (possat@r162)
change file possat under octevia branch:
----------------
brand=skida
model=octevia
tires=4
engine=1900
horsepower=110
----------------
and submit can get (possat@r163)
######################
step 4
change possat under trunk(possat@r161)
--------------
brand=vw
model=possat
tires=5
engine=1900
horsepower=110
---------------
and submit can get (possat@r164)
Now, I switch to branch possat or octevia, do merge from trunk.
the line 'tires=5' will be merge automatically to my branch possat or
octevia.
Strange thing, if I switch to trunk do merge from possat or octevia,
brand line and model line will be automatically overwrite trunk's lines.
I'm using ecilpse + subeclipse. I will go to shell to verify the
correctness.
Regards,
Su Heng
--
QQ : 49757862
MSN: suh.steven@hotmail.com
Mobile: (0512)60780554
Betr.: Re: Betr.: how to avoid text and tree conflict
Posted by Jan Keirse <ja...@tvh.be>.
su heng <st...@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 <st...@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."
Re: Betr.: how to avoid text and tree conflict
Posted by su heng <st...@gmail.com>.
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 <st...@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.^_^
>
> Similar:
> Start filename is A .
> Change B says A should be renamed to B.
> Change C says A should be renamed to C.
> If you want to merge B and C what should the filename be? B or C?
[suheng] : thanks for your explain.
>
> 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."
>
--
QQ : 49757862
MSN: suh.steven@hotmail.com
Mobile: (0512)60780554
Betr.: how to avoid text and tree conflict
Posted by Jan Keirse <ja...@tvh.be>.
su heng <st...@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.
Similar:
Start filename is A .
Change B says A should be renamed to B.
Change C says A should be renamed to C.
If you want to merge B and C what should the filename be? B or C?
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."