[cvsnt] Re: Import on 2.5.01 creates unusable loginfo data...

[Bo Berglund]

On Fri, 25 Mar 2005 12:03:34 +0000, Tony Hoyle <tmh at nodomain.org>
wrote:

>Bo Berglund wrote:
>> All of this has completely broken down now that I am not getting any
>> data at all for cvs import....
>
>The only thing that is missing is the status at the end.. everything 
>else seems to be OK.
>
>TBH given the lack of documentation I'd rather make import consistent 
>with commit rather than the way at the moment which is totally 
>undocumented and not exactly sane (if the parameter for import is as you 
>say then this directly contradicts both the cvsnt and cvshome 
>documentation).
>

It's OK with me provided that all files are listed on the command line
with the %{sVvt} switch and that I have some means of knowing that we
are dealing with an import.
However import and commit differ in the potential number of files
being dealt with at any given time, the file list may well overload
the command line just like tagging does.
So the old way is actually not so bad after all:
- Files are listed (one per line) on STDIN
- Each file has a U/N marker telling me which are new and which are
old files
- There is a single entry for the Vendor tag (all are the same)
- There is a single entry for the Release tag (all are the same)

The only thing here I have missed before is a per-file revision item
(oldrev and newrev). So here I have tried to detect it otherwise.
On the other hand if the old/new revs could be provided in the file
list itself also on STDIN then the U/N markers are no longer needed
and I guess we could make do with something like this to make it
uniform with standard commit:
----------------------------------------------------
Command line final argument:
ImpTest

STDIN:
Import of /pc/ImpTest
In directory antares:C:\\cvstemp\\cvs-serv3028

Vendor Tag:	Module1
Release Tags:	Version6

Modified Files:
  FifthFile.txt,NONE,1.1.1.1 Fourth\ File.txt,NONE,1.1.1.1
  SecondFile.txt,NONE,1.1.1.1 SixthFile.txt,1.1.1.1,1.1.1.2
  ThirdFile.txt,1.1.1.2,1.1.1.3

Log Message:
Message text
----------------------------------------------------

Here the general structure will adhere to the commit structure with
the following changes:

Command line argument indicates the module, but there are no files.

STDIN immediately tells if we are dealing with an Update or an Import.
STDIN also has the "Vendor Tag" and "Release Tags" markers for import
STDIN lists the files in the same way as before with the old/new
revisions added.

With this it would be real easy to parse out the two cases.

Of course the branch tag issue we discussed yesterday could be used
here as well with the standard file list:

Modified Files:
  Tag: Module1
    FifthFile.txt,NONE,1.1.1.1 Fourth\ File.txt,NONE,1.1.1.1
    SecondFile.txt,NONE,1.1.1.1 SixthFile.txt,1.1.1.1,1.1.1.2
    ThirdFile.txt,1.1.1.2,1.1.1.3

This would handle the Vendor branch tag, so we are left with only
giving special care to the Release tag (a sticky tag on the newly
imported files).
Maybe adding a new marker called "Release:" will be possible:

Modified Files:
  Tag: Module1
  Release: Version6
    FifthFile.txt,NONE,1.1.1.1 Fourth\ File.txt,NONE,1.1.1.1
    SecondFile.txt,NONE,1.1.1.1 SixthFile.txt,1.1.1.1,1.1.1.2
    ThirdFile.txt,1.1.1.2,1.1.1.3

What do you think?


/Bo
(Bo Berglund, developer in Sweden)