Mark Phippard wrote:
> On Dec 7, 2007 5:04 AM, Kamesh Jayachandran <kamesh@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
Received on Fri Dec 7 15:27:33 2007