At Sat, 17 Jan 2015 02:48:29 +0100, "Kamil Rytarowski" <n54%gmx.com@localhost> wrote: Subject: End-user VCS thoughts > > CVS: > + best for low bandwidth or fragile connections, actions are "resumable" > + enforces CI flow (merge and commit) > + reduces messing with renaming etc (partly in pros and cons) > - no full repo & history locally > - after renaming file (delete and create in new place) no history > preserved Your last point is not true at all. No history whatsoever is lost when renaming a file in CVS by simply using "cvs rm" and "cvs add" followed by a "cvs commit", provided that the first commit message of a file under its new name actually gives the old pathname for the file (and ideally the commit should not introduce any changes in content at the same time either). Any user reading the log can trivially find and read the old history of the file. Even without the proper identification of the rename in the commit the old history remains in the repository and can be viewed by anyone who can remember (or guess) the old name of the file. Checkouts of the project for dates (or using tags) prior to the rename will of course always "resurrect" the file with the appropriate name for the time represented by the checkout, and the history of the file (up to the rename) will be fully available in such a working dir. It's just that "cvs add", when adding a renamed/moved file, doesn't have a standard way to write a standard commit message referring to the file's original name or location, and of course also the built-in "cvs log" and "cvs diff" don't parse log messages looking for a standard "renamed/moved" comments so that they can follow the history back across a rename. A very long time ago I wrote proposal for a "cvs rename" (or wrapper script) that would record sufficient meta-data in the rename commit for an enhanced "cvs log" and "cvs diff" commands (or front-end scripts) could find the old history automatically. Unfortunately I had no spare time or resources back then to implement such a feature (nor do I now), and too many people seemed afraid to use a log message to store such meta-data about the rename, despite the fact that every CVS project was and is successfully using such a technique manually anyway. I think some of those people went on to create Subversion, a cure far worse than the disease. > When renaming files in CVS, I'm for not "fixing" the back-end, but to > just delete a file and recreate in a new place, DVCS will take care of > tracking the history. Indeed. NetBSD's old practice of copying the repo file is more dangerous than simply living with the need to run multiple "cvs log" and use more complex diff commands to access older history for a renamed file. (Though for the record I am strongly in favour of moving NetBSD entirely to Git, especially if some method of adding more tags might solve the opposing views of how branches appear between Git and CVS.) -- Greg A. Woods Planix, Inc. <woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgpGt5cMo8T2S.pgp
Description: PGP signature