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/