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

Jens,

> 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)?

Simply put I don't want to put any of our settings or metadate into 
sandbox unless there is a very good reason. It's not safe to have 
settings in CVS directories. It's not convenient to have settings 
there. Lets not put it there!

I understand that it may be convenient to keep the settings in CVS 
directory if you move the sandbox around. But you can just as well 
import settings from the old location, or move the settings file if 
you copy it to another machine. In the real life you don't move 
sandboxes all that much and if you do you will quickly learn to copy 
the settings file together.

What I want is to have the feature implemented and I don't want to 
spent time implementing the storage in CVS directories when I think we 
can just use what we have now instead. It's not essential for this 
feature and we can always change it later.

> 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)?

Exactly. When you checkout you have to specify the folder you are 
going to checkout to and the module name. We store the pair of values. 
Next time the checkout is done for the same directory we can user the 
module name. We can skip the dialog if the user selects the checkbox 
to skip it. 

Now we can argue whether it's better to store it on a per-location 
settings or in the common settings. It seems to me that the common 
settings are better so the same module name is used for any given 
directory.

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

Which is a good news actually because that's the way it's supposed to 
be ;)

> 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 am focusing on getting next milestone out so I try to avoid getting 
involved with too great changes at the moment. The modules feature 
will be usefull to me however because it seems like I need it to make 
the new CVSROOT handling more convenient. I want to apply similiar 
logic to the dialogs using CVSROOT in their commands so people don't 
have to select or type it each time.

Best Regards,
Jerzy






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