On Feb 12, 2004, at 4:38 PM, Dmitry Mikhin wrote:
> kfogel@collab.net wrote:
>> Hmmm... This is an interesting question.
>> When cvs2svn.py restores a file, it does a plain add, not an add with
>> history (if I recall correctly, & inspection of the code seems to bear
>> this out). It behaves this way because it doesn't have any way to
>> know if the reappearance of the file is a genuine resurrection -- that
>> is, related to the prior contents -- or just an add of new material
>> that happens to be under the same name as something that was removed
>> long ago.
>> We could have an option governing which way it chooses, though.
>> Before filing a 'cvs2svn-opt' issue, I want to make sure the problem
>> I'm describing is the same as the one you're describing. Does the
>> above all make sense to you?
>
> Yes it does. I looked into it again this morning. It seems that CVS
> and SVN have different behavior wrt this issue:
>
> if a file is removed and later either restored, or a new file with the
> same name created,
>
> - CVS assumes this is the same file and maintains the history
>
> - SVN assumes this is a new file and truncates the history
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." 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?
It could be that there are CVS users yearning for the new SVN behavior
in this case, but cvs2svn's first job is correct conversion, not
cultural reform.
As a practical matter, the only cases I can recall where the question
arose, I wanted the CVS behavior, not the SVN. (I was actually using
ClearCase at the time, which does it like SVN, and that was a problem.)
These cases were (at least, from my wizardly CM God perspective) user
errors: a large tree of files with changes scattered throughout not
easy for a human to guess (test output); it just seemed easier to
remove the top-level directory (and, implicitly, all the files), and
drag in the whole new tree. But that bloated the repository
(whole-copy stored each time), and we ended up wanting to compare
history ... which we couldn't. So put another way, if this behavior is
so natural to the humans, it's maybe not so got that SVN (and
ClearCase) do it the other way. In any case, it's apparently natural
enough to strengthen the presupposition that it is, in fact, what the
human wants.
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835.8090
---------------------------------------------------------------------
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:03:23 2004