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

Jens,

Since Tony has ruled out the support for the functionality by the CVS 
directly it's in our hands now ;)

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

While it's not clear about the metadata in general we surely don't 
want to store the metadata related to checkout in the sandbox. Often 
times users would just wipe out the folders (e.g. using "cvs release") 
just to checkout again into the same working area. If our data were 
stored there it would disappear.

The storage on a per browse location is not detailed enought however 
as people may have few sandboxes, possibly with different module 
settings, in one working location for convenience. It's better to have 
it stored on a per-folder basis. That way even if the same folder is 
pointed in different locations it will suggest the same module for 
checkout. This is similiar to settings of CVS binary which is stored 
using the "dictionary" so we have the code to do it that way already.

Having that it's trivial to implement the optional checkout dialog and 
default module if available for a given directory. 

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

Oh but I am all for added functionality! However not all functionality 
is worth to be added. 

It's just that new CVS users tend to have problems adjusting to 
concurent working model. They always ask for locking support and 
visualisation of repository state versus their sandbox. The truth is 
they should stop worring about repository and simply get to work with 
what they got checkout. It really makes no sense to query repository 
until you are done with your task at hand. CVS was designed to enforce 
such disconnected model and I don't see much benefit in adding the 
features which don't add any value and only increase the network 
traffic like the "update view" or "file editors". For that I can only 
say: Get back to work and focus on your sandbox already ;)

Seriously though we need to implement previously discussed "basket" 
and it will serve the purpose perfectly. But that will not happen 
before WinCvs reaches milestone release...

> 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

With the pace of changes in CVSNT we are having troubles to even keep 
up with the options themselfes. However I do add quite a lot of 
features and many not related to the cvs commands. It's a little bit 
sad that people ask for so many features and report a lot of bugs but 
there is so little patches submitted. That means that things take time 
to develop.

Best Regards,
Jerzy



 
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/