i do think it is that simple in cvs. I think they dont do anything special
for the past over/overwrite file itself..
If i just look at it then they just have that broken down in 2 behaviors
(delete behavior and "new" behavior over existing deletion"
because if i do that in my own steps
Delete a file
then copy "over" it again
It does exactly the same thing
as i paste over it directly
the end result is the same.
johan
On Wed, May 7, 2008 at 3:27 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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:31:06 CEST