Possible bug in nightly build

[Robert Dailey]

I'll do my best to describe the steps to reproduce. Information regarding version numbers and my PC are at the bottom.

1. Find a versioned directory in your WC that contains other versioned directories and files under it.
2. Add some new files and change some existing files under this directory.
3. Commit the directory that contains the modified/added files in it
4. After the commit completes and without doing an update, SVN Delete that directory.
5. Try to commit the delete.
6. It fails, saying it needs to be updated.
7. Do an update. You get a tree conflict.
8. Delete the deleted directory (It should still be there with an X overlay).
9. Do an clean/update a few times, revert the delete, and update again. Notice how it isn't pulling down that directory again. You actually have to delete the parent of the deleted directory and do another update at a higher level in order for it to pull down that directory again so you may try to delete it once more.

Let me know if these directions are clear. Information below:

Operating System: Windows 7 Ultimate x64 Build 7201

TortoiseSVN Version Information: 

TortoiseSVN 1.6.99, Build 16641 - 64 Bit -dev, 2009/06/25 17:55:34

Subversion 1.6.4, -dev

apr 1.3.5

apr-utils 1.3.7

neon 0.28.4

OpenSSL 0.9.8k 25 Mar 2009

zlib 1.2.3

[Stefan Küng]

Robert Dailey wrote:
> I'll do my best to describe the steps to reproduce. Information
> regarding version numbers and my PC are at the bottom.
>

> 1. Find a versioned directory in your WC that contains other

> versioned directories and files under it.

> 2. Add some new files and change some existing files under this
> directory.
> 3. Commit the directory that contains the modified/added files in it
> 4. After the commit completes and without doing an update, SVN Delete
> that directory.
> 5. Try to commit the delete.
> 6. It fails, saying it needs to be updated.
> 7. Do an update. You get a tree conflict.
> 8. Delete the deleted directory (It should still be there with an X
> overlay).
> 9. Do an clean/update a few times, revert the delete, and update

> again. Notice how it isn't pulling down that directory again. You
> actually have to delete the parent of the deleted directory and do
> another update at a higher level in order for it to pull down that
> directory again so you may try to delete it once more.

That's expected: the 'depth' is changed to 'this item only' when you
delete a folder.
To get such a folder back, you have to use the "update to revision"
dialog and specify "fully recursive".

Stefan

--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net

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

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

[Robert Dailey]

So you're basically telling me this is a subversion-specific issue, and if I wanted to see this handled a bit more intuitively then I would have to contact them? Fair enough. I just think the behavior is a bit confusing and broken and could be improved. 

[Simon Large]

2009/6/29 Stefan Küng <torto...@gmail.com>:

> Robert Dailey wrote:
>> I'll do my best to describe the steps to reproduce. Information
>> regarding version numbers and my PC are at the bottom.
>>
>>    1. Find a versioned directory in your WC that contains other
>>       versioned directories and files under it.
>>    2. Add some new files and change some existing files under this
>>       directory.
>>    3. Commit the directory that contains the modified/added files in it
>>    4. After the commit completes and without doing an update, SVN Delete
>>       that directory.
>>    5. Try to commit the delete.
>>    6. It fails, saying it needs to be updated.
>>    7. Do an update. You get a tree conflict.

Why should this happen? It's just an ordinary SVN delete of a folder.

>>    8. Delete the deleted directory (It should still be there with an X
>>       overlay).
>>    9. Do an clean/update a few times, revert the delete, and update
>>       again. Notice how it isn't pulling down that directory again. You
>>       actually have to delete the parent of the deleted directory and do
>>       another update at a higher level in order for it to pull down that
>>       directory again so you may try to delete it once more.
>
> That's expected: the 'depth' is changed to 'this item only' when you
> delete a folder.

Huh? the depth of what is changed? The folder is being deleted, it
doesn't have a depth. The parent depth shouldn't change just because
you decide to delete one of its child items.

> To get such a folder back, you have to use the "update to revision"
> dialog and specify "fully recursive".

Simon

--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net

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

[Robert Dailey]

On Mon, Jun 29, 2009 at 8:38 AM, Simon Large <simon.to...@googlemail.com> wrote:

Huh? the depth of what is changed? The folder is being deleted, it
doesn't have a depth. The parent depth shouldn't change just because
you decide to delete one of its child items.

I'm thinking this too. This never used to be an issue until tree conflicts were implemented I believe. But I can't be sure. I would expect an update to not break anything or cause any conflicts, especially if no one has done anything to the directory that I deleted...

But this might be an issue to bring up on the Subversion list, it just depends on where the issue actually lies. This sounds like an issue with Subversion, but I would like some confirmation from Stefan.

[Stefan Küng]

Robert Dailey wrote:
> On Mon, Jun 29, 2009 at 8:38 AM, Simon Large
> <simon.to...@googlemail.com

The strange thing is that you got a tree conflict in the first place.
From your description, that shouldn't have happened unless there was
something else happening that you forgot to mention.

Anyway: TSVN doesn't change the depth itself when deleting (the
svn_client_delete3() API doesn't even have a depth param).
So it really has to be an svn issue - problem is that without an exact
recipe on how to reproduce, the issue won't get fixed.

Stefan

--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net

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