|
From: | Paul Sander |
Subject: | Re: Why check out elsewhere after import? |
Date: | Wed, 9 Aug 2006 00:13:24 -0700 |
On Aug 8, 2006, at 6:16 PM, address@hidden wrote:
On Tue, Aug 08, 2006 at 01:21:41PM -0700, Paul Sander wrote:On Aug 8, 2006, at 8:03 AM, Larry Jones wrote:Chris writes [quoting the manual]:if you want to work with the sources import them first and then check them out into a different directoryBut it's not clear to me why I'd do it in a _different_ directory. Why can't I just check it out where I am?Because the files alread exist where you are and CVS won't overwriteexisting files. If you don't need the original source, you can deleteit and then checkout into where they used to be.I will add to Larry's comments that CVS does not add its metadata to the import area, so none of the "usual" commands that one would use in their workspace will work in the import area. For example, if you use "cvs import", then change the source, "cvs commit" will fail.I think the sense of the question is, why does one have to go through this song and dance? I would venture to say that in 99% of cases, sources which are being imported are already in the working directory in which you are going to use them. Now you have to manually delete that directory and then 'co' to get it back again. A good example would be, when you import the entire project directory of your favorite IDE. Some sort of 'autocheckout' option would be quite useful in those cases.
I don't know about the 99% figure, but it's certainly greater than 0%. I have several observations:
First, most IDE's integrate with version control systems well enough to invoke their commands and tolerate the presence of their metadata. Hence, IDE's using CVS would likely maintain workspaces using "cvs update" (and probably "cvs checkout" to initially populate a workspace), and "cvs commit" to store changes. An IDE that invokes "cvs import" to checkpoint is comparatively poor, but workable; but such an integration could not pull data out of the repository anyway. In any case, most users already have their own workspaces set up and in my experience they're less likely to change to new ones than to update existing ones. Under these circumstances, the additional checkout (actually "cvs update" in an existing workspace) is the normal practice. The update is probably necessary anyway to merge local changes with the new vendor drop, and you probably don't want to corrupt the vendor's pristine code.
Second, (in mid- to large-size shops) the imports are often done by someone who is not the engineer who's changing the software. This would be an administrative user or technician charged with tasks such as unpacking vendor drops into a pristine reference area and then importing it into version control. Under these conditions, the pristine reference area is usually off limits for any local modification and the engineers must checkout or update their own workspaces anyway.
Third, if you require your import area to be a CVS workspace, you can always unpack the vendor drop into an existing workspace and commit the changes.
Under any set of conditions I've described above, it's unnecessary and perhaps even undesirable to have the import area convert into a CVS workspace. That said, it's likely possible to modify CVS to add CVS metadata to an import area (as an option). I'm neutral on that issue, but I'm sure others feel strongly as to whether or not such a feature should be implemented.
-- Paul Sander | "To do two things at once is to do neither" address@hidden | Publilius Syrus, Roman philosopher, 100 B.C.
[Prev in Thread] | Current Thread | [Next in Thread] |