RE: [PATCH] cvs list

[Peter Bowen]

Eugene,

I did see your cvsls script and that was my inspiration for doing
this.  Is does quite a good job of listing the current files in a
directory, however, it can't list all files that have ever existed in a
given directory.  The only way that I could get it to do this was to
write code that ran on the server, hence cvs list.

In answer to your question about the -a switch, the code by default does
not show files that have state==dead.  When dealing with a tag, branch,
or date, the list of dead files may change.  

For example if I removed a file called foo on Sept 25, a ls today would
show foo as dead, but if I use a -D 'Sept 1 2000' then it would show the
file as Exp, by default.  

The reverse is also true.  If I added a file called baz on branch bar on
Sept 25, then did a merge from branch bar to HEAD on Oct 10, then a ls
today would show baz as Exp, while if I used -D 'Oct 1 2000' it would
show baz as dead, or, without -a, not show baz at all.

As for your last question, it does not look at the local sandbox at
all.  If you run the command sequence that you gave, then it will spit
out the help for cvs list.  You should remember that list requires at
least a top level directory or module name to operate.  It will not
simply spit out a complete repository list upon demand.  I wrote cvs
list to ignore the local sandbox, so that web applications could use it,
but you do pose an interesting question.  What should the code do in
this case?  Or maybe even a better question, do we need a cvs list and a
cvs rlist?  If we were to implement a cvs rlist, then I would suggest
that the code below should probably give a list of the sandbox version
of each file, and it's status.

Thanks.
Peter

> Peter,
> 
> That's great that you incorporated it into cvs itself. Some time ago I
> posted a shell wrapper around 'cvs rdiff' to provide almost the same
> functionality. But integrated solution is better.
> 
> Had a question about your '-a' switch. I guess, if you specify this neither
> -r nor -D take any effect. Also, is 'cvs ls' remote only operation or it
> walks local sandbox to define what to list? What is listed in the following
> scenario:
> 
> cvs co -r Release_123 foomodule
> cd foomodule
> cvs ls
> 
> Is it the HEAD of foomodule, HEAD of the top level, or Release_123 tag of
> foomodule?
> 
> Let me know if you want to take a look at the wrapper. I made several minor
> changes since I posted it to info-cvs.
> 
> Thank you.
> 
> Eugene.
> 
> PS> I also suggest to have -H switch to be in line with other cvs commands.
> 
> -----Original Message-----
> From: Peter Bowen [mailto:address@hidden
> Sent: Monday, October 16, 2000 4:22 PM
> To: address@hidden
> Subject: [PATCH] cvs list
> 
> 
> I started on a patch to add a list option to cvs.  It came about because
> I wanted to run things like bonsai and cvsweb on remote repositories.  I
> guess you could say "I scratched an itch", as Eric S. Raymond has put
> it.
> 
> It is based on patch.c, which I belatedly discovered might not have been
> the best idea, as it uses the do_module function which refers to trigger
> scripts in the comments.  It currently lists all the files, as expected,
> but I am not sure how to get it to list all the directories.  If someone
> could help with this is would be appreciated.
> 
> The are XX options available:
> -r to get a list of files based on tag/branch
> -D to get a list of files based on date
> -l to turn off recursion
> -R to force recursion
> -s to not show state, author, version, and date for each file
> -a to list all files, even if they have state == dead
> -b to not show directory name for each file
> -? to get help
> 
> The default output has state, version, author, date, directory, and
> filename listed for each file in the module.  The author field has a
> width of 35, which is fairly large, but is the longest length username
> on mozilla.org's CVS repository.
> 
> I have not implemented any functionality to list the top level
> directories, but rather require the user to specify the module or
> directory to list.  I chose to do this because some repository
> administrators use the fact that you can't easily get a list of
> modules/top level directories as a feature.
> 
> I would appreciate any assistance with this option, and would hope that
> this will eventually make it into a release of cvs.
> 
> Thanks.
> Peter Bowen
> 
>