You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kamesh Jayachandran <ka...@collab.net> on 2007/12/07 10:04:52 UTC
Summary of discussions that occured on issue 2897 -Part 1
Hi All,
First of all my sorry for not able to cope up with flood of emails on
this issue 2897.
Mark has posted this email
http://svn.haxx.se/dev/archive-2007-11/0729.shtml asking for
clarifications on 2897.
He considered 3 classes of problems
a)synch up merge from /trunk to feature branch + conflict resolution +
committed at rX
When we merge feature branch back to /trunk will conflict resolution
be lost?
My Answer: Yes, as of now in issue-2897 branch, I am working on
extracting 'conflict resolution changes'.
I term the solution to the problem 'merge *non-reflected* changes from a
*reflective* revision'.
Consider we have 2 feature branches FB1 and FB2
FB1 has merged rS from /trunk and committed at rX
FB2 has merged rS from /trunk and committed at rY1
FB2 has merged rT from /trunk and committed at rY2
b) MERGE /FB2 to /FB1 and committed in rZ, Will this merge consider rY1
as *indirect* repeat merge or rX?
No. I hope it is not the goal of issue-2897 atleast as of now.
c)Will MERGE /FB1 to /trunk consider rZ as reflective REV?
Yes. It considers merges on /FB2 as a merges on /FB1 due to implicit
property merges on rZ. Still there exists one problem which I can
attribute to 'merge *non-reflected* changes from a *reflective*'.
As of today in issue-2897@28322 branch we filter rZ too and hence we
loose /FB2 *only* changes.
'merge_non_reflective_changes_from_reflective_rev' testcase in
'merge_tests.py'@issue-2897 branch deals with it.
There were other threads few of them I sparsely looked at and they went
over my head.
As of now all I can say is that there exists a problem 'merge
*non-reflected* changes from a *reflective*' that need to be fixed to
fix a) and c).
I will post one more summary after going through the posts of Folker
especially his concerns over branchA->branchB->branchC'.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Summary of discussions that occured on issue 2897 -Part 1
Posted by Kamesh Jayachandran <ka...@collab.net>.
Mark Phippard wrote:
> On Dec 7, 2007 5:04 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
>
>
>> There were other threads few of them I sparsely looked at and they went
>> over my head.
>>
>> As of now all I can say is that there exists a problem 'merge
>> *non-reflected* changes from a *reflective*' that need to be fixed to
>> fix a) and c).
>>
>> I will post one more summary after going through the posts of Folker
>> especially his concerns over branchA->branchB->branchC'.
>>
>
> I think what we would like to see is an attempt to explain how you
> plan to approach fixing the problem. There have been two general
> ideas floated:
>
> 1) When committing a merge, figure out a way to turn it into 2
> revisions. The clean merge, and the conflict resolution. We would
> then just need to filter out the revision for the merge.
>
> 2) Do some kind of complex delta calculations to determine what part
> of a merge is unique and not a part of the merge itself -- the
> conflict resolution.
>
> I think it is pretty clear that you are going for #2, which is
> probably the best way to do this. That being said, it is viewed as
> pretty difficult. What ideas do you have for doing this?
>
>
Yes I am for #2.
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=133322
details my approach.
I am working on 'get-commit-revs' API to fit to the above idea, may be I
might have to rework on it a bit again to take care of the cases
'Folker' raised. I would like to step by step.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Summary of discussions that occured on issue 2897 -Part 1
Posted by Folker Schamel <sc...@spinor.com>.
Mark Phippard wrote:
> On Dec 7, 2007 5:04 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
>
>> There were other threads few of them I sparsely looked at and they went
>> over my head.
>>
>> As of now all I can say is that there exists a problem 'merge
>> *non-reflected* changes from a *reflective*' that need to be fixed to
>> fix a) and c).
>>
>> I will post one more summary after going through the posts of Folker
>> especially his concerns over branchA->branchB->branchC'.
>
> I think what we would like to see is an attempt to explain how you
> plan to approach fixing the problem. There have been two general
> ideas floated:
>
> 1) When committing a merge, figure out a way to turn it into 2
> revisions. The clean merge, and the conflict resolution. We would
> then just need to filter out the revision for the merge.
"We would then just need to ..."
- sorry for repeating myself, but this does not work, see
http://svn.haxx.se/dev/archive-2007-12/0134.shtml
Cheers,
Folker
>
> 2) Do some kind of complex delta calculations to determine what part
> of a merge is unique and not a part of the merge itself -- the
> conflict resolution.
>
> I think it is pretty clear that you are going for #2, which is
> probably the best way to do this. That being said, it is viewed as
> pretty difficult. What ideas do you have for doing this?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Summary of discussions that occured on issue 2897 -Part 1
Posted by Mark Phippard <ma...@gmail.com>.
On Dec 7, 2007 5:04 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
> There were other threads few of them I sparsely looked at and they went
> over my head.
>
> As of now all I can say is that there exists a problem 'merge
> *non-reflected* changes from a *reflective*' that need to be fixed to
> fix a) and c).
>
> I will post one more summary after going through the posts of Folker
> especially his concerns over branchA->branchB->branchC'.
I think what we would like to see is an attempt to explain how you
plan to approach fixing the problem. There have been two general
ideas floated:
1) When committing a merge, figure out a way to turn it into 2
revisions. The clean merge, and the conflict resolution. We would
then just need to filter out the revision for the merge.
2) Do some kind of complex delta calculations to determine what part
of a merge is unique and not a part of the merge itself -- the
conflict resolution.
I think it is pretty clear that you are going for #2, which is
probably the best way to do this. That being said, it is viewed as
pretty difficult. What ideas do you have for doing this?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org