[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: Tim Hill <drtimhill_at_comcast.net>
Date: 2006-11-14 22:29:25 CET

ok, I just looked at this again...

On Nov 14, 2006, at 11:35 AM, Tom Karzes wrote:

>>>
>>> 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

When I try this same thing on my server I so see an "*" (newer on
server) status for the folder. I'm running 1.4.2, so this might have
been a bug in the earlier versions. Can you try updating to 1.4.2 ?

>>> 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
>

---------------------------------------------------------------------
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:32:11 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.