[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to update when CVS server moves?
From: |
Gerhard Sittig |
Subject: |
Re: How to update when CVS server moves? |
Date: |
Fri, 24 Nov 2000 22:28:30 +0100 |
On Fri, Nov 24, 2000 at 19:45 +0530, Sankaranarayanan K V wrote:
>
> I typically do something like this:
>
> export CVSROOT=:pserver:address@hidden:/export/cvs/root
> cd sandbox
> cvs -d $CVSROOT update
> perl -pi.bak -e '{ s/a.com/b.com/; }' `find . -name Root -print`
>
> assuming of course that you don't have files named Root other than those
> in CVS subdirs.
Why does this come up in this wrong or at least limited form
again and again? To repeat it (as has been done before a few
times) once more:
command `find ...`
does _not_ work with "normally populated" file hierarchies. The
limit for argument counts might be high, but its still finite
(some 4K AFAIR). As well as command line length has an absolute
limit, too. Sooner or later you will run against one of these
walls, more probably sooner than later. :>
Secondly: Can the CVS/Root file have more than the one line it
usually has? If not, you can as well do
echo $NEWROOT > Root
(the above search pattern seems to be just a sketch, too -- for
real world use you probably would escape the dot sign to make it
match a dot and not anything).
Probably the last command in your sequence should read
find . -name Root -print | \
while read R; do
echo $CVSROOT > $R
done
or as an alternative
find . -name Root -print | xargs \
perl -pi.bak -e '{ s/a\.com/b.com/; }'
depending on whether the repo root is the only line in the Root
file or not.
The first has builtin shell functions only (except for the
find(1) command) and "echo" should be cheaper than repeated
sed(1) or perl(1) calls. The second version assumes the perl
invocation to be as gentle in terms of resource usage as it can
be and still allows for (almost) unlimited file numbers.
But the best of all ways is definitely to make the server name
(and repo location in its filesystem) something constant. Name
your servers after the services they provide and tell your
clients that the repo lives at cvs.${DOMAIN}:/cvsroot or the like
-- assuming the machine is under your control. Then it's easier
to change one DNS alias (or pointing the /cvsroot symlink
somewhere else) than fiddling with a few thousand sandboxes and
always forgetting one (if you know at all how many they are and
where they reside).
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" address@hidden
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.