monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: cvs_import failure


From: Michael Haggerty
Subject: Re: [Monotone-devel] Re: cvs_import failure
Date: Sun, 03 Jan 2010 07:08:20 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

Markus Wanner wrote:
> Hendrik Boom wrote:
>> Well, it's possible the topological analysis of the CVS repository could 
>> generate a different graph if a few entries have been added.
> 
> With just using cvs commit to write to the cvs repository, that should
> not be possible, no matter how silly your clock skews.

Unfortunately, there are cases when adding simple revisions to a CVS
repository can change how cvs2svn groups older revisions into
changesets.  This can happen even if the new revisions are not within
the time threshold (by default, 5 minutes) that allows them to be
considered part of an old changeset.  There are lots of ways that this
can happen; I will describe one example.

Consider the following CVS history:

fileA    1.1
            \
             1.1.2.1  BRANCH1
                    \
                      BRANCH2

fileB    1.1
            \
             1.1.2.1  BRANCH2

fileC    1.1
            \
             1.1.2.1  BRANCH2

In this case cvs2svn will generate BRANCH1 and then BRANCH2, because of
the dependency introduced by the history of fileA.

But now suppose that fileB and fileC are later added to BRANCH1, but
that in these files BRANCH1 sprouts off of BRANCH2.  (Yes, DVCS fans,
this is allowed by CVS.)  Also remember that CVS does not record the
time that a branch is created.  Now the history looks like this:

fileA    1.1
            \
             1.1.2.1  BRANCH1
                    \
                      BRANCH2

fileB    1.1
            \
             1.1.2.1  BRANCH2
                    \
                      BRANCH1

fileC    1.1
            \
             1.1.2.1  BRANCH2
                    \
                      BRANCH1

In this case, cvs2svn will create BRANCH2 before BRANCH1, because that
is the preferred order for two files (fileB and fileC) requiring only
one file (fileA) to be added retroactively to a branch.

Of course CVS also allows the history to be changed retroactively; for
example, a file can be added to a tag or branch retroactively; the
revision of a file that is added to a tag or branch (essentially, the
branch point) can be changed retroactively; revisions can be "obsoleted"
(deleted without a trace).  And there are also standard hacks that CVS
users use (e.g., to rename files) which involve renaming *,v files
within the repository.

So there is no reason to be confident that the output of cvs2svn from
conversion N will be compatible with the output of conversion N-1.  It
might work, particularly if CVS users follow some restrictions in how
they use CVS, but it can't work in general.

Michael




reply via email to

[Prev in Thread] Current Thread [Next in Thread]