On Wed, Jun 22, 2016 at 12:44 AM, Branko Čibej <brane_at_apache.org> wrote:
> I have to say I'm mildly put off by your repeated suggestions on this
> list to throw away history to make things "easier" during migrations.
> That "compelling need for history" is very likely to be one of the
> reasons for using a version control system in the first place.
Please excuse the late reply: I've been busy.
Doing a flat export/import is not always considered by an engineer
asked to do a migration. It's why I mention it. *If* you need it,
fine. But complete history preservation can turn a 2 hour project of
locking the old repo, setting up a Subversion server, and doing a flat
export/import with with svn:ignore, svn:eol, and svn:keywords settings
set consistently into a 2 month process of repairing broken old
histories, ensuring identical logs, training users on the
inconsistencies between their old and new checkouts of the same old
and obsolete branches, and in general burning cycles better spent on
necessary tasks like user training and robust backup.
The task of history migraiton is also compounded in complexity if the
old software repository didn't follow Subversion layout of
trunk/branches/tags. Been there, done that, with multiple locally
designed source control systems, with RCS, CVS, git, and once even
Perforce.
I've in fact done both: one dump/load repo with history, locked down
so that clients have access to the old history with Subversion
clients, and a file dropped at the top of it with a README.txt saying
"go use the new repo at this other URL". And the new repo is a flat
export/import of the finaly release of the software, precisely so it's
much smaller, much easier to deal with, and it has a README.txt saying
that the old history and software is available at the other URL.
But there are quite a few procedural and support reasons to make a
clean break when doing a migration. Migrations, with changes to a new
upstream repository URL and clients expected to switch to new
repositories, are just about the only safe time you can clear
accumulated debris in Subversion repositories. This is due to a number
of procedural practices, namely the long-standing implicit policy that
history is immutable. This is borne out by the software difficulty,
and apparent nwillingness by developers to pursue or support the
long-requested "obliterate" feature. Despite it being one of the most
requested feature changes, it's never worked, nor do the updated
versions of Subversion seem to even support leaving room to implement
it.
There are several consequences which I've mentioned before. One is
that bulky, accidental commits are permanently stored in the
Subversion repository and cannot be gracefully cleared from history or
from backups. It's especially a problem for bulky binaries, which can
easily increase the size of a small source code repository by a factor
of 1000 if a single CD image is accidentally committed. Been there,
done that, had to clean up the mess.
Another reason to consider a clean, export/import migration is to
declare a clean separation between the old, canonical code still
accessible with the old software clients, and the new repository with
new default categories of svn:ignore, svn:keywords, svn:eol, and other
potentially repository wide policies to enforce code consistency.
Those settings are impossible to backport into the history of a
repository. New branches generated from old revisions before these
properties were set will retain the *old* property settings, which may
be in conflict with newer policy. The results of that, especially of
failing to use current "svn:ignore" settings, can be the inclusion
once again of bulky binary files. And the result of mismatched
"svn:keywords" or "svn:eol" can be surprisingly devastating to
critical software.
Last: one of the most pernicious sources of bugs in Subversion's
history, one that I've encountered personally, has been the upgrade
process between releases of Subversion for the repository itself If
you don't need to have the dataqbase and fileysstem baggage of a full
history, then the bugs of upgrading become much more avoidable.
Received on 2016-06-25 19:20:29 CEST