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

Am 06.05.2004 um 03:31 schrieb kaczoroj:

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

But if the user wipes out the sandbox and checks out again, (s)he'll 
get the checkout information again.
I don't see where it would be lost then (assuming we just store it in 
e.g. the CVS directories)?

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

Hmmh, I don't quite understand which settings you're talking about 
here...
I seem to understand you propose storing the checkout information per 
subfolder, much like CVS stores it's own metadata in the CVS folders in 
each subfolder, but to store all this information in a central location 
(like the per-browse-location settings we already have)?
The problem I see with this approach is that over the time you'd 
collect tons of stale checkout information for old sandboxes that you 
long ago erased from your hard disk.
Also, you'd loose the ability to move around or create copies of your 
sandbox, which at the moment is very easy to do.
Personally, I definitely think the checkout information must go 
somewhere inside the sandbox - to me it falls into the same category as 
any of the other CVS metadata.
(Correct me if I didn't properly understand your suggestion in the 
above paragraph)

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

Actually, I think there's probably lots of people that actually do 
fix/enhance some of their issues on their own to get it working the way 
they want, but never submit the patches for whatever reason...

> That means that things take time to develop.

Oh, I understand only too well - I can't even shelf out enough time to 
keep MacCvs up to pace with the WinCvs enhancements :(
I could do with a month of MacCvs-only-programming (however I'm sure my 
family wouldn't be too impressed about me taking a month off to lock 
myself up in a room with MacCvs only ;-)

</jum>



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/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/