[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Summary of discussions that occured on issue 2897 -Part 1

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2007-12-07 15:27:40 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.