Problem with deleted directory and changed properties

[Brockamp, Peter]

Hello!

I'm new to TortoiseSVN user mailing list.

I guess I found a problem (or bug) in the actual version 1.7.10 that
seems not to be documented yet. Please do the follwing to reproduce:

- Check out a project to the local HDD.
- Delete one arbitrary subdirectory. This will mark the directory as
locally deleted in Tortoise and delete it and all contained files from
the HDD. Do *not* commit this change.
- Now go to the project root and display the Subversion properties.
- Say New/advanced and add some property, e.g. "svn:ignore" and enter
"*.foo".
- Check "Apply property recursively" and click OK.

Now Tortoise will go through all the project's files/directories and
change their properties accordingly. But when it reaches the deleted
directory it seems to fail to obey the "locally deleted" property and
asumes it must be there instead of skipping it. Below this raises the
error

"Can't set properties on 'C:\Path\To\Deleted\Directory': invalid status
for updating properties."

This message aborts the recursive process, part of the directories have
the properties changed to the new value, the other part that hasn't been
processed before hitting the deleted directory remains in the original
state.

Obviously, the correct behaviour should be to skip the locally deleted
dir/file and continue processing the remaining dirs/files.

Regards

Peter

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3032018

To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].

[Peter Brockamp]

http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3032019

[Andy Levy]

I don't see how this is really a "bug", nor do I believe that your last statement is so obvious.

When you apply a property recursively, TSVN is probably looping through all versioned items (as discovered by svn status) & applying the property to each item that's versioned. When it gets to your improperly-deleted item, it's stopping because there's *supposed* to be a versioned item there, but it's not. This indicates (to me) that someone or something has done something in the WC that shouldn't have been done, and the appropriate action (IMO) is to stop and alert the user that the WC may be broken, and needs to be investigated - rather than continue on and cause damage, or keep attempting to make changes that can't be made (wasting time in the process and possibly causing damage).

Consider this: If TSVN swallows the error and continues, then you run svn update or otherwise restore your incorrectly-deleted subdirectory, your WC no longer has that property recursively applied to all items - but you are completely unaware, because you weren't alerted to the missing item when you applied the property.

Try the same actions with the command-line client; I suspect this behavior is in the core libraries, not TSVN, so you'd have to go there looking for a change.

[Peter Brockamp]

Hello!

> I don't see how this is really a "bug", nor do I believe that your
last statement is so obvious.

Didn't say it is (how could I know), I was wondering if so.

> When you apply a property recursively, TSVN is probably looping
through all versioned items
> (as discovered by svn status) & applying the property to each item
that's versioned.

Yep, think so, too!

> When
> it gets to your improperly-deleted item, it's stopping because there's
*supposed* to be a
> versioned item there, but it's not.

Hm, maybe this is kind of misunderstanding! I don't think it is
*improperly* deleted, but maybe the action taken was misunderstood.

I try to make it more precise:
To delete I right click on a versioned directory in (Windows-)explorer
and choose /TortoiseSVN/Delete. So I *do* tell TSVN yes, I really do
want to delete this directory from the trunk - do it for me and take all
actions necessary. The actions TSVN deems necessary are to tag the
directory and all included files as "deleted" in the database of the
local modifications and to delete the files from the local harddisk -
which all makes sense. Attention: I do *not* manually delete them behind
the eyes of TSVN! I can later on commit this change to the repository
and in the commit list it shows the directory and all included files as
"deleted", so TSVN does knows about these changes and thus I would
consider this as being a proper action - correct me if that's wrong, how
else would I properly delete a version controlled directory?

Now I can - without commiting these changes - try to recursively change
the properties, resulting in the error message described previously.
Or I can commit the delete and afterwards change the properties. This
will - BTW without any prior update action - set the properties of *all*
affected directories without any error message (which may be commited
then as well).

So consider:
- Delete
- Commit
- Change Properties
- Commit
works ok as expected!

On the contrary:
- Delete
- No commit here, instead continue editing
- Change Properties
- Commit
fails early and the behaviour is non-conforming to the previously
depicted situation.

To make it clear: *All* above actions are local (not initiated via the
repo browser directly to the SVN-server) and are triggered by
**selecting the respective TSVN action from the context menu**. This is
*not* right clicking on a directory and selecting "delete" as the
explorer option or anything. I am very well aware that this would be
hidden behind TSVN's eyes and would later on cause absolutely legitimate
error messages by Tortoise.

So, to come to an end:
I still would expect that in case of yet uncommited deletes the attempt
to recursively alter properties would not fail. Instead I would expect
TSVN to realize that there are legitimate local deletes, pending to be
commited, so these files need to be skipped when altering properties.
Or, alternatively, I would expect TSVN to realize that there are local
deletes affected, succesively prohibiting any recursive changes of
properties with an early bail out, before changing anything. Or to say
it in the way of a well known OOP-paradigm: When changing the state of
an object by calling one of its methods, better make sure the new state
is consistent, don't leave the object in a half changed, inconsistent
state, as this would be asking for further trouble down the road. The
same applies here: I get an error message in the thick of it. To know
which directories have been altered I would have to manually inspect all
of them. So for the user this is a kind of inconsistent state, right?
While this doesn't fatally break anything here, at least it doesn't feel
really "nice" to me.

> Try the same actions with the command-line client; I suspect this
behavior is in the core libraries, not TSVN, so you'd have to go there
looking for a change.

Oh, damn! I haven't thought of this option yet! I rarely use the SVN
client directly, so I neglected the underlying infrastructure. You're
absolutely right, this might not be a problem of TSVN but rather of the
SVN client or the like! I will check that out ASAP. At least "SVN
propset" has a commandline switch -R for recursive action, so it seems
likely TSVN does eject one single command only and has to live with
SVN's reaction. So this might well have been the wrong place to report
this problem. I'm sorry about that!

Thanks!

Peter

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3032288