You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2008/01/10 19:04:01 UTC
Re: Finalizing what's in 1.5
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
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 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 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 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