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

Jens Miltner <[email protected]> Thu, 6 May 2004 13:24:20 +0200
Newsgroups gmane.comp.version-control.cvs.gui.devel
Message-ID <[email protected]>
Am 06.05.2004 um 13:04 schrieb Oliver Giesen:
>
>> 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.
>
> OK, but where in the sandbox are you going to store this? As I pointed
> out before, a Checkout is usually performed from the parent folder of
> the actually checked out folder, which usually also is _outside_ the
> sandbox, i.e. in a folder that does not even have a CVS subdirectory.

Hmmh, good point.
However, what we really want to provide is a transparent "update really 
means checkout" solution. For that, when updating the outer "non-CVS" 
folder, we could either rely on some file/folder created in the 
directory when doing a checkout with WinCvs, or we could just look at 
the folders at this level and collect checkout information from those 
folders' CVS directories:

+ Folder "my composite project"
	+ Folder "f1"
		+ Folder "CVS"
			+ file "cvsgui_checkout_info"   -> checkout "project1"
			+ file "Root"  -> CVSROOT for repo 1
	+ Folder "f2"
		+ Folder "CVS"
			+ file "cvsgui_checkout_info"   -> checkout "project1"
			+ file "Root"  -> CVSROOT for repo 1
	+ Folder "f3"
		+ Folder "CVS"
			+ file "cvsgui_checkout_info"   -> checkout "project2"
			+ file "Root"  -> CVSROOT for repo 2

by analysing the CVS information (including our new metadata file) from 
the "root-level" folders "f1", "f2" and "f3" will tell us, which 
checkout commands we need to run:
	checkout "project1" from repo 1
	checkout "project2" from repo 2

Of course, if we find a "CVS" folder in "my composite project" itself, 
we'd just use the checkout info from that folder (if available).
Alternatively, one could traverse the hierarchy and collect information 
about which checkout commands to run in which subdirectory. This would 
be a really complete solution, but of course it'll take some time to 
traverse the file hierarchy for large hierarchies, so maybe this should 
be optional, since I believe in the majority of situations, the users 
will either checkout from a single repo or checkout from multiple 
repos, but all checkouts are run from the root folder, so there 
wouldn't be any need to traverse the hierarchy when updating the root 
folder...

Of course, when only updating a subfolder, we can't use the checkout 
paradigm, so that would be a 'regular' update. This might be a bit 
confusing, so we'd need to make a clear distinction between the two 
update mechanisms in the UI (e.g. two separate commands, where the 
"update-by-checkout" command would only be enabled when a folder is 
selected that provides the necessary metadata files...

</jum>



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/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/