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/04/06 14:33:41 UTC
Subversion 1.5 issues blocking RC1
I thought it would be useful to start a new thread where we can gather
a sort of to-do list of things we need to look at before we can make
the RC1. We did a lot of work yesterday to get close to the release,
but there are still some things left to do.
1) Clean out STATUS. Hyrum pointed this out. Basically, there were a
couple of items discovered yesterday that got fixed late and added to
STATUS. Getting them approved for backport should be trivial but
still needs to be done.
2) Mergeinfo API.
a) As Bert and Stefan have pointed out, the new API can be pretty
slow. The new API is good, they just have a valid case for leaving
the "old" API in place rather than remove it. I have to say we had a
few instances in the JavaHL tests where it the old API was more
appropriate. For example, sometimes you just want to check that there
is mergeinfo, you do not care so much about the details. The log
based approach is too heavy for this.
b) Likely bug in the new API. It appears that the new API only works
when TARGET is a WC. The old API also supported a URL. We had to
change the JavaHL tests because of this. At the time, I thought this
was OK, but now realize it is probably a bug. If nothing else, the
error message has to be better.
Mike Pilato, can you look at these?
3) Reintegrate bugs. David Glasser pointed out a couple of small bugs
that need to be fixed when using reintegrate.
http://svn.haxx.se/dev/archive-2008-04/0291.shtml
I think we probably need to put the --force option back into the API
so that it can pass it along to the merge API it eventually calls.
Julian, since you removed force, could you look at these?
4) Reintegrate "overhaul". David Glasser also has proposed some
significant changes to the API.
http://svn.haxx.se/dev/archive-2008-04/0288.shtml
Given that there is no one available to code these changes, I am in
favor of punting this to 1.6.
Comments?
5) Stefan pointed out a regression when checking out the repository root.
http://subversion.tigris.org/issues/show_bug.cgi?id=3167
It looks like Lieven is looking into this.
6) I think I found a bug in log -g when the item has been renamed:
http://svn.haxx.se/dev/archive-2008-04/0235.shtml
I think we could fix this later, but it needs to be looked at.
Hyrum, do you have any time to look at this?
I think restoring and fixing the mergeinfo API is probably the biggest
blocker on this list, especially since it bleeds into the bindings
which need to catch up. Hopefully we can tackle this list quickly and
get the RC1 wrapped up.
--
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: Subversion 1.5 issues blocking RC1
Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
> Mark Phippard wrote:
>> 2) Mergeinfo API.
>>
>> a) As Bert and Stefan have pointed out, the new API can be pretty
>> slow. The new API is good, they just have a valid case for leaving
>> the "old" API in place rather than remove it. I have to say we had a
>> few instances in the JavaHL tests where it the old API was more
>> appropriate. For example, sometimes you just want to check that there
>> is mergeinfo, you do not care so much about the details. The log
>> based approach is too heavy for this.
>
> I'm fine with re-adding a completely naive svn_client_get_mergeinfo()
> (so named for closer parity with the RA API), but I oppose re-adding the
> "eligible" version of this API.
On second thought, I'll keep the name as is because this function needs to
return a hash mapping full URLs to rangelists -- it's not technically
returning "mergeinfo".
>> b) Likely bug in the new API. It appears that the new API only works
>> when TARGET is a WC. The old API also supported a URL. We had to
>> change the JavaHL tests because of this. At the time, I thought this
>> was OK, but now realize it is probably a bug. If nothing else, the
>> error message has to be better.
>
> Doh!
Hrm. I can't seem to reproduce this at the command-line client level:
### URL SOURCE, URL TARGET
$ svn mergeinfo http://svn.collab.net/repos/svn/trunk \
http://svn.collab.net/repos/svn/branches/1.5.x
r29085
r29091
r29094
...
r30378
r30380
r30392
$ svn mergeinfo http://svn.collab.net/repos/svn/trunk \
http://svn.collab.net/repos/svn/branches/1.5.x \
--show-revs eligible
r29083
r29090
r29092
...
r30398
r30401
r30402
### WC SOURCE, URL TARGET
$ svn mergeinfo . \
http://svn.collab.net/repos/svn/branches/1.5.x
subversion/svn/main.c:1991: (apr_err=205000)
svn: Try 'svn help' for more info
subversion/svn/mergeinfo-cmd.c:80: (apr_err=205000)
svn: Path '' is not a URL
$ svn mergeinfo . \
http://svn.collab.net/repos/svn/branches/1.5.x \
--show-revs eligible
subversion/svn/main.c:1991: (apr_err=205000)
svn: Try 'svn help' for more info
subversion/svn/mergeinfo-cmd.c:80: (apr_err=205000)
svn: Path '' is not a URL
### URL SOURCE, WC TARGET
$ svn mergeinfo http://svn.collab.net/repos/svn/trunk \
../subversion-1.5.x
r29085
r29091
r29094
...
r30378
r30380
r30392
$ svn mergeinfo http://svn.collab.net/repos/svn/trunk \
../subversion-1.5.x \
--show-revs eligible
r29083
r29090
r29092
...
r30398
r30401
r30402
### WC SOURCE, WC TARGET
$ svn mergeinfo . \
../subversion-1.5.x
subversion/svn/main.c:1991: (apr_err=205000)
svn: Try 'svn help' for more info
subversion/svn/mergeinfo-cmd.c:80: (apr_err=205000)
svn: Path '' is not a URL
$ svn mergeinfo . \
../subversion-1.5.x \
--show-revs eligible
subversion/svn/main.c:1991: (apr_err=205000)
svn: Try 'svn help' for more info
subversion/svn/mergeinfo-cmd.c:80: (apr_err=205000)
svn: Path '' is not a URL
$
Do the Java APIs pass unspecified peg revisions into the API or something?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Subversion 1.5 issues blocking RC1
Posted by Stefan Küng <to...@gmail.com>.
Mark Phippard wrote:
> On Mon, Apr 7, 2008 at 10:10 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> Mark Phippard wrote:
>>
>>> I thought it would be useful to start a new thread where we can gather
>>> a sort of to-do list of things we need to look at before we can make
>>> the RC1. We did a lot of work yesterday to get close to the release,
>>> but there are still some things left to do.
>>>
>>> 1) Clean out STATUS. Hyrum pointed this out. Basically, there were a
>>> couple of items discovered yesterday that got fixed late and added to
>>> STATUS. Getting them approved for backport should be trivial but
>>> still needs to be done.
>>>
>>> 2) Mergeinfo API.
>>>
>>> a) As Bert and Stefan have pointed out, the new API can be pretty
>>> slow. The new API is good, they just have a valid case for leaving
>>> the "old" API in place rather than remove it. I have to say we had a
>>> few instances in the JavaHL tests where it the old API was more
>>> appropriate. For example, sometimes you just want to check that there
>>> is mergeinfo, you do not care so much about the details. The log
>>> based approach is too heavy for this.
>>>
>> I'm fine with re-adding a completely naive svn_client_get_mergeinfo() (so
>> named for closer parity with the RA API), but I oppose re-adding the
>> "eligible" version of this API.
>
> That is fine with me. I cannot speak for Stefan or Bert. I think the
> main place where the performance hit becomes ugly is in getting the
> already merged revisions.
I only need svn_client_get_mergeinfo(), I haven't used the other APIs.
The reasons I need this API:
For the log dialog, I'd like to mark already merged revisions. To do
that, we first fetch the log (which we might already have in our cache),
then we call svn_client_get_mergeinfo(), go through the returned hash
and then mark the merged revisions.
The APIs currently available are not really suited for this, because
they both fetch the log too (svn_client_mergeinfo_log_eligible and
svn_client_mergeinfo_log_merged). If there was an API which would
combine those two, that would be a start - I need *all* log entries and
mark those which have already been merged, not just either the merged or
not-merged ones.
But since we can cache the log info in TSVN now, I'd rather have the
svn_client_get_mergeinfo() API back...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: Subversion 1.5 issues blocking RC1
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Apr 7, 2008 at 10:10 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Mark Phippard wrote:
>
> > I thought it would be useful to start a new thread where we can gather
> > a sort of to-do list of things we need to look at before we can make
> > the RC1. We did a lot of work yesterday to get close to the release,
> > but there are still some things left to do.
> >
> > 1) Clean out STATUS. Hyrum pointed this out. Basically, there were a
> > couple of items discovered yesterday that got fixed late and added to
> > STATUS. Getting them approved for backport should be trivial but
> > still needs to be done.
> >
> > 2) Mergeinfo API.
> >
> > a) As Bert and Stefan have pointed out, the new API can be pretty
> > slow. The new API is good, they just have a valid case for leaving
> > the "old" API in place rather than remove it. I have to say we had a
> > few instances in the JavaHL tests where it the old API was more
> > appropriate. For example, sometimes you just want to check that there
> > is mergeinfo, you do not care so much about the details. The log
> > based approach is too heavy for this.
> >
>
> I'm fine with re-adding a completely naive svn_client_get_mergeinfo() (so
> named for closer parity with the RA API), but I oppose re-adding the
> "eligible" version of this API.
That is fine with me. I cannot speak for Stefan or Bert. I think the
main place where the performance hit becomes ugly is in getting the
already merged revisions.
--
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: Subversion 1.5 issues blocking RC1
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> I thought it would be useful to start a new thread where we can gather
> a sort of to-do list of things we need to look at before we can make
> the RC1. We did a lot of work yesterday to get close to the release,
> but there are still some things left to do.
>
> 1) Clean out STATUS. Hyrum pointed this out. Basically, there were a
> couple of items discovered yesterday that got fixed late and added to
> STATUS. Getting them approved for backport should be trivial but
> still needs to be done.
>
> 2) Mergeinfo API.
>
> a) As Bert and Stefan have pointed out, the new API can be pretty
> slow. The new API is good, they just have a valid case for leaving
> the "old" API in place rather than remove it. I have to say we had a
> few instances in the JavaHL tests where it the old API was more
> appropriate. For example, sometimes you just want to check that there
> is mergeinfo, you do not care so much about the details. The log
> based approach is too heavy for this.
I'm fine with re-adding a completely naive svn_client_get_mergeinfo() (so
named for closer parity with the RA API), but I oppose re-adding the
"eligible" version of this API.
> b) Likely bug in the new API. It appears that the new API only works
> when TARGET is a WC. The old API also supported a URL. We had to
> change the JavaHL tests because of this. At the time, I thought this
> was OK, but now realize it is probably a bug. If nothing else, the
> error message has to be better.
Doh!
> Mike Pilato, can you look at these?
Yup.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Subversion 1.5 issues blocking RC1
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Mark Phippard wrote:
> On Mon, Apr 7, 2008 at 9:17 AM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>> Mark Phippard wrote:
>>
>>> On Sun, Apr 6, 2008 at 10:33 AM, Mark Phippard <ma...@gmail.com> wrote:
>>>
>>>> I thought it would be useful to start a new thread where we can gather
>>>> a sort of to-do list of things we need to look at before we can make
>>>> the RC1. We did a lot of work yesterday to get close to the release,
>>>> but there are still some things left to do.
>>>>
>> ...
>>
>>
>>>> 6) I think I found a bug in log -g when the item has been renamed:
>>>> http://svn.haxx.se/dev/archive-2008-04/0235.shtml
>>>> I think we could fix this later, but it needs to be looked at.
>>>>
>>>> Hyrum, do you have any time to look at this?
>>>>
>>>>
>>>> I think restoring and fixing the mergeinfo API is probably the biggest
>>>> blocker on this list, especially since it bleeds into the bindings
>>>> which need to catch up. Hopefully we can tackle this list quickly and
>>>> get the RC1 wrapped up.
>>>>
>>> So, great progress already. It seems like we just need to finalize on
>>> the mergeinfo API stuff and we are good to go. Unless someone was
>>> going to try to tackle the log -g problem today.
>>>
>> I think I'm that someone. :)
>>
>> I've got a number of other (non-svn) things to take care of today, so it
>> might be this evening before I realistically get a chance to start looking
>> at this.
>
> Well, FWIW, I do not think it would be the end of the world if this
> fix came in 1.5.1 (or RC2 if we have one).
Honestly, postponing it is probably more realistic at this point. (Of
course, others are free to look at it if the wish!)
-Hyrum
Re: Subversion 1.5 issues blocking RC1
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Apr 7, 2008 at 9:17 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Mark Phippard wrote:
>
> > On Sun, Apr 6, 2008 at 10:33 AM, Mark Phippard <ma...@gmail.com> wrote:
> >
> > > I thought it would be useful to start a new thread where we can gather
> > > a sort of to-do list of things we need to look at before we can make
> > > the RC1. We did a lot of work yesterday to get close to the release,
> > > but there are still some things left to do.
> > >
> >
> ...
>
>
> >
> > > 6) I think I found a bug in log -g when the item has been renamed:
> > > http://svn.haxx.se/dev/archive-2008-04/0235.shtml
> > > I think we could fix this later, but it needs to be looked at.
> > >
> > > Hyrum, do you have any time to look at this?
> > >
> > >
> > > I think restoring and fixing the mergeinfo API is probably the biggest
> > > blocker on this list, especially since it bleeds into the bindings
> > > which need to catch up. Hopefully we can tackle this list quickly and
> > > get the RC1 wrapped up.
> > >
> >
> > So, great progress already. It seems like we just need to finalize on
> > the mergeinfo API stuff and we are good to go. Unless someone was
> > going to try to tackle the log -g problem today.
> >
>
> I think I'm that someone. :)
>
> I've got a number of other (non-svn) things to take care of today, so it
> might be this evening before I realistically get a chance to start looking
> at this.
Well, FWIW, I do not think it would be the end of the world if this
fix came in 1.5.1 (or RC2 if we have one).
--
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: Subversion 1.5 issues blocking RC1
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Mark Phippard wrote:
> On Sun, Apr 6, 2008 at 10:33 AM, Mark Phippard <ma...@gmail.com> wrote:
>> I thought it would be useful to start a new thread where we can gather
>> a sort of to-do list of things we need to look at before we can make
>> the RC1. We did a lot of work yesterday to get close to the release,
>> but there are still some things left to do.
...
>> 6) I think I found a bug in log -g when the item has been renamed:
>> http://svn.haxx.se/dev/archive-2008-04/0235.shtml
>> I think we could fix this later, but it needs to be looked at.
>>
>> Hyrum, do you have any time to look at this?
>>
>>
>> I think restoring and fixing the mergeinfo API is probably the biggest
>> blocker on this list, especially since it bleeds into the bindings
>> which need to catch up. Hopefully we can tackle this list quickly and
>> get the RC1 wrapped up.
>
> So, great progress already. It seems like we just need to finalize on
> the mergeinfo API stuff and we are good to go. Unless someone was
> going to try to tackle the log -g problem today.
I think I'm that someone. :)
I've got a number of other (non-svn) things to take care of today, so it
might be this evening before I realistically get a chance to start
looking at this.
-Hyrum
Re: Subversion 1.5 issues blocking RC1
Posted by Mark Phippard <ma...@gmail.com>.
Just another follow-up.
On Mon, Apr 7, 2008 at 9:05 AM, Mark Phippard <ma...@gmail.com> wrote:
> > 2) Mergeinfo API.
> >
> > a) As Bert and Stefan have pointed out, the new API can be pretty
> > slow. The new API is good, they just have a valid case for leaving
> > the "old" API in place rather than remove it. I have to say we had a
> > few instances in the JavaHL tests where it the old API was more
> > appropriate. For example, sometimes you just want to check that there
> > is mergeinfo, you do not care so much about the details. The log
> > based approach is too heavy for this.
>
> Bert posted a patch for this. I know we will need to update JavaHL to
> put back our equivalent API.
>
>
> > b) Likely bug in the new API. It appears that the new API only works
> > when TARGET is a WC. The old API also supported a URL. We had to
> > change the JavaHL tests because of this. At the time, I thought this
> > was OK, but now realize it is probably a bug. If nothing else, the
> > error message has to be better.
> >
> > Mike Pilato, can you look at these?
These issues are now DONE and proposed for backport.
> > 6) I think I found a bug in log -g when the item has been renamed:
> > http://svn.haxx.se/dev/archive-2008-04/0235.shtml
> > I think we could fix this later, but it needs to be looked at.
> >
> > Hyrum, do you have any time to look at this?
> >
> >
> > I think restoring and fixing the mergeinfo API is probably the biggest
> > blocker on this list, especially since it bleeds into the bindings
> > which need to catch up. Hopefully we can tackle this list quickly and
> > get the RC1 wrapped up.
>
> So, great progress already. It seems like we just need to finalize on
> the mergeinfo API stuff and we are good to go. Unless someone was
> going to try to tackle the log -g problem today.
So really all that is left to do is to backport the items in status,
and possibly look at this log -g stuff, and then we are good to go for
RC1.
--
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: Subversion 1.5 issues blocking RC1
Posted by Mark Phippard <ma...@gmail.com>.
On Sun, Apr 6, 2008 at 10:33 AM, Mark Phippard <ma...@gmail.com> wrote:
> I thought it would be useful to start a new thread where we can gather
> a sort of to-do list of things we need to look at before we can make
> the RC1. We did a lot of work yesterday to get close to the release,
> but there are still some things left to do.
>
> 1) Clean out STATUS. Hyrum pointed this out. Basically, there were a
> couple of items discovered yesterday that got fixed late and added to
> STATUS. Getting them approved for backport should be trivial but
> still needs to be done.
This is DONE.
> 2) Mergeinfo API.
>
> a) As Bert and Stefan have pointed out, the new API can be pretty
> slow. The new API is good, they just have a valid case for leaving
> the "old" API in place rather than remove it. I have to say we had a
> few instances in the JavaHL tests where it the old API was more
> appropriate. For example, sometimes you just want to check that there
> is mergeinfo, you do not care so much about the details. The log
> based approach is too heavy for this.
Bert posted a patch for this. I know we will need to update JavaHL to
put back our equivalent API.
> b) Likely bug in the new API. It appears that the new API only works
> when TARGET is a WC. The old API also supported a URL. We had to
> change the JavaHL tests because of this. At the time, I thought this
> was OK, but now realize it is probably a bug. If nothing else, the
> error message has to be better.
>
> Mike Pilato, can you look at these?
>
>
> 3) Reintegrate bugs. David Glasser pointed out a couple of small bugs
> that need to be fixed when using reintegrate.
> http://svn.haxx.se/dev/archive-2008-04/0291.shtml
> I think we probably need to put the --force option back into the API
> so that it can pass it along to the merge API it eventually calls.
>
> Julian, since you removed force, could you look at these?
This is DONE.
> 4) Reintegrate "overhaul". David Glasser also has proposed some
> significant changes to the API.
> http://svn.haxx.se/dev/archive-2008-04/0288.shtml
> Given that there is no one available to code these changes, I am in
> favor of punting this to 1.6.
>
> Comments?
It seems like we have consensus on postponing this to after 1.5.
> 5) Stefan pointed out a regression when checking out the repository root.
> http://subversion.tigris.org/issues/show_bug.cgi?id=3167
>
> It looks like Lieven is looking into this.
This is DONE.
> 6) I think I found a bug in log -g when the item has been renamed:
> http://svn.haxx.se/dev/archive-2008-04/0235.shtml
> I think we could fix this later, but it needs to be looked at.
>
> Hyrum, do you have any time to look at this?
>
>
> I think restoring and fixing the mergeinfo API is probably the biggest
> blocker on this list, especially since it bleeds into the bindings
> which need to catch up. Hopefully we can tackle this list quickly and
> get the RC1 wrapped up.
So, great progress already. It seems like we just need to finalize on
the mergeinfo API stuff and we are good to go. Unless someone was
going to try to tackle the log -g problem today.
--
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: Subversion 1.5 issues blocking RC1
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Apr 7, 2008 at 7:24 AM, Julian Foad <ju...@btopenworld.com> wrote:
>
> Mark Phippard wrote:
> > The scenario David presented was that a user uses merge --reintegrate,
> > it passes all of its checks and gets into the do_merge() API but then
> > errors our with a message that suggests the user try the --force
> > option. This leaves us with a couple options:
> >
> > 1) Change the error message. This is probably impossible since the
> > API is being reused here.
> >
> > 2) Change --reintegrate so that it accepts the --force option AND
> > passes it along to the right API. If we do not do the latter, then
> > the user could specify --force AND still get the error message, which
> > would be just as confusing.
> >
> > I have not looked at your commit yet.
> >
>
> Mark, Karl's r30392 log message indicates that he has done the right thing:
> avoided suggesting "--force" in the error message in that case.
Excellent. Thanks
--
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: Subversion 1.5 issues blocking RC1
Posted by David Glasser <gl...@davidglasser.net>.
On Mon, Apr 7, 2008 at 5:19 AM, Karl Fogel <kf...@red-bean.com> wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
> > Mark Phippard wrote:
> >> The scenario David presented was that a user uses merge --reintegrate,
> >> it passes all of its checks and gets into the do_merge() API but then
> >> errors our with a message that suggests the user try the --force
> >> option. This leaves us with a couple options:
> >>
> >> 1) Change the error message. This is probably impossible since the
> >> API is being reused here.
> >>
> >> 2) Change --reintegrate so that it accepts the --force option AND
> >> passes it along to the right API. If we do not do the latter, then
> >> the user could specify --force AND still get the error message, which
> >> would be just as confusing.
> >>
> >> I have not looked at your commit yet.
> >
> > Mark, Karl's r30392 log message indicates that he has done the right
> > thing: avoided suggesting "--force" in the error message in that case.
>
> However, this still leaves the question of whether we want the API to
> take a 'force' parameter, because we have a plan to make it meaningful
> later, and this way could do so in 1.5.x rather than 1.6.
>
> If we know a scenario in which 'svn merge --reintegrate --force' would
> be useful, then I can easily make that change. The parameter would be
> ignored right now, and in 1.5.0 combining those options would still
> cause an error, but 1.5.1 could do something different.
>
> I don't know of such a scenario, though. Does anyone?
I could imagine using --reintegrate --force to mean "yes, I know that
the branch has descendants with different mergeinfo, but I want to
merge anyway". On the other hand, I think it would be reasonable for
that logic to be in the client, not the API (see the partial patch I
posted over the weekend).
--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: Subversion 1.5 issues blocking RC1
Posted by Karl Fogel <kf...@red-bean.com>.
Julian Foad <ju...@btopenworld.com> writes:
> Mark Phippard wrote:
>> The scenario David presented was that a user uses merge --reintegrate,
>> it passes all of its checks and gets into the do_merge() API but then
>> errors our with a message that suggests the user try the --force
>> option. This leaves us with a couple options:
>>
>> 1) Change the error message. This is probably impossible since the
>> API is being reused here.
>>
>> 2) Change --reintegrate so that it accepts the --force option AND
>> passes it along to the right API. If we do not do the latter, then
>> the user could specify --force AND still get the error message, which
>> would be just as confusing.
>>
>> I have not looked at your commit yet.
>
> Mark, Karl's r30392 log message indicates that he has done the right
> thing: avoided suggesting "--force" in the error message in that case.
However, this still leaves the question of whether we want the API to
take a 'force' parameter, because we have a plan to make it meaningful
later, and this way could do so in 1.5.x rather than 1.6.
If we know a scenario in which 'svn merge --reintegrate --force' would
be useful, then I can easily make that change. The parameter would be
ignored right now, and in 1.5.0 combining those options would still
cause an error, but 1.5.1 could do something different.
I don't know of such a scenario, though. Does anyone?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 issues blocking RC1
Posted by Julian Foad <ju...@btopenworld.com>.
Mark Phippard wrote:
> On Mon, Apr 7, 2008 at 6:14 AM, Karl Fogel <kf...@red-bean.com> wrote:
>>"Mark Phippard" <ma...@gmail.com> writes:
>> > 3) Reintegrate bugs. David Glasser pointed out a couple of small bugs
>> > that need to be fixed when using reintegrate.
>> > http://svn.haxx.se/dev/archive-2008-04/0291.shtml
>> > I think we probably need to put the --force option back into the API
>> > so that it can pass it along to the merge API it eventually calls.
>> >
>> > Julian, since you removed force, could you look at these?
>>
>> I've got changes that take care of the two issues mentioned in that
>> mail; as soon as they pass 'make check' I'll commit.
>>
>> Regarding putting 'force' back in svn_client_merge_reintegrate():
>>
>> Background: the revision where Julian removed it was r29634 (which was
>> backported to 1.5.x). The log message says 'force' was removed because
>> it was "redundant" -- not sure that's the right word; I think rather it
>> was removed because forcing was inconsistent with reintegration as we've
>> currently defined it (but could be compatible in the future).
>>
>> We could it back into svn_client_merge_reintegrate(), document for now
>> that it's meaningless, and that callers should pass FALSE (and we could
>> enforce that). I guess it would be within our release/API guidelines to
>> give 'force' a meaning in 1.5.1.
>>
>> Mark, were you proposing that, or were you proposing actually passing it
>> along to merge_cousins_and_supplement_mergeinfo() right now? That's the
>> only merge API called, and it just passes along to do_merge().
>
> The scenario David presented was that a user uses merge --reintegrate,
> it passes all of its checks and gets into the do_merge() API but then
> errors our with a message that suggests the user try the --force
> option. This leaves us with a couple options:
>
> 1) Change the error message. This is probably impossible since the
> API is being reused here.
>
> 2) Change --reintegrate so that it accepts the --force option AND
> passes it along to the right API. If we do not do the latter, then
> the user could specify --force AND still get the error message, which
> would be just as confusing.
>
> I have not looked at your commit yet.
Mark, Karl's r30392 log message indicates that he has done the right thing:
avoided suggesting "--force" in the error message in that case.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 issues blocking RC1
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Apr 7, 2008 at 6:14 AM, Karl Fogel <kf...@red-bean.com> wrote:
> "Mark Phippard" <ma...@gmail.com> writes:
> > 3) Reintegrate bugs. David Glasser pointed out a couple of small bugs
> > that need to be fixed when using reintegrate.
> > http://svn.haxx.se/dev/archive-2008-04/0291.shtml
> > I think we probably need to put the --force option back into the API
> > so that it can pass it along to the merge API it eventually calls.
> >
> > Julian, since you removed force, could you look at these?
>
> I've got changes that take care of the two issues mentioned in that
> mail; as soon as they pass 'make check' I'll commit.
>
> Regarding putting 'force' back in svn_client_merge_reintegrate():
>
> Background: the revision where Julian removed it was r29634 (which was
> backported to 1.5.x). The log message says 'force' was removed because
> it was "redundant" -- not sure that's the right word; I think rather it
> was removed because forcing was inconsistent with reintegration as we've
> currently defined it (but could be compatible in the future).
>
> We could it back into svn_client_merge_reintegrate(), document for now
> that it's meaningless, and that callers should pass FALSE (and we could
> enforce that). I guess it would be within our release/API guidelines to
> give 'force' a meaning in 1.5.1.
>
> Mark, were you proposing that, or were you proposing actually passing it
> along to merge_cousins_and_supplement_mergeinfo() right now? That's the
> only merge API called, and it just passes along to do_merge().
The scenario David presented was that a user uses merge --reintegrate,
it passes all of its checks and gets into the do_merge() API but then
errors our with a message that suggests the user try the --force
option. This leaves us with a couple options:
1) Change the error message. This is probably impossible since the
API is being reused here.
2) Change --reintegrate so that it accepts the --force option AND
passes it along to the right API. If we do not do the latter, then
the user could specify --force AND still get the error message, which
would be just as confusing.
I have not looked at your commit yet.
--
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: Subversion 1.5 issues blocking RC1
Posted by Karl Fogel <kf...@red-bean.com>.
Karl Fogel <kf...@red-bean.com> writes:
> "Mark Phippard" <ma...@gmail.com> writes:
>> 3) Reintegrate bugs. David Glasser pointed out a couple of small bugs
>> that need to be fixed when using reintegrate.
>> http://svn.haxx.se/dev/archive-2008-04/0291.shtml
>> I think we probably need to put the --force option back into the API
>> so that it can pass it along to the merge API it eventually calls.
>>
>> Julian, since you removed force, could you look at these?
>
> I've got changes that take care of the two issues mentioned in that
> mail; as soon as they pass 'make check' I'll commit. [...]
Okay, r30392.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 issues blocking RC1
Posted by Karl Fogel <kf...@red-bean.com>.
"Mark Phippard" <ma...@gmail.com> writes:
> 3) Reintegrate bugs. David Glasser pointed out a couple of small bugs
> that need to be fixed when using reintegrate.
> http://svn.haxx.se/dev/archive-2008-04/0291.shtml
> I think we probably need to put the --force option back into the API
> so that it can pass it along to the merge API it eventually calls.
>
> Julian, since you removed force, could you look at these?
I've got changes that take care of the two issues mentioned in that
mail; as soon as they pass 'make check' I'll commit.
Regarding putting 'force' back in svn_client_merge_reintegrate():
Background: the revision where Julian removed it was r29634 (which was
backported to 1.5.x). The log message says 'force' was removed because
it was "redundant" -- not sure that's the right word; I think rather it
was removed because forcing was inconsistent with reintegration as we've
currently defined it (but could be compatible in the future).
We could it back into svn_client_merge_reintegrate(), document for now
that it's meaningless, and that callers should pass FALSE (and we could
enforce that). I guess it would be within our release/API guidelines to
give 'force' a meaning in 1.5.1.
Mark, were you proposing that, or were you proposing actually passing it
along to merge_cousins_and_supplement_mergeinfo() right now? That's the
only merge API called, and it just passes along to do_merge().
I'm totally comfortable with the first route, to save us API churn. I'm
not sure that actually passing it along now would be good though, since
we're not quite sure what we'd be forcing.
(This is all somewhat independent of your item (4), "reintegrate
overhaul"...)
> 4) Reintegrate "overhaul". David Glasser also has proposed some
> significant changes to the API.
> http://svn.haxx.se/dev/archive-2008-04/0288.shtml
> Given that there is no one available to code these changes, I am in
> favor of punting this to 1.6.
>
> Comments?
In favor of punting it solely because it's much more important to get
1.5.0 out now (same as you :-) ). However, I'd be comfortable releasing
1.6 even if --reintegrate improvements are the only major new thing in
it. In other words, the amount of time users wait for this overhaul
need not be greatly affected by whether the changes are in 1.5 or not.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org