On Wed, May 7, 2008 at 8:56 AM, Johan Compagner <jcompagner_at_gmail.com> wrote:
> hmm how does the cvs plugin then sees this? or work around this?
> if i test quickly then cvs even immediately sees that that some files are
> really not changes (content is the same)
> and the one that are are marked as out going changes..
>
> I have as a test 2 projects
> 1 is cvs and 1 is svn
>
> both have the same dir with the same file set.
> and what i do is copy between them..
> and then cvs is working fine, svn is marking everything as deleted.
>
> I think what cvs does is this
> You delete a file. CVS marks it as outgoing deletion
> then i paste/cop the file again where i just deleted.
> If that had the same contents, the deletion is gone, and i even dont see any
> outgoing changes.
> if i pasted a file that has the same name but different content then the
> delete change is changed to an outgoing change.
>
> This is how svn also should work and then copy/paste is just solved because
> a deletion is alwasy rolledback when it finds the same filename again.
I do not think it is a simple as you make it sound. I do not think
CVS does anything when it receives the initial delete. You can make
Subclipse do the same by adding a property named DeferFileDelete to a
parent folder of the deletion. We will then wait until commit time to
turn it into a delete. There are down sides to this though, such as
Subversion will just blindly restore the file if you do an update
before the commit.
Otherwise to do what you wanted, you would have to add code that
detects when a file is added (which I assume is possible) and then
check the SVN status of that file to see if it is currently deleted,
at which point you would have to run the Subversion revert command.
But first you would have to move the new file to some temp location
and then copy it over the reverted file. And you would have to at
least do the SVN status check for every file that is ever added.
The solution we have requested of Eclipse is to add some new Team API
into these functions so that we have a chance to be involved in the
process and not just hear about it after the fact when the events are
sent. Of course, just changing the Eclipse behavior to match how it
handles the exact same operation when done from the native filesystem
would have been the easier solution. I still do not understand why
they do not at least want it to behave the same way in both cases
(even if they changed it for the worst for the filesystem copy).
--
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-05-07 15:27:55 CEST