On Mon, 25 Dec 2017 10:32:39 -0500, Nico Kadel-Garcia <nka...@gmail.com> wrote:
>> 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. OK, thanks. I only wanted to know what could be done if someone discovered in January that he had not committed all changes after all... The whole migration is meant to be a one-off exercise and the CVS server should be retired. I might shut it down altogether, but until we are comfortable using svn I think I have to keep it as a reference. If some extra commits happen it can be detected using the robocopy trick with a starting time being the last commit before I migrated the data. If there appears files in the copy then something has happened and by examination of these files the guilty part would be detected. And he should then be requested to repeat his commit on the indicated files from a svn working copy. I suspected making it some kind of semi-automatic thing could be asking too much.... -- Bo Berglund Developer in Sweden
