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.
"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
Received on Sun Dec 9 13:59:11 2007