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 2008/01/11 11:38:50 UTC
how issue-2897 branch solves reflective merges?
Hi All,
Let me summarize the changes in issue-2897 branch.
I would love to get some real technical reasons for not accepting 2897
for 1.5 rather than '*it is complex*'.
Yes it was complex when I started and while working on it at times. Now
I see no complexity.
I would love to see real technical problem that justifies that it can
not get in to 1.5.
For those interested to review it, following explanation should help.
1)Implement 'get-commit-and-merge-ranges' API in all layers (40% of the
change)
2)Write the testcases (30-35% change)
3)Extract non-reflective changes from a reflective revision, pure
libsvn_client change (25-30%)
To review item 1) Major focus need to be in
subversion/libsvn_fs_util/mergeinfo-sqlite-index.c,
rest of the other functions at every level is just a wrapper over this
core implementation.
Item 2)Testcases: covers almost all the cases I can imagine, it covers
all reflective callbacks.
Item 3) libsvn_client is very tricky to understand but logic is simple
as described below,
a) Identify reflective revision and merge that reflective revision
alone with reflective callbacks.
b) Let me explain each callback.
i) file_changed callback
reflective_merge_file_changed(mine, older, yours)
mine = WC file.
older = file@reflective_rev-1
yours = file@reflective_rev
Normal merge_file_changed applies diff(older, yours) to mine.
This diff can contain the changes 'synch up from trunk' as well as the
local adhoc changes and conflict resolutions.
Applying the diff directly is going to cause lots of headaches.
So objective is to have a meaningful diff of *only local adhoc changes
done before committing the merge*.
Let me take the example and explain,
Case1:
We merge -r13, -r17, -r29 from /trunk to /feature_branch and commit at
r40 (Assume this is the only synch up)
Now we merge /feature_branch -r1:40 back to /trunk.
It does a merge of -r1:39 which is a normal merge.
It does a reflective merge of 40.
Let us say /feature_branch/test.c got a change from a merge at r40(Our
first merge)
To calculate the *meaningful diff*, We apply -r13 change to OLDER, and
r17 change to OLDER, r29 change to OLDER.
Now in this case after the above 3 merges(r13, r17, r29) OLDER becomes
YOURS and hence no change is applied to MINE.
Case2:
We merge -r13, -r17, -r29 from /trunk to /feature_branch + local
non-conflicting change to /feature_branch/test.c and commit at r40
(Assume this is the only synch up)
Now we merge /feature_branch -r1:40 back to /trunk.
It does a merge of -r1:39 which is a normal merge.
It does a reflective merge of 40.
Let us say /feature_branch/test.c got a change from a merge at r40(Our
first merge)
To calculate the *meaningful diff*, We apply -r13 change to OLDER, and
r17 change to OLDER, r29 change to OLDER.
Now in this case after the above 3 merges(r13, r17, r29) OLDER becomes
(YOURS-local non conflicting changes) and hence
(YOURS-YOURS +local non conflicting changes) is applied to MINE. i.e
local non conflicting changes
Case3:
We merge -r13, -r17(conflicting), -r29 from /trunk to /feature_branch +
local non-conflicting change + conflict resolution to r17 to
/feature_branch/test.c and commit at r40
(Assume this is the only synch up)
Now we merge /feature_branch -r1:40 back to /trunk.
It does a merge of -r1:39 which is a normal merge.
It does a reflective merge of 40.
Let us say /feature_branch/test.c got a change from a merge at r40(Our
first merge)
To calculate the *meaningful diff*, We apply -r13 change to OLDER, and
r29 change to OLDER. (SEE WE DONT APPLY r17 as it is a conflicting one)/
Now in this case after the above 2 merges(r13, r29) OLDER becomes
(YOURS-local non conflicting changes - r17 - conflict resolution to r17)
and hence
(YOURS-YOURS +local non conflicting changes + r17 + conflict resolution
to r17) is applied to MINE. i.e local non conflicting changes + r17 +
conflict resolution to r17. Moral: If synch up gave a conflict reverse
also would give
ii)dir_added/dir_deleted/file_added/file_deleted.
Prior to a *reflective* merge drive we run 'diff summarize on
*reflected* ranges'.
Case 4:
We merge -r13, -r17, -r29 from /trunk to /feature_branch and commit at
r40 (Assume this is the only synch up)(merge adds test.c at r13, deletes
the same at r14)
Now we merge /feature_branch -r1:40 back to /trunk.
It does a merge of -r1:39 which is a normal merge.
It does a reflective merge of 40.
Our summary implementation won't care about 'test.c' as in effect A+D
= NO_CHANGE_COMMITTED and we won't get 'file_added' callback in this case.
Case 5:
We merge -r13, -r17, -r29 from /trunk to /feature_branch and commit at
r40 (Assume this is the only synch up)(merge adds test.c at r13, deletes
the same at r14, user adds adhoc 'test.c')
Now we merge /feature_branch -r1:40 back to /trunk.
It does a merge of -r1:39 which is a normal merge.
It does a reflective merge of 40.
Our summary implementation Would say nothing about 'test.c' as in
effect A+D = NO_CHANGE_COMMITTED.
But we get 'file_added' callback in this case due to local addition.
*SUMMARY IMPLEMENTATION* would help us in deciding whether to add the
file or not. (If there is *no* summary add the file or else leave it).
Same explanation applies to dir additions, file/dir deletions.
Would love to get more feedbacks on it.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how issue-2897 branch solves reflective merges?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Jan 11, 2008 8:39 AM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> The other question that I meant to ask is:
>
> What is blocking issue-2897 branch from being merged to trunk?
And you just answered that ? in your other post. Thanks. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how issue-2897 branch solves reflective merges?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Jan 21, 2008 2:07 PM, C. Michael Pilato <cm...@collab.net> wrote:
>> Mark Phippard wrote:
>>>> Node-origins in FSFS can be done by writing a single file for each node-id
>>>> which contains the origin value into a 'node-origins' subdirectory. We'd
>>>> probably want to shard that in some fashion -- we have around 5000 origins
>>>> to store for the Subversion source code repository today.
>>> If we have to create an object in the file system for every node in
>>> the repository is this potentially a problem waiting to happen? Are
>>> we going to be greatly increasing the size of the repository and the
>>> demands on the server file system? An svn import of thousands of
>>> files would have to create thousands of these items too right?
>> Greatly increasing repository size? Not likely. We're talking about a
>> mapping of node-ids (a single base36 number) to node-revision-ids (one of
>> those dotted triplet thingies).
>
> But suppose minimum file/block size is 4kb. 100k nodes would be 400MB
> of disk space added to the repository.
Well, I suppose that could be a problem. I mean, we could do other things
here -- for example, we could keep a maximum of 36 of these items at a time
in a file that used the same hash-on-disk format that the revprops items use
and was named NODE-ID[:-1]. Or we could use a fixed-record-size file named
the same way. Or ... there are lots of ways to do this.
>> And yes, an import of 2000 files/dirs would create 2000 of these records.
>> But if in the next commit you changed all 2000 of those things and
>> committed, no new records would be created -- they only show up for brand
>> new lines of history.
>
> I did grok that part. I assume tagging would not create new files either?
Right.
>>> Do we have an official goal to remove SQLite as a dependency now?
>> I'd certainly like to see it happen, but that's just my personal preference.
>
> Concerns about SQLite specifically? Just a desire to avoid
> dependencies? If we eventually need to add caches to the repository,
> it does not seem like a bad choice.
Fear of the unknown mixed with a desire to reduce dependencies. But those
are mild feelings -- I was fine with having SQLite in place until Glasser
decided that it wasn't going to cut it for the merge tracking stuff. With
that bit removed, we were left with no need at all for SQLite in BDB, and
only this silly little origins index in FSFS. Seems harsh to add a new
dependency for what is now just a trivial little index. But then, maybe
this is exactly the kind of thing SQLite is perfect for. *shrug* No strong
feelings here.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: how issue-2897 branch solves reflective merges?
Posted by Mark Phippard <ma...@gmail.com>.
On Jan 21, 2008 2:07 PM, C. Michael Pilato <cm...@collab.net> wrote:
> Mark Phippard wrote:
> >> Node-origins in FSFS can be done by writing a single file for each node-id
> >> which contains the origin value into a 'node-origins' subdirectory. We'd
> >> probably want to shard that in some fashion -- we have around 5000 origins
> >> to store for the Subversion source code repository today.
> >
> > If we have to create an object in the file system for every node in
> > the repository is this potentially a problem waiting to happen? Are
> > we going to be greatly increasing the size of the repository and the
> > demands on the server file system? An svn import of thousands of
> > files would have to create thousands of these items too right?
>
> Greatly increasing repository size? Not likely. We're talking about a
> mapping of node-ids (a single base36 number) to node-revision-ids (one of
> those dotted triplet thingies).
But suppose minimum file/block size is 4kb. 100k nodes would be 400MB
of disk space added to the repository.
> And yes, an import of 2000 files/dirs would create 2000 of these records.
> But if in the next commit you changed all 2000 of those things and
> committed, no new records would be created -- they only show up for brand
> new lines of history.
I did grok that part. I assume tagging would not create new files either?
> > Do we have an official goal to remove SQLite as a dependency now?
>
> I'd certainly like to see it happen, but that's just my personal preference.
Concerns about SQLite specifically? Just a desire to avoid
dependencies? If we eventually need to add caches to the repository,
it does not seem like a bad choice.
--
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
Re: how issue-2897 branch solves reflective merges?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
>> Node-origins in FSFS can be done by writing a single file for each node-id
>> which contains the origin value into a 'node-origins' subdirectory. We'd
>> probably want to shard that in some fashion -- we have around 5000 origins
>> to store for the Subversion source code repository today.
>
> If we have to create an object in the file system for every node in
> the repository is this potentially a problem waiting to happen? Are
> we going to be greatly increasing the size of the repository and the
> demands on the server file system? An svn import of thousands of
> files would have to create thousands of these items too right?
Greatly increasing repository size? Not likely. We're talking about a
mapping of node-ids (a single base36 number) to node-revision-ids (one of
those dotted triplet thingies).
And yes, an import of 2000 files/dirs would create 2000 of these records.
But if in the next commit you changed all 2000 of those things and
committed, no new records would be created -- they only show up for brand
new lines of history.
> Do we have an official goal to remove SQLite as a dependency now?
I'd certainly like to see it happen, but that's just my personal preference.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: how issue-2897 branch solves reflective merges?
Posted by Mark Phippard <ma...@gmail.com>.
On Jan 21, 2008 11:25 AM, C. Michael Pilato <cm...@collab.net> wrote:
>
> Mark Phippard wrote:
> > On Jan 21, 2008 10:20 AM, Mark Phippard <ma...@gmail.com> wrote:
> >> On Jan 11, 2008 2:45 PM, David Glasser <gl...@davidglasser.net> wrote:
> >>> My personal preference would be to merge reintegrate to trunk in the
> >>> very near future; then update issue-2897 based on that, then to (on
> >>> the 2897 branch) reimplement the FS API without SQLite (I'll do that),
> >>> while concurrently folks review Kamesh's libsvn_client changes (not
> >>> the backend, which as I said I'll rewrite). Then merge that back to
> >>> trunk, then remove the SQLite dependency (which also involves
> >>> rewriting the node origin cache on FSFS only, which will be very
> >>> easy... just store them as small files in a directory or something),
> >>> then BRANCH 1.5.
> >> This sounded like a good plan. How are we doing? Step 1 was to get
> >> reintegrate merged to trunk. What is left to do for that to happen?
> >>
> >> Also, are there any opportunities to divide this work up so that it is
> >> not all on your shoulders?
> >
> > Looking at your list again, it looks like a good item that could be
> > taken off your shoulders would be rewriting the node origins cache to
> > not use SQLite. Could you file an issue or post something to dev@
> > that describes how you would do it? Then maybe someone else could do
> > that while you are updating the issue-2897 branch?
>
> Node-origins in FSFS can be done by writing a single file for each node-id
> which contains the origin value into a 'node-origins' subdirectory. We'd
> probably want to shard that in some fashion -- we have around 5000 origins
> to store for the Subversion source code repository today.
If we have to create an object in the file system for every node in
the repository is this potentially a problem waiting to happen? Are
we going to be greatly increasing the size of the repository and the
demands on the server file system? An svn import of thousands of
files would have to create thousands of these items too right?
Do we have an official goal to remove SQLite as a dependency now?
--
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
Re: how issue-2897 branch solves reflective merges?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Jan 21, 2008 10:20 AM, Mark Phippard <ma...@gmail.com> wrote:
>> On Jan 11, 2008 2:45 PM, David Glasser <gl...@davidglasser.net> wrote:
>>> My personal preference would be to merge reintegrate to trunk in the
>>> very near future; then update issue-2897 based on that, then to (on
>>> the 2897 branch) reimplement the FS API without SQLite (I'll do that),
>>> while concurrently folks review Kamesh's libsvn_client changes (not
>>> the backend, which as I said I'll rewrite). Then merge that back to
>>> trunk, then remove the SQLite dependency (which also involves
>>> rewriting the node origin cache on FSFS only, which will be very
>>> easy... just store them as small files in a directory or something),
>>> then BRANCH 1.5.
>> This sounded like a good plan. How are we doing? Step 1 was to get
>> reintegrate merged to trunk. What is left to do for that to happen?
>>
>> Also, are there any opportunities to divide this work up so that it is
>> not all on your shoulders?
>
> Looking at your list again, it looks like a good item that could be
> taken off your shoulders would be rewriting the node origins cache to
> not use SQLite. Could you file an issue or post something to dev@
> that describes how you would do it? Then maybe someone else could do
> that while you are updating the issue-2897 branch?
Node-origins in FSFS can be done by writing a single file for each node-id
which contains the origin value into a 'node-origins' subdirectory. We'd
probably want to shard that in some fashion -- we have around 5000 origins
to store for the Subversion source code repository today.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: how issue-2897 branch solves reflective merges?
Posted by Mark Phippard <ma...@gmail.com>.
On Jan 21, 2008 10:20 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Jan 11, 2008 2:45 PM, David Glasser <gl...@davidglasser.net> wrote:
> > My personal preference would be to merge reintegrate to trunk in the
> > very near future; then update issue-2897 based on that, then to (on
> > the 2897 branch) reimplement the FS API without SQLite (I'll do that),
> > while concurrently folks review Kamesh's libsvn_client changes (not
> > the backend, which as I said I'll rewrite). Then merge that back to
> > trunk, then remove the SQLite dependency (which also involves
> > rewriting the node origin cache on FSFS only, which will be very
> > easy... just store them as small files in a directory or something),
> > then BRANCH 1.5.
>
> This sounded like a good plan. How are we doing? Step 1 was to get
> reintegrate merged to trunk. What is left to do for that to happen?
>
> Also, are there any opportunities to divide this work up so that it is
> not all on your shoulders?
Looking at your list again, it looks like a good item that could be
taken off your shoulders would be rewriting the node origins cache to
not use SQLite. Could you file an issue or post something to dev@
that describes how you would do it? Then maybe someone else could do
that while you are updating the issue-2897 branch?
--
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
Re: how issue-2897 branch solves reflective merges?
Posted by Karl Fogel <kf...@red-bean.com>.
"Mark Phippard" <ma...@gmail.com> writes:
> This sounded like a good plan. How are we doing? Step 1 was to get
> reintegrate merged to trunk. What is left to do for that to happen?
Mainly this:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=134344
(There are some other todo items left, but I think we agreed that they
can be taken care of post-merge. So could this one, if absolutely
necessary, but I'd been hoping not to.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how issue-2897 branch solves reflective merges?
Posted by Mark Phippard <ma...@gmail.com>.
On Jan 11, 2008 2:45 PM, David Glasser <gl...@davidglasser.net> wrote:
> My personal preference would be to merge reintegrate to trunk in the
> very near future; then update issue-2897 based on that, then to (on
> the 2897 branch) reimplement the FS API without SQLite (I'll do that),
> while concurrently folks review Kamesh's libsvn_client changes (not
> the backend, which as I said I'll rewrite). Then merge that back to
> trunk, then remove the SQLite dependency (which also involves
> rewriting the node origin cache on FSFS only, which will be very
> easy... just store them as small files in a directory or something),
> then BRANCH 1.5.
This sounded like a good plan. How are we doing? Step 1 was to get
reintegrate merged to trunk. What is left to do for that to happen?
Also, are there any opportunities to divide this work up so that it is
not all on your shoulders?
--
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
Re: how issue-2897 branch solves reflective merges?
Posted by David Glasser <gl...@davidglasser.net>.
On Jan 12, 2008 4:34 AM, Karl Fogel <kf...@red-bean.com> wrote:
> David, I wanted -- honestly, I *really* wanted -- to finish writing a
> test for the mergeinfo-authz-check change on the reintegrate branch
> (the change you reviewed earlier, the one that's not committed yet),
> and then merge the branch. But I didn't, because I ran smack into
> issue #2712, which makes it hard to test authz on mergeinfo (at least
> over svnserve), and got sidetracked trying to fix it.
2712 is easily avoided by setting anon-access=none.
Really, I think we should just document that for svnserve, anon-access
> none is incompatible with path-based authz that makes any paths
unreadable. Or do a client-side solution.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how issue-2897 branch solves reflective merges?
Posted by Karl Fogel <kf...@red-bean.com>.
"David Glasser" <gl...@davidglasser.net> writes:
> My personal preference would be to merge reintegrate to trunk in the
> very near future; then update issue-2897 based on that, then to (on
> the 2897 branch) reimplement the FS API without SQLite (I'll do that),
> while concurrently folks review Kamesh's libsvn_client changes (not
> the backend, which as I said I'll rewrite). Then merge that back to
> trunk, then remove the SQLite dependency (which also involves
> rewriting the node origin cache on FSFS only, which will be very
> easy... just store them as small files in a directory or something),
> then BRANCH 1.5.
+1
David, I wanted -- honestly, I *really* wanted -- to finish writing a
test for the mergeinfo-authz-check change on the reintegrate branch
(the change you reviewed earlier, the one that's not committed yet),
and then merge the branch. But I didn't, because I ran smack into
issue #2712, which makes it hard to test authz on mergeinfo (at least
over svnserve), and got sidetracked trying to fix it.
Once again I'm driving tomorrow (I know it seems like I never stop,
but only two more days before I'm in NY), so I won't be online during
the day.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how issue-2897 branch solves reflective merges?
Posted by David Glasser <gl...@davidglasser.net>.
On Jan 11, 2008 11:39 AM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Jan 11, 2008 8:28 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
> > > Could we redo this to be FSFSy? Or does this require SQLite? -- justin
> > >
> > It uses sqlite.
>
> Thanks, but that wasn't quite the question I was asking. =)
>
> I'm not in favor of having SQLite as a dependency if at all possible,
> so let me rephrase the question:
>
> While the current implementation obviously uses SQLite, are the
> algorithms used dependent upon relational features only present in
> SQL? If not, then can we rewrite the algorithms using a flat-file
> index or something similar?
I believe I know how to support the backend from Kamesh's branch
(which may also help fix log -g) with only in-FS annotations, like on
the reintegrate branch.
> I'm not suggesting that you have to do that work before it gets merged
> to trunk, but I guess a number of us (hi dglasser) would like to
> remove SQLite if we can.
>
> The other question that I meant to ask is:
>
> What is blocking issue-2897 branch from being merged to trunk?
I would like there to be more review by people other than me. Kamesh
has done a lot of good work, but I've certainly found a number of
serious (since-fixed) issues, and I'd be surprised if I caught them
all.
My personal preference would be to merge reintegrate to trunk in the
very near future; then update issue-2897 based on that, then to (on
the 2897 branch) reimplement the FS API without SQLite (I'll do that),
while concurrently folks review Kamesh's libsvn_client changes (not
the backend, which as I said I'll rewrite). Then merge that back to
trunk, then remove the SQLite dependency (which also involves
rewriting the node origin cache on FSFS only, which will be very
easy... just store them as small files in a directory or something),
then BRANCH 1.5.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: how issue-2897 branch solves reflective merges?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Hi Justin,
-----Original Message-----
From: justin.erenkrantz@gmail.com on behalf of Justin Erenkrantz
Sent: Fri 1/11/2008 10:09 PM
To: Kamesh Jayachandran
>I'm not in favor of having SQLite as a dependency if at all possible,
>so let me rephrase the question:
Me too does not like it.
Just for your info we use sqlite for node-origins cache, So as a dependency it would still remain.
>While the current implementation obviously uses SQLite, are the
>algorithms used dependent upon relational features only present in
>SQL? If not, then can we rewrite the algorithms using a flat-file
>index or something similar?
Algorithms that does this reflective merge is purely client side and hence no interaction directly with sqlite.
>I'm not suggesting that you have to do that work before it gets merged
>to trunk, but I guess a number of us (hi dglasser) would like to
>remove SQLite if we can.
Yes I also would like to start working on it after this code finds its place in /trunk.
With regards
Kamesh Jayachandran
Re: how issue-2897 branch solves reflective merges?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Jan 11, 2008 8:28 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
> > Could we redo this to be FSFSy? Or does this require SQLite? -- justin
> >
> It uses sqlite.
Thanks, but that wasn't quite the question I was asking. =)
I'm not in favor of having SQLite as a dependency if at all possible,
so let me rephrase the question:
While the current implementation obviously uses SQLite, are the
algorithms used dependent upon relational features only present in
SQL? If not, then can we rewrite the algorithms using a flat-file
index or something similar?
I'm not suggesting that you have to do that work before it gets merged
to trunk, but I guess a number of us (hi dglasser) would like to
remove SQLite if we can.
The other question that I meant to ask is:
What is blocking issue-2897 branch from being merged to trunk?
Thanks. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how issue-2897 branch solves reflective merges?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Justin Erenkrantz wrote:
> On Jan 11, 2008 3:38 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
>
>> To review item 1) Major focus need to be in
>> subversion/libsvn_fs_util/mergeinfo-sqlite-index.c,
>> rest of the other functions at every level is just a wrapper over this
>> core implementation.
>>
>
> Could we redo this to be FSFSy? Or does this require SQLite? -- justin
>
>
It uses sqlite.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how issue-2897 branch solves reflective merges?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Jan 11, 2008 3:38 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
> To review item 1) Major focus need to be in
> subversion/libsvn_fs_util/mergeinfo-sqlite-index.c,
> rest of the other functions at every level is just a wrapper over this
> core implementation.
Could we redo this to be FSFSy? Or does this require SQLite? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how issue-2897 branch solves reflective merges?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Hi Folker,
>>
>> >It is possible. By doing suitable patch arithmetics.
>> >(For example by the algorithm which I posted some time ago.)
>>
>> >But of course, this does not mean that it must be supported
>> >in the next subversion release.
>>
>> Can you post a link to your algorithm?
>
> http://svn.haxx.se/dev/archive-2007-12/0137.shtml
> See also
> http://svn.haxx.se/dev/archive-2007-12/0139.shtml
> http://svn.haxx.se/dev/archive-2007-12/0185.shtml
>
> Cheers,
> Folker
>
I will think through it carefully and figure out how best to merge
conflict resolutions from /feature_branch to /trunk.
Thanks for the links.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how issue-2897 branch solves reflective merges?
Posted by Folker Schamel <sc...@spinor.com>.
Kamesh Jayachandran wrote:
> Hi Folker,
>
> >b) But when you have resolved conflicts when merging trunk into
> >feature-branch, then you have to do that conflict resolution again
> >when merging feature-trunk back to trunk
> >(except for the special case you mentioned "accepting MINE").
>
> >Is this correct?
>
> Yes. We can not do anything intelligent here as conflict resolution
> could be any arbitary change.
>
> Now I tend to think we can make conflict resolution to be unidirectional
> for 'accepting THEIRS' too on a line basis, but would require some
> amount of thought and coding.
>
> >> Yes. But not always, In one special case conflict is not bi-directional.
> >> That special case 'Resolving conflict by accepting MINE changes'.
> >>
> >> In other words this algorithm reduces the conflict not eliminate it
> >> fully which is impossible.
>
> >It is possible. By doing suitable patch arithmetics.
> >(For example by the algorithm which I posted some time ago.)
>
> >But of course, this does not mean that it must be supported
> >in the next subversion release.
>
> Can you post a link to your algorithm?
http://svn.haxx.se/dev/archive-2007-12/0137.shtml
See also
http://svn.haxx.se/dev/archive-2007-12/0139.shtml
http://svn.haxx.se/dev/archive-2007-12/0185.shtml
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: how issue-2897 branch solves reflective merges?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Hi Folker,
>b) But when you have resolved conflicts when merging trunk into
>feature-branch, then you have to do that conflict resolution again
>when merging feature-trunk back to trunk
>(except for the special case you mentioned "accepting MINE").
>Is this correct?
Yes. We can not do anything intelligent here as conflict resolution could be any arbitary change.
Now I tend to think we can make conflict resolution to be unidirectional for 'accepting THEIRS' too on a line basis, but would require some amount of thought and coding.
>> Yes. But not always, In one special case conflict is not bi-directional.
>> That special case 'Resolving conflict by accepting MINE changes'.
>>
>> In other words this algorithm reduces the conflict not eliminate it
>> fully which is impossible.
>It is possible. By doing suitable patch arithmetics.
>(For example by the algorithm which I posted some time ago.)
>But of course, this does not mean that it must be supported
>in the next subversion release.
Can you post a link to your algorithm?
With regards
Kamesh Jayachandran
Re: how issue-2897 branch solves reflective merges?
Posted by Folker Schamel <sc...@spinor.com>.
Hi Kamesh!
To summarize what 2897 can and what it cannot do:
a) 2897 is better than svnmerge, because,
when merging feature-branch back into trunk,
then it is able to correctly handle manual changes
which were committed together with merges
from trunk into feature-branch.
b) But when you have resolved conflicts when merging trunk into
feature-branch, then you have to do that conflict resolution again
when merging feature-trunk back to trunk
(except for the special case you mentioned "accepting MINE").
Is this correct?
Some additional comments below:
> Hi Folker,
>
> ...
>
> >In other words, Case3 results in a conflict?
>
>
> Yes.
>
>
> >In other words, if you merge changes from trunk into a feature branch
> >causing conflicts, and you have resolved these conflicts,
> >then you again have to resolve conflicts
> >when merging the feature branch back to trunk?
>
> Yes. But not always, In one special case conflict is not bi-directional.
> That special case 'Resolving conflict by accepting MINE changes'.
>
> In other words this algorithm reduces the conflict not eliminate it
> fully which is impossible.
It is possible. By doing suitable patch arithmetics.
(For example by the algorithm which I posted some time ago.)
But of course, this does not mean that it must be supported
in the next subversion release.
> >Regarding your overall approach,
> >is is my following analysis correct?
> >Your current approach indirectly implements patch arithmetic
> >(merging changes into OLDER effectively means substracting
> >changes for the final merge) as required for solving the issues, right?
>
>
> Yes.
>
>
> >However, since you don't care about the order of operations
> >in that "patch arithmetic" (and patch algebra obviously is
> non-commutative),
> >the limitation is that the user get problems if changes overlap
> >(as for example when merging from trunk to feature-branch
> >and resolving conflicts), right?
>
> Yes.
>
> >As consequence, it cannot handle the following scenario, right?
> >- Trunk has one file containing just one line "a".
> >- Branch is created from trunk.
> >- Branch changes manually "a" to "aa" and commits.
> >- Trunk changes manually "a" to "b" and commits.
> >- Trunk is merged (with merge-tracking, "a" -> "b") into branch
> (currently: "aa").
> >This gives a conflict. The conflict is resolved manually as "bb" and
> committed.
> >- Trunk changes manually "b" to "c" and commits.
> >- Trunk is merged (with merge-tracking, "b" -> "c") into branch
> (currently: "bb").
> >This gives a conflict. The conflict is resolved manually as "cc" and
> committed.
> >- Now we merge branch into a trunk wc.
> >Obviously the overall result of all these merges should be "cc",
> >since the feature branch is up-to-date with all work of trunk.
> >(This is scenario
> >http://svn.haxx.se/dev/archive-2007-12/0134.shtml
> >but without assuming implicit commits.)
>
> What you say is correct. But our textual merge is always line based not
> character based.
Yes, but this is only a simplified technical sample.
In real world, "a", "b", "aa" etc. represent overlapping
multi-line code blocks.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: how issue-2897 branch solves reflective merges?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Hi Folker,
>> We are not applying the r17, sorry if I worded it that way. Following
>> example should make this case clear.
>>
>> Consider the case
>> a. /trunk/test.c = 'line1\nline2\nline3'
>>
>> b. Create feature branch /feature_branch from /trunk
>>
>>
>> c. Modify /trunk/test.c line1 -> tline1 at r13
>>
>>
>> d. Modify /trunk/test.c line2 -> tline2 at r17
>>
>> e. Modify /trunk/test.c line3 -> tline3 at r29
>>
>> f. Modify /feature_branch/test.c line2 ->fbline2 commit at r30.
>>
>> g. merge /trunk r13 to /feature_branch working copy. NO COMMIT
>>
>> h. merge /trunk r17 to /feature_branch working copy. This would give
>> raise to a conflict resolve it by 'line2' being 'RESOLVED_LINE2'. NO COMMIT
>>
>> i. merge /trunk r29 to /feature_branch working copy. COMMIT at r40
>> (Reflective revision)
>>
>> j. merge /feature_branch to /trunk working copy.
>>
>> r40 is merged with reflective call back.
>>
>> reflective_merge_file_changed(mine, older, yours)
>>
>> mine = 'tline1\ntline2\ntline3'
>> older = 'line1\nfbline2\nline3'
>> yours = 'tline1\nRESOLVED_LINE2\ntline3'
>>
>>
>> After merging r13 older='tline1\nfbline2\nline3'
>> After merging r29 older='tline1\nfbline2\ntline3'
>>
>> diff(older, yours) = "@@ -1,3 +1,3 @@
>> tline1
>> -fbline2
>> +RESOLVED_LINE2
>> tline3"
>>
>> Which would give raise to a conflict as trunk does not have 'fbline2'.
>In other words, Case3 results in a conflict?
Yes.
>In other words, if you merge changes from trunk into a feature branch
>causing conflicts, and you have resolved these conflicts,
>then you again have to resolve conflicts
>when merging the feature branch back to trunk?
Yes. But not always, In one special case conflict is not bi-directional.
That special case 'Resolving conflict by accepting MINE changes'.
In other words this algorithm reduces the conflict not eliminate it fully which is impossible.
>Regarding your overall approach,
>is is my following analysis correct?
>Your current approach indirectly implements patch arithmetic
>(merging changes into OLDER effectively means substracting
>changes for the final merge) as required for solving the issues, right?
Yes.
>However, since you don't care about the order of operations
>in that "patch arithmetic" (and patch algebra obviously is non-commutative),
>the limitation is that the user get problems if changes overlap
>(as for example when merging from trunk to feature-branch
>and resolving conflicts), right?
Yes.
>As consequence, it cannot handle the following scenario, right?
>- Trunk has one file containing just one line "a".
>- Branch is created from trunk.
>- Branch changes manually "a" to "aa" and commits.
>- Trunk changes manually "a" to "b" and commits.
>- Trunk is merged (with merge-tracking, "a" -> "b") into branch (currently: "aa").
>This gives a conflict. The conflict is resolved manually as "bb" and committed.
>- Trunk changes manually "b" to "c" and commits.
>- Trunk is merged (with merge-tracking, "b" -> "c") into branch (currently: "bb").
>This gives a conflict. The conflict is resolved manually as "cc" and committed.
>- Now we merge branch into a trunk wc.
>Obviously the overall result of all these merges should be "cc",
>since the feature branch is up-to-date with all work of trunk.
>(This is scenario
>http://svn.haxx.se/dev/archive-2007-12/0134.shtml
>but without assuming implicit commits.)
What you say is correct. But our textual merge is always line based not character based.
>(My post is not meant as critics. I know that merge-tracking is hard.
>I just want to understand what is supported and what not.)
You are welcome. I always liked your meticulous posts.
Thanks
With regards
Kamesh Jayachandran
Re: how issue-2897 branch solves reflective merges?
Posted by Folker Schamel <sc...@spinor.com>.
Hi Kamesh!
>>> Case3:
>>>
>>> We merge -r13, -r17(conflicting), -r29 from /trunk to /feature_branch
>>> + local non-conflicting change + conflict resolution to r17 to
>>> /feature_branch/test.c and commit at r40
>>> (Assume this is the only synch up)
>>>
>>> Now we merge /feature_branch -r1:40 back to /trunk.
>>>
>>> It does a merge of -r1:39 which is a normal merge.
>>> It does a reflective merge of 40.
>>> Let us say /feature_branch/test.c got a change from a merge at
>>> r40(Our first merge)
>>>
>>> To calculate the *meaningful diff*, We apply -r13 change to OLDER,
>>> and r29 change to OLDER. (SEE WE DONT APPLY r17 as it is a
>>> conflicting one)/
>>>
>>> Now in this case after the above 2 merges(r13, r29) OLDER becomes
>>> (YOURS-local non conflicting changes - r17 - conflict resolution to
>>> r17) and hence
>>> (YOURS-YOURS +local non conflicting changes + r17 + conflict
>>> resolution to r17) is applied to MINE. i.e local non conflicting
>>> changes + r17 + conflict resolution to r17.
>>
>> Isn't r17 already contained in MINE and now applied again?
>>
>> Cheers,
>> Folker
>>
>
> We are not applying the r17, sorry if I worded it that way. Following
> example should make this case clear.
>
> Consider the case
> a. /trunk/test.c = 'line1\nline2\nline3'
>
> b. Create feature branch /feature_branch from /trunk
>
>
> c. Modify /trunk/test.c line1 -> tline1 at r13
>
>
> d. Modify /trunk/test.c line2 -> tline2 at r17
>
> e. Modify /trunk/test.c line3 -> tline3 at r29
>
> f. Modify /feature_branch/test.c line2 ->fbline2 commit at r30.
>
> g. merge /trunk r13 to /feature_branch working copy. NO COMMIT
>
> h. merge /trunk r17 to /feature_branch working copy. This would give
> raise to a conflict resolve it by 'line2' being 'RESOLVED_LINE2'. NO COMMIT
>
> i. merge /trunk r29 to /feature_branch working copy. COMMIT at r40
> (Reflective revision)
>
> j. merge /feature_branch to /trunk working copy.
>
> r40 is merged with reflective call back.
>
> reflective_merge_file_changed(mine, older, yours)
>
> mine = 'tline1\ntline2\ntline3'
> older = 'line1\nfbline2\nline3'
> yours = 'tline1\nRESOLVED_LINE2\ntline3'
>
>
> After merging r13 older='tline1\nfbline2\nline3'
> After merging r29 older='tline1\nfbline2\ntline3'
>
> diff(older, yours) = "@@ -1,3 +1,3 @@
> tline1
> -fbline2
> +RESOLVED_LINE2
> tline3"
>
> Which would give raise to a conflict as trunk does not have 'fbline2'.
In other words, Case3 results in a conflict?
In other words, if you merge changes from trunk into a feature branch
causing conflicts, and you have resolved these conflicts,
then you again have to resolve conflicts
when merging the feature branch back to trunk?
Regarding your overall approach,
is is my following analysis correct?
Your current approach indirectly implements patch arithmetic
(merging changes into OLDER effectively means substracting
changes for the final merge) as required for solving the issues, right?
However, since you don't care about the order of operations
in that "patch arithmetic" (and patch algebra obviously is non-commutative),
the limitation is that the user get problems if changes overlap
(as for example when merging from trunk to feature-branch
and resolving conflicts), right?
As consequence, it cannot handle the following scenario, right?
- Trunk has one file containing just one line "a".
- Branch is created from trunk.
- Branch changes manually "a" to "aa" and commits.
- Trunk changes manually "a" to "b" and commits.
- Trunk is merged (with merge-tracking, "a" -> "b") into branch (currently: "aa").
This gives a conflict. The conflict is resolved manually as "bb" and committed.
- Trunk changes manually "b" to "c" and commits.
- Trunk is merged (with merge-tracking, "b" -> "c") into branch (currently: "bb").
This gives a conflict. The conflict is resolved manually as "cc" and committed.
- Now we merge branch into a trunk wc.
Obviously the overall result of all these merges should be "cc",
since the feature branch is up-to-date with all work of trunk.
(This is scenario
http://svn.haxx.se/dev/archive-2007-12/0134.shtml
but without assuming implicit commits.)
(My post is not meant as critics. I know that merge-tracking is hard.
I just want to understand what is supported and what not.)
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how issue-2897 branch solves reflective merges?
Posted by Kamesh Jayachandran <ka...@collab.net>.
>> Case3:
>>
>> We merge -r13, -r17(conflicting), -r29 from /trunk to /feature_branch
>> + local non-conflicting change + conflict resolution to r17 to
>> /feature_branch/test.c and commit at r40
>> (Assume this is the only synch up)
>>
>> Now we merge /feature_branch -r1:40 back to /trunk.
>>
>> It does a merge of -r1:39 which is a normal merge.
>> It does a reflective merge of 40.
>> Let us say /feature_branch/test.c got a change from a merge at
>> r40(Our first merge)
>>
>> To calculate the *meaningful diff*, We apply -r13 change to OLDER,
>> and r29 change to OLDER. (SEE WE DONT APPLY r17 as it is a
>> conflicting one)/
>>
>> Now in this case after the above 2 merges(r13, r29) OLDER becomes
>> (YOURS-local non conflicting changes - r17 - conflict resolution to
>> r17) and hence
>> (YOURS-YOURS +local non conflicting changes + r17 + conflict
>> resolution to r17) is applied to MINE. i.e local non conflicting
>> changes + r17 + conflict resolution to r17.
>
> Isn't r17 already contained in MINE and now applied again?
>
> Cheers,
> Folker
>
We are not applying the r17, sorry if I worded it that way. Following
example should make this case clear.
Consider the case
a. /trunk/test.c = 'line1\nline2\nline3'
b. Create feature branch /feature_branch from /trunk
c. Modify /trunk/test.c line1 -> tline1 at r13
d. Modify /trunk/test.c line2 -> tline2 at r17
e. Modify /trunk/test.c line3 -> tline3 at r29
f. Modify /feature_branch/test.c line2 ->fbline2 commit at r30.
g. merge /trunk r13 to /feature_branch working copy. NO COMMIT
h. merge /trunk r17 to /feature_branch working copy. This would give
raise to a conflict resolve it by 'line2' being 'RESOLVED_LINE2'. NO COMMIT
i. merge /trunk r29 to /feature_branch working copy. COMMIT at r40
(Reflective revision)
j. merge /feature_branch to /trunk working copy.
r40 is merged with reflective call back.
reflective_merge_file_changed(mine, older, yours)
mine = 'tline1\ntline2\ntline3'
older = 'line1\nfbline2\nline3'
yours = 'tline1\nRESOLVED_LINE2\ntline3'
After merging r13 older='tline1\nfbline2\nline3'
After merging r29 older='tline1\nfbline2\ntline3'
diff(older, yours) = "@@ -1,3 +1,3 @@
tline1
-fbline2
+RESOLVED_LINE2
tline3"
Which would give raise to a conflict as trunk does not have 'fbline2'.
Thanks
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how issue-2897 branch solves reflective merges?
Posted by Folker Schamel <sc...@spinor.com>.
Hi Kamesh!
> Hi All,
>
> Let me summarize the changes in issue-2897 branch.
>
> I would love to get some real technical reasons for not accepting 2897
> for 1.5 rather than '*it is complex*'.
>
> Yes it was complex when I started and while working on it at times. Now
> I see no complexity.
>
> I would love to see real technical problem that justifies that it can
> not get in to 1.5.
>
>
> For those interested to review it, following explanation should help.
>
>
> 1)Implement 'get-commit-and-merge-ranges' API in all layers (40% of the
> change)
> 2)Write the testcases (30-35% change)
> 3)Extract non-reflective changes from a reflective revision, pure
> libsvn_client change (25-30%)
>
>
> To review item 1) Major focus need to be in
> subversion/libsvn_fs_util/mergeinfo-sqlite-index.c,
> rest of the other functions at every level is just a wrapper over this
> core implementation.
>
>
> Item 2)Testcases: covers almost all the cases I can imagine, it covers
> all reflective callbacks.
>
>
> Item 3) libsvn_client is very tricky to understand but logic is simple
> as described below,
> a) Identify reflective revision and merge that reflective revision alone
> with reflective callbacks.
> b) Let me explain each callback.
>
>
> i) file_changed callback
> reflective_merge_file_changed(mine, older, yours)
> mine = WC file.
> older = file@reflective_rev-1
> yours = file@reflective_rev
>
>
> Normal merge_file_changed applies diff(older, yours) to mine.
> This diff can contain the changes 'synch up from trunk' as well as the
> local adhoc changes and conflict resolutions.
>
> Applying the diff directly is going to cause lots of headaches.
>
> So objective is to have a meaningful diff of *only local adhoc changes
> done before committing the merge*.
>
> Let me take the example and explain,
>
> Case1:
>
> We merge -r13, -r17, -r29 from /trunk to /feature_branch and commit at
> r40 (Assume this is the only synch up)
>
> Now we merge /feature_branch -r1:40 back to /trunk.
>
> It does a merge of -r1:39 which is a normal merge.
> It does a reflective merge of 40.
> Let us say /feature_branch/test.c got a change from a merge at r40(Our
> first merge)
>
> To calculate the *meaningful diff*, We apply -r13 change to OLDER, and
> r17 change to OLDER, r29 change to OLDER.
>
> Now in this case after the above 3 merges(r13, r17, r29) OLDER becomes
> YOURS and hence no change is applied to MINE.
>
>
> Case2:
>
> We merge -r13, -r17, -r29 from /trunk to /feature_branch + local
> non-conflicting change to /feature_branch/test.c and commit at r40
> (Assume this is the only synch up)
>
> Now we merge /feature_branch -r1:40 back to /trunk.
>
> It does a merge of -r1:39 which is a normal merge.
> It does a reflective merge of 40.
> Let us say /feature_branch/test.c got a change from a merge at r40(Our
> first merge)
>
> To calculate the *meaningful diff*, We apply -r13 change to OLDER, and
> r17 change to OLDER, r29 change to OLDER.
>
> Now in this case after the above 3 merges(r13, r17, r29) OLDER becomes
> (YOURS-local non conflicting changes) and hence
> (YOURS-YOURS +local non conflicting changes) is applied to MINE. i.e
> local non conflicting changes
>
> Case3:
>
> We merge -r13, -r17(conflicting), -r29 from /trunk to /feature_branch +
> local non-conflicting change + conflict resolution to r17 to
> /feature_branch/test.c and commit at r40
> (Assume this is the only synch up)
>
> Now we merge /feature_branch -r1:40 back to /trunk.
>
> It does a merge of -r1:39 which is a normal merge.
> It does a reflective merge of 40.
> Let us say /feature_branch/test.c got a change from a merge at r40(Our
> first merge)
>
> To calculate the *meaningful diff*, We apply -r13 change to OLDER, and
> r29 change to OLDER. (SEE WE DONT APPLY r17 as it is a conflicting one)/
>
> Now in this case after the above 2 merges(r13, r29) OLDER becomes
> (YOURS-local non conflicting changes - r17 - conflict resolution to r17)
> and hence
> (YOURS-YOURS +local non conflicting changes + r17 + conflict resolution
> to r17) is applied to MINE. i.e local non conflicting changes + r17 +
> conflict resolution to r17.
Isn't r17 already contained in MINE and now applied again?
Cheers,
Folker
> Moral: If synch up gave a conflict reverse
> also would give
>
>
>
>
> ii)dir_added/dir_deleted/file_added/file_deleted.
> Prior to a *reflective* merge drive we run 'diff summarize on
> *reflected* ranges'.
> Case 4:
>
> We merge -r13, -r17, -r29 from /trunk to /feature_branch and commit at
> r40 (Assume this is the only synch up)(merge adds test.c at r13, deletes
> the same at r14)
>
> Now we merge /feature_branch -r1:40 back to /trunk.
>
> It does a merge of -r1:39 which is a normal merge.
> It does a reflective merge of 40.
>
>
> Our summary implementation won't care about 'test.c' as in effect A+D
> = NO_CHANGE_COMMITTED and we won't get 'file_added' callback in this case.
>
> Case 5:
>
> We merge -r13, -r17, -r29 from /trunk to /feature_branch and commit at
> r40 (Assume this is the only synch up)(merge adds test.c at r13, deletes
> the same at r14, user adds adhoc 'test.c')
>
> Now we merge /feature_branch -r1:40 back to /trunk.
>
> It does a merge of -r1:39 which is a normal merge.
> It does a reflective merge of 40.
>
>
> Our summary implementation Would say nothing about 'test.c' as in
> effect A+D = NO_CHANGE_COMMITTED.
> But we get 'file_added' callback in this case due to local addition.
> *SUMMARY IMPLEMENTATION* would help us in deciding whether to add the
> file or not. (If there is *no* summary add the file or else leave it).
>
>
> Same explanation applies to dir additions, file/dir deletions.
>
>
>
> Would love to get more feedbacks on it.
>
> With regards
> Kamesh Jayachandran
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org