I should also add that if you make a local change to a property
on the directory, then svn status *does* report that it has been
modified. If it weren't reporting info for your current working
directory, then that would be absent (and in fact, the entire status
line would be absent). It is not.
Tom
Tom Karzes wrote:
> You missed something: There *is* no level up. Foo is the top-level,
> either the top-level of my working copy, or an externals def point.
> One more time: I have a working copy. The externals defs on the
> top level are out of date. There is no way to use the status command
> to determine this. Also, by your argument, "svn update" should only
> update the contents of a work area, and not the directory itself. This
> makes no sense.
>
> You need to think of this in terms of how it's used. A person has
> a working copy. He wants to know if it's up-to-date. I don't care
> about any theoretical notions of how only the contents of a directory
> get reported on; I'm looking for what people actually want. They
> want to know if their working copy is up to date. There is no way
> to determine this, short of using "svn info" on on the repository.
> This is a bug.
>
> Furthermore, look at my example: I am doing status and I'm giving
> it a working copy pathname as an argument. It should not matter
> if that pathname contains a / or not. All that should matter is the
> directory it points to. But it does matter. If the parent is "visible"
> in the path, then it shows the status. If not, then it doesn't. Even
> when reporting on the exact same path. Bug.
>
> It might help you to think of this properly if you view the properties
> of a directory as "contents" of the directory. Then, by your argument,
> their status should be reported when requesting status for the directory.
>
> In any case, svn status *does* report on the directory itself. It appear
> on a line. It includes all of the fields, including whether it is out of
> date. Your argument would only make sense if that entry did not
> appear at all. But it does. And the information reported on that line
> is incorrect.
>
> Tom
>
>
> Tim Hill wrote:
>
>> Did I miss something, or isn't this just an issue about svn status
>> usage?
>>
>> When you do svn status on "foo", you are asking for the status of
>> the _contents_ of foo, not foo itself. So, if nothing _inside_ foo
>> has changed, then that's what svn status will tell you. To get the
>> status of the directory foo, you need to go one level up. The
>> semantic nuance here is if we consider "foo" itself to be an
>> anonymous container of stuff or if "foo" is really part of the whole
>> package which is "foo+contents". If the latter, then you can think
>> of the properties of "foo" as part of the package and you assertion
>> would be correct. But I think svn thinks "foo" is just an anonymous
>> container.
>>
>> I think this is consistent: at the top of every working copy is an
>> unversioned directory that contains versioned files and folders. You
>> can do an "svn status" against this folder, which will show you the
>> status of the files _inside_ this unversioned folder, but does not
>> (of course) show the status of the folder itself.
>>
>> --Tim
>>
>> On Nov 14, 2006, at 1:14 AM, Tom Karzes wrote:
>>
>>> I experimented with this some more. It seems that this bug only
>>> occurs if Subversion isn't aware of a parent directory that
>>> corresponds
>>> to the parent in the repository. For for instance, if your working
>>> copy
>>> has "foo" as the top-level, and "bar" is beneath is (as a direct
>>> child of
>>> "foo", and not an externals def), then if you're in "foo" and do
>>> "svn status --show-updates", and if both "foo" and "bar" have
>>> property changes, you'll see the "*" for "bar", but not for "foo".
>>> If you cd to "bar" and do it again, without giving it a path argument
>>> that includes "foo", then the "*" will disappear from "bar" as well.
>>>
>>> Here is a complete example:
>>>
>>>
>>> Create foo and foo/bar, and import it into the repository:
>>>
>>> % mkdir foo foo/bar
>>> % svn import -m xxx foo file:///home/tkarzes/svntest/repos/xyz
>>> Adding foo/bar
>>>
>>> Committed revision 82.
>>> %
>>>
>>> Check it out as as both foo2 and foo3:
>>>
>>> % svn co file:///home/tkarzes/svntest/repos/xyz foo2
>>> A foo2/bar
>>> Checked out revision 82.
>>> % svn co file:///home/tkarzes/svntest/repos/xyz foo3
>>> A foo3/bar
>>> Checked out revision 82.
>>> %
>>>
>>> Set properties on foo2 and foo2/bar, and commit:
>>>
>>> % svn propset prop1 abc foo2
>>> property 'prop1' set on 'foo2'
>>> % svn propset prop2 def foo2/bar
>>> property 'prop2' set on 'foo2/bar'
>>> % svn commit -m xxx foo2
>>> Sending foo2
>>> Sending foo2/bar
>>>
>>> Committed revision 83.
>>> %
>>>
>>> At this point, both foo3 and foo3/bar are out of date. However,
>>> "svn status --show-updates" only shows foo3/bar as being out of
>>> date, and even that fails if you cd to foo3/bar:
>>>
>>> % svn status --show-updates --verbose foo3
>>> * 82 82 tkarzes foo3/bar
>>> 82 82 tkarzes foo3
>>> Status against revision: 83
>>> % cd foo3
>>> % svn status --show-updates --verbose .
>>> * 82 82 tkarzes bar
>>> 82 82 tkarzes .
>>> Status against revision: 83
>>> % cd bar
>>> % svn status --show-updates --verbose .
>>> 82 82 tkarzes .
>>> Status against revision: 83
>>> %
>>>
>>> But, if you give it a little more context, it will figure it out:
>>>
>>> % svn status --show-updates --verbose ./../.
>>> * 82 82 tkarzes ../bar
>>> 82 82 tkarzes ..
>>> Status against revision: 83
>>> %
>>>
>>> Unfortunately, this trick only works for bar, because the
>>> parent directory apparently contains the information it needs.
>>> This trick doesn't work for the parent directory, foo3. There is
>>> no way to see that it's out of date. Yet, clearly it is, as can
>>> be seen with an update:
>>>
>>> % svn update .
>>> U bar
>>> U .
>>> Updated to revision 83.
>>> % svn status --show-updates --verbose .
>>> 83 83 tkarzes bar
>>> 83 83 tkarzes .
>>> Status against revision: 83
>>> %
>>>
>>> Notice that it now recognizes that the last committed change to
>>> both foo and bar was 83. Can anyone tell me if there is a fix
>>> for this? I'm using version 1.3.0 (r17949).
>>>
>>>
>>> Tom Karzes
>>> tkarzes@pixelworks.com
>>>
>>>
>>> Tom Karzes wrote:
>>>
>>>> As far as I can tell, "svn status --show-updates" ignores
>>>> properties that
>>>> have changed in the repository. This means that there's no way to
>>>> use
>>>> "svn status" to tell if your working copy is truly up-to-date. Some
>>>> reasons why I believe this is a bug/design flaw:
>>>>
>>>> 1. Since "svn status" does report changed properties in your
>>>> working
>>>> copy, it is inconsistent for "svn status --show-updates"
>>>> not to
>>>> report changed properties in the repository.
>>>>
>>>> 2. There is no simple passive way to know if your working copy is
>>>> up-to-date, i.e. if "svn update" would update anything. You
>>>> could probably do a recursive "svn info" on the repository
>>>> URL,
>>>> and compare each and every "last changed revision" to see if
>>>> everything is up-to-date, but this seems impractical to me.
>>>>
>>>> 3. If you make some unrelated change to your working copy, and
>>>> try to commit it, the Subversion server will complain that
>>>> your
>>>> working copy is out-of-date. If your working copy is out of
>>>> date to a point where you cannot commit changes made to it,
>>>> then "svn status --show-updates" needs to report that.
>>>>
>>>> Am I missing something here? Or is this just a bug/design flaw in
>>>> the status command?
>>>>
>>>> Tom Karzes
>>>> tkarzes@pixelworks.com
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>> For additional commands, e-mail: users-help@subversion.tigris.org
>>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 14 22:12:01 2006