On Mon, Dec 25, 2017 at 9:41 AM, Bo Berglund <bo.berglund_at_gmail.com> wrote:
> I am working on converting eight CVS repositories to Subversion.
> The CVS repositories are managed by CVS(nt) on Windows Server 2016,
> migrated there 2 months ago from a Windows Server 2003.
>
> The new version control server is also running VisualSVN with
> Subversion 1.9.7.
>
> To do the conversion I am using cvs2svn version 2.5.0 on an Ubuntu
> 16.04.3 LTS Server. Python on the Ubuntu machine is the 2.7.12
> version.
>
> Prior to conversion I have committed all of the uncommitted changes I
> have done myself and I have requested the developers to also commit
> all of their changes.
>
> The procedure I used to convert each repository is this:
> - Copy the repository files to a migration folder
> - Remove projects not needed in the conversion
> - Remove all CVS subdirectories in the repository (otherwise errors)
> - Remove all top level files so only subdirectories remain
> - Create a zipfile for the repository folder using 7zip
> - Copy the repository zipfiile to the Ubuntu 16 server
> - Expand the zip on Ubuntu into a migration folder
> - Run cvs2svn using an options file to create all projects as
> subrepositories in the main target repository
> - gzip the resulting dump file
> - Copy the dump file back to the Windows 2016 server
> - Use the VisualSVN management console to import the dump file to a
> new repository
>
> All of this worked without any visible problems. But it took quite
> some time to do...
>
> Now I wonder what will happen if some developer commits changes to the
> old CVS server....
This is a basic "split brain" database problem, and direct violation
of how CVS and svn are designed to work.
> Is it possible to update a Subversion repository with the new data
> somehow? (Except by manually copying the files to a svn working copy
> and committing from that). I would like to do this server side.
It doesn't have to be completely manual. It can be automatically
deposited in a daily branch and merges done after review on the new
svn repository. I've done precisely this for importing upstream
software from a third party, who published their software as tarballs,
into a Subversion repository.
In theory, you could do fresh cvs2svn runs and maintain a list of what
the last accepted revision was, and import the cvs2svn generated
svndump content *after* that marked revision, then update that marker.
This can get really burdensome.
What you might also be able to do, and will get you more dynamic
control of the resulting process, is use cvs2svn, then svn2git to
import that into a git repo. Do updates and merges there as needed,
publish from *that* into the upstream subversion reposory. This is a
case where the distributed workflow of git could be helpful to do the
merges outside of the active Subversion repository, before
publication. I'd especially want flexibility here because the changes
done by the CVS using developers become more and more likely to
require manual merging the longer the use of the svn server continues.
> I could use robocopy on the CVS repository to extract files that have
> changed after I made the migration into a folder structure that
> exactly mirrors the repo structure.
> If I use cvs2svn on these changed files (probably a small number of
> files) can then the resulting dump file be used to "mirror" the new
> commits in CVS to the Subversion version?
In my opinion, *no*. This is begging for pain because of malformed
merges. A series of commits done on one CVS server which overlaps code
committed on the Subversion server, with no opportunity to review the
code, will have unpredictable and even dangerous results.
> Or is there some other way?
The "can I merge cvs and svn commits vrom live servers" is treating
them each as parts of a distributed source control system. I think you
need some way to get it into a distributed source control system
precisely to manage the merges resulting merges. It can work to do it
as a one-off, especially if you're just bringing over a reference copy
from the CVS server and not actually do merges on top of the code.
> --
> Bo Berglund
> Developer in Sweden
>
Received on 2017-12-25 16:32:50 CET