You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Küng <to...@gmail.com> on 2010/08/17 19:27:59 UTC
svn_client_status5() and depth
Hi,
* check out a folder with depth svn_depth_empty (svn co
file:///d:/testrepo/trunk testwc)
* cd into that folder (cd testwc)
* run 'svn st -u -v --depth infinity'
In 1.6.x, I get the status for all the files under that folder that
exist in the repository.
With the latest trunk (r986453), I only get
32 32 user .
Status against revision: 32
All the files in the repository are not reported back.
I'm relying on the behavior of the 1.6.x version in TSVN. If this change
was by design, why was this changed? I couldn't find anything in recent
discussions about this. But that could easily be because of the
not-very-good search feature of the mailing list archives.
Or is this a bug?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
RE: svn_client_status5() and depth
Posted by Bert Huijben <be...@vmoo.com>.
> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
> Sent: dinsdag 17 augustus 2010 12:28
> To: Subversion Development
> Subject: svn_client_status5() and depth
>
> Hi,
>
> * check out a folder with depth svn_depth_empty (svn co
> file:///d:/testrepo/trunk testwc)
> * cd into that folder (cd testwc)
> * run 'svn st -u -v --depth infinity'
>
> In 1.6.x, I get the status for all the files under that folder that
> exist in the repository.
>
> With the latest trunk (r986453), I only get
> 32 32 user .
> Status against revision: 32
>
> All the files in the repository are not reported back.
>
> I'm relying on the behavior of the 1.6.x version in TSVN. If this change
> was by design, why was this changed? I couldn't find anything in recent
> discussions about this. But that could easily be because of the
> not-very-good search feature of the mailing list archives.
>
> Or is this a bug?
This looks like a bug to me. It should show all nodes with -v.
Bert
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 17.08.2010 22:45, C. Michael Pilato wrote:
> On 08/17/2010 01:42 PM, Stefan Küng wrote:
>> Maybe I don't understand that change:
>> --depth specifies a depth to use for the command. If I want the command
>> to use the depth of the working copy, I specify an unknown depth or none
>> at all. But if I specify a depth, I would assume the command to respect
>> that depth and return the info with that depth.
>> So why should the -u flag not use the specified depth?
>
> --depth is a filtering option -- it can only reduce the scope of an
> operation, it can not expand it.
>
> Bert sez he'll make the behavior optional in the API call so you can make
> use of it. We won't expose it at all in the 'svn' command-line client, but
> TortoiseSVN can get its behavior back. Sound good?
>
Sounds good, yes.
I think I got confused a little bit: the API for svn_client_status()
only has a depth param. and svn_client_update has a depth param and a
flag 'depth_is_sticky', so there's no two depth params as in the CL -
one for filtering and one for setting.
Would the svn_client_status3 API get another depth param for this? Or a
flag to allow a depth deeper than the depth of the WC?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 17.08.2010 22:45, C. Michael Pilato wrote:
> On 08/17/2010 01:42 PM, Stefan Küng wrote:
>> Maybe I don't understand that change:
>> --depth specifies a depth to use for the command. If I want the command
>> to use the depth of the working copy, I specify an unknown depth or none
>> at all. But if I specify a depth, I would assume the command to respect
>> that depth and return the info with that depth.
>> So why should the -u flag not use the specified depth?
>
> --depth is a filtering option -- it can only reduce the scope of an
> operation, it can not expand it.
>
> Bert sez he'll make the behavior optional in the API call so you can make
> use of it. We won't expose it at all in the 'svn' command-line client, but
> TortoiseSVN can get its behavior back. Sound good?
>
Sounds good, yes.
I think I got confused a little bit: the API for svn_client_status()
only has a depth param. and svn_client_update has a depth param and a
flag 'depth_is_sticky', so there's no two depth params as in the CL -
one for filtering and one for setting.
Would the svn_client_status3 API get another depth param for this? Or a
flag to allow a depth deeper than the depth of the WC?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: svn_client_status5() and depth
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Wed, Aug 18, 2010 at 7:39 PM, Stefan Küng <to...@gmail.com> wrote:
> On 17.08.2010 23:41, Hyrum K. Wright wrote:
>>
>> On Tue, Aug 17, 2010 at 3:45 PM, C. Michael Pilato<cm...@collab.net>
>> wrote:
>>>
>>> On 08/17/2010 01:42 PM, Stefan Küng wrote:
>>>>
>>>> Maybe I don't understand that change:
>>>> --depth specifies a depth to use for the command. If I want the command
>>>> to use the depth of the working copy, I specify an unknown depth or none
>>>> at all. But if I specify a depth, I would assume the command to respect
>>>> that depth and return the info with that depth.
>>>> So why should the -u flag not use the specified depth?
>>>
>>> --depth is a filtering option -- it can only reduce the scope of an
>>> operation, it can not expand it.
>>>
>>> Bert sez he'll make the behavior optional in the API call so you can make
>>> use of it. We won't expose it at all in the 'svn' command-line client,
>>> but
>>> TortoiseSVN can get its behavior back. Sound good?
>>
>> <sarcasm>
>> Yay for another API flag!
>> </sarcasm>
>
> Well, it's either another flag, or use bitmasks. And since bitmasks are not
> allowed anymore, there aren't any more options.
False dichotomy. There are more options than just "add parameters" or
"add bitmasks," one of which I mentioned below: rethinking the roles
of our various APIs, and augmenting *that* instead. (But given your
comments below, I think you're right about this particular case.)
>> I'm starting to wonder if the mission (at the API level) of 'st -u'
>> and vanilla 'st' has diverged enough that we may want to consider an
>> API named svn_client_remote_status() or something. It seems a bit
>> silly to keep extending APIs using various boolean flags[1], in a
>> manner which eventually leads to both consumer and programmer
>> confusion. This eventually leads to entry points whose behavior
>> wildly varies based upon the permutations of the set of flags.
>> Perhaps status5 (with its 13 parameters) has reached this point?
>
> But that would lead to another problem: how would you combine the local
> status and the remote status data? Have the clients merge those two?
Good point. I'm not claiming the above solution is optimal, but that
we need to do some hard thinking about these issues before adding Yet
Another Parameter to the APIs.
-Hyrum
Re: svn_client_status5() and depth
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/19/2010 09:15 AM, Stefan Küng wrote:
> What's the harm in leaving the behavior in the old APIs even though it's
> not what you intended? Please read the docs for the API again - that
> intention isn't documented so the old API works as documented.
As someone who was close to the project when 'svn st -u' was conceived, I
agree with Bert's evaluation of the intent of that feature, and by
extension, agree that the behavior changed in a bad way -- albeit
inadvertently -- when we added the depth stuff. But that's water under the
bridge now. I agree with Stefan that any harm done by the behavior change
has been done already, and there's no reason to further penalize API
consumers with a second change of behavior. Let's just preserve the 1.6.x
behavior for _status4().
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn_client_status5() and depth
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/19/2010 09:15 AM, Stefan Küng wrote:
> What's the harm in leaving the behavior in the old APIs even though it's
> not what you intended? Please read the docs for the API again - that
> intention isn't documented so the old API works as documented.
As someone who was close to the project when 'svn st -u' was conceived, I
agree with Bert's evaluation of the intent of that feature, and by
extension, agree that the behavior changed in a bad way -- albeit
inadvertently -- when we added the depth stuff. But that's water under the
bridge now. I agree with Stefan that any harm done by the behavior change
has been done already, and there's no reason to further penalize API
consumers with a second change of behavior. Let's just preserve the 1.6.x
behavior for _status4().
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 18.08.2010 21:58, Bert Huijben wrote:
>> I've checked r986510 and I like to add some comments:
>>
>> In libsvn_client/deprecated.c, svn_client_status4() you pass FALSE for
>> the new sticky param. But that's wrong: in 1.6.x and previous versions,
>> the depth was always respected/enforced. That's why I noticed the
>> changed behavior in the first place!
>> Shouldn't you pass TRUE there?
>
> The not filtering of the nodes was never the intended behavior. It was a
> bug, but had useful behavior for your specific case: explicitly pulling
> unavailable nodes into the working copy.
I've checked the original docs of the svn_client_status4() API. It
nowhere mentions that the intended behavior is to show what an 'svn up'
would do. Actually 'svn up' isn't mentioned at all:
https://svn.apache.org/repos/asf/subversion/tags/1.6.0/subversion/include/svn_client.h
So, no matter if the old behavior is not correct: you can't just change
the behavior and tell people: sorry, that was a bug. Because it wasn't
documented that way so people start to rely on what's documented and on
how it actually works.
If you change the behavior, the API is not compatible anymore.
It's perfectly fine to do that with svn_client_status5() if it gets
documented that way - after all, that's what new APIs are for: not just
changing the params but also the behavior if necessary.
But the older (existing) APIs must not change their behavior.
What's the harm in leaving the behavior in the old APIs even though it's
not what you intended? Please read the docs for the API again - that
intention isn't documented so the old API works as documented.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
RE: svn_client_status5() and depth
Posted by Bert Huijben <be...@vmoo.com>.
> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
> Sent: woensdag 18 augustus 2010 13:37
> To: Bert Huijben
> Cc: 'Hyrum K. Wright'; 'C. Michael Pilato'; 'Subversion Development'
> Subject: Re: svn_client_status5() and depth
> I don't understand: what exactly are you missing from that table above?
> Can you maybe provide me that part of the table, and I'll fill in the
> data that's returned.
If I have a directory with ambient depth files, I want
svn status -u --depth children .
to show exactly what would change if I would do
svn up --depth children .
As this is the documented behavior for 'svn status -u'. *)
If status is patched as suggested by you, I would see all the directories
that are missing in my local working copy in the 'svn status', but I
wouldn't get them by calling the update. (not what I want)
If I do pass --depth unknown (by not passing --depth) I would not have depth
children, but depth infinity. (not what I want as that shows nodes inside
the directories below the current directory)
Theoretically. I could get the same result by calling something like 'svn
info' to retrieve the depth and then pass that depth..
So that would be
svn status -u --depth files.
But this also removes all the directories that I have explicitly checked out
from the status information.
So there is no way that I can use this documented behavior, without this
flag.
Bert
*) And that is the reason I didn't pass TRUE. The old behavior is a bug,
which we ought to fix in 1.6.. But then we break TortoiseSVN 1.6, which is
something that I try to avoid. So maybe I should forget that.... (which is
what I did)
RE: svn_client_status5() and depth
Posted by Bert Huijben <be...@vmoo.com>.
> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
> Sent: woensdag 18 augustus 2010 13:37
> To: Bert Huijben
> Cc: 'Hyrum K. Wright'; 'C. Michael Pilato'; 'Subversion Development'
> Subject: Re: svn_client_status5() and depth
> I don't understand: what exactly are you missing from that table above?
> Can you maybe provide me that part of the table, and I'll fill in the
> data that's returned.
If I have a directory with ambient depth files, I want
svn status -u --depth children .
to show exactly what would change if I would do
svn up --depth children .
As this is the documented behavior for 'svn status -u'. *)
If status is patched as suggested by you, I would see all the directories
that are missing in my local working copy in the 'svn status', but I
wouldn't get them by calling the update. (not what I want)
If I do pass --depth unknown (by not passing --depth) I would not have depth
children, but depth infinity. (not what I want as that shows nodes inside
the directories below the current directory)
Theoretically. I could get the same result by calling something like 'svn
info' to retrieve the depth and then pass that depth..
So that would be
svn status -u --depth files.
But this also removes all the directories that I have explicitly checked out
from the status information.
So there is no way that I can use this documented behavior, without this
flag.
Bert
*) And that is the reason I didn't pass TRUE. The old behavior is a bug,
which we ought to fix in 1.6.. But then we break TortoiseSVN 1.6, which is
something that I try to avoid. So maybe I should forget that.... (which is
what I did)
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 18.08.2010 21:58, Bert Huijben wrote:
>> In libsvn_client/deprecated.c, svn_client_status4() you pass FALSE for
>> the new sticky param. But that's wrong: in 1.6.x and previous versions,
>> the depth was always respected/enforced. That's why I noticed the
>> changed behavior in the first place!
>> Shouldn't you pass TRUE there?
>
> The not filtering of the nodes was never the intended behavior. It was a
> bug, but had useful behavior for your specific case: explicitly pulling
> unavailable nodes into the working copy.
Well, it might have been intended, but it didn't work that way. It
worked as if you would pass TRUE. Since you pass FALSE, the behavior is
not the same as in 1.6.x.
And shouldn't the old APIs stay compatible? To stay compatible with the
old APIs, you would have to pass TRUE in that wrapper.
Or am I missing something important here?
>
>> And what I don't understand: why the extra parameter at all?
>> If the param is set to TRUE unconditionally, then the behavior seems to
>> be the very same as in 1.6.x:
>> If the depth is less than the depth of the WC, it behaves the same as if
>> the param is FALSE. Only if the depth is deeper then the param has any
>> effect - setting the param to TRUE *ignores* deeper depths.
>>
>> So from my point of view, that parameter isn't necessary: the behavior
>> can be configured by using the depth parameter alone.
>
> Well.. that depends on what is the ambient depth of the directory and what
> you try to do with it. If the directory has depth children, passing depth
> infinity should be seen as depth children and depth files as depth files.
Why? If I pass depth infinity, I *want* the depth infinity, not depth
children. If I want the depth of the WC, I can pass depth unknown.
That's what the depth 'unknown' is for: to specify that the depth of the
WC should be used instead. If I pass a specific depth, I want that depth
and not something else.
> svn status -u was designed to show what svn up would do, and that really
> needs the current behavior to work correctly. I think that is the behavior
> older clients want. (But thanks for opening the discussion on that!)
>
>> Also, since this is a readonly operation, the naming 'depth_is_sticky'
>> isn't very good. Even confusing.
>
> Actually the name is 'depth_as_sticky'.
>
>>
>> Ok, reading my text above again, I think I'm not very clear why I think
>> the parameter isn't necessary. So I'll try again:
>>
>> depth sticky
>> <= WC depth FALSE 1.6.x == 1.7 : data for depth
>> <= WC depth TRUE 1.6.x == 1.7 : data for depth
>> > WC depth FALSE 1.6.x data for depth, 1.7 data for
> WCdepth
>> > WC depth TRUE 1.6.x data for depth, 1.7 data for depth
>>
>> Also, if a client wants the data only for the WC depth, passing a depth
>> of 'unknown' will do exactly that, no matter what the sticky is set to.
>>
>> So: every outcome of that API can be triggered by specifying the depth
>> alone. So why not get rid of the sticky param and always do as if it was
>> set to TRUE?
>
> Note that depth is used for more than just this filtering on the ra layer.
> It also applies on what nodes of your local working copy are shown. It did
> work as a filter there.
>
> Are you sure you can mimic that without the extra Boolean?
> (I certainly don't see any of this in your table)
I don't understand: what exactly are you missing from that table above?
Can you maybe provide me that part of the table, and I'll fill in the
data that's returned.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 18.08.2010 21:58, Bert Huijben wrote:
>> I've checked r986510 and I like to add some comments:
>>
>> In libsvn_client/deprecated.c, svn_client_status4() you pass FALSE for
>> the new sticky param. But that's wrong: in 1.6.x and previous versions,
>> the depth was always respected/enforced. That's why I noticed the
>> changed behavior in the first place!
>> Shouldn't you pass TRUE there?
>
> The not filtering of the nodes was never the intended behavior. It was a
> bug, but had useful behavior for your specific case: explicitly pulling
> unavailable nodes into the working copy.
I've checked the original docs of the svn_client_status4() API. It
nowhere mentions that the intended behavior is to show what an 'svn up'
would do. Actually 'svn up' isn't mentioned at all:
https://svn.apache.org/repos/asf/subversion/tags/1.6.0/subversion/include/svn_client.h
So, no matter if the old behavior is not correct: you can't just change
the behavior and tell people: sorry, that was a bug. Because it wasn't
documented that way so people start to rely on what's documented and on
how it actually works.
If you change the behavior, the API is not compatible anymore.
It's perfectly fine to do that with svn_client_status5() if it gets
documented that way - after all, that's what new APIs are for: not just
changing the params but also the behavior if necessary.
But the older (existing) APIs must not change their behavior.
What's the harm in leaving the behavior in the old APIs even though it's
not what you intended? Please read the docs for the API again - that
intention isn't documented so the old API works as documented.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 18.08.2010 21:58, Bert Huijben wrote:
>> In libsvn_client/deprecated.c, svn_client_status4() you pass FALSE for
>> the new sticky param. But that's wrong: in 1.6.x and previous versions,
>> the depth was always respected/enforced. That's why I noticed the
>> changed behavior in the first place!
>> Shouldn't you pass TRUE there?
>
> The not filtering of the nodes was never the intended behavior. It was a
> bug, but had useful behavior for your specific case: explicitly pulling
> unavailable nodes into the working copy.
Well, it might have been intended, but it didn't work that way. It
worked as if you would pass TRUE. Since you pass FALSE, the behavior is
not the same as in 1.6.x.
And shouldn't the old APIs stay compatible? To stay compatible with the
old APIs, you would have to pass TRUE in that wrapper.
Or am I missing something important here?
>
>> And what I don't understand: why the extra parameter at all?
>> If the param is set to TRUE unconditionally, then the behavior seems to
>> be the very same as in 1.6.x:
>> If the depth is less than the depth of the WC, it behaves the same as if
>> the param is FALSE. Only if the depth is deeper then the param has any
>> effect - setting the param to TRUE *ignores* deeper depths.
>>
>> So from my point of view, that parameter isn't necessary: the behavior
>> can be configured by using the depth parameter alone.
>
> Well.. that depends on what is the ambient depth of the directory and what
> you try to do with it. If the directory has depth children, passing depth
> infinity should be seen as depth children and depth files as depth files.
Why? If I pass depth infinity, I *want* the depth infinity, not depth
children. If I want the depth of the WC, I can pass depth unknown.
That's what the depth 'unknown' is for: to specify that the depth of the
WC should be used instead. If I pass a specific depth, I want that depth
and not something else.
> svn status -u was designed to show what svn up would do, and that really
> needs the current behavior to work correctly. I think that is the behavior
> older clients want. (But thanks for opening the discussion on that!)
>
>> Also, since this is a readonly operation, the naming 'depth_is_sticky'
>> isn't very good. Even confusing.
>
> Actually the name is 'depth_as_sticky'.
>
>>
>> Ok, reading my text above again, I think I'm not very clear why I think
>> the parameter isn't necessary. So I'll try again:
>>
>> depth sticky
>> <= WC depth FALSE 1.6.x == 1.7 : data for depth
>> <= WC depth TRUE 1.6.x == 1.7 : data for depth
>> > WC depth FALSE 1.6.x data for depth, 1.7 data for
> WCdepth
>> > WC depth TRUE 1.6.x data for depth, 1.7 data for depth
>>
>> Also, if a client wants the data only for the WC depth, passing a depth
>> of 'unknown' will do exactly that, no matter what the sticky is set to.
>>
>> So: every outcome of that API can be triggered by specifying the depth
>> alone. So why not get rid of the sticky param and always do as if it was
>> set to TRUE?
>
> Note that depth is used for more than just this filtering on the ra layer.
> It also applies on what nodes of your local working copy are shown. It did
> work as a filter there.
>
> Are you sure you can mimic that without the extra Boolean?
> (I certainly don't see any of this in your table)
I don't understand: what exactly are you missing from that table above?
Can you maybe provide me that part of the table, and I'll fill in the
data that's returned.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
RE: svn_client_status5() and depth
Posted by Bert Huijben <be...@vmoo.com>.
> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
> Sent: woensdag 18 augustus 2010 11:39
> To: Hyrum K. Wright
> Cc: C. Michael Pilato; Bert Huijben; Subversion Development
> Subject: Re: svn_client_status5() and depth
>
> On 17.08.2010 23:41, Hyrum K. Wright wrote:
> > On Tue, Aug 17, 2010 at 3:45 PM, C. Michael Pilato<cm...@collab.net>
> wrote:
> >> On 08/17/2010 01:42 PM, Stefan Küng wrote:
> >>> Maybe I don't understand that change:
> >>> --depth specifies a depth to use for the command. If I want the
> command
> >>> to use the depth of the working copy, I specify an unknown depth or
> none
> >>> at all. But if I specify a depth, I would assume the command to
respect
> >>> that depth and return the info with that depth.
> >>> So why should the -u flag not use the specified depth?
> >>
> >> --depth is a filtering option -- it can only reduce the scope of an
> >> operation, it can not expand it.
> >>
> >> Bert sez he'll make the behavior optional in the API call so you can
make
> >> use of it. We won't expose it at all in the 'svn' command-line client,
but
> >> TortoiseSVN can get its behavior back. Sound good?
> >
> > <sarcasm>
> > Yay for another API flag!
> > </sarcasm>
>
> Well, it's either another flag, or use bitmasks. And since bitmasks are
> not allowed anymore, there aren't any more options.
>
> > I'm starting to wonder if the mission (at the API level) of 'st -u'
> > and vanilla 'st' has diverged enough that we may want to consider an
> > API named svn_client_remote_status() or something. It seems a bit
> > silly to keep extending APIs using various boolean flags[1], in a
> > manner which eventually leads to both consumer and programmer
> > confusion. This eventually leads to entry points whose behavior
> > wildly varies based upon the permutations of the set of flags.
> > Perhaps status5 (with its 13 parameters) has reached this point?
>
> But that would lead to another problem: how would you combine the local
> status and the remote status data? Have the clients merge those two?
>
> Bert:
> I've checked r986510 and I like to add some comments:
>
> In libsvn_client/deprecated.c, svn_client_status4() you pass FALSE for
> the new sticky param. But that's wrong: in 1.6.x and previous versions,
> the depth was always respected/enforced. That's why I noticed the
> changed behavior in the first place!
> Shouldn't you pass TRUE there?
The not filtering of the nodes was never the intended behavior. It was a
bug, but had useful behavior for your specific case: explicitly pulling
unavailable nodes into the working copy.
> And what I don't understand: why the extra parameter at all?
> If the param is set to TRUE unconditionally, then the behavior seems to
> be the very same as in 1.6.x:
> If the depth is less than the depth of the WC, it behaves the same as if
> the param is FALSE. Only if the depth is deeper then the param has any
> effect - setting the param to TRUE *ignores* deeper depths.
>
> So from my point of view, that parameter isn't necessary: the behavior
> can be configured by using the depth parameter alone.
Well.. that depends on what is the ambient depth of the directory and what
you try to do with it. If the directory has depth children, passing depth
infinity should be seen as depth children and depth files as depth files.
svn status -u was designed to show what svn up would do, and that really
needs the current behavior to work correctly. I think that is the behavior
older clients want. (But thanks for opening the discussion on that!)
> Also, since this is a readonly operation, the naming 'depth_is_sticky'
> isn't very good. Even confusing.
Actually the name is 'depth_as_sticky'.
>
> Ok, reading my text above again, I think I'm not very clear why I think
> the parameter isn't necessary. So I'll try again:
>
> depth sticky
> <= WC depth FALSE 1.6.x == 1.7 : data for depth
> <= WC depth TRUE 1.6.x == 1.7 : data for depth
> > WC depth FALSE 1.6.x data for depth, 1.7 data for
WCdepth
> > WC depth TRUE 1.6.x data for depth, 1.7 data for depth
>
> Also, if a client wants the data only for the WC depth, passing a depth
> of 'unknown' will do exactly that, no matter what the sticky is set to.
>
> So: every outcome of that API can be triggered by specifying the depth
> alone. So why not get rid of the sticky param and always do as if it was
> set to TRUE?
Note that depth is used for more than just this filtering on the ra layer.
It also applies on what nodes of your local working copy are shown. It did
work as a filter there.
Are you sure you can mimic that without the extra Boolean?
(I certainly don't see any of this in your table)
Bert
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
RE: svn_client_status5() and depth
Posted by Bert Huijben <be...@vmoo.com>.
> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
> Sent: woensdag 18 augustus 2010 11:39
> To: Hyrum K. Wright
> Cc: C. Michael Pilato; Bert Huijben; Subversion Development
> Subject: Re: svn_client_status5() and depth
>
> On 17.08.2010 23:41, Hyrum K. Wright wrote:
> > On Tue, Aug 17, 2010 at 3:45 PM, C. Michael Pilato<cm...@collab.net>
> wrote:
> >> On 08/17/2010 01:42 PM, Stefan Küng wrote:
> >>> Maybe I don't understand that change:
> >>> --depth specifies a depth to use for the command. If I want the
> command
> >>> to use the depth of the working copy, I specify an unknown depth or
> none
> >>> at all. But if I specify a depth, I would assume the command to
respect
> >>> that depth and return the info with that depth.
> >>> So why should the -u flag not use the specified depth?
> >>
> >> --depth is a filtering option -- it can only reduce the scope of an
> >> operation, it can not expand it.
> >>
> >> Bert sez he'll make the behavior optional in the API call so you can
make
> >> use of it. We won't expose it at all in the 'svn' command-line client,
but
> >> TortoiseSVN can get its behavior back. Sound good?
> >
> > <sarcasm>
> > Yay for another API flag!
> > </sarcasm>
>
> Well, it's either another flag, or use bitmasks. And since bitmasks are
> not allowed anymore, there aren't any more options.
>
> > I'm starting to wonder if the mission (at the API level) of 'st -u'
> > and vanilla 'st' has diverged enough that we may want to consider an
> > API named svn_client_remote_status() or something. It seems a bit
> > silly to keep extending APIs using various boolean flags[1], in a
> > manner which eventually leads to both consumer and programmer
> > confusion. This eventually leads to entry points whose behavior
> > wildly varies based upon the permutations of the set of flags.
> > Perhaps status5 (with its 13 parameters) has reached this point?
>
> But that would lead to another problem: how would you combine the local
> status and the remote status data? Have the clients merge those two?
>
> Bert:
> I've checked r986510 and I like to add some comments:
>
> In libsvn_client/deprecated.c, svn_client_status4() you pass FALSE for
> the new sticky param. But that's wrong: in 1.6.x and previous versions,
> the depth was always respected/enforced. That's why I noticed the
> changed behavior in the first place!
> Shouldn't you pass TRUE there?
The not filtering of the nodes was never the intended behavior. It was a
bug, but had useful behavior for your specific case: explicitly pulling
unavailable nodes into the working copy.
> And what I don't understand: why the extra parameter at all?
> If the param is set to TRUE unconditionally, then the behavior seems to
> be the very same as in 1.6.x:
> If the depth is less than the depth of the WC, it behaves the same as if
> the param is FALSE. Only if the depth is deeper then the param has any
> effect - setting the param to TRUE *ignores* deeper depths.
>
> So from my point of view, that parameter isn't necessary: the behavior
> can be configured by using the depth parameter alone.
Well.. that depends on what is the ambient depth of the directory and what
you try to do with it. If the directory has depth children, passing depth
infinity should be seen as depth children and depth files as depth files.
svn status -u was designed to show what svn up would do, and that really
needs the current behavior to work correctly. I think that is the behavior
older clients want. (But thanks for opening the discussion on that!)
> Also, since this is a readonly operation, the naming 'depth_is_sticky'
> isn't very good. Even confusing.
Actually the name is 'depth_as_sticky'.
>
> Ok, reading my text above again, I think I'm not very clear why I think
> the parameter isn't necessary. So I'll try again:
>
> depth sticky
> <= WC depth FALSE 1.6.x == 1.7 : data for depth
> <= WC depth TRUE 1.6.x == 1.7 : data for depth
> > WC depth FALSE 1.6.x data for depth, 1.7 data for
WCdepth
> > WC depth TRUE 1.6.x data for depth, 1.7 data for depth
>
> Also, if a client wants the data only for the WC depth, passing a depth
> of 'unknown' will do exactly that, no matter what the sticky is set to.
>
> So: every outcome of that API can be triggered by specifying the depth
> alone. So why not get rid of the sticky param and always do as if it was
> set to TRUE?
Note that depth is used for more than just this filtering on the ra layer.
It also applies on what nodes of your local working copy are shown. It did
work as a filter there.
Are you sure you can mimic that without the extra Boolean?
(I certainly don't see any of this in your table)
Bert
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 17.08.2010 23:41, Hyrum K. Wright wrote:
> On Tue, Aug 17, 2010 at 3:45 PM, C. Michael Pilato<cm...@collab.net> wrote:
>> On 08/17/2010 01:42 PM, Stefan Küng wrote:
>>> Maybe I don't understand that change:
>>> --depth specifies a depth to use for the command. If I want the command
>>> to use the depth of the working copy, I specify an unknown depth or none
>>> at all. But if I specify a depth, I would assume the command to respect
>>> that depth and return the info with that depth.
>>> So why should the -u flag not use the specified depth?
>>
>> --depth is a filtering option -- it can only reduce the scope of an
>> operation, it can not expand it.
>>
>> Bert sez he'll make the behavior optional in the API call so you can make
>> use of it. We won't expose it at all in the 'svn' command-line client, but
>> TortoiseSVN can get its behavior back. Sound good?
>
> <sarcasm>
> Yay for another API flag!
> </sarcasm>
Well, it's either another flag, or use bitmasks. And since bitmasks are
not allowed anymore, there aren't any more options.
> I'm starting to wonder if the mission (at the API level) of 'st -u'
> and vanilla 'st' has diverged enough that we may want to consider an
> API named svn_client_remote_status() or something. It seems a bit
> silly to keep extending APIs using various boolean flags[1], in a
> manner which eventually leads to both consumer and programmer
> confusion. This eventually leads to entry points whose behavior
> wildly varies based upon the permutations of the set of flags.
> Perhaps status5 (with its 13 parameters) has reached this point?
But that would lead to another problem: how would you combine the local
status and the remote status data? Have the clients merge those two?
Bert:
I've checked r986510 and I like to add some comments:
In libsvn_client/deprecated.c, svn_client_status4() you pass FALSE for
the new sticky param. But that's wrong: in 1.6.x and previous versions,
the depth was always respected/enforced. That's why I noticed the
changed behavior in the first place!
Shouldn't you pass TRUE there?
And what I don't understand: why the extra parameter at all?
If the param is set to TRUE unconditionally, then the behavior seems to
be the very same as in 1.6.x:
If the depth is less than the depth of the WC, it behaves the same as if
the param is FALSE. Only if the depth is deeper then the param has any
effect - setting the param to TRUE *ignores* deeper depths.
So from my point of view, that parameter isn't necessary: the behavior
can be configured by using the depth parameter alone.
Also, since this is a readonly operation, the naming 'depth_is_sticky'
isn't very good. Even confusing.
Ok, reading my text above again, I think I'm not very clear why I think
the parameter isn't necessary. So I'll try again:
depth sticky
<= WC depth FALSE 1.6.x == 1.7 : data for depth
<= WC depth TRUE 1.6.x == 1.7 : data for depth
> WC depth FALSE 1.6.x data for depth, 1.7 data for WCdepth
> WC depth TRUE 1.6.x data for depth, 1.7 data for depth
Also, if a client wants the data only for the WC depth, passing a depth
of 'unknown' will do exactly that, no matter what the sticky is set to.
So: every outcome of that API can be triggered by specifying the depth
alone. So why not get rid of the sticky param and always do as if it was
set to TRUE?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 17.08.2010 23:41, Hyrum K. Wright wrote:
> On Tue, Aug 17, 2010 at 3:45 PM, C. Michael Pilato<cm...@collab.net> wrote:
>> On 08/17/2010 01:42 PM, Stefan Küng wrote:
>>> Maybe I don't understand that change:
>>> --depth specifies a depth to use for the command. If I want the command
>>> to use the depth of the working copy, I specify an unknown depth or none
>>> at all. But if I specify a depth, I would assume the command to respect
>>> that depth and return the info with that depth.
>>> So why should the -u flag not use the specified depth?
>>
>> --depth is a filtering option -- it can only reduce the scope of an
>> operation, it can not expand it.
>>
>> Bert sez he'll make the behavior optional in the API call so you can make
>> use of it. We won't expose it at all in the 'svn' command-line client, but
>> TortoiseSVN can get its behavior back. Sound good?
>
> <sarcasm>
> Yay for another API flag!
> </sarcasm>
Well, it's either another flag, or use bitmasks. And since bitmasks are
not allowed anymore, there aren't any more options.
> I'm starting to wonder if the mission (at the API level) of 'st -u'
> and vanilla 'st' has diverged enough that we may want to consider an
> API named svn_client_remote_status() or something. It seems a bit
> silly to keep extending APIs using various boolean flags[1], in a
> manner which eventually leads to both consumer and programmer
> confusion. This eventually leads to entry points whose behavior
> wildly varies based upon the permutations of the set of flags.
> Perhaps status5 (with its 13 parameters) has reached this point?
But that would lead to another problem: how would you combine the local
status and the remote status data? Have the clients merge those two?
Bert:
I've checked r986510 and I like to add some comments:
In libsvn_client/deprecated.c, svn_client_status4() you pass FALSE for
the new sticky param. But that's wrong: in 1.6.x and previous versions,
the depth was always respected/enforced. That's why I noticed the
changed behavior in the first place!
Shouldn't you pass TRUE there?
And what I don't understand: why the extra parameter at all?
If the param is set to TRUE unconditionally, then the behavior seems to
be the very same as in 1.6.x:
If the depth is less than the depth of the WC, it behaves the same as if
the param is FALSE. Only if the depth is deeper then the param has any
effect - setting the param to TRUE *ignores* deeper depths.
So from my point of view, that parameter isn't necessary: the behavior
can be configured by using the depth parameter alone.
Also, since this is a readonly operation, the naming 'depth_is_sticky'
isn't very good. Even confusing.
Ok, reading my text above again, I think I'm not very clear why I think
the parameter isn't necessary. So I'll try again:
depth sticky
<= WC depth FALSE 1.6.x == 1.7 : data for depth
<= WC depth TRUE 1.6.x == 1.7 : data for depth
> WC depth FALSE 1.6.x data for depth, 1.7 data for WCdepth
> WC depth TRUE 1.6.x data for depth, 1.7 data for depth
Also, if a client wants the data only for the WC depth, passing a depth
of 'unknown' will do exactly that, no matter what the sticky is set to.
So: every outcome of that API can be triggered by specifying the depth
alone. So why not get rid of the sticky param and always do as if it was
set to TRUE?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: svn_client_status5() and depth
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Tue, Aug 17, 2010 at 3:45 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 08/17/2010 01:42 PM, Stefan Küng wrote:
>> Maybe I don't understand that change:
>> --depth specifies a depth to use for the command. If I want the command
>> to use the depth of the working copy, I specify an unknown depth or none
>> at all. But if I specify a depth, I would assume the command to respect
>> that depth and return the info with that depth.
>> So why should the -u flag not use the specified depth?
>
> --depth is a filtering option -- it can only reduce the scope of an
> operation, it can not expand it.
>
> Bert sez he'll make the behavior optional in the API call so you can make
> use of it. We won't expose it at all in the 'svn' command-line client, but
> TortoiseSVN can get its behavior back. Sound good?
<sarcasm>
Yay for another API flag!
</sarcasm>
I'm starting to wonder if the mission (at the API level) of 'st -u'
and vanilla 'st' has diverged enough that we may want to consider an
API named svn_client_remote_status() or something. It seems a bit
silly to keep extending APIs using various boolean flags[1], in a
manner which eventually leads to both consumer and programmer
confusion. This eventually leads to entry points whose behavior
wildly varies based upon the permutations of the set of flags.
Perhaps status5 (with its 13 parameters) has reached this point?
-Hyrum
[1] I will readily admit to being as guilty of this as anybody else,
but the first step in repentance is recognition, and the next is, uh,
proselyting a new-found vision of The Way things should be.
Re: svn_client_status5() and depth
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/17/2010 01:42 PM, Stefan Küng wrote:
> Maybe I don't understand that change:
> --depth specifies a depth to use for the command. If I want the command
> to use the depth of the working copy, I specify an unknown depth or none
> at all. But if I specify a depth, I would assume the command to respect
> that depth and return the info with that depth.
> So why should the -u flag not use the specified depth?
--depth is a filtering option -- it can only reduce the scope of an
operation, it can not expand it.
Bert sez he'll make the behavior optional in the API call so you can make
use of it. We won't expose it at all in the 'svn' command-line client, but
TortoiseSVN can get its behavior back. Sound good?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn_client_status5() and depth
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/17/2010 01:42 PM, Stefan Küng wrote:
> Maybe I don't understand that change:
> --depth specifies a depth to use for the command. If I want the command
> to use the depth of the working copy, I specify an unknown depth or none
> at all. But if I specify a depth, I would assume the command to respect
> that depth and return the info with that depth.
> So why should the -u flag not use the specified depth?
--depth is a filtering option -- it can only reduce the scope of an
operation, it can not expand it.
Bert sez he'll make the behavior optional in the API call so you can make
use of it. We won't expose it at all in the 'svn' command-line client, but
TortoiseSVN can get its behavior back. Sound good?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 17.08.2010 22:32, C. Michael Pilato wrote:
> On 08/17/2010 12:44 PM, Stefan Küng wrote:
>>> Like I said in r957917, I think we should fix this in a different way.
>>>
>>> The difference is between:
>>> What would you get with
>>> * svn up --depth infinity
>>> and
>>> * svn up --set-depth infinity
>>>
>>> svn status --depth infinity used to show the last variant, but shows the
>>> first variant now.
>>>
>>> I think we should add an option to choose between those two variants. (By
>>> enabling --set-depth on 'svn status' and a similar change to
>>> libsvn_client)
>>
>> But 'svn status' with a --set-depth would mean that this call could
>> change the WC?
>> Until now, 'svn st' didn't change the WC at all, i.e., it was a
>> read-only operation. So is such a change really wanted or necessary?
>
> Agreed. 'svn st' is a read-only operation, period. But I suspect that Bert
> is saying that the --set-depth option, when applied to 'svn status -u',
> would be merely a way to describe the "mode" of the -u?
Isn't that what --depth is for?
As I understand it, --depth is to specify the depth you want, and
--set-depth is the depth you want the target to set to (i.e., keep that
depth after the operation).
> If that's the case, personally I think it would be a horrendous UI decision.
> Any option that has "set" as its action-word sounds like something's about
> to be changed, which is not what's really going on here.
That's how I understand it: --set-depth sets the depth. But of course
it's likely that I'm wrong here.
> But that said, I believe Bert's change in r957917 was a good one -- a
> correct one -- perfectly in line with the interpretation of the -u option to
> 'svn st' altogether. So I'm interested, Stefan, in understanding why
> TortoiseSVN wants the prior behavior. What's TortoiseSVN trying to tell its
> users with this extra data?
I use this in the "check for modifications" dialog which shows the
status of the whole working copy in a flat view. There's a 'check
repository' button which uses the '-u' flag.
Now, if users have a sparse checkout, they can use the 'check
repository' button and get all the files that are not in their sparse
checkout but in the repository. Then users can right-click on those
files and update those - which is used to populate a sparse checkout.
And also, if new folders are added users can 'extend' their sparse
checkout that way, so those new folders have to show up with an 'svn st
-u -v --depth infinity' so users can actually see that there's something
new in the repository.
Maybe I don't understand that change:
--depth specifies a depth to use for the command. If I want the command
to use the depth of the working copy, I specify an unknown depth or none
at all. But if I specify a depth, I would assume the command to respect
that depth and return the info with that depth.
So why should the -u flag not use the specified depth?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 17.08.2010 22:32, C. Michael Pilato wrote:
> On 08/17/2010 12:44 PM, Stefan Küng wrote:
>>> Like I said in r957917, I think we should fix this in a different way.
>>>
>>> The difference is between:
>>> What would you get with
>>> * svn up --depth infinity
>>> and
>>> * svn up --set-depth infinity
>>>
>>> svn status --depth infinity used to show the last variant, but shows the
>>> first variant now.
>>>
>>> I think we should add an option to choose between those two variants. (By
>>> enabling --set-depth on 'svn status' and a similar change to
>>> libsvn_client)
>>
>> But 'svn status' with a --set-depth would mean that this call could
>> change the WC?
>> Until now, 'svn st' didn't change the WC at all, i.e., it was a
>> read-only operation. So is such a change really wanted or necessary?
>
> Agreed. 'svn st' is a read-only operation, period. But I suspect that Bert
> is saying that the --set-depth option, when applied to 'svn status -u',
> would be merely a way to describe the "mode" of the -u?
Isn't that what --depth is for?
As I understand it, --depth is to specify the depth you want, and
--set-depth is the depth you want the target to set to (i.e., keep that
depth after the operation).
> If that's the case, personally I think it would be a horrendous UI decision.
> Any option that has "set" as its action-word sounds like something's about
> to be changed, which is not what's really going on here.
That's how I understand it: --set-depth sets the depth. But of course
it's likely that I'm wrong here.
> But that said, I believe Bert's change in r957917 was a good one -- a
> correct one -- perfectly in line with the interpretation of the -u option to
> 'svn st' altogether. So I'm interested, Stefan, in understanding why
> TortoiseSVN wants the prior behavior. What's TortoiseSVN trying to tell its
> users with this extra data?
I use this in the "check for modifications" dialog which shows the
status of the whole working copy in a flat view. There's a 'check
repository' button which uses the '-u' flag.
Now, if users have a sparse checkout, they can use the 'check
repository' button and get all the files that are not in their sparse
checkout but in the repository. Then users can right-click on those
files and update those - which is used to populate a sparse checkout.
And also, if new folders are added users can 'extend' their sparse
checkout that way, so those new folders have to show up with an 'svn st
-u -v --depth infinity' so users can actually see that there's something
new in the repository.
Maybe I don't understand that change:
--depth specifies a depth to use for the command. If I want the command
to use the depth of the working copy, I specify an unknown depth or none
at all. But if I specify a depth, I would assume the command to respect
that depth and return the info with that depth.
So why should the -u flag not use the specified depth?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: svn_client_status5() and depth
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/17/2010 12:44 PM, Stefan Küng wrote:
>> Like I said in r957917, I think we should fix this in a different way.
>>
>> The difference is between:
>> What would you get with
>> * svn up --depth infinity
>> and
>> * svn up --set-depth infinity
>>
>> svn status --depth infinity used to show the last variant, but shows the
>> first variant now.
>>
>> I think we should add an option to choose between those two variants. (By
>> enabling --set-depth on 'svn status' and a similar change to
>> libsvn_client)
>
> But 'svn status' with a --set-depth would mean that this call could
> change the WC?
> Until now, 'svn st' didn't change the WC at all, i.e., it was a
> read-only operation. So is such a change really wanted or necessary?
Agreed. 'svn st' is a read-only operation, period. But I suspect that Bert
is saying that the --set-depth option, when applied to 'svn status -u',
would be merely a way to describe the "mode" of the -u?
If that's the case, personally I think it would be a horrendous UI decision.
Any option that has "set" as its action-word sounds like something's about
to be changed, which is not what's really going on here.
But that said, I believe Bert's change in r957917 was a good one -- a
correct one -- perfectly in line with the interpretation of the -u option to
'svn st' altogether. So I'm interested, Stefan, in understanding why
TortoiseSVN wants the prior behavior. What's TortoiseSVN trying to tell its
users with this extra data?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 17.08.2010 22:29, Bert Huijben wrote:
>> But 'svn status' with a --set-depth would mean that this call could
>> change the WC?
>> Until now, 'svn st' didn't change the WC at all, i.e., it was a
>> read-only operation. So is such a change really wanted or necessary?
>
> No it doesn't change the WC, but it sends different information to the
> network.
> In one case the depth stored in the working copy is used (to filter the
> information you miss in your example) and in the other case the information
> isn't filtered.
>
> svn status -u was designed to show what an equivalent 'svn up' would do and
> in this case it didn't do that. Instead it just showed everything below,
> without looking at the ambient depth.
Hmm, you're right. An 'svn up --depth infinity' also doesn't extend a
sparse checkout. But 'svn up --set-depth infinity' does.
So, '--depth ARG' only does something if ARG is less or equal the depth
of the working copy. If it is more (a deeper depth) then it just does
nothing, i.e., uses the depth of the working copy.
I think for read-only operations, --depth ARG should work with a deeper
depth too. For write operations like update, a deeper depth would
automatically imply '--set-depth' (depth_is_sticky in the
svn_client_update3 API), so for those the --set-depth is necessary to
use the deeper depth.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 17.08.2010 22:29, Bert Huijben wrote:
>> But 'svn status' with a --set-depth would mean that this call could
>> change the WC?
>> Until now, 'svn st' didn't change the WC at all, i.e., it was a
>> read-only operation. So is such a change really wanted or necessary?
>
> No it doesn't change the WC, but it sends different information to the
> network.
> In one case the depth stored in the working copy is used (to filter the
> information you miss in your example) and in the other case the information
> isn't filtered.
>
> svn status -u was designed to show what an equivalent 'svn up' would do and
> in this case it didn't do that. Instead it just showed everything below,
> without looking at the ambient depth.
Hmm, you're right. An 'svn up --depth infinity' also doesn't extend a
sparse checkout. But 'svn up --set-depth infinity' does.
So, '--depth ARG' only does something if ARG is less or equal the depth
of the working copy. If it is more (a deeper depth) then it just does
nothing, i.e., uses the depth of the working copy.
I think for read-only operations, --depth ARG should work with a deeper
depth too. For write operations like update, a deeper depth would
automatically imply '--set-depth' (depth_is_sticky in the
svn_client_update3 API), so for those the --set-depth is necessary to
use the deeper depth.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
RE: svn_client_status5() and depth
Posted by Bert Huijben <be...@vmoo.com>.
> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
> Sent: dinsdag 17 augustus 2010 12:45
> To: Bert Huijben
> Cc: 'Subversion Development'
> Subject: Re: svn_client_status5() and depth
>
> On 17.08.2010 21:37, Bert Huijben wrote:
> >
> >
> >> -----Original Message-----
> >> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
> >> Sent: dinsdag 17 augustus 2010 12:28
> >> To: Subversion Development
> >> Subject: svn_client_status5() and depth
> >>
> >> Hi,
> >>
> >> * check out a folder with depth svn_depth_empty (svn co
> >> file:///d:/testrepo/trunk testwc)
> >> * cd into that folder (cd testwc)
> >> * run 'svn st -u -v --depth infinity'
> >>
> >> In 1.6.x, I get the status for all the files under that folder that
> >> exist in the repository.
> >>
> >> With the latest trunk (r986453), I only get
> >> 32 32 user .
> >> Status against revision: 32
> >>
> >> All the files in the repository are not reported back.
> >>
> >> I'm relying on the behavior of the 1.6.x version in TSVN. If this
change
> >> was by design, why was this changed? I couldn't find anything in recent
> >> discussions about this. But that could easily be because of the
> >> not-very-good search feature of the mailing list archives.
> >>
> >> Or is this a bug?
> >
> > Hmm.. I think I know why you see this bug and I was responsible for
> > introducing it:
> >
> > Like I said in r957917, I think we should fix this in a different way.
> >
> > The difference is between:
> > What would you get with
> > * svn up --depth infinity
> > and
> > * svn up --set-depth infinity
> >
> > svn status --depth infinity used to show the last variant, but shows the
> > first variant now.
> >
> > I think we should add an option to choose between those two variants.
(By
> > enabling --set-depth on 'svn status' and a similar change to
libsvn_client)
>
> But 'svn status' with a --set-depth would mean that this call could
> change the WC?
> Until now, 'svn st' didn't change the WC at all, i.e., it was a
> read-only operation. So is such a change really wanted or necessary?
No it doesn't change the WC, but it sends different information to the
network.
In one case the depth stored in the working copy is used (to filter the
information you miss in your example) and in the other case the information
isn't filtered.
svn status -u was designed to show what an equivalent 'svn up' would do and
in this case it didn't do that. Instead it just showed everything below,
without looking at the ambient depth.
Bert
RE: svn_client_status5() and depth
Posted by Bert Huijben <be...@vmoo.com>.
> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
> Sent: dinsdag 17 augustus 2010 12:45
> To: Bert Huijben
> Cc: 'Subversion Development'
> Subject: Re: svn_client_status5() and depth
>
> On 17.08.2010 21:37, Bert Huijben wrote:
> >
> >
> >> -----Original Message-----
> >> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
> >> Sent: dinsdag 17 augustus 2010 12:28
> >> To: Subversion Development
> >> Subject: svn_client_status5() and depth
> >>
> >> Hi,
> >>
> >> * check out a folder with depth svn_depth_empty (svn co
> >> file:///d:/testrepo/trunk testwc)
> >> * cd into that folder (cd testwc)
> >> * run 'svn st -u -v --depth infinity'
> >>
> >> In 1.6.x, I get the status for all the files under that folder that
> >> exist in the repository.
> >>
> >> With the latest trunk (r986453), I only get
> >> 32 32 user .
> >> Status against revision: 32
> >>
> >> All the files in the repository are not reported back.
> >>
> >> I'm relying on the behavior of the 1.6.x version in TSVN. If this
change
> >> was by design, why was this changed? I couldn't find anything in recent
> >> discussions about this. But that could easily be because of the
> >> not-very-good search feature of the mailing list archives.
> >>
> >> Or is this a bug?
> >
> > Hmm.. I think I know why you see this bug and I was responsible for
> > introducing it:
> >
> > Like I said in r957917, I think we should fix this in a different way.
> >
> > The difference is between:
> > What would you get with
> > * svn up --depth infinity
> > and
> > * svn up --set-depth infinity
> >
> > svn status --depth infinity used to show the last variant, but shows the
> > first variant now.
> >
> > I think we should add an option to choose between those two variants.
(By
> > enabling --set-depth on 'svn status' and a similar change to
libsvn_client)
>
> But 'svn status' with a --set-depth would mean that this call could
> change the WC?
> Until now, 'svn st' didn't change the WC at all, i.e., it was a
> read-only operation. So is such a change really wanted or necessary?
No it doesn't change the WC, but it sends different information to the
network.
In one case the depth stored in the working copy is used (to filter the
information you miss in your example) and in the other case the information
isn't filtered.
svn status -u was designed to show what an equivalent 'svn up' would do and
in this case it didn't do that. Instead it just showed everything below,
without looking at the ambient depth.
Bert
Re: svn_client_status5() and depth
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/17/2010 12:44 PM, Stefan Küng wrote:
>> Like I said in r957917, I think we should fix this in a different way.
>>
>> The difference is between:
>> What would you get with
>> * svn up --depth infinity
>> and
>> * svn up --set-depth infinity
>>
>> svn status --depth infinity used to show the last variant, but shows the
>> first variant now.
>>
>> I think we should add an option to choose between those two variants. (By
>> enabling --set-depth on 'svn status' and a similar change to
>> libsvn_client)
>
> But 'svn status' with a --set-depth would mean that this call could
> change the WC?
> Until now, 'svn st' didn't change the WC at all, i.e., it was a
> read-only operation. So is such a change really wanted or necessary?
Agreed. 'svn st' is a read-only operation, period. But I suspect that Bert
is saying that the --set-depth option, when applied to 'svn status -u',
would be merely a way to describe the "mode" of the -u?
If that's the case, personally I think it would be a horrendous UI decision.
Any option that has "set" as its action-word sounds like something's about
to be changed, which is not what's really going on here.
But that said, I believe Bert's change in r957917 was a good one -- a
correct one -- perfectly in line with the interpretation of the -u option to
'svn st' altogether. So I'm interested, Stefan, in understanding why
TortoiseSVN wants the prior behavior. What's TortoiseSVN trying to tell its
users with this extra data?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 17.08.2010 21:37, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
>> Sent: dinsdag 17 augustus 2010 12:28
>> To: Subversion Development
>> Subject: svn_client_status5() and depth
>>
>> Hi,
>>
>> * check out a folder with depth svn_depth_empty (svn co
>> file:///d:/testrepo/trunk testwc)
>> * cd into that folder (cd testwc)
>> * run 'svn st -u -v --depth infinity'
>>
>> In 1.6.x, I get the status for all the files under that folder that
>> exist in the repository.
>>
>> With the latest trunk (r986453), I only get
>> 32 32 user .
>> Status against revision: 32
>>
>> All the files in the repository are not reported back.
>>
>> I'm relying on the behavior of the 1.6.x version in TSVN. If this change
>> was by design, why was this changed? I couldn't find anything in recent
>> discussions about this. But that could easily be because of the
>> not-very-good search feature of the mailing list archives.
>>
>> Or is this a bug?
>
> Hmm.. I think I know why you see this bug and I was responsible for
> introducing it:
>
> Like I said in r957917, I think we should fix this in a different way.
>
> The difference is between:
> What would you get with
> * svn up --depth infinity
> and
> * svn up --set-depth infinity
>
> svn status --depth infinity used to show the last variant, but shows the
> first variant now.
>
> I think we should add an option to choose between those two variants. (By
> enabling --set-depth on 'svn status' and a similar change to libsvn_client)
But 'svn status' with a --set-depth would mean that this call could
change the WC?
Until now, 'svn st' didn't change the WC at all, i.e., it was a
read-only operation. So is such a change really wanted or necessary?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: svn_client_status5() and depth
Posted by Stefan Küng <to...@gmail.com>.
On 17.08.2010 21:37, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
>> Sent: dinsdag 17 augustus 2010 12:28
>> To: Subversion Development
>> Subject: svn_client_status5() and depth
>>
>> Hi,
>>
>> * check out a folder with depth svn_depth_empty (svn co
>> file:///d:/testrepo/trunk testwc)
>> * cd into that folder (cd testwc)
>> * run 'svn st -u -v --depth infinity'
>>
>> In 1.6.x, I get the status for all the files under that folder that
>> exist in the repository.
>>
>> With the latest trunk (r986453), I only get
>> 32 32 user .
>> Status against revision: 32
>>
>> All the files in the repository are not reported back.
>>
>> I'm relying on the behavior of the 1.6.x version in TSVN. If this change
>> was by design, why was this changed? I couldn't find anything in recent
>> discussions about this. But that could easily be because of the
>> not-very-good search feature of the mailing list archives.
>>
>> Or is this a bug?
>
> Hmm.. I think I know why you see this bug and I was responsible for
> introducing it:
>
> Like I said in r957917, I think we should fix this in a different way.
>
> The difference is between:
> What would you get with
> * svn up --depth infinity
> and
> * svn up --set-depth infinity
>
> svn status --depth infinity used to show the last variant, but shows the
> first variant now.
>
> I think we should add an option to choose between those two variants. (By
> enabling --set-depth on 'svn status' and a similar change to libsvn_client)
But 'svn status' with a --set-depth would mean that this call could
change the WC?
Until now, 'svn st' didn't change the WC at all, i.e., it was a
read-only operation. So is such a change really wanted or necessary?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
RE: svn_client_status5() and depth
Posted by Bert Huijben <be...@vmoo.com>.
> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
> Sent: dinsdag 17 augustus 2010 12:28
> To: Subversion Development
> Subject: svn_client_status5() and depth
>
> Hi,
>
> * check out a folder with depth svn_depth_empty (svn co
> file:///d:/testrepo/trunk testwc)
> * cd into that folder (cd testwc)
> * run 'svn st -u -v --depth infinity'
>
> In 1.6.x, I get the status for all the files under that folder that
> exist in the repository.
>
> With the latest trunk (r986453), I only get
> 32 32 user .
> Status against revision: 32
>
> All the files in the repository are not reported back.
>
> I'm relying on the behavior of the 1.6.x version in TSVN. If this change
> was by design, why was this changed? I couldn't find anything in recent
> discussions about this. But that could easily be because of the
> not-very-good search feature of the mailing list archives.
>
> Or is this a bug?
Hmm.. I think I know why you see this bug and I was responsible for
introducing it:
Like I said in r957917, I think we should fix this in a different way.
The difference is between:
What would you get with
* svn up --depth infinity
and
* svn up --set-depth infinity
svn status --depth infinity used to show the last variant, but shows the
first variant now.
I think we should add an option to choose between those two variants. (By
enabling --set-depth on 'svn status' and a similar change to libsvn_client)
Bert
RE: svn_client_status5() and depth
Posted by Bert Huijben <be...@vmoo.com>.
> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
> Sent: dinsdag 17 augustus 2010 12:28
> To: Subversion Development
> Subject: svn_client_status5() and depth
>
> Hi,
>
> * check out a folder with depth svn_depth_empty (svn co
> file:///d:/testrepo/trunk testwc)
> * cd into that folder (cd testwc)
> * run 'svn st -u -v --depth infinity'
>
> In 1.6.x, I get the status for all the files under that folder that
> exist in the repository.
>
> With the latest trunk (r986453), I only get
> 32 32 user .
> Status against revision: 32
>
> All the files in the repository are not reported back.
>
> I'm relying on the behavior of the 1.6.x version in TSVN. If this change
> was by design, why was this changed? I couldn't find anything in recent
> discussions about this. But that could easily be because of the
> not-very-good search feature of the mailing list archives.
>
> Or is this a bug?
This looks like a bug to me. It should show all nodes with -v.
Bert
RE: svn_client_status5() and depth
Posted by Bert Huijben <be...@vmoo.com>.
> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn@gmail.com]
> Sent: dinsdag 17 augustus 2010 12:28
> To: Subversion Development
> Subject: svn_client_status5() and depth
>
> Hi,
>
> * check out a folder with depth svn_depth_empty (svn co
> file:///d:/testrepo/trunk testwc)
> * cd into that folder (cd testwc)
> * run 'svn st -u -v --depth infinity'
>
> In 1.6.x, I get the status for all the files under that folder that
> exist in the repository.
>
> With the latest trunk (r986453), I only get
> 32 32 user .
> Status against revision: 32
>
> All the files in the repository are not reported back.
>
> I'm relying on the behavior of the 1.6.x version in TSVN. If this change
> was by design, why was this changed? I couldn't find anything in recent
> discussions about this. But that could easily be because of the
> not-very-good search feature of the mailing list archives.
>
> Or is this a bug?
Hmm.. I think I know why you see this bug and I was responsible for
introducing it:
Like I said in r957917, I think we should fix this in a different way.
The difference is between:
What would you get with
* svn up --depth infinity
and
* svn up --set-depth infinity
svn status --depth infinity used to show the last variant, but shows the
first variant now.
I think we should add an option to choose between those two variants. (By
enabling --set-depth on 'svn status' and a similar change to libsvn_client)
Bert