[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why check out elsewhere after import?

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 directory

But 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 overwrite
existing files. If you don't need the original source, you can delete
it 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]