<dir>/foo,v and <dir>/Attic/foo,v

[William Rassieur]

Hi,

I'm actually using cvs2p4 and not cvs2svn, but if my apostasy doesn't preclude submitting a question here, I think my question is in fact relevant.

Does anybody know what CVS does when it is going to operate (update, commit, label, etc.) a file ...<dir>/foo   and the backend contains ...<dir>/foo,v as well as ...<dir>/Attic/foo,v??

Not having done "use the Source, Luke", it seems to me that CVS  would ONLY go to Attic for foo,v if foo,v were not in Attic/..

I've seen other posts to this forum that talk about how something Bad(TM) has happened to the repository when you get doppelgangers like this. But, I'm a pragmatic guy: if people come to me and say my conversion is bad, the gold standard is to test against what they get out of CVS  TODAY... (it's one point of view; I like it).

Thanks,

Bill

[mhagger]

William Rassieur wrote:

> Hi,
>
> I'm actually using cvs2p4 and not cvs2svn, but if my apostasy doesn't
> preclude submitting a question here, I think my question is in fact
> relevant.
>
> Does anybody know what CVS does when it is going to operate (update,
> commit, label, etc.) a file ...<dir>/foo   and the backend contains
> ...<dir>/foo,v as well as ...<dir>/Attic/foo,v??
>
> Not having done "use the Source, Luke", it seems to me that CVS  would
> ONLY go to Attic for foo,v if foo,v were not in Attic/..
>
> I've seen other posts to this forum that talk about how something
> Bad(TM) has happened to the repository when you get doppelgangers like
> this. But, I'm a pragmatic guy: if people come to me and say my
> conversion is bad, the gold standard is to test against what they get
> out of CVS  TODAY... (it's one point of view; I like it).

This situation cannot be created using the CVS client alone, but it is
not hard to create with a little bit of repository manipulation:

1. Create file.txt in CVS.
2. Make a backup copy of file.txt,v from the CVS repo.
3. Delete file.txt from CVS.
4. Restore your copy of file1.txt,v to the non-Attic directory.
5. Check out freshly from CVS again and see what appears.
6. Report your results to the mailing list so that we can all benefit
from your work :-)

For completeness I suppose one could also test the reversed scenario,
where the file was deleted from CVS, then the Attic file moved aside,
then the file recreated, then the Attic file restored.

Michael

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=2402824

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[William Rassieur]

Michael, thanks for your response. I have chosen to put my efforts in to using the Source.

In rev 11.21 (the one I'm concerned with presently) of the CVS source, the routine  below clearly checks <dir> prior to checking <dir>/Attic.

At this point, I'm not asserting that I have proven that this routine is the ONLY place in the CVS source where the knowledge of how to find a comma vee file is represented. However, I have poked around a bit in the source, and I will say I'm reasonably confident such is the case (and I'd like to believe it, too!)

Anyone want to dispute my theory? Please do...


/*
 * char *
 * locate_rcs ( const char* file, const char *repository , int *inattic )
 *
 * Find an RCS file in the repository, case insensitively when the cased name
 * doesn't exist, we are running as the server, and a client has asked us to
 * ignore case.
 *
 * Most parts of CVS will want to rely instead on RCS_parse which calls this
 * function and is called by recurse.c which then puts the result in useful
 * places like the rcs field of struct file_info.
 *
 * INPUTS
 *
 *  repository        the repository (including the directory)
 *  file        the filename within that directory (without RCSEXT).
 *  inattic        NULL or a pointer to the output boolean
 *
 * OUTPUTS
 *
 *  inattic        If this input was non-null, the destination will be
 *              set to true if the file was found in the attic or
 *              false if not.  If no RCS file is found, this value
 *              is undefined.
 *
 * RETURNS
 *
 *  a newly-malloc'd array containing the absolute pathname of the RCS
 *  file that was found or NULL when none was found.
 *
 * ERRORS
 *
 *  errno can be set by the return value of the final call to
 *  locate_file_in_dir().  This should resolve to the system's existence error
 *  value (sometime ENOENT) if the Attic directory did not exist and ENOENT if
 *  the Attic was found but no matching files were found in the Attic or its
 *  parent.
 */
static char *
locate_rcs (repository, file, inattic)
    const char *repository;
    const char *file;
    int *inattic;
{
    char *retval;

    /* First, try to find the file as cased. */
    retval = xmalloc (strlen (repository)
                      + sizeof (CVSATTIC)
                      + strlen (file)
                      + sizeof (RCSEXT)
                      + 3);
    sprintf (retval, "%s/%s%s", repository, file, RCSEXT);
    if (isreadable (retval))
    {
    if (inattic)
        *inattic = 0;
    return retval;
    }
    sprintf (retval, "%s/%s/%s%s", repository, CVSATTIC, file, RCSEXT);
    if (isreadable (retval))
    {
    if (inattic)
        *inattic = 1;
    return retval;
    }
    free (retval);

    return NULL;
}

On Fri, Oct 2, 2009 at 2:46 AM, Michael Haggerty <mhagger@...> wrote:

William Rassieur wrote:
> Hi,
>
> I'm actually using cvs2p4 and not cvs2svn, but if my apostasy doesn't
> preclude submitting a question here, I think my question is in fact
> relevant.
>
> Does anybody know what CVS does when it is going to operate (update,
> commit, label, etc.) a file ...<dir>/foo   and the backend contains
> ...<dir>/foo,v as well as ...<dir>/Attic/foo,v??
>
> Not having done "use the Source, Luke", it seems to me that CVS  would
> ONLY go to Attic for foo,v if foo,v were not in Attic/..
>
> I've seen other posts to this forum that talk about how something
> Bad(TM) has happened to the repository when you get doppelgangers like
> this. But, I'm a pragmatic guy: if people come to me and say my
> conversion is bad, the gold standard is to test against what they get
> out of CVS  TODAY... (it's one point of view; I like it).

This situation cannot be created using the CVS client alone, but it is
not hard to create with a little bit of repository manipulation:

1. Create file.txt in CVS.
2. Make a backup copy of file.txt,v from the CVS repo.
3. Delete file.txt from CVS.
4. Restore your copy of file1.txt,v to the non-Attic directory.
5. Check out freshly from CVS again and see what appears.
6. Report your results to the mailing list so that we can all benefit
from your work :-)

For completeness I suppose one could also test the reversed scenario,
where the file was deleted from CVS, then the Attic file moved aside,
then the file recreated, then the Attic file restored.

Michael

[Bernhard Merkle]

Hi, I think CVSNT was the first to put all removed/delete file NOT under Attic.
So maybe this is a compatibility wrapper to handle also this situation.

anyway I had the same problem and just removed the doubled entires first.

Berni.

On Fri, Oct 2, 2009 at 7:03 PM, William Rassieur <william.rassieur@...> wrote:

Michael, thanks for your response. I have chosen to put my efforts in to using the Source.

In rev 11.21 (the one I'm concerned with presently) of the CVS source, the routine  below clearly checks <dir> prior to checking <dir>/Attic.

At this point, I'm not asserting that I have proven that this routine is the ONLY place in the CVS source where the knowledge of how to find a comma vee file is represented. However, I have poked around a bit in the source, and I will say I'm reasonably confident such is the case (and I'd like to believe it, too!)

Anyone want to dispute my theory? Please do...


/*
 * char *
 * locate_rcs ( const char* file, const char *repository , int *inattic )
 *
 * Find an RCS file in the repository, case insensitively when the cased name
 * doesn't exist, we are running as the server, and a client has asked us to
 * ignore case.
 *
 * Most parts of CVS will want to rely instead on RCS_parse which calls this
 * function and is called by recurse.c which then puts the result in useful
 * places like the rcs field of struct file_info.
 *
 * INPUTS
 *
 *  repository        the repository (including the directory)
 *  file        the filename within that directory (without RCSEXT).
 *  inattic        NULL or a pointer to the output boolean
 *
 * OUTPUTS
 *
 *  inattic        If this input was non-null, the destination will be
 *              set to true if the file was found in the attic or
 *              false if not.  If no RCS file is found, this value
 *              is undefined.
 *
 * RETURNS
 *
 *  a newly-malloc'd array containing the absolute pathname of the RCS
 *  file that was found or NULL when none was found.
 *
 * ERRORS
 *
 *  errno can be set by the return value of the final call to
 *  locate_file_in_dir().  This should resolve to the system's existence error
 *  value (sometime ENOENT) if the Attic directory did not exist and ENOENT if
 *  the Attic was found but no matching files were found in the Attic or its
 *  parent.
 */
static char *
locate_rcs (repository, file, inattic)
    const char *repository;
    const char *file;
    int *inattic;
{
    char *retval;

    /* First, try to find the file as cased. */
    retval = xmalloc (strlen (repository)
                      + sizeof (CVSATTIC)
                      + strlen (file)
                      + sizeof (RCSEXT)
                      + 3);
    sprintf (retval, "%s/%s%s", repository, file, RCSEXT);
    if (isreadable (retval))
    {
    if (inattic)
        *inattic = 0;
    return retval;
    }
    sprintf (retval, "%s/%s/%s%s", repository, CVSATTIC, file, RCSEXT);
    if (isreadable (retval))
    {
    if (inattic)
        *inattic = 1;
    return retval;
    }
    free (retval);

    return NULL;

}

On Fri, Oct 2, 2009 at 2:46 AM, Michael Haggerty <mhagger@...> wrote:

William Rassieur wrote:
> Hi,
>
> I'm actually using cvs2p4 and not cvs2svn, but if my apostasy doesn't
> preclude submitting a question here, I think my question is in fact
> relevant.
>
> Does anybody know what CVS does when it is going to operate (update,
> commit, label, etc.) a file ...<dir>/foo   and the backend contains
> ...<dir>/foo,v as well as ...<dir>/Attic/foo,v??
>
> Not having done "use the Source, Luke", it seems to me that CVS  would
> ONLY go to Attic for foo,v if foo,v were not in Attic/..
>
> I've seen other posts to this forum that talk about how something
> Bad(TM) has happened to the repository when you get doppelgangers like
> this. But, I'm a pragmatic guy: if people come to me and say my
> conversion is bad, the gold standard is to test against what they get
> out of CVS  TODAY... (it's one point of view; I like it).

This situation cannot be created using the CVS client alone, but it is
not hard to create with a little bit of repository manipulation:

1. Create file.txt in CVS.
2. Make a backup copy of file.txt,v from the CVS repo.
3. Delete file.txt from CVS.
4. Restore your copy of file1.txt,v to the non-Attic directory.
5. Check out freshly from CVS again and see what appears.
6. Report your results to the mailing list so that we can all benefit
from your work :-)

For completeness I suppose one could also test the reversed scenario,
where the file was deleted from CVS, then the Attic file moved aside,
then the file recreated, then the Attic file restored.

Michael