On Sat, Jan 20, 2018 at 11:25 AM, Bo Berglund <bo.berglund_at_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.
Received on 2018-01-20 19:19:33 CET