Re: CVS to SVN branch migration issue

On 03/15/2012 03:19 PM, Fisher, Randall wrote:
> We have a CVS repository with separate folders that contain PL/SQL
> (Oracle) code, DDL scripts, DML scripts, views, and triggers.
> 
> These artifact sets differ from a Java or C project.  This is a series
> of flat floders with all the artifacts in it and not an entire folder
> structure with a set of artifacts needed for building a project.
> 
> For any given change request or development effort, we currently create
> a branch, in CVS, where we alter the artifacts as needed.  Those
> artifacts that change, and only those that change, get commited to that
> branch.  At some point these are merged down to the trunk, but that goes
> without saying.

This this always happen one folder at a time (e.g., are all files in one
folder branched) or does it happen on a file-by-file basis?

> So now when I use cvs2svn, it keeps track of all the artifacts that
> reside on the trunk and it keeps track of the smaller set of artifacts
> that changed and reside on the branches.

Yes.

> Now here is the problem.  It also is recording a delete (Node-action:
> delete) for the artifacts that reside on the trunk and not on the
> branch.  (ie. not altered and never commited on the branch)

This is because only the branched files exist on the branch.  If you
would check that branch out of CVS, you would only get the branched
files.  So cvs2svn arranges your SVN repository to have the same behavior.

> This becomes a problem when we try merge a branch into the trunk in SVN,
> as it is also pulling in all the deletes with it.

Presumably this is only a problem for branches that were still unmerged
at the time of the cvs2svn conversion, right?  Because if you are just
trying to add SVN merge metadata to merges that have already been done
in CVS, all you have to do is "svn merge --record-only ..." and
Subversion won't change anything on trunk.

So yes, if you have unmerged branches at the time of the conversion,
then you will have a problem.  You could solve it either by:

1. merging only the modified files back to trunk.  In this case you will
probably be producing a lot of subtree svn:mergeinfo that you will have
to schlepp with you throughout eternity.

2. copy the files that were originally unbranched onto the branch before
the merge.  This would effectively undo the delete.  I'm not exactly
sure what effect this would have on your svn:mergeinfo; the result might
or might not be cleaner than when using the other approach.

> Is there anyway to head off this issue by getting cvs2svn to not exhibit
> this behavior during the dump?

I think it would require some significant programming.

> (Is this part of the CVS to SVN paradigm shift I have not grasped yet?)

I think the moral of the story is that partial-tree branching and
tagging are evil, even though CVS and Subversion nominally support them.
 The impedance mismatch is even worse between CVS/Subversion and the
DVCSs like git and Mercurial, which do not even allow partial-tree
branches and tags.

Michael

-- 
Michael Haggerty
[email protected]
http://softwareswirl.blogspot.com/

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=2936200

To unsubscribe from this discussion, e-mail: [[email protected]].