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

[Tony Hoyle]

Bo Berglund wrote:
> 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.

In theory you shouldn't have to care.. although you can get the command 
name at any point (%c).

> 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.

It'd be better on standard input... putting file lists on the command 
line isn't going to work in the long term.  If it's going to change, 
better to change it completely...

It's worth looking at properly for 2.5.02 since at the moment the 
loginfo format only part of the scripting process that has to be hardcoded.

> 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:

Import is just a large number of adds and updates in...  It could be 
treated as such rather than trying to make the same script do two 
completely different things.

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

I'd have the same for commit.

> 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?

That would work, although I'd make it barer than that...

Release:Version6
Comment:
stuff

A FifthFile.txt NONE 1.1.1.1 Module1
A Fourth\ File.txt NONE 1.1.1.1 Module1

etc.. then it's relatively easily parsable.