On Sat, Jan 20, 2018 at 11:25 AM, Bo Berglund <bo.bergl...@gmail.com> wrote:
> Maybe the cvs2svn script choked on the very big file sizes for the > problem file? Can you re-run csv2svn to build a different Subversion repo and do a comparison? And are those files that were frequently updated and may have gotten an individual update messed up? > But luckily the project it belongs to has not yet been touched by a > SVN commit so given that I can remove it completely it should be > possible to convert it once more (only this single project) and then > load it from the dump file into the repository again. Or is this not > possible? And... this is the part where you start thinking about putting individual projects in individual repos. > Is there any way to re-migrate just the affected project from the CVS > files into Svn with some improved configuration of the cvs2svn > process? Each project (top level directory in CVS) has been treated as > a separate svn project during import so the trunk, tags and branches > directories are located separately inside each such project. Part of the problem is that it's very painful, and normally considered heresy, to delete *anything* from a Subversion repository. So you're stuck with the corrupted files in the history, and as you said, they're quite large. That looks to me like time to put that project in a separate repository, and if necessary don't bother with cvs2svn. Take a working snapshot of the old CVS working copy, import that into a new project, and put a README.md in place to say "hey, history has been discarded as part of the import for this project!" > So if I re-convert only this single project I will get an SVN dump > file that only contains this and it should be possible to load it, > provided that the already loaded project by the same name can somehow > be completely removed from the SVN server. If I just delete it via svn > I guess it will still live there as older revisions and blocking a > renewed load, right? Not if the old material is still there. In theory, you could use svnadmin dump, svndumpfilter, and svnadmin load to create a *new* Subversion multi-project repository without that content, and import a new load into *that*. But if you have commits that affected multiple repositories, including this one, I think you're looking at trouble doing this. And yes, "svn delete" still leaves the old material embedded in the history. Expect adventures, and a much bulkier master repository with changes for hundreds of megabyte files, never cleared out. > Being new to Subversion I don't know where to continue my search for > how to resolve the problem. I suspect you can simplify the whole situation a great deal by moving at least this project to its own Subversion repository. You should be able to to at least test and debug ideas by doing a cvs2svn of just that project and trying out ideas. And you can import that into a local working Subversion repository, rather than touching the primary repository at all. There is also a philosophically nasty trick that I've used. Use cvs2git to get a working git repo, one you can work with locally without touching the Subversion repository. Re-arrange *that*, especially pruning content, obsolete tags and obsolete branches you don't want to import to the new repository more dynamically. This can can allow much more sophisticated pruning than "svndumpfilter". Then Apply "git gc --aggressive". And yes, this discards history, which is the primary point of svndumpfilter, but can be much more tightly tuned this way. Push that to a testable Subversion repository, with "git svn". As much as I appreciate Subversion's "one repository to rule them all" approach for a master, centralized repository, this has been my friend in transferring or re-arranging a number of Subversion repositories with awkward, bulky binaries in their history.
