On Wed, Jun 22, 2016 at 12:44 AM, Branko Čibej <br...@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.
