Re: Best Practice: SVN Copy / Move

On Tue, Jul 22, 2008 at 11:45:51AM +0200, Jan Hendrik wrote:
> Hi all,
>
> likely I just have got a wrong impression from the --force switch in
> svn move and reading about copy/move in book & mails & tutorials,
> but what is the best practice?
>
> -- Most I read about svn copy was copy to a (new) branch, then
> commit the branch, to my understanding before any other work on
> the branch. Is that the correct use of svn copy?

I don't understand what you mean here.

Branches can (and should) be created by doing a repo-to-repo copy,
like so:

svn cp http://svn.example.com/repos/svn/trunk \
       http://svn.example.com/repos/svn/branches/mynewbranch

Then you just get a working copy of branches/mynewbranch and
start editing.

Or have I misunderstood your question?
 
> -- Should this go similarily for svn move? Or does the --force
> switch I have to use to move a modified file just has the purpose of
> a security layer (modifications may have been intended for the
> current, not a new place)?

The behaviour you are describing seems to be specific to 1.4.
Files carrying local modifications can be moved without --force
in 1.5.0:

$ cat a
a
$ echo aa > a
$ svn diff
Index: a
===================================================================
--- a (revision 1)
+++ a (working copy)
@@ -1 +1 @@
-a
+aa
$ svn mkdir d
A d
$ svn mv a d/
A d/a
D a
Index: a
===================================================================
--- a (revision 0)
+++ a (working copy)
@@ -1 +0,0 @@
-a
Index: d/a
===================================================================
--- d/a (revision 0)
+++ d/a (working copy)
@@ -1 +1 @@
-a
+aa

Property changes on: d/a
___________________________________________________________________
Added: svn:mergeinfo

> I can't tell much about program code, though I suppose there are
> the same issues, but with webpages
>
> -- a file copied to some other place likely has to be edited to work
> OK in the new place (e.g. w/o modifications links would go stale).
> The same goes for moved files. In either case it wouldn't make
> much sense to me to commit before those modifications have been
> done as otherwise I would end up with a revision practically
> deliberately broken.
>
> -- in most cases I know beforehand I want to move/rename some
> file. But usually I don't know what all has to go with it, e.g.
> images, duplicates in other places. So my workflow is to search
> the web project for all related dependencies and occurances (links
> and other references), make all the necessary changes in all
> places, including the file(s) to be renamed, and only then do the
> move/rename and commit. Which now requires the --force switch.
>
> Is that OK with SVN or are there implications or hidden traps with
> this workflow?

I think the workflow you describe is fine. By using "svn copy" and
"svn move" you are simply creating some meta data in addition to your
file modifications -- files "know" where they came from.

You could as well copy the file with the copy operation of your
operating system, modify it, and "svn add" it. However, Subversion
would then not be able to relate the copied file to its source,
which is likely not what you want.

You can modify files which have been "svn copied/moved" as much
as you want, the modifications will just add up to the fact that
you've copied/moved the files.

Stefan