[Top][All Lists]

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

CVS 1.11.6: export bug in CVS on (LI/U)nix when CVSROOT env conta ins tr

From: Lane, Roy
Subject: CVS 1.11.6: export bug in CVS on (LI/U)nix when CVSROOT env conta ins trailing slash
Date: Tue, 29 Jul 2003 09:07:38 -0700


Here's a bug I believe I've found in CVS that has been there at least since
1.11.2 and is present in the 1.11.6 release.  I think others have hit this
problem, but from my searches it's not clear that anyone has pinpointed the
problem yet.

The problem is that EXPORT does not work correctly (on UNIX/LINUX at least)
when the CVSROOT environment variable is set and the cvs root path in the
definition contains a trailing slash (/).  With CVSROOT defined this way,
export command results in the following error:

    > setenv CVSROOT /home/relane/hwlc/cvs/
    > cvs export -rHEAD hwlc
    cvs [export aborted]: cannot export into working directory

This problem ONLY occurs when CVSROOT is used to specify the repository.  If
"-d" is used on the command line, the EXPORT command works correctly with or
without the trailing slash.

With the bug, checkout_proc() is actually entered twice for the single
command.  The first time, the directory and CVS subdirectory are created,
but no
export is done.  The second time, the CVS subdirectory created by the first
is found and CVS complains because it thinks the export is being done in a
directory.  The command exits leaving only the CVS subdirectory without
any export.  Under normal circumstances, checkout_proc() is only called once
a successful export.

The code fragment below shows how the problem occurs.  The "if" block is
entered if CVSROOT is defined and no repository was specified on the command
line (via -d).  'process_this_directory' becomes "false" because the
comparison fails due to the differences in the trailing slash.  This is what
prevents the export from completing during the first call to

1 of 2)   RECURSE.C - 1.11.6, line 570 in do_recursion():

    if (
        /* If -d was specified, it should override CVS/Root.

           In the single-repository case, it is long-standing CVS behavior
           and makes sense - the user might want another access method,
           another server (which mounts the same repository), &c.

           In the multiple-repository case, -d overrides all CVS/Root
           files.  That is the only plausible generalization I can
           think of.  */
        CVSroot_cmdline == NULL

        && ! server_active
        char *this_root = Name_Root ((char *) NULL, update_dir);
        if (this_root != NULL)
            if (findnode (root_directories, this_root) == NULL)
                /* Add it to our list. */

                Node *n = getnode ();
                n->type = NT_UNKNOWN;
                n->key = xstrdup (this_root);

                if (addnode (root_directories, n))
                    error (1, 0, "cannot add new CVSROOT %s", this_root);

THE PROBLEM IS HERE (and in DUPLICATE code - see below):

        current_parsed_root->original = "/home/relane/hwlc/cvs/"
        this_root                     = "/home/relane/hwlc/cvs"
they're the same directory but don't match becaue of the trailing '/'
'process_this_directory' becomes "FALSE".

            process_this_directory =
                    (strcmp (current_parsed_root->original, this_root) ==

            free (this_root);

2 of 2)    RECURSE.C - 1.11.6, line 1037 in do_dir_proc():

SAME SEGMENT OF CODE AS DESCRIBED ABOVE, 'process_this_directory' becomes


I haven't proposed a fix for this, except that I would think that any
user-specified CVS root path should be "normalized" to remove trailing
duplicate directory separators (/) expecially if the path is to be compared
a cvs-generated directory path.

This isn't a major CVS bug, but it did cause me to spend a few hours trying
figure out why export appeared to be broken when CVS was upgraded from a
version.  From the looks of other bug reports/questions I've seen, others
have hit this also and probably spent some time investigating it.  I'm
hoping that someone will be able to get a fix in for a future release soon.


Roy Lane

reply via email to

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