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
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-11-30 11:38:21 CET