[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: cvs2svn: log conversion

From: <kfogel_at_collab.net>
Date: 2004-02-13 14:59:35 CET

Dmitry Mikhin <dmitrym@acres.com.au> writes:
> 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

SVN's behavior is correct for SVN. If you wanted to preserve the
file's lineage, you would 'svn cp' it from back in history, instead of
doing 'svn add' on a new file.

(This is unrelated to the question of cvs2svn.py's behavior, of course.)

> 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.

Okay. Could you please file a cvs2svn-opt issue regarding this? I
don't know if we will get it done for cvs2svn-1.0, but we at least
need to not forget about it.

> > 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.

It's the dead state, yes.

In general, cvs2svn has a problem with dead-state revisions whose
content appears nowhere else in the repository. SVN has no way to
preserve the information, because 'dead' is CVS's way of saying the
file was removed.

The only thing I can think of is to create a /dead/ directory in the
repository for such files. Yeccch.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 13 16:01:23 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.