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


From: Greg Irvine <greg.irvine_at_thalesatm.com>
Date: 2005-02-28 02:27:23 CET

Hi all.

Currently our company is using CVS as it's backend for source management.
As a new (Java) subproject we've had some free reign to try new tools, one
of which is Subversion.

For various reasons, before we consider a large scale transition to
Subversion, we are required to delivery to the end user
(integration/validation/customer) via CVS.

Obviously the team wants to continue to Subversion so we're trying to come
up with a simple way to allow us to do so and still manage deliveries to
CVS. A restriction we have on the delivery to CVS is that each piece of
work is identified and delivered individually against particular defined
requirement packages.

One idea we came up with was to have a working branch(es) in SVN that we
work with, and another branch (eg. called cvssync) that is merged into when
it comes time to deliver to CVS and this branch is delivered to CVS. This
branch is always in sync with what is in the CVS repository.

We can do the manual task of checking out the SVN "cvssync" branch, then
import it into a CVS clone and commit it that way. The problem with this is
CVS doesn't easily pick up refactored/moved/added/deleted files unless it's
explicitly told something is new/added/moved, etc.

So, there's already an cvs2svn script for converting from CVS to SVN, but is
there the reverse? Or does someone else have another method/suggestion on
how we can achieve the above goals?

Thanks for any help or information.



To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 28 02:29:27 2005

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.