| it's too easy to lose history!!! [message #21492] |
Thu, 19 June 2008 10:57  |
Eclipse User |
|
|
|
Deleting a file and adding it back will create a new file - with a
fresh history, example:
in eclipse, take any file (whose history you do not care about) under svn;
using the navigator/project explorer
right click copy and paste (so you have another copy of it)
delete the original
rename the copy as the original
checkin
history is gone
----
I do not know if this is an SVN client bug or an as-designed feature,
however it is very easy to lose the history of a file.
is there a way to restore it ?
or a setting to checkin a file that underwent such lifecycle not as new
but as a new version ?
Edoardo
|
|
|
|
| Re: it's too easy to lose history!!! [message #21529 is a reply to message #21507] |
Fri, 20 June 2008 00:04  |
| Eclipse User |
|
|
|
Hi both,
maybe this is related to my thread "Copy/Past should have svn copy functionality" above.
Cheers, Jörg
On 06/20/08 05:58, Francois Cottet wrote:
> Hi Edoardo,
>
> Yes this behavior is very painful.
> I had the same remarks few days ago and it seems to be well-known from
> the development team.
>
> One way to avoid this is to do the copy/paste directly in Windows
> Explorer or MacOS Finder. If you modify the files and then refresh your
> Eclipse view, Subversive will consider the file as 'modified' and not
> 'replaced'.
>
> Regards,
> Francois
>
>
> Edoardo Comar wrote:
>> Deleting a file and adding it back will create a new file - with a
>> fresh history, example:
>>
>> in eclipse, take any file (whose history you do not care about) under
>> svn;
>> using the navigator/project explorer
>> right click copy and paste (so you have another copy of it)
>> delete the original
>> rename the copy as the original
>> checkin
>> history is gone
>>
>> ----
>> I do not know if this is an SVN client bug or an as-designed feature,
>> however it is very easy to lose the history of a file.
>>
>>
>> is there a way to restore it ?
>> or a setting to checkin a file that underwent such lifecycle not as
>> new but as a new version ?
>>
>> Edoardo
|
|
|
| Re: it's too easy to lose history!!! [message #21755 is a reply to message #21529] |
Fri, 20 June 2008 05:55 |
| Eclipse User |
|
|
|
I entered
https://bugs.eclipse.org/bugs/show_bug.cgi?id=237899
Jörg Thönnes wrote:
> Hi both,
>
> maybe this is related to my thread "Copy/Past should have svn copy functionality" above.
>
> Cheers, Jörg
>
> On 06/20/08 05:58, Francois Cottet wrote:
>> Hi Edoardo,
>>
>> Yes this behavior is very painful.
>> I had the same remarks few days ago and it seems to be well-known from
>> the development team.
>>
>> One way to avoid this is to do the copy/paste directly in Windows
>> Explorer or MacOS Finder. If you modify the files and then refresh your
>> Eclipse view, Subversive will consider the file as 'modified' and not
>> 'replaced'.
>>
>> Regards,
>> Francois
>>
>>
>> Edoardo Comar wrote:
>>> Deleting a file and adding it back will create a new file - with a
>>> fresh history, example:
>>>
>>> in eclipse, take any file (whose history you do not care about) under
>>> svn;
>>> using the navigator/project explorer
>>> right click copy and paste (so you have another copy of it)
>>> delete the original
>>> rename the copy as the original
>>> checkin
>>> history is gone
>>>
>>> ----
>>> I do not know if this is an SVN client bug or an as-designed feature,
>>> however it is very easy to lose the history of a file.
>>>
>>>
>>> is there a way to restore it ?
>>> or a setting to checkin a file that underwent such lifecycle not as
>>> new but as a new version ?
>>>
>>> Edoardo
|
|
|
| Re: it's too easy to lose history!!! [message #21800 is a reply to message #21492] |
Fri, 20 June 2008 11:18 |
| Eclipse User |
|
|
|
Originally posted by: alexander.gurov.polarion.org
Hello Edoardo,
This is standard Subversion behaviour: when you manually deleted file then
added a new one Subversion performs a file replacement. Subversive shows
this situation in commit window using "Replaced" status string.
Next moment is that when you perform copy/paste inside Eclipse IDE the
file is deleted by Eclipse first and then copied. Though the Eclipse
behaviour looks strange we can do nothing.
Regarding history loosing - you simply missed one moment :) Yes, replaced
file is a new repository element from the Subversion point of view and
Subversion does not connect it with history of a previous element with the
same name. But Subversion also tracks folder changes. So, you can access
required history by performing few steps:
1) Get the parent folder history
2) Find revision before file replacement
3) Get the history of required file using Affected Paths view.
|
|
|
Powered by
FUDForum. Page generated in 0.05436 seconds
Home