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 20:37:19 2006