sslug-teknik team mailing list archive
-
sslug-teknik team
-
Mailing list archive
-
Message #19291
Re: Hjælp til CVS ønskes
On Fri, 25 Feb 2000, ALM wrote:
> Jeg har kæmpet en kamp med at få cvs til at virke på min RH6.0 Server
> at home.
Du siger ikke om du ikke kan installere eller bruge det. Hvis du ikke
kan installeret kan jeg fortælle at det virker fint out-of-the-box fra
mandrake 7.0.
Hvis du ikke kan bruge det kan det være at du kan extrahere noget
fornuftigt af nedenstående (der er bla. link til medfølgende postscript
bog om emnet) (fra min kommende ph.d.-afhandling):
In this section I shall just give the information necessary to start
using CVS for your own software project. A free book is often
distributed with the CVS-software
\cite{cvsbook}\footnote{/usr/doc/cvs-1.10.7/cvs.ps} and people are
referred to that for full details.
Assume you have the program files distributed in some tree structure
under $\sim$/MDSIMUL, then the following commands initialises CVS,
backups your files (this is the only time we \emph{like} to make this
manual backup, we don't need it, and can delete it once we have seen
that the transport to CVS has succeeded) and check out the first
version for further editing.
\begin{verbatim}
mkdir -p ~/cvs/CVSROOT
cd
cp -r MDSIMUL MDSIMUL.bak
cvs import -m "my MDSIMUL tree" MDSIMUL Nikolaj_Berntsen start
cvs checkout MDSIMUL
\end{verbatim}
now you have the new editable source files in \texttt{MDSIMUL} and the
old ones in \texttt{MDSIMUL.bak}. When you have made som change to the
working copies in \texttt{MDSIMUL} you can get them safely into the
repository with the command (similar commands allows for checking
individual files)
\begin{verbatim}
cvs commit MDSIMUL.
\end{verbatim}
It is possible to get rid of the working copy by the command
\begin{verbatim}
cvs release -d MDSIMUL
\end{verbatim}
RCS and SCCS work by \emph{inserting} the files into the repository
and deleting the afterwards. If one wants to continue editing one can
check it out setting a \emph{lock} telling the system that you are
working on the file now. Keeping this structure, remembering to lock
in and lock out, how to deal with if you happens to make two checkout
hence making two locks, can be a time robber, which is why CVS seemed
a better choice. CVS does not remove files or check them out under
some lock, rather it just accepts that now you have made some changes,
inserts them into the system and leaves your files alone, so there is
no bookkeeping, just edit and program along, and submit/commit changes
when wanted. When individual files have been changed the get different
version numbers. If would be nice that the program you run simulations
with for scientific purposes are reproducible and CVS allows to easily
upgrade all files to some common high version number which in the end
allows one to get all the source files that were used for a specific
simulation which in turn allows for inspection by other if they find
you results strange.
This I deem is necessary for any scientific work involving computer
programmes. Upgrading all files to a common version (which should be
higher than all existing version numbers), say 1.5 is done by the
command
\begin{verbatim}
cvs commit -r1.5 MDSIMUL.
\end{verbatim}
This prevents knowing in an easy way whether some file has changed
between simulations with versions 1.5 and 1.8 og the programme.
Therefore it is better to work with \emph{tags} or \emph{symbolic
revisions} which is a version number or tag independent of the
numeric revision number. To tag all files with tag \texttt{ICASP8}
issure the following command\footnote{I changes to CVS after ICASP8}
so while I can reget the source files for those simulations I cannot
do so with the ease illustrated here
\begin{verbatim}
cvs tag ICASP8 MDSIMUL
\end{verbatim}
Later you can get a hold of all your files used for those simulations
issuing the command
\begin{verbatim}
cvs checkout -c -r ICASP MDSIMUL
\end{verbatim}
the \texttt{-c} option tells whether the files in the \texttt{MDSIMUL}
directory have been commited yet. If they have then it refuses to tag
before changes have been commited. If one omites the \texttt{-c} then
the versions that are being tagged are the versions of the files they
were checked out from (most lately have been checked in as).
To see that status of your files in the CVS repository you can issue
the command
\begin{verbatim}
cvs status MDSIMUL
\end{verbatim}
It is possible to \emph{branch} the programme inside CVS, which means
that updates to the files are no longer affecting the files on the
main tree (or another branch). When wanted it is possible to merge the
programme with another branch or with the main tree. This could for
example be when some experiments are made with the code, e.g. to
optimize some computations, while at the same time adding
e.g. features to the programme. The details of this are to be found in
\cite{cvsbook} since I have not used it yet myself because I shifted
to CVS too early. Another reason might be that much later a bug is
found that affects result in a paper, but the programme has changed so
much such that the old simulations cannot be easily redone. Then the
old version of the programme (ICASP8, say) could be branched, the bug
fixed and the simulations could be run with the branched version of
the programme.
Mit besten gr\"ussen, Nikolaj
--
Ph.d.-stud, BKM, DTU, DK-2800 Lyngby
Nikolaj Berntsen; Dr. Olgasvej 57B 2.tv; DK-2000 F [tel +45 3811 1864]
If you write an interesting email, please CC: 26508034@xxxxxxxxxxxxxx