Karl Fogel wrote:
> "Mark Phippard" <markphip_at_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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-29 17:22:24 CET