[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: converting from SVN to CVS

From: Jim Hanley <jhanley_at_DGtlRift.com>
Date: Wed, 28 Jan 2009 08:31:57 -0700

Quoting Jason Boehle <jboehle_at_gmail.com>:

> My company has been acquired, and we previously used SVN, but the new
> company uses CVS. Is there a tool to import an SVN repository into CVS,
> preserving the history, etc.?
> Regards,
> Jason Boehle
> jboehle_at_gmail.com
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1043638
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe_at_subversion.tigris.org].

I've read through this thread, and I believe the point is truly being
missed. Jason's company has been acquired, and if I had to guess,
their engineering and IT is being consolidated.

This is total speculation but I'm sure the acquiring company wants to
minimize redundancy and two version control systems are redundant.
Why not migrate to SVN, because they don't have to and there will be
cost and politics involved - the acquiring IT department would have to
learn to administer new software they are unfamiliar with and
surrender power and knowledge to the acquired IT department, and
increase their overhead. Their may already be tools, scripts, etc
that are used by the acquiring company that analyze the CVS
repositories. Running the repositories in parallel may not be an
option for the previously mentioned. Even keeping the SVN repository
around for legacy history may not be an option again for the
previously mentioned. In the worse case scenario, you will just have
to export the tree and import it to CVS with no history and loose the
SVN repository - this may not be considered an issue by the acquiring
company depending on their business model. If the were previously a
competitor, they have no interest in continued development and support
of your software as they would want your customer base to "upgrade" to
their products. If there was previously symbiotic relationship they
may be looking to incorporate the acquired software directly into
their product base as a suite. In either case - they really don't
need the history, because they would want those customers to upgrade.
  If they are looking to just maintain one VCS system, the acquired
engineering teams cost goes up because of the lack of a familiar tool
and removed functionality - making the acquired engineers look bad on
paper, which is better then the acquiring engineering teams look bad.

Seems like your stuck with dumping SVN, given that you wanted a
conversion tool, and I'm sure no one wants to stick their neck out to
defend the features of SVN over CVS, but perhaps you could convince
others in the acquiring engineering teams that they could use your
installation of SVN as a test bed, provide a short course for how it
is better then CVS - this might make you look ambitious and
forthcoming. I'm sure if they don't live under a rock and are extra
professionally active some are probably already familiar with it - and
may already be dreading the use of CVS.

If worse came to worse, I'm sure with enough effort, your IT
department could write a one time conversion tool from SVN to CVS, but
no one on this list would see the point (technically) but I'm certain
we are just scratching at the surface of the politics involved.

Good luck.
Received on 2009-01-28 16:37:17 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.