You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@softlanding.com> on 2006/04/17 13:09:41 UTC
Improved support for Copy/Move (was: Summer of Code)
"Ivan Zhakov" <ch...@gmail.com> wrote on 04/16/2006 03:57:49 PM:
> > 1) Improve Copy/Move support.
> >
> > This is not about "true renames" although I suspect having them could
help.
> > I come to Subversion from a Java persepective and Java programmers are
> > always interested in Subversion because it handles move/rename better
than
> > CVS. Since refactoring is such a hot topic in Java programming,
people
> > think switching to Subversion from CVS will bring them a lot of
benefits.
> > In reality, that is not always the case, because people often like to
do
> > several refactorings before doing a commit. For example, a folder
> > containing classes might be renamed, then some of the classes in that
folder
> > might also be renamed, and/or moved to other folders. I do not know
all of
> > the scenarios where Subversion has problems, but it definitely has
them.
> > This comes up a lot with Subclipse users as they get errors when we
try to
> > move something and Subversion does not let them because it has already
> > moved.
> >
> > JavaSVN has already implemented what they call a "Smart Move" feature
that
> > gets around these problems by updating the WC as necessary. Perhaps
they
> > could document how they handle various scenarios to see if the design
would
> > work for Subversion.
>
> I've already posted patch to enable moving moved files. But there was
> objections on idea itself. See discussion here:
> http://svn.haxx.se/dev/archive-2005-12/0020.shtml
Is there any chance this could get revived? It didn't seem the objections
were that strong, I thought they were seeking more work or clarification.
It would stink to discard a useful feature over theoretical disputes. One
thing that occurs to me is what if we initially limited the scope of the
patch to the move subcommand? Refactoring almost exclusively uses
move/rename and there really isn't any ambiguity that I can see to
supporting letting a file or folder be moved multiple times.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Improved support for Copy/Move (was: Summer of Code)
Posted by Mark Phippard <ma...@softlanding.com>.
"Peter N. Lundblad" <pe...@famlundblad.se> wrote on 04/17/2006 10:06:16
AM:
> Mark Phippard writes:
> > "Ivan Zhakov" <ch...@gmail.com> wrote on 04/16/2006 03:57:49 PM:
> >
> > > I've already posted patch to enable moving moved files. But there
was
> > > objections on idea itself. See discussion here:
> > > http://svn.haxx.se/dev/archive-2005-12/0020.shtml
> >
> > Is there any chance this could get revived? It didn't seem the
objections
> > were that strong, I thought they were seeking more work or
clarification.
> > It would stink to discard a useful feature over theoretical disputes.
One
> > thing that occurs to me is what if we initially limited the scope of
the
> > patch to the move subcommand? Refactoring almost exclusively uses
> > move/rename and there really isn't any ambiguity that I can see to
> > supporting letting a file or folder be moved multiple times.
> >
> I'm +1 on lifting this restriction. I don't see why not recording the
> intermediate state of the WC is a problem in this case.
>
> Say you move a line inside a file and then move it again. The commit
> will show this as a delete and an add in the final place leaving no
> trace of the intermediate state. I think we can view a copy/move of a
> file in the same way. Also, the reason we keep copyfrom information
> is to trace history. However, the intermediate path really doesn't
> have any history to trace, so to speak:-)
That all makes sense to me. All I can add is that I would really like to
see this added to Subversion. We could provide a lot better refactoring
experience in Subclipse if these limitations were removed. I also think
that a lot of new users to Subversion that come from CVS suffer a bit of a
"let-down" when they first run into this. So in my opinion, it would be
good for everyone if we could remove this limitation.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Improved support for Copy/Move (was: Summer of Code)
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
Mark Phippard writes:
> "Ivan Zhakov" <ch...@gmail.com> wrote on 04/16/2006 03:57:49 PM:
>
> > I've already posted patch to enable moving moved files. But there was
> > objections on idea itself. See discussion here:
> > http://svn.haxx.se/dev/archive-2005-12/0020.shtml
>
> Is there any chance this could get revived? It didn't seem the objections
> were that strong, I thought they were seeking more work or clarification.
> It would stink to discard a useful feature over theoretical disputes. One
> thing that occurs to me is what if we initially limited the scope of the
> patch to the move subcommand? Refactoring almost exclusively uses
> move/rename and there really isn't any ambiguity that I can see to
> supporting letting a file or folder be moved multiple times.
>
I'm +1 on lifting this restriction. I don't see why not recording the
intermediate state of the WC is a problem in this case.
Say you move a line inside a file and then move it again. The commit
will show this as a delete and an add in the final place leaving no
trace of the intermediate state. I think we can view a copy/move of a
file in the same way. Also, the reason we keep copyfrom information
is to trace history. However, the intermediate path really doesn't
have any history to trace, so to speak:-)
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org