Brian Behlendorf wrote:
> I haven't seen this brought up yet: what about repositories where people
> performed a "rename" by mv'ing the ,v files in the repos instead of cvs
> add/delete?
You won't have any way to detect that the RCS file was renamed like
this, so if foo.h is moved to bar.h, cvs2svn can't know that foo.h
ever existed.
Files are more commonly renamed in cvs by (a) copying the RCS file,
(b) cvs rm'ing the old file, (c) cvs tag -d'ing all of the tags in
the new file. It'd be freaky cool if cvs2svn could detect this
rename by noticing that the history on files foo.h and bar.h are
identical up until 1.93, when foo.h was cvs removed and bar.h
continued getting revised.
A third method for renaming files in cvs is to cvs remove; cvs add
the file. There's no way to detect that, short of having cvs2svn
notice that the contents of foo.h are the same as bar.h, and that
foo.h was removed at nearly the same time that bar.h was added.
> Is it safe to assume that it won't corrupt the cvs2svn
> process, but does mean (as expected) that checkouts before that corruption
> date will be inconsistant in the same way they would have been under CVS?
> Or are we talking about broken histories that make creating an SVN tree
> impossible?
Why would someone mv'ing an RCS file in their CVS repository be
categorized as corruption? If a C file expects to see foo.h, you
move it to bar.h and updated the C file, you'll be fine unless
someone checks out an old branch or tag and the C file cannot find
foo.h any longer. This problem is inherent in the way that they
"moved" the file in CVS, and it'll be replicated in a cvs2svn'ed
subversion repository.
Jason
Received on Sat Oct 21 14:36:28 2006