You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Tom Karzes <tk...@pixelworks.com> on 2006/11/13 23:09:04 UTC
status command ignores property changes in repository
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
Re: status command ignores property changes in repository
Posted by Tom Karzes <tk...@pixelworks.com>.
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
Re: status command ignores property changes in repository
Posted by Tom Karzes <tk...@pixelworks.com>.
I just tested this with 1.4.2 and confirmed what you said - the
bug is indeed fixed in that version. Thanks,
Tom
Tom Karzes wrote:
> Oh, cool -- I don't have 1.4.2 at the moment but I'll try it out and
> see if it fixes this for me -- thanks!
>
> Tom
>
>
> Tim Hill wrote:
>
>> 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
Re: status command ignores property changes in repository
Posted by Tom Karzes <tk...@pixelworks.com>.
Oh, cool -- I don't have 1.4.2 at the moment but I'll try it out and
see if it fixes this for me -- thanks!
Tom
Tim Hill wrote:
> 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
Re: status command ignores property changes in repository
Posted by Tim Hill <dr...@comcast.net>.
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
Re: status command ignores property changes in repository
Posted by Tom Karzes <tk...@pixelworks.com>.
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
Re: status command ignores property changes in repository
Posted by Tim Hill <dr...@comcast.net>.
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
Re: status command ignores property changes in repository
Posted by Tom Karzes <tk...@pixelworks.com>.
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