You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2016/02/22 18:23:56 UTC
merging adjacent changes
"Bert Huijben" <be...@qqmail.nl> writes:
> Personally I agree that I would like to see a text-conflict raised in
> this specific case where the change regions touch each other. But then
> there is that old discussion, ....
I added the test because we had already, perhaps inadvertently,
implemented the behaviour.
Back in 2003 we didn't have 'svn resolve' so resolving a text conflict
required the user to edit the file. Now we have 'svn resolved' which
may make resolving text conflicts easier. Perhaps that allows us to
change Subversion to create more conflicts?
We know merge is essentially imperfect or fuzzy, the question is where
to draw the line. Which, if any, of these cases should merge without
conflict and what should the merged result be?
1. common first second
ancestor branch branch
A A A
B Bbr1 B
C C Cbr2
D D D
2. common first second
ancestor branch branch
A A A
B Bbr1 B
C new new
D C C
D D
3. common first second
ancestor branch branch
A A A
B Bbr1 B
C new new
D C Cbr2
D D
4. common first second
ancestor branch branch
A A A
B Bbr1 B
C newbr1 newbr2
D C Cbr2
D D
There are probably more cases.
--
Philip Martin
WANdisco
RE: merging adjacent changes
Posted by Michal Matyl <Mi...@zf.com>.
Hello,
Thanks for paying attention to this. Unfortunately I can't submit new item in SVN's JIRA. Apart from discussion raised by my example can someone please fill an issue for this ? It's already identified by Daniel as a bug. Per his suggestion I have also rewritten the example into Win batch script.
Regards
Michal
-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com]
Sent: Monday, February 22, 2016 6:24 PM
To: Bert Huijben
Cc: 'Daniel Shahaf'; 'Michal Matyl'; dev@subversion.apache.org; jcorvel@apache.org; philip@apache.org
Subject: merging adjacent changes
"Bert Huijben" <be...@qqmail.nl> writes:
> Personally I agree that I would like to see a text-conflict raised in
> this specific case where the change regions touch each other. But then
> there is that old discussion, ....
I added the test because we had already, perhaps inadvertently, implemented the behaviour.
Back in 2003 we didn't have 'svn resolve' so resolving a text conflict required the user to edit the file. Now we have 'svn resolved' which may make resolving text conflicts easier. Perhaps that allows us to change Subversion to create more conflicts?
We know merge is essentially imperfect or fuzzy, the question is where to draw the line. Which, if any, of these cases should merge without conflict and what should the merged result be?
1. common first second
ancestor branch branch
A A A
B Bbr1 B
C C Cbr2
D D D
2. common first second
ancestor branch branch
A A A
B Bbr1 B
C new new
D C C
D D
3. common first second
ancestor branch branch
A A A
B Bbr1 B
C new new
D C Cbr2
D D
4. common first second
ancestor branch branch
A A A
B Bbr1 B
C newbr1 newbr2
D C Cbr2
D D
There are probably more cases.
--
Philip Martin
WANdisco