tech-repository archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: End-user VCS thoughts



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



Home | Main Index | Thread Index | Old Index