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
Received on Tue Nov 14 17:27:07 2006