You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2008/01/29 00:47:41 UTC
Issue-2897 Branch
Kamesh,
It looks increasingly likely that SVN 1.5 will not include the branch
you are working on. I am sending you this both to prepare you for
that and also get your take on it. I think one reason the issue has
even lingered as long as it has is that people have a lot of respect
for the work you have put into this problem. I want to give you my
take.
You started working on this problem a long time ago, when it did not
even seem solvable and you made some great progress. While you were
working on the problem, the repository landscape completely changed.
Mike made some major improvements by using the repository ancestry
more and reducing the need for mergeinfo etc. This suddenly made the
reintegrate solution possible. Dan and I spent a lot of time back in
May exploring that solution and there were some major roadblocks based
on how the design existed back then. Our conclusion then was that the
reintegrate approach could not be done.
The reintegrate solution seems like a lot simpler approach to solving
the same basic problem. I suspect that what you are doing possibly
solves a few additional scenarios, but they may be less critical (more
edge-case) and we need to wrap-up 1.5.
There are a couple of things you can do to help at this point:
1) Take a serious look at the reintegrate option and what it does. If
there are common scenarios that it does not handle but that your
branch will, then you need to articulate those scenarios as best you
can.
2) If you cannot find any, then I think a note from you that
encourages us to branch for 1.5 now without your change would do a
great deal towards getting us moving towards release.
Everybody sees how much work you have put into that branch and so we
are all hesitant to do the release without it. It just really seems
like the reintegrate option handles the major scenarios that we are
most concerned with and it would be best to just proceed towards the
release.
--
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: Issue-2897 Branch
Posted by Kamesh Jayachandran <ka...@collab.net>.
Mark Phippard wrote:
> Kamesh,
>
> It looks increasingly likely that SVN 1.5 will not include the branch
> you are working on. I am sending you this both to prepare you for
> that and also get your take on it. I think one reason the issue has
> even lingered as long as it has is that people have a lot of respect
> for the work you have put into this problem. I want to give you my
> take.
>
> You started working on this problem a long time ago, when it did not
> even seem solvable and you made some great progress. While you were
> working on the problem, the repository landscape completely changed.
> Mike made some major improvements by using the repository ancestry
> more and reducing the need for mergeinfo etc. This suddenly made the
> reintegrate solution possible. Dan and I spent a lot of time back in
> May exploring that solution and there were some major roadblocks based
> on how the design existed back then. Our conclusion then was that the
> reintegrate approach could not be done.
>
> The reintegrate solution seems like a lot simpler approach to solving
> the same basic problem. I suspect that what you are doing possibly
> solves a few additional scenarios, but they may be less critical (more
> edge-case) and we need to wrap-up 1.5.
>
> There are a couple of things you can do to help at this point:
>
> 1) Take a serious look at the reintegrate option and what it does. If
> there are common scenarios that it does not handle but that your
> branch will, then you need to articulate those scenarios as best you
> can.
>
Will explore and get back.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue-2897 Branch
Posted by David Glasser <gl...@davidglasser.net>.
On Jan 30, 2008 1:22 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
>
> David Glasser wrote:
> > On Jan 29, 2008 9:46 AM, C. Michael Pilato <cm...@collab.net> wrote:
> >
> >> David Glasser wrote:
> >>
> >>> On Jan 29, 2008 7:42 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
> >>>
> >>>> I found the following differences(will add them as and when I find them).
> >>>>
> >>>> 1)If feature branch is not fully up-to-date with trunk(having sparse
> >>>> merges), we will get faulty behavior.
> >>>> a)have /trunk/test.c (r1)
> >>>> tline1
> >>>> tline2
> >>>> tline3
> >>>> tline4
> >>>> tline5
> >>>> b)branch /b1 from /trunk(r2)
> >>>> c)In trunk change 'tline1'->'Tline1' and commit(r3)
> >>>> d)In trunk change 'tline2'->'Tline2' and commit(r4)
> >>>> e)merge r4 from trunk to /b1 and commit(r5)
> >>>> f)merge /b1 to /trunk <-This gives a spurious conflict
> >>>>
> >>>> Issue-2897 branch does merge at f) correctly(Though it is broken due to
> >>>> missing sqlite data, which I am *still* making a progress to implement
> >>>> the FS based solution).
> >>>>
> >>> Kamesh, that's a set of merge operations which does one (arguably more
> >>> correct) thing with your branch and another thing without it. But
> >>> that's not really a "use case"... what is the motiviation here? Why
> >>> did the user only merge r4 but not r3, and then later try to
> >>> bulk-merge back? Is the user trying to merge "all but a few specific"
> >>> revisions, in which case a record-only merge of r3 could have happened
> >>> (which would then allow reintegrate to work)?
> >>>
> >> David, does this scenario really surprise you all that much? I run into
> >> this kind of thing all the time. The story goes like this:
> >>
> >> I make a branch from trunk to rework the libsvn_fs_base implementation of
> >> some functionality. But while my code lives out in space, my email reader
> >> does not, and so I happen to notice that someone else has done some trivial
> >> code formatting change that I know will cause a conflict with my branch
> >> work. I'd like to resolve that now while my code is freshly in mind rather
> >> than deal with it later at merge-back time. So I have a choice to make --
> >> do I merge to my branch all the changes in the trunk since my branchpoint (a
> >> large merge, a large commit, etc.) or do I just cherry-pick the revision
> >> that I know will cause the problem?
> >>
> >
> > Sure, that's a real use case, but I don't think that the 2897 work
> > fixes that. As far as I understand it, as soon as any diff causes a
> > conflict anywhere the 2897 branch gives up on trying to do anything
> > special.
> No it just leaves that *reflected range* and continues with others.
>
> Let me take the following scenario(I am assuming a sparse merge sceario so
> I may left out few instructions for brevity.)
>
> 1)We have /trunk/test.c with the following contents at r1.
>
> #include <stdio.h>
> int main(void)
> {
> printf ("I am from trunk");
> return 0;
> }
>
> 2)Mike makes a branch of /trunk as /b1 at r2.
> In the branch he wants to change the output of the above program to "I
> am from nowhere".
> Meanwhile he sees someone doing a commit to '/trunk/test.c' at r3 with
> the following
> diff(change of remove space before parenthesis, pure stylistic change).
>
> - printf ("I am from trunk");
> + printf("I am from trunk");
>
>
> Here Mike can do 2 things described by 3a and 3b series.
>
> 3a1)He decides to merge this stylistic change from /trunk before making
> his code change
> which will definitely give raise to conflict if done later. And continue
> with his development and make one
> single commit.(Making 2 different commit is older style, making it in
> one commit is issue-2897 style).
>
> 3a2)He commits both merge and his change in one commit at r4 which turns
> out to be the following diff.
> - printf ("I am from trunk");
> + printf("I am from nowhere");
>
> 3a3)Merge /b1 back to /trunk, This merge will be smooth and conflict free.
>
> 3b1) Make his modifications first at r4 via the following diff
>
> - printf ("I am from trunk");
> + printf ("I am from nowhere");
>
> 3b2) merge r3 from /trunk, This will give raise to a conflict which he
> resolves with a following diff
>
> - printf ("I am from nowhere");
> + printf("I am from nowhere");
>
> 3b3) Makes a commit at r5
>
> 3b4)Merge /b1 back to /trunk.
> 3b41)r4 would give a conflict(It is not a reflective merge but *normal
> merge*,
> Assume the user resolves this conflict with '--accept=theirs',
> Subsequent merge of r5(reflective) will be smooth.
> If he chooses to resolve r4 merge in other way, he need to
> resolve other conflicts,
> where svn can not help.
> If someone sees some special case to make system aware of,
> please detail them, I will see how we
> can do that.
Hmm. So if I understand this correctly, in order to get the benefits
of the 2897 branch, we have to actively encourage people to combine
unrelated changes (the merge from trunk and the new development) into
one commit? That seems kind of poor to me.
--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: Issue-2897 Branch
Posted by Kamesh Jayachandran <ka...@collab.net>.
David Glasser wrote:
> On Jan 29, 2008 9:46 AM, C. Michael Pilato <cm...@collab.net> wrote:
>
>> David Glasser wrote:
>>
>>> On Jan 29, 2008 7:42 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
>>>
>>>> I found the following differences(will add them as and when I find them).
>>>>
>>>> 1)If feature branch is not fully up-to-date with trunk(having sparse
>>>> merges), we will get faulty behavior.
>>>> a)have /trunk/test.c (r1)
>>>> tline1
>>>> tline2
>>>> tline3
>>>> tline4
>>>> tline5
>>>> b)branch /b1 from /trunk(r2)
>>>> c)In trunk change 'tline1'->'Tline1' and commit(r3)
>>>> d)In trunk change 'tline2'->'Tline2' and commit(r4)
>>>> e)merge r4 from trunk to /b1 and commit(r5)
>>>> f)merge /b1 to /trunk <-This gives a spurious conflict
>>>>
>>>> Issue-2897 branch does merge at f) correctly(Though it is broken due to
>>>> missing sqlite data, which I am *still* making a progress to implement
>>>> the FS based solution).
>>>>
>>> Kamesh, that's a set of merge operations which does one (arguably more
>>> correct) thing with your branch and another thing without it. But
>>> that's not really a "use case"... what is the motiviation here? Why
>>> did the user only merge r4 but not r3, and then later try to
>>> bulk-merge back? Is the user trying to merge "all but a few specific"
>>> revisions, in which case a record-only merge of r3 could have happened
>>> (which would then allow reintegrate to work)?
>>>
>> David, does this scenario really surprise you all that much? I run into
>> this kind of thing all the time. The story goes like this:
>>
>> I make a branch from trunk to rework the libsvn_fs_base implementation of
>> some functionality. But while my code lives out in space, my email reader
>> does not, and so I happen to notice that someone else has done some trivial
>> code formatting change that I know will cause a conflict with my branch
>> work. I'd like to resolve that now while my code is freshly in mind rather
>> than deal with it later at merge-back time. So I have a choice to make --
>> do I merge to my branch all the changes in the trunk since my branchpoint (a
>> large merge, a large commit, etc.) or do I just cherry-pick the revision
>> that I know will cause the problem?
>>
>
> Sure, that's a real use case, but I don't think that the 2897 work
> fixes that. As far as I understand it, as soon as any diff causes a
> conflict anywhere the 2897 branch gives up on trying to do anything
> special.
No it just leaves that *reflected range* and continues with others.
Let me take the following scenario(I am assuming a sparse merge sceario so
I may left out few instructions for brevity.)
1)We have /trunk/test.c with the following contents at r1.
#include <stdio.h>
int main(void)
{
printf ("I am from trunk");
return 0;
}
2)Mike makes a branch of /trunk as /b1 at r2.
In the branch he wants to change the output of the above program to "I
am from nowhere".
Meanwhile he sees someone doing a commit to '/trunk/test.c' at r3 with
the following
diff(change of remove space before parenthesis, pure stylistic change).
- printf ("I am from trunk");
+ printf("I am from trunk");
Here Mike can do 2 things described by 3a and 3b series.
3a1)He decides to merge this stylistic change from /trunk before making
his code change
which will definitely give raise to conflict if done later. And continue
with his development and make one
single commit.(Making 2 different commit is older style, making it in
one commit is issue-2897 style).
3a2)He commits both merge and his change in one commit at r4 which turns
out to be the following diff.
- printf ("I am from trunk");
+ printf("I am from nowhere");
3a3)Merge /b1 back to /trunk, This merge will be smooth and conflict free.
3b1) Make his modifications first at r4 via the following diff
- printf ("I am from trunk");
+ printf ("I am from nowhere");
3b2) merge r3 from /trunk, This will give raise to a conflict which he
resolves with a following diff
- printf ("I am from nowhere");
+ printf("I am from nowhere");
3b3) Makes a commit at r5
3b4)Merge /b1 back to /trunk.
3b41)r4 would give a conflict(It is not a reflective merge but *normal
merge*,
Assume the user resolves this conflict with '--accept=theirs',
Subsequent merge of r5(reflective) will be smooth.
If he chooses to resolve r4 merge in other way, he need to
resolve other conflicts,
where svn can not help.
If someone sees some special case to make system aware of,
please detail them, I will see how we
can do that.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue-2897 Branch
Posted by David Glasser <gl...@davidglasser.net>.
On Jan 29, 2008 9:46 AM, C. Michael Pilato <cm...@collab.net> wrote:
>
> David Glasser wrote:
> > On Jan 29, 2008 7:42 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
> >> I found the following differences(will add them as and when I find them).
> >>
> >> 1)If feature branch is not fully up-to-date with trunk(having sparse
> >> merges), we will get faulty behavior.
> >> a)have /trunk/test.c (r1)
> >> tline1
> >> tline2
> >> tline3
> >> tline4
> >> tline5
> >> b)branch /b1 from /trunk(r2)
> >> c)In trunk change 'tline1'->'Tline1' and commit(r3)
> >> d)In trunk change 'tline2'->'Tline2' and commit(r4)
> >> e)merge r4 from trunk to /b1 and commit(r5)
> >> f)merge /b1 to /trunk <-This gives a spurious conflict
> >>
> >> Issue-2897 branch does merge at f) correctly(Though it is broken due to
> >> missing sqlite data, which I am *still* making a progress to implement
> >> the FS based solution).
> >
> > Kamesh, that's a set of merge operations which does one (arguably more
> > correct) thing with your branch and another thing without it. But
> > that's not really a "use case"... what is the motiviation here? Why
> > did the user only merge r4 but not r3, and then later try to
> > bulk-merge back? Is the user trying to merge "all but a few specific"
> > revisions, in which case a record-only merge of r3 could have happened
> > (which would then allow reintegrate to work)?
>
> David, does this scenario really surprise you all that much? I run into
> this kind of thing all the time. The story goes like this:
>
> I make a branch from trunk to rework the libsvn_fs_base implementation of
> some functionality. But while my code lives out in space, my email reader
> does not, and so I happen to notice that someone else has done some trivial
> code formatting change that I know will cause a conflict with my branch
> work. I'd like to resolve that now while my code is freshly in mind rather
> than deal with it later at merge-back time. So I have a choice to make --
> do I merge to my branch all the changes in the trunk since my branchpoint (a
> large merge, a large commit, etc.) or do I just cherry-pick the revision
> that I know will cause the problem?
Sure, that's a real use case, but I don't think that the 2897 work
fixes that. As far as I understand it, as soon as any diff causes a
conflict anywhere the 2897 branch gives up on trying to do anything
special. I'm still trying to find a real use case that isn't
completely trivial that 2897 helps with. (I'm not saying I don't
believe they exist. I just haven't seen a convincing one yet.)
--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: Issue-2897 Branch
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
> On Jan 29, 2008 7:42 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
>> I found the following differences(will add them as and when I find them).
>>
>> 1)If feature branch is not fully up-to-date with trunk(having sparse
>> merges), we will get faulty behavior.
>> a)have /trunk/test.c (r1)
>> tline1
>> tline2
>> tline3
>> tline4
>> tline5
>> b)branch /b1 from /trunk(r2)
>> c)In trunk change 'tline1'->'Tline1' and commit(r3)
>> d)In trunk change 'tline2'->'Tline2' and commit(r4)
>> e)merge r4 from trunk to /b1 and commit(r5)
>> f)merge /b1 to /trunk <-This gives a spurious conflict
>>
>> Issue-2897 branch does merge at f) correctly(Though it is broken due to
>> missing sqlite data, which I am *still* making a progress to implement
>> the FS based solution).
>
> Kamesh, that's a set of merge operations which does one (arguably more
> correct) thing with your branch and another thing without it. But
> that's not really a "use case"... what is the motiviation here? Why
> did the user only merge r4 but not r3, and then later try to
> bulk-merge back? Is the user trying to merge "all but a few specific"
> revisions, in which case a record-only merge of r3 could have happened
> (which would then allow reintegrate to work)?
David, does this scenario really surprise you all that much? I run into
this kind of thing all the time. The story goes like this:
I make a branch from trunk to rework the libsvn_fs_base implementation of
some functionality. But while my code lives out in space, my email reader
does not, and so I happen to notice that someone else has done some trivial
code formatting change that I know will cause a conflict with my branch
work. I'd like to resolve that now while my code is freshly in mind rather
than deal with it later at merge-back time. So I have a choice to make --
do I merge to my branch all the changes in the trunk since my branchpoint (a
large merge, a large commit, etc.) or do I just cherry-pick the revision
that I know will cause the problem?
Claims that one way is "better than" the other will ultimately wind up
standing on Subversion's implementation and merging prowess. A perfect
system would be able to handle either of the routes I take without odd
gyrations like manually claiming the branch-rev-of-my-cherry-picked-merge
was already merged to trunk or somesuch.
So, I don't think we have to look far for a use-case. Our task is simply to
prioritize use-cases, letting slide what we feel we need to let slide, but
ideally having comprehensible workarounds in hand.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Issue-2897 Branch
Posted by David Glasser <gl...@davidglasser.net>.
On Jan 29, 2008 7:42 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
> I found the following differences(will add them as and when I find them).
>
> 1)If feature branch is not fully up-to-date with trunk(having sparse
> merges), we will get faulty behavior.
> a)have /trunk/test.c (r1)
> tline1
> tline2
> tline3
> tline4
> tline5
> b)branch /b1 from /trunk(r2)
> c)In trunk change 'tline1'->'Tline1' and commit(r3)
> d)In trunk change 'tline2'->'Tline2' and commit(r4)
> e)merge r4 from trunk to /b1 and commit(r5)
> f)merge /b1 to /trunk <-This gives a spurious conflict
>
> Issue-2897 branch does merge at f) correctly(Though it is broken due to
> missing sqlite data, which I am *still* making a progress to implement
> the FS based solution).
Kamesh, that's a set of merge operations which does one (arguably more
correct) thing with your branch and another thing without it. But
that's not really a "use case"... what is the motiviation here? Why
did the user only merge r4 but not r3, and then later try to
bulk-merge back? Is the user trying to merge "all but a few specific"
revisions, in which case a record-only merge of r3 could have happened
(which would then allow reintegrate to work)?
I mean, I certainly understand that the 2897 branch supports
interesting operations. I'm just trying to figure out what use cases
would make them useful.
--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: Issue-2897 Branch
Posted by Kamesh Jayachandran <ka...@collab.net>.
Mark Phippard wrote:
> Kamesh,
>
> It looks increasingly likely that SVN 1.5 will not include the branch
> you are working on. I am sending you this both to prepare you for
> that and also get your take on it. I think one reason the issue has
> even lingered as long as it has is that people have a lot of respect
> for the work you have put into this problem. I want to give you my
> take.
>
> You started working on this problem a long time ago, when it did not
> even seem solvable and you made some great progress. While you were
> working on the problem, the repository landscape completely changed.
> Mike made some major improvements by using the repository ancestry
> more and reducing the need for mergeinfo etc. This suddenly made the
> reintegrate solution possible. Dan and I spent a lot of time back in
> May exploring that solution and there were some major roadblocks based
> on how the design existed back then. Our conclusion then was that the
> reintegrate approach could not be done.
>
> The reintegrate solution seems like a lot simpler approach to solving
> the same basic problem. I suspect that what you are doing possibly
> solves a few additional scenarios, but they may be less critical (more
> edge-case) and we need to wrap-up 1.5.
>
> There are a couple of things you can do to help at this point:
>
> 1) Take a serious look at the reintegrate option and what it does. If
> there are common scenarios that it does not handle but that your
> branch will, then you need to articulate those scenarios as best you
> can.
>
>
I found the following differences(will add them as and when I find them).
1)If feature branch is not fully up-to-date with trunk(having sparse
merges), we will get faulty behavior.
a)have /trunk/test.c (r1)
tline1
tline2
tline3
tline4
tline5
b)branch /b1 from /trunk(r2)
c)In trunk change 'tline1'->'Tline1' and commit(r3)
d)In trunk change 'tline2'->'Tline2' and commit(r4)
e)merge r4 from trunk to /b1 and commit(r5)
f)merge /b1 to /trunk <-This gives a spurious conflict
Issue-2897 branch does merge at f) correctly(Though it is broken due to
missing sqlite data, which I am *still* making a progress to implement
the FS based solution).
2)One has to learn one special switch to do the normal job(Of course job
is not *trivial* and hence worth to learn them)
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue-2897 Branch
Posted by Kamesh Jayachandran <ka...@collab.net>.
Karl Fogel wrote:
> Kamesh Jayachandran <ka...@collab.net> writes:
>
>> I made my best to explain the implementation.
>>
>> I am always there to explain it, if someone could not understand it.
>>
>> I would have been more happy if I had solid points on how issue-2897
>> branch *fail* to
>> understand the complexity that really others tend to think as existing
>> for quite some time.
>>
>> When I was done with issue-2897 branch work as at r28870, I was going
>> through the logs of 'reintegrate' branch.
>> Unfortunately my top-down approach did not help me in understanding
>> the solution completely.
>> In other words that problem/solution was complex in my eyes.
>>
>
> Yes, yes! Right! :-)
>
> I'm definitely not saying that the issue 2897 branch is more complex
> than the reintegrate branch. I'm only saying that enough people (at a
> minimum three, possibly more) understood the reintegrate branch, such
> that we felt safe merging it back to trunk. If we had even three
> people who understood the 2897 branch, we could merge it too. But we
> don't, yet.
>
> I'm not saying that the reason we don't have those people is your
> fault. It's not -- you've done your best to explain it. I'm merely
> pointing out the reality that, for whatever reason, we don't have
> them. We may get them before 1.5 releases, in which case we should
> merge it; but branching 1.5 should not depend on that.
>
> (I completely agree with you that, to your eyes, it is reasonable for
> the reintegrate branch to look equally complex.)
>
>
Thanks Karl for the clarification.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue-2897 Branch
Posted by Karl Fogel <kf...@red-bean.com>.
Kamesh Jayachandran <ka...@collab.net> writes:
> I made my best to explain the implementation.
>
> I am always there to explain it, if someone could not understand it.
>
> I would have been more happy if I had solid points on how issue-2897
> branch *fail* to
> understand the complexity that really others tend to think as existing
> for quite some time.
>
> When I was done with issue-2897 branch work as at r28870, I was going
> through the logs of 'reintegrate' branch.
> Unfortunately my top-down approach did not help me in understanding
> the solution completely.
> In other words that problem/solution was complex in my eyes.
Yes, yes! Right! :-)
I'm definitely not saying that the issue 2897 branch is more complex
than the reintegrate branch. I'm only saying that enough people (at a
minimum three, possibly more) understood the reintegrate branch, such
that we felt safe merging it back to trunk. If we had even three
people who understood the 2897 branch, we could merge it too. But we
don't, yet.
I'm not saying that the reason we don't have those people is your
fault. It's not -- you've done your best to explain it. I'm merely
pointing out the reality that, for whatever reason, we don't have
them. We may get them before 1.5 releases, in which case we should
merge it; but branching 1.5 should not depend on that.
(I completely agree with you that, to your eyes, it is reasonable for
the reintegrate branch to look equally complex.)
> rather I want to bring in an empathy of how difficult for one to grok
> with any feature branch
> by going through the logs and diff(I believe diff size of both
> issue-2897 and reintegrate was almost
> same around 5000 lines, I am just bringing in this 'line-number'
> comparision just for
> naive-statistics as that could be a daunting number for any starter).
Yup... I empathize, and I'm trying to review it (the size of the diff
doesn't daunt me, er, at least not *too* much).
> I am there to go with the group's decision.
>
>> Kamesh, does this sound like a good course to you?
>
> Yes.(I am still making a progress on implementing
> get-commit-and-merge-ranges via FS')
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue-2897 Branch
Posted by Kamesh Jayachandran <ka...@collab.net>.
Karl Fogel wrote:
> "Mark Phippard" <ma...@gmail.com> writes:
>
>> 1) Take a serious look at the reintegrate option and what it does. If
>> there are common scenarios that it does not handle but that your
>> branch will, then you need to articulate those scenarios as best you
>> can.
>>
>> 2) If you cannot find any, then I think a note from you that
>> encourages us to branch for 1.5 now without your change would do a
>> great deal towards getting us moving towards release.
>>
>> Everybody sees how much work you have put into that branch and so we
>> are all hesitant to do the release without it. It just really seems
>> like the reintegrate option handles the major scenarios that we are
>> most concerned with and it would be best to just proceed towards the
>> release.
>>
>
> I second Mark's points. The 2897 work is important, but it may
> actually go beyond what we want to do in 1.5. We don't need 1.5 to be
> everything under the sun; we just need it to do better tracking of
> merges. 1.6 will do even more.
>
> For comparison:
>
> The branch for the sparse-directories work was created on August 9th,
> 2006, and not merged until March 21st, 2007. That's *8.5 months*
> before it was merged (and we still had to do more work after merging
> it). Also, what made it okay to merge was that people other than me
> finally read, understood, and started changing that code. That was
> key.
>
> By contrast, the issue-2897 branch was created on November 22nd of
> last year, so it's only about two months old now, for a problem of
> similar complexity (in some ways less, in some ways more).
>
> Two months is not a long time, really!
>
> For those very familiar with the branch (especially Kamesh), mails
> like this are perhaps a bit frustrating to read, because if the rest
> of us would just take the time to understand the branch's code, we
> would see that it is maintainable and solves important problems. I
> sympathize, a lot. But as a group, we have to take perceived
> complexity into account as a concern in itself, because we'll have to
> maintain that code collectively. Until we really understand what it
> does and how it interacts with the rest of the code, we shouldn't
> release it. I'm not sure we can grok it in time for 1.5, that's all.
>
I made my best to explain the implementation.
I am always there to explain it, if someone could not understand it.
I would have been more happy if I had solid points on how issue-2897
branch *fail* to
understand the complexity that really others tend to think as existing
for quite some time.
When I was done with issue-2897 branch work as at r28870, I was going
through the logs of 'reintegrate' branch.
Unfortunately my top-down approach did not help me in understanding the
solution completely.
In other words that problem/solution was complex in my eyes.
I am *not* starting a war on which solution is better here,
rather I want to bring in an empathy of how difficult for one to grok
with any feature branch
by going through the logs and diff(I believe diff size of both
issue-2897 and reintegrate was almost
same around 5000 lines, I am just bringing in this 'line-number'
comparision just for
naive-statistics as that could be a daunting number for any starter).
I am there to go with the group's decision.
> Improving our merge algorithms is something we should aim for over the
> long term. If close inspection of 2897 during the 1.5 branch period
> shows that it can get us better merges without imposing new
> complexities that we or our users are not prepared to deal with, then
> we can merge it in before 1.5. But it's also okay if we have to wait
> until 1.6. (There is no way that 1.6 is going to take as long as 1.5
> did, because we know not to try a release that big again.)
>
> So, I hope this explains Mark's and my cautiousness.
>
> Right now, my instinct is that we should branch 1.5 from trunk, and
> not let 2897 block the 1.5 release; but we should be willing to merge
> 2897 into the 1.5 branch (via trunk, of course) if we are confident
> that we understand what it does and that it won't be too destabilizing
> in an already-large release.
>
> Kamesh, does this sound like a good course to you?
>
Yes.(I am still making a progress on implementing
'get-commit-and-merge-ranges via FS')
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue-2897 Branch
Posted by Karl Fogel <kf...@red-bean.com>.
"Mark Phippard" <ma...@gmail.com> writes:
> 1) Take a serious look at the reintegrate option and what it does. If
> there are common scenarios that it does not handle but that your
> branch will, then you need to articulate those scenarios as best you
> can.
>
> 2) If you cannot find any, then I think a note from you that
> encourages us to branch for 1.5 now without your change would do a
> great deal towards getting us moving towards release.
>
> Everybody sees how much work you have put into that branch and so we
> are all hesitant to do the release without it. It just really seems
> like the reintegrate option handles the major scenarios that we are
> most concerned with and it would be best to just proceed towards the
> release.
I second Mark's points. The 2897 work is important, but it may
actually go beyond what we want to do in 1.5. We don't need 1.5 to be
everything under the sun; we just need it to do better tracking of
merges. 1.6 will do even more.
For comparison:
The branch for the sparse-directories work was created on August 9th,
2006, and not merged until March 21st, 2007. That's *8.5 months*
before it was merged (and we still had to do more work after merging
it). Also, what made it okay to merge was that people other than me
finally read, understood, and started changing that code. That was
key.
By contrast, the issue-2897 branch was created on November 22nd of
last year, so it's only about two months old now, for a problem of
similar complexity (in some ways less, in some ways more).
Two months is not a long time, really!
For those very familiar with the branch (especially Kamesh), mails
like this are perhaps a bit frustrating to read, because if the rest
of us would just take the time to understand the branch's code, we
would see that it is maintainable and solves important problems. I
sympathize, a lot. But as a group, we have to take perceived
complexity into account as a concern in itself, because we'll have to
maintain that code collectively. Until we really understand what it
does and how it interacts with the rest of the code, we shouldn't
release it. I'm not sure we can grok it in time for 1.5, that's all.
Improving our merge algorithms is something we should aim for over the
long term. If close inspection of 2897 during the 1.5 branch period
shows that it can get us better merges without imposing new
complexities that we or our users are not prepared to deal with, then
we can merge it in before 1.5. But it's also okay if we have to wait
until 1.6. (There is no way that 1.6 is going to take as long as 1.5
did, because we know not to try a release that big again.)
So, I hope this explains Mark's and my cautiousness.
Right now, my instinct is that we should branch 1.5 from trunk, and
not let 2897 block the 1.5 release; but we should be willing to merge
2897 into the 1.5 branch (via trunk, of course) if we are confident
that we understand what it does and that it won't be too destabilizing
in an already-large release.
Kamesh, does this sound like a good course to you?
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue-2897 Branch
Posted by Kamesh Jayachandran <ka...@collab.net>.
Kamesh Jayachandran wrote:
> Mark Phippard wrote:
>> I am going to post this in this thread because it is related.
>>
>> Let's say that 1.5 is released without the issue-2897 branch included.
>> If that is the case, we still need to decide how to handle reflective
>> revisions in 1.5. The choices just become more crude:
>>
>> 1) We include those revisions in the merge. That means we will be
>> repeating merge, but also not losing the parts not related to the
>> merge.
>>
>> 2) Skip those revisions in the merge. That means we will lose the
>> parts of the merge that were not related to the merge.
>>
>> I would probably favor #1. I think we try to do some form of #2
>> today. I know that code had problems, I am not sure if it was
>> removed.
>>
>>
>
Fixed in r29176 /trunk and proposed for 1.5.x.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue-2897 Branch
Posted by Kamesh Jayachandran <ka...@collab.net>.
Mark Phippard wrote:
> I am going to post this in this thread because it is related.
>
> Let's say that 1.5 is released without the issue-2897 branch included.
> If that is the case, we still need to decide how to handle reflective
> revisions in 1.5. The choices just become more crude:
>
> 1) We include those revisions in the merge. That means we will be
> repeating merge, but also not losing the parts not related to the
> merge.
>
> 2) Skip those revisions in the merge. That means we will lose the
> parts of the merge that were not related to the merge.
>
> I would probably favor #1. I think we try to do some form of #2
> today. I know that code had problems, I am not sure if it was
> removed.
>
>
Yes we do #2. snip from
subversion/libsvn_client/merge.c:filter_reflected_revisions
if (src_rangelist_for_tgt)
SVN_ERR(svn_rangelist_remove(requested_rangelist, src_rangelist_for_tgt,
*requested_rangelist,
FALSE, pool));
This logic is faulty (origin of issue 2897)
I would remove it on trunk after testing. Will propose the same for back
porting to 1.5.x.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue-2897 Branch
Posted by Mark Phippard <ma...@gmail.com>.
I am going to post this in this thread because it is related.
Let's say that 1.5 is released without the issue-2897 branch included.
If that is the case, we still need to decide how to handle reflective
revisions in 1.5. The choices just become more crude:
1) We include those revisions in the merge. That means we will be
repeating merge, but also not losing the parts not related to the
merge.
2) Skip those revisions in the merge. That means we will lose the
parts of the merge that were not related to the merge.
I would probably favor #1. I think we try to do some form of #2
today. I know that code had problems, I am not sure if it was
removed.
--
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