cvs2svn conversion - can later updates be done?

[Bo Berglund]

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....
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.

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?

Or is there some other way?

[Nico Kadel-Garcia]

Post by Bo Berglund
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.
- 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.

Post by Bo Berglund
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.

Post by Bo Berglund
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.

Post by Bo Berglund
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.

Post by Bo Berglund
--
Bo Berglund
Developer in Sweden

[Bo Berglund]

On Mon, 25 Dec 2017 10:32:39 -0500, Nico Kadel-Garcia

Post by Nico Kadel-Garcia

Post by Bo Berglund
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.

Post by Bo Berglund
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....

[Branko Čibej]

Post by Bo Berglund
On Mon, 25 Dec 2017 10:32:39 -0500, Nico Kadel-Garcia

Post by Nico Kadel-Garcia

Post by Bo Berglund
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.

Post by Bo Berglund
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....

For a small set of possible changes, the best way to transfer them would
be to create a patch file from CVS and apply it to a Subversion working
copy.

-- Brane

[Nico Kadel-Garcia]

Post by Branko Čibej
For a small set of possible changes, the best way to transfer them would
be to create a patch file from CVS and apply it to a Subversion working
copy.
-- Brane

This could be notably safer. It discards the original history from the
CVS server.

[Ryan Schmidt]

Post by Bo Berglund
Now I wonder what will happen if some developer commits changes to the
old CVS server....

I would expect that after the migration to SVN you would configure the CVS repository to disable write access and allow only read access from then on, so that it's not possible to encounter that problem. But I've never administered a CVS server so I don't know how to accomplish that.

[Nico Kadel-Garcia]

On Mon, Dec 25, 2017 at 9:15 PM, Ryan Schmidt

Post by Ryan Schmidt

Post by Bo Berglund
Now I wonder what will happen if some developer commits changes to the
old CVS server....

I would expect that after the migration to SVN you would configure the CVS repository to disable write access and allow only read access from then on, so that it's not possible to encounter that problem. But I've never administered a CVS server so I don't know how to accomplish that.

It's a trivial step, often done by taking away write privileges for
the designated cvs user on the cvs server.