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 2007/08/28 14:23:57 UTC
Problem with suggestMergeSources() API and getCopySource() removal
I came up with a scenario where the recent API change to add the new
suggestMergeSources API and possibly remove getCopySource has caused a
problem.
In the GUI merge client I am working on we recently added support to
merge to multiple projects at the same time. Basically, this is a UI
feature where we figure out the common root of the selected projects,
base the UI off that, and then run merge once for each selected
project.
Here are the problems:
1) The new API does not work with a URL. In our scenario, the common
local path is not a WC, so we need to use the common URL of the
selections to get the suggested merge information.
2) If we do not remove the getCopySource() API we could just go back
to using that since it did work OK with a URL. As of last night, the
plan was to remove this API as we did not see a need for it.
It does not matter to me which way we want to go with this. I think
that this is a valid scenario and suggestMergeSources probably ought
to be modified to support a URL.
--
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: Problem with suggestMergeSources() API and getCopySource() removal
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> I have attached patch for JavaHL tests that demonstrates the problem.
> I verified the test produces the problem, I am not 100% certain when
> the problem is fixed that I am comparing the right value to have the
> test pass. So that might need to be adjusted.
I think r26388 fixes this problem. It makes your test pass, at least. :-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Problem with suggestMergeSources() API and getCopySource() removal
Posted by Mark Phippard <ma...@gmail.com>.
On 8/28/07, Mark Phippard <ma...@gmail.com> wrote:
> On 8/28/07, C. Michael Pilato <cm...@collab.net> wrote:
> > Okay. Well, I can teach svn_client_suggest_merge_sources() to accept
> > path_or_url + revision easy enough, and am doing so now.
>
> It looks like you added this in r26370. When I try to use it however,
> it looks like it is treating my URL as local path:
>
> svn: 'file:///Users/mphippard/repositories/dev1.5/branches' is not a
> working copy
> No such file or directory
> svn: Can't open file
> 'file:///Users/mphippard/repositories/dev1.5/branches/.svn/entries':
> No such file or directory
> svn: subversion/libsvn_wc/lock.c:598: (apr_err=155007)
>
> The above was from OSX. On Windows, you get something like this:
>
> svn: Can't check path 'file:\\\repos\test1\trunk': The filename,
> directory name, or volume label syntax is incorrect.
>
> In that example, the URL was right when it entered JavaHL.
I have attached patch for JavaHL tests that demonstrates the problem.
I verified the test produces the problem, I am not 100% certain when
the problem is fixed that I am comparing the right value to have the
test pass. So that might need to be adjusted.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Problem with suggestMergeSources() API and getCopySource() removal
Posted by Mark Phippard <ma...@gmail.com>.
On 8/28/07, C. Michael Pilato <cm...@collab.net> wrote:
> Okay. Well, I can teach svn_client_suggest_merge_sources() to accept
> path_or_url + revision easy enough, and am doing so now.
It looks like you added this in r26370. When I try to use it however,
it looks like it is treating my URL as local path:
svn: 'file:///Users/mphippard/repositories/dev1.5/branches' is not a
working copy
No such file or directory
svn: Can't open file
'file:///Users/mphippard/repositories/dev1.5/branches/.svn/entries':
No such file or directory
svn: subversion/libsvn_wc/lock.c:598: (apr_err=155007)
The above was from OSX. On Windows, you get something like this:
svn: Can't check path 'file:\\\repos\test1\trunk': The filename,
directory name, or volume label syntax is incorrect.
In that example, the URL was right when it entered JavaHL.
--
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: Problem with suggestMergeSources() API and getCopySource() removal
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On 8/28/07, C. Michael Pilato <cm...@collab.net> wrote:
>> Mark Phippard wrote:
>>>> suggestMergeSources() only returns URLs -- no peg revisions. Now, this
>>>> isn't anything new -- the code I abstracted into this API was always doing
>>>> this. But it does strike me as odd. If a merge target tells me that it has
>>>> merge info from /branches/somebranch, and that that location would make a
>>>> nice, sane, merge source, that's great. But what if /branches/somebranch
>>>> has been renamed to something else?
>>> In our GUI client, we are always using HEAD for peg revision. It is
>>> not a perfect solution, but the UI complexity of adding peg revision
>>> and then having to explain to users what it means just seems to high.
>>>
>>> You are obviously asking about the API level.
>> Indeed, I am. And a sane GUI client would get from a sane underlying API
>> URL@PEG, and verify that URL@HEAD and URL@PEG are suitably related before
>> trusting that result and presenting it to the user.
>
> That might be the sane thing to do, but it would be overly expensive
> in my opinion. In addition, whatever API might exist to do such a
> comparison is not exposed to me via the API I use.
Okay. Well, I can teach svn_client_suggest_merge_sources() to accept
path_or_url + revision easy enough, and am doing so now.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Problem with suggestMergeSources() API and getCopySource() removal
Posted by Mark Phippard <ma...@gmail.com>.
On 8/28/07, C. Michael Pilato <cm...@collab.net> wrote:
> Mark Phippard wrote:
> >> suggestMergeSources() only returns URLs -- no peg revisions. Now, this
> >> isn't anything new -- the code I abstracted into this API was always doing
> >> this. But it does strike me as odd. If a merge target tells me that it has
> >> merge info from /branches/somebranch, and that that location would make a
> >> nice, sane, merge source, that's great. But what if /branches/somebranch
> >> has been renamed to something else?
> >
> > In our GUI client, we are always using HEAD for peg revision. It is
> > not a perfect solution, but the UI complexity of adding peg revision
> > and then having to explain to users what it means just seems to high.
> >
> > You are obviously asking about the API level.
>
> Indeed, I am. And a sane GUI client would get from a sane underlying API
> URL@PEG, and verify that URL@HEAD and URL@PEG are suitably related before
> trusting that result and presenting it to the user.
That might be the sane thing to do, but it would be overly expensive
in my opinion. In addition, whatever API might exist to do such a
comparison is not exposed to me via the API I use.
--
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: Problem with suggestMergeSources() API and getCopySource() removal
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On 8/28/07, C. Michael Pilato <cm...@collab.net> wrote:
>> Mark Phippard wrote:
>>> I came up with a scenario where the recent API change to add the new
>>> suggestMergeSources API and possibly remove getCopySource has caused a
>>> problem.
>>>
>>> In the GUI merge client I am working on we recently added support to
>>> merge to multiple projects at the same time. Basically, this is a UI
>>> feature where we figure out the common root of the selected projects,
>>> base the UI off that, and then run merge once for each selected
>>> project.
>>>
>>> Here are the problems:
>>>
>>> 1) The new API does not work with a URL. In our scenario, the common
>>> local path is not a WC, so we need to use the common URL of the
>>> selections to get the suggested merge information.
>>>
>>> 2) If we do not remove the getCopySource() API we could just go back
>>> to using that since it did work OK with a URL. As of last night, the
>>> plan was to remove this API as we did not see a need for it.
>>>
>>> It does not matter to me which way we want to go with this. I think
>>> that this is a valid scenario and suggestMergeSources probably ought
>>> to be modified to support a URL.
>>>
>> Here's another problem that maybe someone can help me to understand:
>>
>> suggestMergeSources() only returns URLs -- no peg revisions. Now, this
>> isn't anything new -- the code I abstracted into this API was always doing
>> this. But it does strike me as odd. If a merge target tells me that it has
>> merge info from /branches/somebranch, and that that location would make a
>> nice, sane, merge source, that's great. But what if /branches/somebranch
>> has been renamed to something else?
>
> In our GUI client, we are always using HEAD for peg revision. It is
> not a perfect solution, but the UI complexity of adding peg revision
> and then having to explain to users what it means just seems to high.
>
> You are obviously asking about the API level.
Indeed, I am. And a sane GUI client would get from a sane underlying API
URL@PEG, and verify that URL@HEAD and URL@PEG are suitably related before
trusting that result and presenting it to the user.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Problem with suggestMergeSources() API and getCopySource() removal
Posted by Mark Phippard <ma...@gmail.com>.
On 8/28/07, C. Michael Pilato <cm...@collab.net> wrote:
> Mark Phippard wrote:
> > I came up with a scenario where the recent API change to add the new
> > suggestMergeSources API and possibly remove getCopySource has caused a
> > problem.
> >
> > In the GUI merge client I am working on we recently added support to
> > merge to multiple projects at the same time. Basically, this is a UI
> > feature where we figure out the common root of the selected projects,
> > base the UI off that, and then run merge once for each selected
> > project.
> >
> > Here are the problems:
> >
> > 1) The new API does not work with a URL. In our scenario, the common
> > local path is not a WC, so we need to use the common URL of the
> > selections to get the suggested merge information.
> >
> > 2) If we do not remove the getCopySource() API we could just go back
> > to using that since it did work OK with a URL. As of last night, the
> > plan was to remove this API as we did not see a need for it.
> >
> > It does not matter to me which way we want to go with this. I think
> > that this is a valid scenario and suggestMergeSources probably ought
> > to be modified to support a URL.
> >
>
> Here's another problem that maybe someone can help me to understand:
>
> suggestMergeSources() only returns URLs -- no peg revisions. Now, this
> isn't anything new -- the code I abstracted into this API was always doing
> this. But it does strike me as odd. If a merge target tells me that it has
> merge info from /branches/somebranch, and that that location would make a
> nice, sane, merge source, that's great. But what if /branches/somebranch
> has been renamed to something else?
In our GUI client, we are always using HEAD for peg revision. It is
not a perfect solution, but the UI complexity of adding peg revision
and then having to explain to users what it means just seems to high.
You are obviously asking about the API level.
--
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: Problem with suggestMergeSources() API and getCopySource() removal
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> I came up with a scenario where the recent API change to add the new
> suggestMergeSources API and possibly remove getCopySource has caused a
> problem.
>
> In the GUI merge client I am working on we recently added support to
> merge to multiple projects at the same time. Basically, this is a UI
> feature where we figure out the common root of the selected projects,
> base the UI off that, and then run merge once for each selected
> project.
>
> Here are the problems:
>
> 1) The new API does not work with a URL. In our scenario, the common
> local path is not a WC, so we need to use the common URL of the
> selections to get the suggested merge information.
>
> 2) If we do not remove the getCopySource() API we could just go back
> to using that since it did work OK with a URL. As of last night, the
> plan was to remove this API as we did not see a need for it.
>
> It does not matter to me which way we want to go with this. I think
> that this is a valid scenario and suggestMergeSources probably ought
> to be modified to support a URL.
>
Here's another problem that maybe someone can help me to understand:
suggestMergeSources() only returns URLs -- no peg revisions. Now, this
isn't anything new -- the code I abstracted into this API was always doing
this. But it does strike me as odd. If a merge target tells me that it has
merge info from /branches/somebranch, and that that location would make a
nice, sane, merge source, that's great. But what if /branches/somebranch
has been renamed to something else?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand