You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jan Hendrik <li...@gmail.com> on 2008/07/22 09:45:51 UTC
Best Practice: SVN Copy / Move
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?
-- 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)?
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?
TIA for any insights/suggestions.
Jan Hendrik
---------------------------------------
Freedom quote:
Der Preis der Größe heißt Verantwortung.
-- Sir Winston Churchill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best Practice: SVN Copy / Move
Posted by Jan Hendrik <li...@gmail.com>.
Concerning Re: Best Practice: SVN Copy / Move
Stefan Sperling wrote on 22 Jul 2008, 13:13, at least in part:
> On Tue, Jul 22, 2008 at 11:45:51AM +0200, Jan Hendrik wrote:
> 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?
No. Obviously I read too much about copying and almost all was
related to branches one way or the other. (I have given up on
branching long ago as switching would practically always result in
a complete checkout - *every* file would be "updated" to
branch/trunk, had something to do with the EOL property IIRC.
Instead I checkout a second working copy, only committing when
everything is done.)
> > -- 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:
Haven't updated yet, TortoiseSVN never complains either, but SVN
1.4.6 not:
svn: Use --force to override this restriction
svn: Move will not be attempted unless forced
svn: 'testwc1/newfoo.txt' has local modifications
> 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.
Thanks, Stefan. It is what I did since long and didn't experience
any issues (except for the necessity of the --force switch), but after
reading a lot from quite a number of sources (w/o copy/move
originally on my mind) I had become uncertain about it and
possible implications.
Jan Hendrik
---------------------------------------
Freedom quote:
If some among you fear taking a stand
because you are afraid of reprisals
from customers, clients, or even government,
recognize that you are just feeding the crocodile
hoping he'll eat you last.
-- Ronald Reagan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best Practice: SVN Copy / Move
Posted by Stefan Sperling <st...@elego.de>.
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