On Mon, Dec 25, 2017 at 9:41 AM, Bo Berglund <bo.bergl...@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 >
