Re: Problem with importing third-party sources and adding/committing changes

[Greg A. Woods]

[ On Monday, November 15, 2004 at 14:43:06 (-0800), Mark D. Baushke wrote: ]
> Subject: Re: Problem with importing third-party sources and adding/committing 
> changes 
>
> If you wish to provide them again, such a feature
> has a high probability of being incorporated into
> the cvs sources...

They should still be somewhere in the CVS repo -- but migrating them
will be hard.

Unfortunately I can't even get anonymous access to the repo given the
ongoing complete festering brain damage at Collab.net.

> > Alternately, or additionally, my old "cvs add"
> > proposal needs to be implemented.
> 
> Could you restate it please? Is it just that you
> want a recursive 'cvs add' or is it something
> else?

Much more:

(note this is just a cut&paste from the copy I kept since it was last
posted here -- I've not reviewed it in well over a year now, though it
may have had some minor edits and corrections since last being posted)

A Proposal to Avoid Immediately Creating Directories in the Repository
======================================================================

This proposal fixes the "cvs add" function so that it no longer handles
directories in any special way and instead simply treats them as
underlying structure that holds all the files apart.  Together with
this change will be bundled the total disconnection of "cvs add" from
any repository actions (thus allowing "cvs add" to work properly on a
disconnected client machine in all circumstances).  In its entirety this
proposal brings the "cvs add" user interface (command-line interface and
resulting behaviour) into conformance with all other CVS sub-commands
that operate from within a CVS working directory.

This is proposal is based on suggestions posted by Andrew Nicholson
<address@hidden> and on further ideas by John Macdonald
<address@hidden>, Aldo Longhi <<address@hidden> and myself, Greg
A. Woods <address@hidden>.


The basic idea is that "cvs add" will no longer speak to the repository
in any way, and indeed it will never create directories in the
repository as it now does.  It will instead simply arrange the state of
the working directory such that a subsequent "cvs commit" will both
create any necessary directories in the repository as well as entering
the initial "delta" (doing the initial checkin) for each new "added"
file.

In addition a "cvs radd" command could be implemented to replace "cvs
import".  This would basically work as a combined `add' and `commit',
just as "cvs import" now does, but instead of working on a fixed magic
vendor branch it would work on any normal branch, including the trunk.



General changes to the recursion engine:
----------------------------------------

  - From a known working directory (i.e. one that has a "CVS" admin
    directory) "Walk into" each subdirectory, known or not.

  - If this sub-directory contains a "CVS" administrative sub-directory,
    process as normal.  If the repository doesn't contain a
    corresponding sub-directory then simply remember the parent and
    treat everything from here in as new -- i.e. don't even look in the
    repository any more until we re-wind back out.

      - What do we do if someone does a checkout into a newly added
        directory?  Maybe we should just prevent such a checkout from
        ever happening until the first commit has been done from within
        this new directory and thus a corresponding repository directory
        exists.

  - If there is no CVS administrative sub-directory then print '!' (to
    differentiate it from an unknown file printed as '?'), rewind to the
    parent again, and continue with the next item....

This may imply that the nonsense about 'D' CVS/Entries records can all
be garbage collected -- directories will always be treated identically
on first glance and there is no longer any reason to even optimise their
handling by mentioning previously known ones in the CVS/Entries file.  I
would even contend that such mention will only complicate things
unnecessarily.


"cvs add" details:
------------------

  - In an existing CVS working directory "cvs add newfile" will add the
    new file to the current working directory, as it does now, by simply
    creating a new record for "newfile" in the CVS/Entries file.
    Nothing else is done.

  - In a new sub-directory of a CVS working directory "cvs add newfile"
    (where "newfile" exists and is not yet ``known'' by CVS) will first
    create a new set of CVS/* administrative files, and then it will add
    the new file to the current working directory, as above.

      - The new directory will only be considered a part of an existing
        working directory if any parent directory contains a valid CVS
        administrative sub-directory.  New CVS/* administrative files
        will be first created in any intermediate parent directory that
        does not have them.

  - "cvs add path/to/newfile" will first create a new set of CVS/*
    administrative files in each sub-directory leading to "newfile", if
    necessary, and then go on to add the new file as above.

      - As above a search in parent directories will be made for a valid
        CVS administrative sub-directory.

      - The desired repository directory is taken from the last seen
        CVS/Repository file, i.e. first ./CVS is read, and if it doesn't
        exist then "../CVS" is read (and if it doesn't exist then keep
        going back to "/" and die if no valid CVS admin directory is
        found); and then if "path/CVS" exists it is read and so on until
        no "CVS" subdir is found.

  - "cvs add dirname" will recurse through the specified directory
    adding all new ``un-ignored'' files if the current directory, or one
    of the parent directories, is a valid CVS working directory (as
    above).  (including if "dirname" == "." || == "")

      - Nothing will be done if no new files are found to add.

      - "cvs add dirname" will honour the '-l', '-R', and '-I' "Common
        Options" just as every other command which operates recursively.

      - "cvs add -I ! dirname" will not ignore any files, not even those
        listed in any .cvsignore files, except of course all CVS
        administrative sub-directories and their contents.

      - If "CVS" (admin subdir's name) is specified explicitly it will be
        (silently) ignored.

      - Variations of "newfile", "path/to/newfile", and "dirname" will
        be accepted simultaneously on the command-line (just as with
        other CVS commands).

  - no explicitly named file or directory will ever be ignored, even if
    it would be ignored by the current "cvsignore" list (i.e. "-I !" is
    not necessary for explicitly specified names that would be otherwise
    ignored if they were simply implied by recursion)


"cvs commit" details:
---------------------

  - "cvs commit", upon encountering the absence of a directory in the
    repository, will recursively do the following process for each new
    directory needed to get to the point where a new file is being
    added:

    a) trigger any commitinfo hooks for the new sub-directory and then,

    b) if all commitinfo hooks succeed will create the directory, and
       then of course

    c) trigger any loginfo hooks to report the directory creation;

    before finally going on to committing the "add" of the new file that
    needed the new directory(ies).

  - Should "cvs commit" make any special mention when a file is actually
    resurrected?  (I think not, but the old "cvs add" does, so.... --GAW)

  - The current C/S protocol allows committing of an un-added file, but
    the native "cvs commit" client implementation does not.  If this is
    ever changed then "cvs commit" will have to also do all of the "cvs
    add" work too....


"cvs update" details:
---------------------

  - Should "cvs update" make any special mention when it finds that a
    new file will actually be a resurrection?  (see "cvs commit" --GAW)


Other Stuff:
------------

  - The "there is no version here; run 'cvs checkout' first" message
    needs fixing so that it doesn't suggest "checkout" as the only
    solution.  If any parent directory is a proper CVS working directory
    then it will suggest "cvs add" instead of "checkout"

  - "cvs checkout new" will be fixed so that it just creates an empty
    new working directory just as "cvs add" does instead of printing the
    error "cvs [checkout aborted]: there is no repository /cvs/new" when
    there isn't yet a corresponding directory in the repository.  The
    first commit in this new module will be what creates the repository
    directory.  A valid modules file definition will still be required
    in order to encourage the use of modules.  "cvs add new", when there
    is no parent working directory, won't work because it would have to
    contact the server to verify the module name.


"cvs edit" details:
-------------------

  * "cvs edit" is basically a dead-end and should be removed, however:

  - If "cvs edit newfile" is to continue to be allowed then some way
    must be found to store the CVS/fileattr info in the repository.

    The best idea so far is to allow the "FILENAME" field to contain a
    relative pathname and have "cvs commit" migrate such entries to the
    new sub-directories in the repository as they are created.  This no
    doubt has implications for other parts of CVS, as well as new and
    exciting ways for errors and inconsistencies to arise.


"cvs watch" details:
--------------------

  * "cvs watch" is basically a dead-end and should be removed, however:

  - It may be necessary to allow one to specify a "cvs watch" in such a
    way that all new sub-directories and new files are automatically
    watched as they are ``added'' by "cvs edit", or maybe the existing
    "directory" watch will suffice for this purpose.



-- 
                                                Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>