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/09 20:48:55 UTC
Getting closer to a 1.5 release?
I'd like to hear what people doing the work think about where we are
in relationship to starting the 1.5 release process.
I know there is some branch activity that needs to be wrapped up and
merged back to trunk before we can branch for 1.5. Other than the
reintegrate branch, are there any others that need to be merged to
trunk before we branch? Estimates on when we will be ready?
Anyone want to give their feelings on what needs to happen after we
branch in order to get us to RC1?
Finally, any ideas on things we can do to kickstart this process and
get things wrapped up? I know we all want this release done so we can
move on. When I start looking at the calendar, counting out when we
might have an RC1, then counting out to when there would be a GA it
gets depressing. That is a bad way to start a new year -- depressed.
I know there are a lot of us that have been working hard to get this
release done. What more can be done to move the process along and
maybe pick up some new momentum? Ideas welcomed.
When we branch for 1.5 I intend to produce and host various binaries
based on the branch so that we can hopefully get some testing and
feedback that will move us closer to RC1.
Anyway, not expecting definitive answers but it is good to hear
feedback from others. We have not talked about this in quite a while
with the holidays and all. On the positive side, it seems like things
are wrapping up and we have solutions in place or being finalized for
the main problems.
--
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: Finalizing what's in 1.5
Posted by Mark Phippard <ma...@gmail.com>.
On Jan 10, 2008 2:38 PM, Mark Phippard <ma...@gmail.com> wrote:
> I tend to think we should merge reintegrate branch to trunk, and then
> get your branch caught up and also do the work to replace the usage of
> SQLite in that branch, and then merge back to trunk.
I was reading Kamesh on IRC while typing this, hence the use of "your
branch" instead of "Kamesh's 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: Finalizing what's in 1.5
Posted by Mark Phippard <ma...@gmail.com>.
On Jan 10, 2008 2:18 PM, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On Jan 10, 2008 1:04 PM, Blair Zajac <bl...@orcaware.com> wrote:
>
> > Now after reading the IRC conversation, it appears that the amount of energy
> > going into #2897 isn't going to be enough for a faster 1.5 release, there's
> > nobody else really looking at the work. So if we want this feature, we should
> > merge it soon into trunk and deal with it in trunk.
>
> That's an interesting question: is the branch so unstable (at the
> moment) that would make the trunk impossible to work on? If not,
> there's no reason for the branch to persist.
>
> My vote is the same always (which doesn't have much weight, since I'm
> not doing any work): Kamesh's branch is THE main use-case for
> merge-tracking and svnmerge.py. An svn 1.5 release without the
> ability to track and painlessly re-merge feature branches just isn't
> interesting to the general public.
I feel pretty much the same, and given that Kamesh's work touches on
something that already does not work, I do not see a lot of potential
to make things a lot worse than they are. To me the main question was
how to synch up this work with the reintegrate (and remove SQLite
work). ie. who should merge to trunk first?
I tend to think we should merge reintegrate branch to trunk, and then
get your branch caught up and also do the work to replace the usage of
SQLite in that branch, and then merge back to trunk.
Obviously the reverse could also be done.
--
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: Finalizing what's in 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
Ben Collins-Sussman wrote:
> On Jan 10, 2008 1:04 PM, Blair Zajac <bl...@orcaware.com> wrote:
>
>> Now after reading the IRC conversation, it appears that the amount of energy
>> going into #2897 isn't going to be enough for a faster 1.5 release, there's
>> nobody else really looking at the work. So if we want this feature, we should
>> merge it soon into trunk and deal with it in trunk.
>
> That's an interesting question: is the branch so unstable (at the
> moment) that would make the trunk impossible to work on? If not,
> there's no reason for the branch to persist.
>
> My vote is the same always (which doesn't have much weight, since I'm
> not doing any work): Kamesh's branch is THE main use-case for
> merge-tracking and svnmerge.py. An svn 1.5 release without the
> ability to track and painlessly re-merge feature branches just isn't
> interesting to the general public.
I'm with Ben here in my vote doesn't have as much weight since I'm not helping
deliver this feature, but I still strongly believe it should be in 1.5.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finalizing what's in 1.5
Posted by Karl Fogel <kf...@red-bean.com>.
Jack Repenning <jr...@collab.net> writes:
> Karl Fogel wrote:
>> Branko Čibej <br...@xbc.nu> writes:
>>>> ability to track and painlessly re-merge feature branches just isn't
>>>> interesting to the general public.
>>> +1. I won't repeat earlier rants, since the most you'll get in return
>>> is lots of cheering and no code ... in the short term. :)
>>
>> Everyone agrees with what I've quoted above. The question is whether
>> 2897 is necessary to achieve that: reintegrate branch says "no".
>
> Yurk: Karl's quote of Branko's quote left out Ben's "an svn without",
> which rather changes the meaning of the exchange!
Sorry about that, Jack's right.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finalizing what's in 1.5
Posted by Jack Repenning <jr...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Karl Fogel wrote:
> Branko Čibej <br...@xbc.nu> writes:
>>> ability to track and painlessly re-merge feature branches just isn't
>>> interesting to the general public.
>> +1. I won't repeat earlier rants, since the most you'll get in return
>> is lots of cheering and no code ... in the short term. :)
>
> Everyone agrees with what I've quoted above. The question is whether
> 2897 is necessary to achieve that: reintegrate branch says "no".
Yurk: Karl's quote of Branko's quote left out Ben's "an svn without",
which rather changes the meaning of the exchange!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: PGP-encrypted email preferred
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkeGk0YACgkQUfE+7TuC6HAXMgCgu9ZRoEHRGamjhw9GKe1kBZj2
ALMAoJyNNPHWy94qSTGndFslglZpBEhN
=/ukl
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finalizing what's in 1.5
Posted by Karl Fogel <kf...@red-bean.com>.
Branko Čibej <br...@xbc.nu> writes:
>> ability to track and painlessly re-merge feature branches just isn't
>> interesting to the general public.
>
> +1. I won't repeat earlier rants, since the most you'll get in return
> is lots of cheering and no code ... in the short term. :)
Everyone agrees with what I've quoted above. The question is whether
2897 is necessary to achieve that: reintegrate branch says "no".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finalizing what's in 1.5
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> On Jan 10, 2008 1:04 PM, Blair Zajac <bl...@orcaware.com> wrote:
>
>
>> Now after reading the IRC conversation, it appears that the amount of energy
>> going into #2897 isn't going to be enough for a faster 1.5 release, there's
>> nobody else really looking at the work. So if we want this feature, we should
>> merge it soon into trunk and deal with it in trunk.
>>
>
> That's an interesting question: is the branch so unstable (at the
> moment) that would make the trunk impossible to work on? If not,
> there's no reason for the branch to persist.
>
> My vote is the same always (which doesn't have much weight, since I'm
> not doing any work): Kamesh's branch is THE main use-case for
> merge-tracking and svnmerge.py. An svn 1.5 release without the
> ability to track and painlessly re-merge feature branches just isn't
> interesting to the general public.
>
+1. I won't repeat earlier rants, since the most you'll get in return is
lots of cheering and no code ... in the short term. :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finalizing what's in 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
David Glasser wrote:
> On Jan 10, 2008 3:04 PM, Blair Zajac <bl...@orcaware.com> wrote:
>> David Glasser wrote:
>>> On Jan 10, 2008 2:18 PM, Ben Collins-Sussman <su...@red-bean.com> wrote:
>>>> On Jan 10, 2008 1:04 PM, Blair Zajac <bl...@orcaware.com> wrote:
>>>>
>>>>> Now after reading the IRC conversation, it appears that the amount of energy
>>>>> going into #2897 isn't going to be enough for a faster 1.5 release, there's
>>>>> nobody else really looking at the work. So if we want this feature, we should
>>>>> merge it soon into trunk and deal with it in trunk.
>>>> That's an interesting question: is the branch so unstable (at the
>>>> moment) that would make the trunk impossible to work on? If not,
>>>> there's no reason for the branch to persist.
>>>>
>>>> My vote is the same always (which doesn't have much weight, since I'm
>>>> not doing any work): Kamesh's branch is THE main use-case for
>>>> merge-tracking and svnmerge.py. An svn 1.5 release without the
>>>> ability to track and painlessly re-merge feature branches just isn't
>>>> interesting to the general public.
>>> The reintegrate branch gives the ability to track and painlessly
>>> re-merge feature branches.
>>>
>>> It may not give as much flexibility as the issue-2897 branch, but I'm
>>> still not actually convinced that the issue-2897 version will actually
>>> work as well.
>> Why is that? How does issue-2897 differ from the reintegrate branch? What use
>> cases are supported by one and not the other? I haven't been following these
>> branches closely enough to know the differences between them.
>
> It really depends what you mean "merge back from a feature branch"
> should actually mean.
>
> If you think it should mean "figure out the net difference between
> trunk and the branch, as of the last time the branch was pulled from
> the trunk, and apply that to trunk", then you want reintegrate.
So reintegrate is the mirror of rebasing a branch then.
> If you think it should mean "find every single separate range of
> changes done on the branch, and apply them one by one to the trunk in
> order, possibly requiring resolving the same conflicts over and over",
> you want current trunk code.
>
> If you think it should mean "find every single separate range of
> changes done on the branch, and apply them one by one to the trunk in
> order, but before applying each range, see if there's actually some
> merged revisions in there, in which case attempt to reapply the
> changes done by the original merge in some temp files, and if this
> happens to not cause conflicts, use that as a base for the diff that
> you're applying to trunk, oh and you still probably need to resolve
> the same conflicts over and over", you want issue-2897.
>
> Now, I'm sure there are some cases where the issue-2897 algorithm is best.
Thanks for clarifying them.
> But just like many SVK users gave up on using non "--lump" merges (due
> to repeated conflict resolution, etc), I think that actually using the
> issue-2897 version is going to be an exercise in unpredictability and
> tedium, whereas the reintegrate version will either work correctly or
> return an error saying (essentially) that you haven't been treating
> the branch like a feature branch.
What will cause a branch to not be usable by the reintegrate feature? If you
only do merges between the branch and trunk, will you be fine? If you merge in
changes from a location that is not the trunk, will that break reintegrate?
Hopefully if reintegrate fails and warns the user, it tells the user what they
need to do to do the merge.
> (There's no reason not to include both features, by the way; they're
> orthogonal. I just don't want to include issue-2897 at all unless
> several people have been convinced that it actually works well.)
Reading your description makes it sound like 2897 will require us to test the
feature, which sounds like you want to test it without merging it back into
trunk. I guess we can always pull it out of trunk if need be.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finalizing what's in 1.5
Posted by Jack Repenning <jr...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
C. Michael Pilato wrote:
> Please, please, **please** stop trying to add automated voodoo and
> complex intelligence to our command-line tool. Every time we do this,
> we steal power from users' hands that cannot be re-granted to them
> without them writing software against our APIs themselves.
Please, please, **PLEASE** add automated voodoo to this particular
feature, because its whole point is to save the users work, and if you
only give them a heap of tinker toys, you aren't saving them anything.
Please, please, please, ***PLEASE!!!*** add intelligent "do the right
thing" logic to this feature, because the last thing in the WORLD the
enterprise customer wants is a tool that makes the user figure that all
out, and risks destroying a central build, ruining a distribution
package, or even breaking a thousand customer sites, due to some
miscalculation.
And, yes, ppp accept the responsibility for making it *good* voodoo and
the RIGHT right thing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: PGP-encrypted email preferred
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkeGkMAACgkQUfE+7TuC6HARsQCg0+qU1NaubpAv+W8q3rFMW/ni
+8UAnRE05t4SnikoHr1UGzIYwe3/UI+y
=V/pJ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finalizing what's in 1.5
Posted by Karl Fogel <kf...@red-bean.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
>> Why do I need to specify --reintegrate? Why can't we just see that
>> feature-branch meets our criteria for using --reintegrate and then do
>> it. And it it does not, allow the work Kamesh is doing to come into
>> play?
>
> Please, please, **please** stop trying to add automated voodoo and
> complex intelligence to our command-line tool. Every time we do this,
> we steal power from users' hands that cannot be re-granted to them
> without them writing software against our APIs themselves.
That's not quite true in this case, but I'll follow up in more detail
after finishing the current IRC conversation on this very topic.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finalizing what's in 1.5
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Jan 10, 2008 6:46 PM, Karl Fogel <kf...@red-bean.com> wrote:
>> "David Glasser" <gl...@davidglasser.net> writes:
>>> (There's no reason not to include both features, by the way; they're
>>> orthogonal. I just don't want to include issue-2897 at all unless
>>> several people have been convinced that it actually works well.)
>> David said exactly what I would have said.
>>
>> The issue-2897 stuff will be very useful, but it is *not* necessary
>> for maintaining and merging back feature branches. The --reintegrate
>> thang will take care of the common case there.
>
> Here is a simple question I still do not understand the answer to.
>
> I am sitting in a trunk WC. I run this command:
>
> svn merge url://feature-branch
>
> Why do I need to specify --reintegrate? Why can't we just see that
> feature-branch meets our criteria for using --reintegrate and then do
> it. And it it does not, allow the work Kamesh is doing to come into
> play?
Please, please, **please** stop trying to add automated voodoo and complex
intelligence to our command-line tool. Every time we do this, we steal
power from users' hands that cannot be re-granted to them without them
writing software against our APIs themselves.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Finalizing what's in 1.5
Posted by Mark Phippard <ma...@gmail.com>.
On Jan 10, 2008 6:46 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "David Glasser" <gl...@davidglasser.net> writes:
> > (There's no reason not to include both features, by the way; they're
> > orthogonal. I just don't want to include issue-2897 at all unless
> > several people have been convinced that it actually works well.)
>
> David said exactly what I would have said.
>
> The issue-2897 stuff will be very useful, but it is *not* necessary
> for maintaining and merging back feature branches. The --reintegrate
> thang will take care of the common case there.
Here is a simple question I still do not understand the answer to.
I am sitting in a trunk WC. I run this command:
svn merge url://feature-branch
Why do I need to specify --reintegrate? Why can't we just see that
feature-branch meets our criteria for using --reintegrate and then do
it. And it it does not, allow the work Kamesh is doing to come into
play?
--
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: Finalizing what's in 1.5
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Jan 10, 2008 5:46 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "David Glasser" <gl...@davidglasser.net> writes:
> > (There's no reason not to include both features, by the way; they're
> > orthogonal. I just don't want to include issue-2897 at all unless
> > several people have been convinced that it actually works well.)
>
> David said exactly what I would have said.
>
> The issue-2897 stuff will be very useful, but it is *not* necessary
> for maintaining and merging back feature branches. The --reintegrate
> thang will take care of the common case there.
OK, I misunderstood the difference between the 'reintegrate' branch
and the 2897 branch.
It seems like the reintegrate branch at least makes it easy an
automatic for users to manage and re-merge feature branches (assuming
they treat their branch reasonably.) That's all I care about for svn
1.5. It sounds like Kamesh's branch is a much fancier (and more
complex) generalization of this problem, so I'm fine with putting that
off till svn 1.6.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finalizing what's in 1.5
Posted by Karl Fogel <kf...@red-bean.com>.
"David Glasser" <gl...@davidglasser.net> writes:
> (There's no reason not to include both features, by the way; they're
> orthogonal. I just don't want to include issue-2897 at all unless
> several people have been convinced that it actually works well.)
David said exactly what I would have said.
The issue-2897 stuff will be very useful, but it is *not* necessary
for maintaining and merging back feature branches. The --reintegrate
thang will take care of the common case there.
One problem in this discussion is that people have very different
ideas of what the issue-2897 solution would actually *do* in practice.
We need hard facts about the benefits it brings to users (that nothing
else brings). I believe David's summary of what it does, vs what
plain merge does vs what reintegrate does, was accurate, though.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finalizing what's in 1.5
Posted by David Glasser <gl...@davidglasser.net>.
On Jan 10, 2008 3:04 PM, Blair Zajac <bl...@orcaware.com> wrote:
>
> David Glasser wrote:
> > On Jan 10, 2008 2:18 PM, Ben Collins-Sussman <su...@red-bean.com> wrote:
> >> On Jan 10, 2008 1:04 PM, Blair Zajac <bl...@orcaware.com> wrote:
> >>
> >>> Now after reading the IRC conversation, it appears that the amount of energy
> >>> going into #2897 isn't going to be enough for a faster 1.5 release, there's
> >>> nobody else really looking at the work. So if we want this feature, we should
> >>> merge it soon into trunk and deal with it in trunk.
> >> That's an interesting question: is the branch so unstable (at the
> >> moment) that would make the trunk impossible to work on? If not,
> >> there's no reason for the branch to persist.
> >>
> >> My vote is the same always (which doesn't have much weight, since I'm
> >> not doing any work): Kamesh's branch is THE main use-case for
> >> merge-tracking and svnmerge.py. An svn 1.5 release without the
> >> ability to track and painlessly re-merge feature branches just isn't
> >> interesting to the general public.
> >
> > The reintegrate branch gives the ability to track and painlessly
> > re-merge feature branches.
> >
> > It may not give as much flexibility as the issue-2897 branch, but I'm
> > still not actually convinced that the issue-2897 version will actually
> > work as well.
>
> Why is that? How does issue-2897 differ from the reintegrate branch? What use
> cases are supported by one and not the other? I haven't been following these
> branches closely enough to know the differences between them.
It really depends what you mean "merge back from a feature branch"
should actually mean.
If you think it should mean "figure out the net difference between
trunk and the branch, as of the last time the branch was pulled from
the trunk, and apply that to trunk", then you want reintegrate.
If you think it should mean "find every single separate range of
changes done on the branch, and apply them one by one to the trunk in
order, possibly requiring resolving the same conflicts over and over",
you want current trunk code.
If you think it should mean "find every single separate range of
changes done on the branch, and apply them one by one to the trunk in
order, but before applying each range, see if there's actually some
merged revisions in there, in which case attempt to reapply the
changes done by the original merge in some temp files, and if this
happens to not cause conflicts, use that as a base for the diff that
you're applying to trunk, oh and you still probably need to resolve
the same conflicts over and over", you want issue-2897.
Now, I'm sure there are some cases where the issue-2897 algorithm is best.
But just like many SVK users gave up on using non "--lump" merges (due
to repeated conflict resolution, etc), I think that actually using the
issue-2897 version is going to be an exercise in unpredictability and
tedium, whereas the reintegrate version will either work correctly or
return an error saying (essentially) that you haven't been treating
the branch like a feature branch.
(There's no reason not to include both features, by the way; they're
orthogonal. I just don't want to include issue-2897 at all unless
several people have been convinced that it actually works well.)
--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: Finalizing what's in 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
David Glasser wrote:
> On Jan 10, 2008 2:18 PM, Ben Collins-Sussman <su...@red-bean.com> wrote:
>> On Jan 10, 2008 1:04 PM, Blair Zajac <bl...@orcaware.com> wrote:
>>
>>> Now after reading the IRC conversation, it appears that the amount of energy
>>> going into #2897 isn't going to be enough for a faster 1.5 release, there's
>>> nobody else really looking at the work. So if we want this feature, we should
>>> merge it soon into trunk and deal with it in trunk.
>> That's an interesting question: is the branch so unstable (at the
>> moment) that would make the trunk impossible to work on? If not,
>> there's no reason for the branch to persist.
>>
>> My vote is the same always (which doesn't have much weight, since I'm
>> not doing any work): Kamesh's branch is THE main use-case for
>> merge-tracking and svnmerge.py. An svn 1.5 release without the
>> ability to track and painlessly re-merge feature branches just isn't
>> interesting to the general public.
>
> The reintegrate branch gives the ability to track and painlessly
> re-merge feature branches.
>
> It may not give as much flexibility as the issue-2897 branch, but I'm
> still not actually convinced that the issue-2897 version will actually
> work as well.
Why is that? How does issue-2897 differ from the reintegrate branch? What use
cases are supported by one and not the other? I haven't been following these
branches closely enough to know the differences between them.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finalizing what's in 1.5
Posted by David Glasser <gl...@davidglasser.net>.
On Jan 10, 2008 2:18 PM, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On Jan 10, 2008 1:04 PM, Blair Zajac <bl...@orcaware.com> wrote:
>
> > Now after reading the IRC conversation, it appears that the amount of energy
> > going into #2897 isn't going to be enough for a faster 1.5 release, there's
> > nobody else really looking at the work. So if we want this feature, we should
> > merge it soon into trunk and deal with it in trunk.
>
> That's an interesting question: is the branch so unstable (at the
> moment) that would make the trunk impossible to work on? If not,
> there's no reason for the branch to persist.
>
> My vote is the same always (which doesn't have much weight, since I'm
> not doing any work): Kamesh's branch is THE main use-case for
> merge-tracking and svnmerge.py. An svn 1.5 release without the
> ability to track and painlessly re-merge feature branches just isn't
> interesting to the general public.
The reintegrate branch gives the ability to track and painlessly
re-merge feature branches.
It may not give as much flexibility as the issue-2897 branch, but I'm
still not actually convinced that the issue-2897 version will actually
work as well.
--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: Finalizing what's in 1.5
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Jan 10, 2008 1:04 PM, Blair Zajac <bl...@orcaware.com> wrote:
> Now after reading the IRC conversation, it appears that the amount of energy
> going into #2897 isn't going to be enough for a faster 1.5 release, there's
> nobody else really looking at the work. So if we want this feature, we should
> merge it soon into trunk and deal with it in trunk.
That's an interesting question: is the branch so unstable (at the
moment) that would make the trunk impossible to work on? If not,
there's no reason for the branch to persist.
My vote is the same always (which doesn't have much weight, since I'm
not doing any work): Kamesh's branch is THE main use-case for
merge-tracking and svnmerge.py. An svn 1.5 release without the
ability to track and painlessly re-merge feature branches just isn't
interesting to the general public.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finalizing what's in 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
Karl Fogel wrote:
> Karl Fogel <kf...@red-bean.com> writes:
>> ...there are some big decisions we haven't made yet, about exactly
>> what goes into 1.5. That's going to need a separate thread (sorry),
>> and I'll post about it right after this. We really need to nail
>> down what's going in, whether we're shipping with an SQLite
>> dependency or not, etc.
>
> Okay, we just had a long IRC conversation about this (see transcript
> below). To summarize: we need to decide what's going into 1.5, and
> here's a list of open questions:
>
> 1. The #2897 (reflective merges) branch. Do we need to ship with
> it for 1.5, or should we punt and say this problem is too
> complex to put into the initial release of merge tracking. The
> latter way would mean adjusting user expectations accordingly,
> carefully documenting what 1.5 does and doesn't handle.
>
> This possibility is no slight on Kamesh, by the way: he's
> putting in a ton of work on the #2897 branch, and reflective
> merge handling should get folded in someday. The only question
> is whether we can afford more delay on 1.5 in particular.
>
> We do not currently have a clear answer about whether to try to
> incorporate that work into 1.5. The branch isn't getting the
> review it needs, because there's so much else going on. Should
> we try to make a decision now? (I won't try to hide the fact
> that I'm worried about merging a branch that big without
> substantial review; and I'm worried about delaying 1.5 more. On
> the other hand, if the feature is close to done and relatively
> stable, I don't want to turn it down, either.)
>
> This is the major outstanding question for 1.5. We need to
> settle it ASAP.
Speaking just from a feature point of view, I haven't looked at the code nor
have a sense how long it would be to stabilize the work, I'm of the mind to get
this into 1.5 now. 1.6 could be a long time coming to get reflective merges
into 1.6 (at least 9 months I would guess at the earliest), which will mean
people will still end up using svnmerge.py to handle this case. I'd like 1.5 to
make most of svnmerge.py obsolete. Not having reflective merges removes one of
the major points of merge-tracking.
Now after reading the IRC conversation, it appears that the amount of energy
going into #2897 isn't going to be enough for a faster 1.5 release, there's
nobody else really looking at the work. So if we want this feature, we should
merge it soon into trunk and deal with it in trunk.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Finalizing what's in 1.5 (was: Getting closer to a 1.5 release?)
Posted by Karl Fogel <kf...@red-bean.com>.
Karl Fogel <kf...@red-bean.com> writes:
> ...there are some big decisions we haven't made yet, about exactly
> what goes into 1.5. That's going to need a separate thread (sorry),
> and I'll post about it right after this. We really need to nail
> down what's going in, whether we're shipping with an SQLite
> dependency or not, etc.
Okay, we just had a long IRC conversation about this (see transcript
below). To summarize: we need to decide what's going into 1.5, and
here's a list of open questions:
1. The #2897 (reflective merges) branch. Do we need to ship with
it for 1.5, or should we punt and say this problem is too
complex to put into the initial release of merge tracking. The
latter way would mean adjusting user expectations accordingly,
carefully documenting what 1.5 does and doesn't handle.
This possibility is no slight on Kamesh, by the way: he's
putting in a ton of work on the #2897 branch, and reflective
merge handling should get folded in someday. The only question
is whether we can afford more delay on 1.5 in particular.
We do not currently have a clear answer about whether to try to
incorporate that work into 1.5. The branch isn't getting the
review it needs, because there's so much else going on. Should
we try to make a decision now? (I won't try to hide the fact
that I'm worried about merging a branch that big without
substantial review; and I'm worried about delaying 1.5 more. On
the other hand, if the feature is close to done and relatively
stable, I don't want to turn it down, either.)
This is the major outstanding question for 1.5. We need to
settle it ASAP.
2. Related to the above: there's the question of whether that
branch truly needs SQLite or whether (as glasser thinks) it can
be done in a more FSFSy way. This question is not itself a
release-definer: it could go either way, just noting it here.
3. Finishing up and merging the reintegrate branch. glasser and I
are working on that, remaining time should be measured in a
small number of weeks. I think this branch is a pretty safe bet
(it's a much smaller problem than #2897), though glasser and I
need to chat about a couple of items in the
'reintegrate-branch-TODO' file.
4. Solution to the 'cp -g' conundrum: well, we came to a pretty
convincing agreement in IRC. This isn't a hard problem
technically, it's just a matter of making a decision. I think
we have made one (see transcript below), and probably the best
course is just to commit it and make sure no one objects
violently.
5. 'log -g' and 'blame -g' need to be fixed; hwright and cmpilato
are both working on that. I think there aren't any difficult
decisions to make here, it's just that they need to be fixed.
This shouldn't take longer than (say) the reintegrate work;
Hyrum, would you agree?
In summary: our biggest open question is #2897. We really need to
make a decision about that soon. It affects our ability to branch 1.5
more than any other issue.
Here's the IRC transcript:
<kfogel> So I see a few major questions still outstanding:
<kfogel> 1. Is the #2897 work going into 1.5?
<kfogel> 2. If so, will it depend on SQLite or not?
<kfogel> 3. (related) Are we trying to ship without SQLite dep?
<markphip> 3. we need it for the node origins cache
<kfogel> 4. How much work left on reintegrate branch?
<kfogel> (I'll say "EOT" when done listing, btw.)
<glasser> markphip: no we don't, that's dirt simple to reimplement
in a more FSFSy way
<kfogel> 5. The 'cp -g' situation. This is more of a plain
decision than an implementation question. I'll expand on
it in a moment; it shouldn't take long, it's just a
discussion.
<glasser> hwright: dannyb was suggesting otherwise when i saw him
the other day :)
<markphip> glasser: excellent!
<kfogel> 6. log -g and blame -g need to be fixed, but that seems
to be happening pretty quickly (yay, hwright and cmpilato)
<kfogel> Okay, EOT.
<kfogel> Is that list missing anything major?
<hwright> glasser: yay for subversion!
<kfogel> (Of course, there's the 19 or so issues marked "1.5" in
the tracker, but I'm going for overview of big things
here.)
<hwright> (the process, not the software)
<markphip> Since you gave EOT ... is 5 still an issue? I thought
that went away back when cmpilato made his changes
<kfogel> markphip: yes, it's still an issue.
<glasser> 1: Um. I can't tell to what degree Kamesh's branch is "an
easy obvious fix" or a big ball of hair, and nobody else is
looking
<kfogel> Before I go into details why, I'd like to get overall
response to 1-6, so let's table that for a moment.
* kfogel was referring to cp -g just now
<markphip> I was under the impression glasser knew how to remove the
need for SQLite if we did #1
<kfogel> glasser: that's what I'm worried about. My instinct is
"big ball of hair" (no slight on Kamesh there, it's a hard
problem), and that we want to just defer that
feature/bugfix until after 1.5, and adjust expectations
accordingly.
<glasser> 2: I think I can make it not depend on SQLite. And if we
don't put that in at all, we definitely don't need SQLite
<kfogel> whew -- both halves of that statement are reassuring
<glasser> kfogel: Yeah. Like, the core of what he's doing is
actually pretty localized. On the other hand, it's a
subtle heuristic, dunno how easy to implement
<kfogel> glasser: I'm sorry so much is on your shoulders, btw :-(.
Just personally a difficult time for me, a lot of my life
is consumed with moving logistics right now, so I can't
exceed my 20 hrs/wk easily.
<markphip> the node origins cache seems pretty critical for
performance. So I'd be interested to hear how that can be
replaced
<glasser> 3: I don't care about deps or not, I just care about using
the DB correctly. If we ship wtih SQLite dep we need to
rewrite all the SQLite code anyway to not be broken
(copies/deletes). I know how, I'd just rather not if
unnecessary
<kfogel> *nod* ok
<glasser> kfogel: Oh, understood. And I'm spending a bit of time on
non-1.5 stuff at work (not to mention outside of work)
right now anyway to give myself a breather
<markphip> 3. I agree. having the dep is not the issue
<glasser> 4: I dunno, I think we're almost ready to merge back. I
kind of think we could do it right now. It might even help
Hyrum with the log/blame stuff
<markphip> removing it would be great of course
<glasser> Though I haven't looked at our TODOs in the past couple of
days
<kfogel> ok -- looks like I was more concerned about the pure
sqlite dep question than anyone else, but I'm happy to
relax about that.
<kfogel> glasser: I'm chipping away at them, but I think I will
need your help for some. I'll take a look now while
you/others are typing
<markphip> I think a lot of people mistook the work glasser was doing
as a desire to remove the dependency, when he was really
just fixing the problems
<glasser> 5: Well, we have a current decision. cmpilato even added
some doc about it to the "svn cp --help" yesterday (sadly
the text isn't necessarily... constructive? but I'm not
sure how to do it better)
<kfogel> markphip: (yes, that may have happened.)
<markphip> has there been any recent threads about cp -g ? I really
thought cmpilato just removed the need for it completely
<kfogel> Okay, here is my understanding about cp -g:
<kfogel> (and I'll check this with cmpilato after I type it, as
he's sitting right next to me)
<glasser> He removed the need. In return we get "mergeinfo gets
corrupted in a way that nobody not on IRC right now will
ever understand". I'm not convinced that I care too much,
though
<kfogel> Currently, 'svn cp' with no '-g' will be a purely local
operation, but will not preserve mergeinfo in certain
circumstances. With -g, it does (or just may?) contact the
repository, but it will always preserve all mergeinfo;
however, you'd have to remember to type -g.
* kfogel checks with cmpilato now
<kfogel> Mike says he removed the option entirely!
* kfogel listens to mike
<glasser> Dumb question: how did "cp -g" ever even work? Wouldn't
there have been a race condition between the parent's
mergeinfo when you type "svn cp -g" and whne you actually
commit anyway?
<markphip> it is based on what you copied though, right? And there
is no race there
<kfogel> Mike and I are settling on a solution here; it might be
nice to let you all in on it :-).
<markphip> Issue 2897 is our only remaining P1
<kfogel> I'm not going to go into details of what 'svn cp -g' *did*
precisely, except to say that it preserved some mergeinfo
by contacting the server (I don't know all the details).
<kfogel> But Mike and I propose this:
<kfogel> (one sec, sorry)
<kfogel> mike is joining
<kfogel> typa typa typa
<cmpilato> Here's the proposal: we never re-add -g to 'svn cp';
instead, we make that behavior the default for 'svn cp'.
then, we add --ignore-mergeinfo (or somesuch) which
actually can apply to *all four* forms of 'svn cp' (i think
there's valid use-cases for such)
<kfogel> (the priority this proposal is aiming for, as soon as mike
gets done typing, is that the most important thing is for
cp to be correct by default, and local-only operation can
be a user-chosen decision if necessary, I think)
<cmpilato> yes, this changes the default behavior of 'svn cp WC WC'
w.r.t. repos contact.
<cmpilato> no, we don't care.
<kfogel> Amen. bikeshed: --local-mergeinfo-only for the opt, but
whatever
<cmpilato> because we value correctness, and merge tracking is a big
enough change that the whole world gets to be rocked a
little bit anyway.
<glasser> If we can wrap the "can't contact server" error in a "try
--local-only" message, then I'm very +1
<kfogel> (glasser: after this discussion, I have a couple of quick
questions for you re reint, that may help me take care of
some of the other todo items so you can concentrate on
2897; more on that right after this cp discussion)
* cmpilato doesn't like the current do-the-best-you-can behavior.
<pburba >if we really don't care then about the change in default
WC->WC copy behavior then +1 here too. That was ever the
*only* objection as I recall.
<glasser> (I mean, the big downside is if the "svn cp" is actually
being run by some tool N levels away from a user-editable
command-line)
<cmpilato> yes, that's true, but none of our subcommands ever
*promise* to be offline-only.
<kfogel> I think we sort of care, but not enough to tolerate
incorrect default behavior. Yes, it's too bad we lose the
local-only behavior, but that's an okay price to pay. We
need to make sure to fix up the error messages as glasser
says, and note this prominently in the release notes.
<cmpilato> we aren't violating promises in this way.
<hwright> so, would 'svn cp' still create mergeinfo? or would the
current behavior stick?
<cmpilato> that some commands didn't need to contact the repo before
turned out to be beneficial (and a selling point), but...
<kfogel> (and note that we're free to *restore* local-only behavior
in future releases, when our wc can cache more data
perhaps)
<cmpilato> 'svn cp' would not *create* mergeinfo; though it might
duplicate some from the source/source's-parents
<kfogel> glasser: for "some tool", read "TortoiseSVN", and we work
closely enough with them that we can make sure they know
what to do.
<markphip> would it always contact the repository?
<cmpilato> svn cp would always contact the repository unless
WC-WC-style and asked not to contact the repos.
<cmpilato> (basically)
<markphip> I thought people considered that not acceptable?
<cmpilato> i was one of those people.
<glasser> kfogel: Tortoise is fine, I'm thinking of other things
that are doing a higher-level op that happens to include a
cp in the middle. But whatever, maybe it'll be OK
<cmpilato> people change.
<glasser> If the answer is "these people need to rewrite their
tools, oh well", then, mm, ok
<kfogel> glasser: yeah, there will be fallout. But having
mergeinfo discovered later to be incorrect will produce
much worse fallout, in the long run.
<kfogel> because the latter is a time bomb, where as the former
hits you right up front, and has a clear immediate
workaround (the new option).
<glasser> agreed
<cmpilato> +1
<markphip> I'm slightly less convinced
<kfogel> now, that error will only come after an N-second or
N-minute timeout while it tries to contact the repos from
your airplane seat...
<pburba >cmpilato: We'd contact the repos even if the copied source
path has explicit mergeinfo?
<markphip> if the information is potentially critical, then I am not
sure a user should have the option to do it incorrectly.
If contacting the repository is a show-stopper, it seems
like we need a way to defer it or something as we had
discussed way back when
<kfogel> markphip: we can potentially fix this decision in later
releases. But we can't go back and fix people's mergeinfo
if it's wrong.
<cmpilato> pburba: oh! good point! no, that'd be silly.
<kfogel> markphip: I agree that would be a better solution, but
trying to implement it for 1.5 will cause too much delay,
that's all. Let's defer that.
<pburba >cmpilato: I think the if the copy source has a WC parent
with explicit mergeinfo to inherit we'd be in the same boat
(no need to copy). But then I think about mixed rev WC
(something glasser mentioned a while back) and get sick.
<cmpilato> pburba: but i'm not sure we can trust anything other than
the exact copy source -- not its parents.
<cmpilato> oh. heh. you were in the same town i was, there.
<cmpilato> i'd feel much better about saying outright "we only trust
the copy source"
<cmpilato> much less fuzzy and complex to explain to folks.
* pburba meant "no need to copy" -->"no need to contact repos" if that wasnt obvious
<markphip> kfogel: thanks, that is a good point. This solution could
be improved later without changing the interface
<kfogel> very much, yeah
<glasser> kfogel: Oh! I have a super huge reason why this change is
good :)
<kfogel> hit us!
<glasser> kfogel: because otherwise every wc-wc copy (which in
practice is a rename) introduces mergeinfo on the kid that
differs from its parents
<glasser> which breaks --reintegrate :)
* kfogel ponders that
<kfogel> really?
<kfogel> every one?
<glasser> maybe not quite every
<cmpilato> even same-dir copies?
<glasser> (for the record, I am still of the opinion of "if you ever
end up with explicit mergeinfo that isn't at the top of a
branch, and you're a relatively simple project, not some
enormous beast, you are wrong")
<glasser> (eg, "open source projects smaller than mozilla shouldn't
have mixed mergeinfo")
<kfogel> glasser: I think that's probably true almost always, sure.
But it's hard to predict usage patterns; there may be ways
of working we haven't thought of.
<kfogel> okay, it sounds like we have a general agreement here,
anyway (and I doubt the list is going to reverse that).
glasser, can I poke you about some reint stuff briefly?
<glasser> (Or to put it another way: the metnal model of mergeinfo
when it's only at the root of branches is really easy to
explain to people and comprehend. Nested mergeinfo is
stupidly complex)
<markphip> help me out here ... I am working in one of these "sane
branches". I rename/move some files (refactoring - which
someday we will handle) does this need to create mergeinfo
on those files?
<glasser> sure
<glasser> I'm lunching soon though
<kfogel> glasser: oh, let's answer markphip first, I can hit you up
after lunch.
<kfogel> better to get to the bottom of cp questions
<kfogel> markphip: I believe the answer is the explicit empty
mergeinfo needs to be created?
<kfogel> I am SO not sure about that, though.
<kfogel> or rather, explicit mergeinfo that either preserves the
source's mergeinfo, or is empty.
<kfogel> it doesn't want to inherit from the new parent, since that
would be invalid
* kfogel waits for someone to tell him he's insane
<markphip> I ask because I do not think simple open source projects
would consider that they are doing anything strange or
wrong
<kfogel> well, copying isn't strange or wrong
<kfogel> subversion should do the right thing w/ mergeinfo under
the hood, without bothering the user, is the wohle point
here.
<glasser> markphip: i think the easy answer is "if all mergeinfo is
at the root, and you're allowed to contact the server, then
it all elides away"
<markphip> if it creates mergeinfo that makes things look like you
did something strange or wrong though ??
<kfogel> markphip: not sure what you maen
<markphip> glasser: well that is what I am getting at then. Are we
saying we would "fix" this problem
<markphip> kfogel: if we create mergeinfo on the files, it starts to
resemble a branch where cherry picking happened
<markphip> when all they really did was "normal" development
<markphip> we ideally want a system that encourages and preserves
mergeinfo at the branch root
<kfogel> markphip: I think glasser's point is that contacting the
server allows us to avoid setting that explicit mergeinfo
(empty or otherwise) in most cases.
<kfogel> Which I agree with, if that's what he's saying.
<markphip> kfogel: right, and that was really what my original
question was
<kfogel> (Heck, I agree with it even if he's not saying it!)
<kfogel> ok
<markphip> I agree that should be our goal
<kfogel> so the answer satisfies you, I'm presuming :-)
<markphip> yes
<kfogel> cool
<markphip> if the root of your WC is the only place that contains
mergeinfo, could we not optimize this and not contact the
server?
<kfogel> glasser: I'll hit you up after lunch about the reint stuff
<markphip> too much to check?
<kfogel> (and then I think I'll be ready to post a State of the
Onion mail)
<hwright> kfogel: re 6: there may be a bit of design work, now that
we don't have a way to detect branching copies.
<kfogel> markphip: I think the deal is, there are some
circumstances where the wc will not have all the info we
need, and in those circumstances, we'll need to contact the
server.
<hwright> but I don't think it to be overly complex.
<kfogel> hwright: ooooh. uh, okay (shiver)
<kfogel> I hear "design work" and worry.
<kfogel> You're talking about blame, not log?
<hwright> well, not *that* kind of design work, more like "how does
this really impact us, and what do we have to do about it?"
design work.
<kfogel> ah, okay
<hwright> both will need a look-see.
<kfogel> ok
<hwright> witness the failing blame test on trunk right now. :(
<kfogel> I think enough information has been gathered here. I'm
gonna go grab lunch and then try to post the promised
followup to Mark on dev@.
<kfogel> hwright: *nod* this is separate from the 'log -g output
format' discussion, though?
<hwright> seperate, but that discussion is related.
<kfogel> (There, I think the final answer is that our non-xml
cmdline client log -g output simply cannot be very
intuitive, and we'll have to live with that)
<hwright> because we can't filter history in front of branching
revisions, our log output now becomes very verbose, hence
the discussion.
<kfogel> s/in front of/earlier than/ ?
<hwright> yes
<kfogel> there might be ways the client could bunch stuff up and
then spew it after removing redundancies, but that would
lower responsiveness.
<kfogel> hmmm
<hwright> yup. cmpilato and I had a conversation about this last
night, which prompted his mail.
<hwright> we were both pretty tired, though, so the details are a
bit fuzzy. :P
<kfogel> ok
<kfogel> brain full, stomach empty
<kfogel> back l8r
<hwright> same.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting closer to a 1.5 release?
Posted by Karl Fogel <kf...@red-bean.com>.
"Mark Phippard" <ma...@gmail.com> writes:
> I'd like to hear what people doing the work think about where we are
> in relationship to starting the 1.5 release process.
>
> I know there is some branch activity that needs to be wrapped up and
> merged back to trunk before we can branch for 1.5. Other than the
> reintegrate branch, are there any others that need to be merged to
> trunk before we branch? Estimates on when we will be ready?
>
> Anyone want to give their feelings on what needs to happen after we
> branch in order to get us to RC1?
Two independent questions going on here:
1) When do we branch?
2) How close are we to RC1 (and thence to final release)?
Taking (1) first: since we're probably holding up non-1.5 trunk
development, we should branch as soon as we can. But there are some
big decisions we haven't made yet, about exactly what goes into 1.5.
That's going to need a separate thread (sorry), and I'll post about it
right after this. We really need to nail down what's going in,
whether we're shipping with an SQLite dependency or not, etc.
As far as (2), I think that once we branch, we're probably a month
away from an RC1 (though some kind of alpha could come sooner).
That's pessimistic, but 1.5 is an unusually large release and we'll
have a lot of stabilizing to do.
> Finally, any ideas on things we can do to kickstart this process and
> get things wrapped up? I know we all want this release done so we can
> move on. When I start looking at the calendar, counting out when we
> might have an RC1, then counting out to when there would be a GA it
> gets depressing. That is a bad way to start a new year -- depressed.
> I know there are a lot of us that have been working hard to get this
> release done. What more can be done to move the process along and
> maybe pick up some new momentum? Ideas welcomed.
IMHO the single most important thing we can do is make the hard calls
about what goes in and what doesn't, and stick to those decisions.
(Again, separate thread, coming in a moment.)
> When we branch for 1.5 I intend to produce and host various binaries
> based on the branch so that we can hopefully get some testing and
> feedback that will move us closer to RC1.
Excellent! That'll be a big help.
> Anyway, not expecting definitive answers but it is good to hear
> feedback from others. We have not talked about this in quite a while
> with the holidays and all. On the positive side, it seems like things
> are wrapping up and we have solutions in place or being finalized for
> the main problems.
Agreed.
More in a bit,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Getting closer to a 1.5 release?
Posted by Paul Burba <pb...@collab.net>.
> -----Original Message-----
> From: Kamesh Jayachandran
> Sent: Thursday, January 10, 2008 9:26 AM
> To: Paul Burba
> Cc: Mark Phippard; dev@subversion.tigris.org
> Subject: Re: Getting closer to a 1.5 release?
>
>
> > log_tests-17
> > log-tests-19
> > blame-tests-10
> > blame-tests-11
> >
> > Kamesh,
> >
> > Blame tests 10 and 11 are failing on the Win32 buildbot
> since sometime
> > before or at r28827 but after r28776. Are the failures you
> are seeing
> > anything on your branch anything like those the buildbot is having?
> >
> http://www.mobsol.be/buildbot/win32-xp%20VS2005/builds/3041/step-Test%
> > 20
> > fsfs%2Bra_local/0
> >
> > Paul
> >
>
> No. The cause was peculiar to issue-2897 branch, made them to PASS at
> r28843.
Yeah, I just looked at r28823 and 28843, sorry for the noise.
> With regards
> Kamesh Jayachandran
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting closer to a 1.5 release?
Posted by Kamesh Jayachandran <ka...@collab.net>.
> log_tests-17
> log-tests-19
> blame-tests-10
> blame-tests-11
>
> Kamesh,
>
> Blame tests 10 and 11 are failing on the Win32 buildbot since sometime
> before or at r28827 but after r28776. Are the failures you are seeing
> anything on your branch anything like those the buildbot is having?
> http://www.mobsol.be/buildbot/win32-xp%20VS2005/builds/3041/step-Test%20
> fsfs%2Bra_local/0
>
> Paul
>
No. The cause was peculiar to issue-2897 branch, made them to PASS at
r28843.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: Getting closer to a 1.5 release?
Posted by sv...@mobsol.be.
Quoting Paul Burba <pb...@collab.net>:
> > -----Original Message-----
> > From: Kamesh Jayachandran [mailto:kamesh@collab.net]
> > Sent: Thursday, January 10, 2008 4:15 AM
> > To: Mark Phippard
> > Cc: dev@subversion.tigris.org
> > Subject: Re: Getting closer to a 1.5 release?
> >
> > Current status of issue-2897 branch.
> >
> > Pending items
> > ----------------------------
> > 1. Address David Glasser's comments on this branch, Which I
> > hope to complete by tomorrow.
> > 2. Stylistic adjustments for long func names + long parameter names.
> >
> >
> > Problem I found yesterday since my synch up from '/trunk'.(r28821)
> > --------------------------------------------------------------
> > --------------------------------
> > Since this synch up log_tests-17 and log-tests-19, blame-tests-10,
> > blame-tests-11 starts failing thanks to r28729.
> >
> > The trigger of a failure being 'no-op mergeinfo' recording in r28729.
> >
> > I am working on making these testcases to PASS.
>
> log_tests-17
> log-tests-19
> blame-tests-10
> blame-tests-11
>
> Kamesh,
>
> Blame tests 10 and 11 are failing on the Win32 buildbot since sometime
> before or at r28827 but after r28776. Are the failures you are seeing
> anything on your branch anything like those the buildbot is having?
> http://www.mobsol.be/buildbot/win32-xp%20VS2005/builds/3041/step-Test%20
> fsfs%2Bra_local/0
Paul,
these failing tests on Windows were fixed yesterday in r28840. The same tests
also fail over ra_serf, but that has to do with ra_serf calculating an
incorrect delta base path in some situations which the code that sets up the
merge_info_history repo happens to trigger.
Lieven
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: Getting closer to a 1.5 release?
Posted by Paul Burba <pb...@collab.net>.
> -----Original Message-----
> From: Kamesh Jayachandran [mailto:kamesh@collab.net]
> Sent: Thursday, January 10, 2008 4:15 AM
> To: Mark Phippard
> Cc: dev@subversion.tigris.org
> Subject: Re: Getting closer to a 1.5 release?
>
> Current status of issue-2897 branch.
>
> Pending items
> ----------------------------
> 1. Address David Glasser's comments on this branch, Which I
> hope to complete by tomorrow.
> 2. Stylistic adjustments for long func names + long parameter names.
>
>
> Problem I found yesterday since my synch up from '/trunk'.(r28821)
> --------------------------------------------------------------
> --------------------------------
> Since this synch up log_tests-17 and log-tests-19, blame-tests-10,
> blame-tests-11 starts failing thanks to r28729.
>
> The trigger of a failure being 'no-op mergeinfo' recording in r28729.
>
> I am working on making these testcases to PASS.
log_tests-17
log-tests-19
blame-tests-10
blame-tests-11
Kamesh,
Blame tests 10 and 11 are failing on the Win32 buildbot since sometime
before or at r28827 but after r28776. Are the failures you are seeing
anything on your branch anything like those the buildbot is having?
http://www.mobsol.be/buildbot/win32-xp%20VS2005/builds/3041/step-Test%20
fsfs%2Bra_local/0
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting closer to a 1.5 release?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Current status of issue-2897 branch.
Pending items
----------------------------
1. Address David Glasser's comments on this branch, Which I hope to
complete by tomorrow.
2. Stylistic adjustments for long func names + long parameter names.
Problem I found yesterday since my synch up from '/trunk'.(r28821)
----------------------------------------------------------------------------------------------
Since this synch up log_tests-17 and log-tests-19, blame-tests-10,
blame-tests-11 starts failing thanks to r28729.
The trigger of a failure being 'no-op mergeinfo' recording in r28729.
I am working on making these testcases to PASS.
With regards
Kamesh Jayachandran
Mark Phippard wrote:
> I'd like to hear what people doing the work think about where we are
> in relationship to starting the 1.5 release process.
>
> I know there is some branch activity that needs to be wrapped up and
> merged back to trunk before we can branch for 1.5. Other than the
> reintegrate branch, are there any others that need to be merged to
> trunk before we branch? Estimates on when we will be ready?
>
> Anyone want to give their feelings on what needs to happen after we
> branch in order to get us to RC1?
>
> Finally, any ideas on things we can do to kickstart this process and
> get things wrapped up? I know we all want this release done so we can
> move on. When I start looking at the calendar, counting out when we
> might have an RC1, then counting out to when there would be a GA it
> gets depressing. That is a bad way to start a new year -- depressed.
> I know there are a lot of us that have been working hard to get this
> release done. What more can be done to move the process along and
> maybe pick up some new momentum? Ideas welcomed.
>
> When we branch for 1.5 I intend to produce and host various binaries
> based on the branch so that we can hopefully get some testing and
> feedback that will move us closer to RC1.
>
> Anyway, not expecting definitive answers but it is good to hear
> feedback from others. We have not talked about this in quite a while
> with the holidays and all. On the positive side, it seems like things
> are wrapping up and we have solutions in place or being finalized for
> the main problems.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org