On Wed, Jul 30, 2008 at 1:11 PM, steveking <steveking_at_gmx.ch> wrote:
> Mark Phippard wrote:
>>
>> On Tue, Jul 29, 2008 at 1:49 PM, Hasan Ceylan <hceylan_at_batoo.org> wrote:
>>>
>>> I have noticed the following behaviour and wanted to make sure this is
>>> intended.
>>>
>>> 1. Delete a vesioned file
>>> 2. Recreate the file
>>>
>>> When you commit the file, first commit is deletion, then file becomes
>>> changed. Then a second commit will commit the file for good.
>>>
>>> IMHO, this two steps need to be combined and the commit should be a
>>> change
>>> rather then delete + commit
>>>
>>> Can someone check this this out. If I am correct, then I will create a
>>> bugzilla for the issue...
>>
>> We actually just committed a fix for next release (1.4.3). It detects
>> this situations and reverts the delete so that it just looks like a
>> file modification.
>
> If I may add a comment here:
>
> there's one step missing:
> 3. Add the recreated file to version control
>
> this will result in a 'replace', i.e. Subversion will mark the file as
> 'replaced' and properly show the 'R' in the log.
>
> Of course, that's only if you really wanted to replace the file and your
> deletion of the file was not a mistake.
In our case we have decided to revert the delete, and preserve the new
file so that it appears as a modification. We do this because in
Eclipse it is a lot easier to have svn delete run on your behalf when
you maybe did not want it to. In Tortoise it is such an explicit step
I probably would not consider similar behavior, but that is why we did
it this way.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org
Received on 2008-07-30 21:08:14 CEST