[cvsnt] Several questions on cvs usage

Tom pxknet at gmail.com
Fri Jul 20 18:08:43 BST 2007


I comes out to be a big discussion. I don't know whether this is a place to 
ask for feature in for the next version. I just would like to suggest this 
feature as the "output" of this discussion:
I wish there is a native built in command or parameter of "cvs editors" to 
find out the locally modified files by myself.
And while doing the "cvs update", if just didn't display the unknow files 
prefixed with the question mark by default. And for the purpose to find out 
which file is in my local directory only but not in the cvs server, invent a 
new command for this or add a new parameter to "cvs update".
My idea is support these basic operations natively rather than work around.
Wish it helps and make a better cvs.

"Chuck Kirschman" <Chuck.Kirschman at Nosp_am.bentley.com> 
news:f7qggk$q2n$1 at paris.nodomain.org...
> It's interesting that "cvs status -q" is all but undocumented.  Most of 
> information on Google is about issues, not about using it.  I'll give it a 
> whirl, but I still dislike the fact that it doesn't support -I!.
>
> If there are ANY files in my source tree that aren't part of the source, I 
> want to know about it.  They should not be there.  The only people that 
> think that having the ? in front of EXEs and DLLs is clutter are people 
> that build into their source tree.  This is a bad practice that is only 
> due to people who use Visual Studio (which builds into the source tree by 
> default) and can't be bothered to set it up to build into an output tree. 
> Essentially it's the same people that will use Visual Source Safe rather 
> than setting up CVS, because it comes by default with Visual Studio.  Both 
> practices work fine for tiny projects; neither scales at all.
>
> chuck
>
> Tony Hoyle wrote:
>> Chuck Kirschman wrote:
>>
>>> "cvs -nq up" has been the time-honored way of determining which files 
>>> are changed in cvs.  I'm surprised that Tony desupported it.  The lucky 
>>> coincidence is that it still works for now, and is much easier to use 
>>> with regex's and other commands.
>>
>>
>> -n up hasn't worked properly for years.. status -q has been around a bit 
>> longer and has basically replaced it except for a couple of corner cases 
>> (that haven't been mentioned in living memory so I assume nobody's that 
>> bothered about them).  The official deprecation is a bit newer because it 
>> became clear that making it work was not only nontrivial (involving 
>> essentially rewriting parts of the update process in dummy form) it 
>> seemed nobody had even noticed how broken it actually was...
>>
>>  > Is "cvs -q stat -qq" everyone's
>>  > preferred way to look at the change set now?
>>
>> If you want changeset information then log can filter on commit and bug 
>> identifiers.
>>
>>> One other problem with that command is that it misses DLLs, EXEs, etc. 
>>> Update at least supports -I! so you can see these files.  I have no idea
>>
>>
>> If you're after the list of changed files then I don't see what listing 
>> DLLs and EXEs that aren't under CVS control is going to do for you... no 
>> cvs command is going to do that since it basically ignores things that it 
>> doesn't know about, other than printing the questionmark (personally I 
>> hate that.. clutters the output).
>>
>> Tony 




More information about the cvsnt mailing list