Re: backing up of cvs repositories

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ankush grover <address@hidden> writes:

> > >   --exclude '#cvs.lock' \
> > >   --exclude '#cvs.history.lock' \
> > >   --exlcude '#cvs.val-tags.lock' \
> > >   --exlcude '#cvs.rfl*' \
> > >   --exlcude '#cvs.pfl*' \
> > >   --exlcude '#cvs.wfl*' \
> > >   --exlcude ',*,' \
> > >   --exclude 'CVS'
> > >
> >
> 
> hey Mr. Mark,
> 
> I searched for the above files on my system and to my surprise I did
> not find any one of them.

All that means is that no one was actively doing a read or write
operation on your repository while you were doing your search.

The lifetime of the #cvs.*fl* files is typically sub-second. They are
used to create the #cvs.lock directory long enough to perform the cvs
operation of a checkout or commit. The ,*, files are also only in
existence for a sub-second. The #cvs.lock file will typically exist for
one second.

In proper operation, you will only see those files if/when someone is
doing a CVS operation on the repository at the same time that you are
doing an rsync operation to your backup copy.

If rsync exits with return code 24, then you know that one of those
files was added and removed while rsync was doing its scan for candidate
files to be copied.

The CVS/fileattr files only exist if someone has done a 'cvs watch on'
or 'cvs edit' command for a file or directory in the repository.

> The developers are not using any locks means
> default is editable as same files have to be edited by the developers
> so I using the default settings that comes with the cvs.
> 
> The files under CVSROOT of one Repository.
> 
> 234914 drwxrwsr-x  3 sun test   4096 Apr 24 18:29 .
> 234913 drwxrws---  6 sun  test   4096 May 23 16:41 ..
> 234947 -r--r--r--  1 sun test    495 Apr 24 18:29 checkoutlist
> 234928 -rw-rw-r--  1 sun test    495 Apr 24 18:29 .#checkoutlist
> 234929 -r--r--r--  1 sun test    698 Apr 24 18:29 checkoutlist,v
> 234945 -r--r--r--  1 sun test    760 Apr 24 18:29 commitinfo
> 234924 -rw-rw-r--  1 sun test    760 Apr 24 18:29 .#commitinfo
> 234925 -r--r--r--  1 sun test    963 Apr 24 18:29 commitinfo,v
> 234950 -r--r--r--  1 sun test    991 Apr 24 18:29 config
> 234936 -rw-rw-r--  1 sun test    991 Apr 24 18:29 .#config
> 234937 -r--r--r--  1 sun test   1194 Apr 24 18:29 config,v
> 234948 -r--r--r--  1 sun test    602 Apr 24 18:29 cvswrappers
> 234930 -rw-rw-r--  1 sun test    602 Apr 24 18:29 .#cvswrappers
> 234931 -r--r--r--  1 sun test    805 Apr 24 18:29 cvswrappers,v
> 234943 -r--r--r--  1 sun test   1025 Apr 24 18:29 editinfo
> 234920 -rw-rw-r--  1 sun test   1025 Apr 24 18:29 .#editinfo
> 234921 -r--r--r--  1 sun test   1228 Apr 24 18:29 editinfo,v
> 234915 drwxrwsr-x  2 sun test   4096 Apr 24 18:29 Emptydir
> 234938 -rw-rw-rw-  1 sun test 126331 May 30 19:12 history
> 234941 -r--r--r--  1 sun test   1168 Apr 24 18:29 loginfo
> 234916 -rw-rw-r--  1 sun test   1168 Apr 24 18:29 .#loginfo
> 234917 -r--r--r--  1 sun test   1371 Apr 24 18:29 loginfo,v
> 234940 -r--r--r--  1 sun test   1151 Apr 24 18:29 modules
> 234934 -rw-rw-r--  1 sun test   1151 Apr 24 18:29 .#modules
> 234935 -r--r--r--  1 sun test   1354 Apr 24 18:29 modules,v
> 234949 -r--r--r--  1 sun test    564 Apr 24 18:29 notify
> 234932 -rw-rw-r--  1 sun test    564 Apr 24 18:29 .#notify
> 234933 -r--r--r--  1 sun test    767 Apr 24 18:29 notify,v
> 234942 -r--r--r--  1 sun test    649 Apr 24 18:29 rcsinfo
> 234918 -rw-rw-r--  1 sun test    649 Apr 24 18:29 .#rcsinfo
> 234919 -r--r--r--  1 sun test    852 Apr 24 18:29 rcsinfo,v
> 234946 -r--r--r--  1 sun test    879 Apr 24 18:29 taginfo
> 234926 -rw-rw-r--  1 sun test    879 Apr 24 18:29 .#taginfo
> 234927 -r--r--r--  1 sun test   1082 Apr 24 18:29 taginfo,v
> 234939 -rw-rw-rw-  1 sun test      0 Apr 24 18:29 val-tags
> 234944 -r--r--r--  1 sun test   1026 Apr 24 18:29 verifymsg
> 234922 -rw-rw-r--  1 sun test   1026 Apr 24 18:29 .#verifymsg
> 234923 -r--r--r--  1 sun test   1229 Apr 24 18:29 verifymsg,v

The .#<file> files are the temporary copies that are created in the
process of rebuilding the CVSROOT <file> versions as specified by the
checkoutlist files and the normally defined cvs administrative files
during the commit of any file to the CVSROOT directory itself.

> 
> What I want to know is my cvs running properly or there is some
> problem? 

It seems like it is working as you do not have any stale locks in your
repository.

> The developers are not facing any kind of problem in
> commiting or getting the updates of the files/folders.

Good.

The repositories I have played in typically have thousands of
directories and hundreds of thousands of files and it still takes only
minutes to update or commit changes. Most of the time the rsync
proceedures to clone the repository never hit a user commit. But
collisions (ie, making the backup while someone is actively modifying
the files you are copying) do happen, so your code should be ready for
it.

Note: You may find it desirable to run the contirb/validate_repo.pl
script on your repository once in a while as well if you wish to watch
out for possible corruptions.

        Enjoy!
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)

iD8DBQFEfaFoCg7APGsDnFERAm9TAKClKx732CCKIAhLhPjjuAE8pYyWAQCfUSXP
CT4WMK2WgXq+xFYeAll6Ap4=
=zJXD
-----END PGP SIGNATURE-----