[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why check out elsewhere after import?
Re: Why check out elsewhere after import?
Wed, 9 Aug 2006 00:28:29 -0700
On Aug 9, 2006, at 12:13 AM, Paul Sander wrote:
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
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
their workspace will work in the import area. For example, if you
"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
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
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.
Following up my own message, it occurred to me that there might be some
assumptions being made that aren't clear. The big one is that, in the
context of using CVS, the verb "import" implies the use of the "cvs
import" command, which in turn has certain characteristics.
If you're using the verb "import" in a more generic sense, to copy a
code drop into the repository regardless of method, then you have a
couple of options. One is indeed to use the "cvs import" command,
which in best practice requires creating or updating a separate
workspace. A second method involves populating a workspace, unpacking
the vendor's distribution medium, and finally using "cvs commit" to
store the result after whatever other actions are needed (such as
adding new files, removing old ones, etc.).
If you use the second method, then you can use an existing workspace
after bringing it up to date according to whatever policy you use to
manage code drops. However, that method is not usually described as an
"import" in the context of using CVS.
Paul Sander | "To do two things at once is to do neither"
address@hidden | Publilius Syrus, Roman philosopher, 100 B.C.