At the risk of getting burnt, I'll try to help, too.
First, as was pointed out by another responder, CVS manages files, not
directories. This is key to understanding what it can do. When you check
in a file from your sandbox, or all the files in a directory tree (there
is no concept of checking in a directory), CVS does keep track of what
directory each file was in, but that's pretty much all it cares about
regarding directories. This has several implications, which are expanded
upon in my responses below.
Hans Schwaebli wrote:
Am I misunderstanding you or are you misunderstanding me?
Please try to get out of your CVS implementation thinking and open
your mind to this:
Ouch! Sounds a bit rude to people who are trying to help you.
There is a directory with subdirectories and files which has been
previously checked in. Now imagine some random changes afterwards in
this directory like:
- subdirectories have been added
If the subdirectories contain no files, CVS won't care or keep track of
them. However, on a restore (checkout or export), if there were files in
a subdirectory in the version to be restored, CVS will create the
subdirectory. But if you restore into a sandbox with preexisting
directories and there are no files to be checked out into a particular
subdirectory in the version to be restored, CVS will not delete that
subdirectory from your sandbox, unless you (as was previously pointed
out) give it the -P switch. This may be adequate to fulfill your
requirement.
- some subdirectories have been deleted, which have been previously
checked in
Subdirectories were never previously checked in -- there is no such
operation in CVS; only files in subdirectories can be checked in. CVS
doesn't know or care if subdirectories have been added or removed on
checkin. But if there are files in those subdirectories, the files can
be checked in, and the subdirectories containing those files will be
restored on checkout. This may be adequate to fulfill your requirement.
You can have no directories or extra directories in your sandbox on a
restore. CVS doesn't care. It only creates those it needs (and I think
empty ones that had files in another version).
- some files have been modified
CVS ci handles file changes fine, assuming the modified files were
previously added to CVS (see next response).
- some files have been added
CVS does NOT assume any new file that shows up in your sandbox is to be
managed, when a ci is performed. You need to explicitly tell CVS to
manage the new file with a cvs add command before the commit. This would
need to be done manually (normally by the developer managing the
sandbox) or by an external process. You could write a fairly simple
script to keep track of what's new in the directory since the last time
the script ran, and add those files to CVS, but CVS won't do it for you.
- some files have been deleted, which have been previously checked in
When you do a cvs ci without specifying filenames, it processes whatever
files it finds in the sandbox. So, a file that's no longer in the
sandbox (whether removed by you or an external process) will not be seen
and will not be processed. (If you specify a filename and it's not found
in the sandbox, you get an error.) CVS does NOT look in its repository
and say, "there was a file in this directory before and now there isn't,
so the developer must not want this file to exist in this version". If
you do want the file to not exist in this version, you have to
explicitly tell CVS with a remove command before the commit.
Said another way, you can only check in files that exist in your
sandbox. So, if the deletion of a file happens through a script or some
external process, CVS will not remove that file from the version
committed, unless the script or automated process does a cvs remove of
the file before the ci. Again, you could write a script to keep track of
what's now missing in the directory since the last time the script ran,
and do a cvs remove of those files before the cvs ci, but CVS won't do
it for you.
Assume I DON'T know what has been changed in this directory, or if
anything at all has been changed. My skript runs at night,
automatically and unattended. It is stupid. It does not know what has
been changed.
The requirement is that this nightly script commits every change in
this directory, unattended, automatically, by force if there are any
conflicts. Thats the requirement.
How do I solve this with CVS?
What do you mean with "and the 'cvs checkout' commands into your
.cvsrc"? I don't understand how this can help me for my question. Or
any other answer you gave me.
If it does not work with CVS, just say so, PLEASE, so that I
understand it clearly.
So, in summary, CVS must be told when files are to be added and removed
before committing. This could be done manually or by an external script
that calls CVS, but CVS won't figure it out for you. It expects a
developer to tell it what files should exist in whatever version is
being checked in. So if you want to add some scripting to handle that,
and are satisfied with CVS's directory restoration capabilities, it
would appear CVS can help you. If not, I don't think it can.
Garyl
*/Spiro Trikaliotis <[EMAIL PROTECTED]>/* wrote:
Hello Hans,
* On Wed, Aug 15, 2007 at 01:50:15AM -0700 Hans Schwaebli wrote:
>
> 1. I want to commint ANY changes inside a folder
This is what "cvs commit" (or "cvs ci", the synonym) does. At
least, it
commits ANY changes CVS even cares about.
> (yes, they do exist in the IT world since very long times), which
> means subfolders, files and so on. Any changes means any
> modifications, including deletions of files and folders inside this
> folder.
CVS (and, btw, Subversion, too) does not care at all about folders.
Thery are just present if they were generated at any time back in
history.
> CVS does not know anything of folders? Nevertheless I ask for a
> solution how to commit every change in this folder, any change
in all
> files and subfolders. Does it work with CVS, yes or no, and if yes,
> how?
Again: "cvs commit" is what you are asking for.
Any, you might want to add the -P command for the "cvs update" and the
"cvs checkout" commands into your .cvsrc. This way, CVS will not show
empty directories when doing an update or a checkout. Note, however,
that this option gets tricky when doing branches (with "cvs tag"). In
this case, I suggest using "cvs rtag".
Additionally, this option is tricky when you want to "recreate" a
directory that was once empty.
But you already know most of this, Larry already explained it. This is
the only way to work with CVS here, as it is the way CVS works.
The only other options I see are:
1. Check out if meta-cvs (or other tools on top of CVS) support
directories (I do not know, you have to check yourself).
2. If the directory is realy, really, REALLY not needed anymore, you
might consider deleting it from the repository (that is, from the
server). Note that you loose anything that was once inside that;
thus, I do not recommend this unless the directory was created by
accident only.
HTH,
Spiro.
--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
