Re: Re: Suggestion for improved use of cvs checkout to update sandboxes

Am 23.04.2004 um 12:33 schrieb Oliver Giesen:

>> I would say it's a good idea. In fact it's such a good idea that CVS
>> should handle the whole thing so and the same should work
>> from regular
>> command line. One should be able to just do "cvs co" and CVS should
>> use it's metadata to figure out the module and checkout as
>> neccessary.
>>
>> Currently we have:
>>
>> cvs co (in directory D:\CvsTest\loki)
>> cvs [checkout aborted]: must specify at least one module or directory
>>
>> I think we could convince Tony to implement the caching of module in
>> CVS metadata. Eventually we could have additional option for checkout
>> command, like '-U', to make checkout read the modules and don't
>> require explicitic module specification.
>
> Generally this _is_ a good idea but the problem as I see it is that
> usually this kind of "update checkout" is performed from a non-CVS
> directory (unless the TopLevelAdmin option is used) so where should
> CVS(NT) put/read that info?
>
> A better approach IMO would be if _all_ directories of a working copy
> (i.e. not only the root) were aware of the module definition that was
> used to check them out and then simply allow to use Update on them.

I agree with that last paragraph (assuming this functionality is 
provided by the cvs tool itself).

>
>
>> I think we should not have to store the module name - it's the CVS
>> business to know what it's dealing with in the given sandbox. We
>> should keep clear off storing any data in the sandboxes.
>
> Agreed. In case we do end up implementing this ourselves (i.e. if Tony
> won't do it) we should probably consider putting it in our Settings
> folder instead of the sandbox.

Hmmh, not sure this is how it should be implemented: Right now, I can 
just duplicate a sandbox folder on disc and create a copy of the 
sandbox with everything working just fine.
When storing this information in the settings, this important piece of 
cvs operational information is stored somewhere else and I have to 
remember to use the settings of the original sandbox as the starting 
point. Not that much of an issue, but still, it's somewhat strange to 
have repository related settings spread over two places.
I wouldn't consider it a problem to have WinCvs/MacCvs/gCvs create it's 
own metafiles in the sandbox where it could keep additional 
information. It might even go into the CVS folder(s), so it won't 
conflict with user file names...
I agree that ideally it would be nice to have cvs take this 
responsibility, but the fact is that cvs out of the box doesn't support 
this and I don't see why a GUI frontend to cvs can't support additional 
functionality on top of cvs. This one is a simple matter of 
auto-supplying one of the parameters which the GUI frontend can pick 
from some well-known location.
In fact, I'd rather see more of such add-on functionality to be 
implemented in the GUI (e.g. the long-awaited browser view for cvs 
update output, etc.). After all, that's what a GUI frontend is all 
about: make the rather bare-bones functionality of a power tool more 
easily available. To be honest, I don't necessarily share Jerzy's view 
(or at least this is what I conceive as Jerzy's point of view) that the 
GUI frontend should just be more or less a frontend to the underlying 
tool's options - I'd rather go for a full-blown GUI app with all the 
bells and whistles that stem from combining options and operations and 
making output available in a more useful way, etc

</jum>



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com.  Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/NhFolB/TM
---------------------------------------------------------------------~->

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/cvsgui-dev/

<*> To unsubscribe from this group, send an email to:
     [email protected]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/