Renaming [FreeBSD WIKI]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Description =====
A way to rename files while keeping the history is essential to any decent VCS.

===== Current Implementation =====
CVS, well, does not cope at all with renames.  We implement a crude way to deal with these by using direct repository intervention through the CVSmeisters (with all the risks that approach entail).  Renaming a file is done through a direct copy of the %%<%%file>,v files from one place to the other (note that because we may have tags and branch tags within the files, we do not use ''%%mv%%'' even though the file moves.  We use ''%%cp%%'' instead then mark the file as deleted).

===== SVN Implementation =====
SVN supports renaming/moving files via the ''%%svn move%%'' ([[http://svnbook.red-bean.com/en/1.2/svn.ref.svn.c.move.html|doc]]) command. It relies on the fact that in a given point in time (understand revision, revision numbers are per-repository) only one object can occupy a given path. To unambiguously refer to a file one can further specify at which point in time (revision) did the file occupy the specified path. To implement this SVN introduces [[http://svnbook.red-bean.com/en/1.2/svn.advanced.pegrevs.html|Peg revisions]].

===== Hg Implementation =====
''%%hg mv%%'' is the way to rename files while retaining the history.  Soon there will be merge-following-renames feature in Hg, sponsored by Sun.  It means that if file "A" from repository "R" is renamed as "B" but "R" was cloned into "S" before "A" is renamed, then modifications to "A" in "S", the modifications will show up in file "B" in "R" when merging (XXX is that clear?).

==== Update - 2006-10-13 ====
The merge-following-renames code has been written and is available starting at revision 8c36b33a27c7 in the current Hg repository.

===== Git Implementation =====
Git is a content-addressable rather then filename-addressable system. In short that means that the problem with "merge-following-renames" that was described in the Mercurial section simply doesn't exist with git since files are tracked by their content instead of their name so it's clear when merging that content has been changed. The concept of content addressability is described in further detail in this post to the git mailing list: http://article.gmane.org/gmane.comp.version-control.git/46348

===== Monotone Implementation =====
**Supported**
(also see [[http://venge.net/monotone/wiki/FeatureRename|monotone:FeatureRename]])

The ''%%rename%%'' command (also aliased as ''%%mv%%'') will allow files and directories to be renamed without breaking forwards or backwards history.  These changes can be committed along with content changes as a single revision. Commands that use the history, including ''%%log%%'' and ''%%merge%%'' and ''%%annotate%%'', will follow files through arbitrary renames.  Two revisions that rename the same original file to different names, or that rename two different files to the same new name, will (correctly) cause a conflict will need to be resolved before they can be merged.