# HG changeset patch # User Arne Babenhauserheide # Date 1242109398 -7200 # Node ID 6d5a62a9821e6bfda0cb418cd565a3dd7209f916 # Parent 2d6b15433c6078487d5d4c7419cf9d26c7aa4e8d learning in workflows: Added section on explicit file copy and move. diff -r 2d6b15433c60 -r 6d5a62a9821e hgscm/templates/workflow_guide.html --- a/hgscm/templates/workflow_guide.html Tue May 12 08:00:08 2009 +0200 +++ b/hgscm/templates/workflow_guide.html Tue May 12 08:23:18 2009 +0200 @@ -71,6 +71,23 @@ Note: You can also supply the commit message directly via hg commit -m 'MESSAGE' +
Move and copy files
+ +When you copy or move files, you should tell Mercurial to do the copy or move for you, so it can track the relationship between the files. + +Remember to commit after moving or copying. From the basic commands only commit creates a new revision. + +
$ hg cp original copy
+$ hg commit
+(enter the commit message)
+$ hg mv original target
+$ hg commit
+(enter the commit message)
+ +Now you have two files, "copy" and "target", and Mercurial knows how they are related. + +Note: Should you forget to do the explicit move, you can still tell Mercurial to detect the changes via hg addremove --similarity 100. Just use hg help addremove for details. +
Check your history
$ hg log
@@ -174,6 +191,8 @@ So now you can initialize repositories, save changes, update to previous changes and develop in a nonlinear history by committing in earlier changesets and merging the changes into the current code. +Note: If you fix a bug in an earlier revision, and some later revision copied or moved that file, the fix will be propagated to the target file(s) when you merge. This is the main reason why you should always use hg cp and hg mv. +

Seperate features

Use Case