On Wed, 2004-02-18 at 21:03, Jack Repenning wrote:
> If things are like that, then it seems clear that cvs2svn *does* have
> enough info to know whether this is a new file, or a restored old one:
> we're converting a CVS repo, which only has the behavior "restored old
> file."
It would be more accurate to say that CVS simply doesn't have the
concept of files independent of pathnames. The cvs log command tells
you about a pathname; the svn log command tells you about a file.
> From the user perspective, this is what their old VC system was
> doing, this is the nature of the file as they've become familiar with
> it. Yesterday (before they ran cvs2svn), the history was joined and
> the log output was long; tomorrow (when cvs2svn completes), surely
> their most natural expectation is that this will continue to be so?
The primary question is what is the best way to model the data in a CVS
repository. I don't think the answer to that question should be driven
by producing similar operational behavior to what CVS did on the data.
Put another way: if you "svn add" a file, then "svn rm" it, then "svn
add" the same filename again (committing after each step), an svn log on
the filename will only show the new incarnation. That's different
behavior from CVS. Should CVS users see one behavior on the data they
had in their CVS repositories, and another behavior on data they have
created since?
(I'm not saying it's 100% wrong to model the CVS data with copy history
for reincarnated files. I just don't believe that the operational
argument favors that interpretation.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 19 03:14:06 2004