[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: status command ignores property changes in repository

From: Tom Karzes <tkarzes_at_pixelworks.com>
Date: 2006-11-14 20:35:15 CET

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.


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 20:56:47 2006

This is an archived mail posted to the Subversion Users mailing list.