[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: cvs add <directory>
From: |
Paul Sander |
Subject: |
RE: cvs add <directory> |
Date: |
Fri, 23 May 2003 22:02:55 -0700 |
>--- Forwarded mail from address@hidden
>[ On Friday, May 23, 2003 at 14:59:34 (-0700), Paul Sander wrote: ]
>> Subject: RE: cvs add <directory>
>>
>> Quite right. Directories carry with them minimally the metadata necessary
>> to map files in the workspace to their history containers in the repository.
>> Even CVS does it with the CVS/Repository file, which in my opinion is
>> insufficient to the task.
>No, not right AT ALL. Directories cannot be versioned, especially not
>with an underlying, shared, file-based repository system like RCS.
>There is no useful metadata that can be changed. They either exist
>because versioned files exist in them, or they don't. There's literally
>nothing else useful to do with them that should not be done with a build
>system.
Your claim is not correct. Directories CAN be versioned, even using an
underlying shared, file-based repository system, even if it uses RCS.
The useful metadata, as I said above, are the mappings between the working
copies of the files and their history containers, and the versions selected.
CVS embodies the mappings using the CVS/Repository file; actually it maps
the user's directory to its counterpart in the repository and then uses
a computation to complete the mapping to the actual history container.
The versions selected are stored by CVS in the CVS/Entries file.
This simple concept is invariant in all source control systems that I have
used, whether the metadata are stored in the workspace (like CVS does) or
in a database (like ClearCase does).
There's other useful stuff that could be stored about directories, but
this is the minimal set. CVS offers a solution, but it's incomplete,
which is why this subject keeps coming up.
>If you think otherwise then you are (still) confusing concepts
>with other kinds of tools which are designed completely differently from
>the very ground up. All your attempts to date to invent schemes to do
>what you think you want to do are only warped mis-application of foreign
>ideas from other systems that simply do not fit at all with CVS.
Nope, there's no confusion of the concepts; just griping about the
implementation.
>--- End of forwarded message from address@hidden
- Re: cvs add <directory>, (continued)
- Re: cvs add <directory>, Phil R Lawrence, 2003/05/23
- Re: cvs add <directory>, Donald Sharp, 2003/05/23
- Re: cvs add <directory>, Greg A. Woods, 2003/05/23
- RE: cvs add <directory>, Shankar Unni, 2003/05/23
- RE: cvs add <directory>, Paul Sander, 2003/05/23
- RE: cvs add <directory>, Greg A. Woods, 2003/05/23
- RE: cvs add <directory>,
Paul Sander <=
- RE: cvs add <directory>, Greg A. Woods, 2003/05/24
- RE: cvs add <directory>, Shankar Unni, 2003/05/24
- RE: cvs add <directory>, Greg A. Woods, 2003/05/24
- RE: cvs add <directory>, Paul Sander, 2003/05/25
- RE: cvs add <directory>, Greg A. Woods, 2003/05/25
- RE: cvs add <directory>, Paul Sander, 2003/05/26
- RE: cvs add <directory>, Greg A. Woods, 2003/05/26
- RE: cvs add <directory>, Paul Sander, 2003/05/27
- RE: cvs add <directory>, Greg A. Woods, 2003/05/27
- Re: cvs add <directory>, Kaz Kylheku, 2003/05/28