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
I made a small (sorry! last time the sample repo was half a meg, I did not
check. This one is 9k.) repo as an illustration (attached).
Both files in src/util were removed at some point (Makefile.am in rev. 1.2,
cpl2grd.F in 1.3), then restored (they were the same files). CVS shows
continuous log. Then Makefile.am was completely removed for test (rev. 1.6), and
a new file with the same name added (1.7). CVS again considers all versions as
incarnations of the same file and continues the log.
On the opposite, SVN shows only the history after the last resurrection / addition.
So, the behavior is inconsistent (although it does not make a bug per se). For
me the CVS style looks more natural, because if I saw some file name in, say,
revision 10 (using svn notation), then did 'svn up' and got revision 20, and
again see the same file name, I'd inherently assume that those two files are
versions of the same. I just tried to imagine the opposite: I updated, should I
suspect every file that it is not the file I'm familiar with and check whether
it was replaced? No, it does not sound right, the thought just does not cross my
mind when running '[cvs,svn] up'.
But if someone feels differently, he may choose not to keep the long history in
the logs. So, making this decision an cvs2svn option makes sense, although the
CVS behavior would make a good default for me.
> Doesn't the file appear in an SVN revision, which has a log message?
> I'm not sure I understand the problem... Er, could you come up with a
> very small example repository, containing just the minimal amount of
> data needed to describe this problem? That would make it much easier
> to understand, thanks.
Well, as I wrote in the first email, my test just compared logs line-by-line,
and if different indicated an error. File 'docs/Makefile.am' has the following
feature:
CVS log starts (in time) as:
----------------------------
revision 1.2
date: 2003/01/17 04:50:10; author: dmitrym; state: Exp; lines: +17 -0
Install docs.
----------------------------
revision 1.1
date: 2003/01/16 00:22:46; author: dmitrym; state: dead;
branches: 1.1.2; 1.1.4;
file Makefile.am was initially added on branch owwe3.
=============================================================================
SVN log:
------------------------------------------------------------------------
r7 | dmitrym | 2003-01-17 15:20:10 +1030 (Fri, 17 Jan 2003) | 2 lines
Install docs.
------------------------------------------------------------------------
So, the message about adding the file on the branch (cvs 1.1) did not make it to
svn. Obviously, the issue is minor (am I just a paranoid neatnik?). I just noted
that the file was technically 'dead' in 1.1, so it could be another example of
the issue discussed above.
Cheers,
Dmitry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 15 00:32:50 2004