[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Web developpement with CVS...
Jesus Manuel NAVARRO LOPEZ
Re: Web developpement with CVS...
Thu, 04 Oct 2001 11:12:24 +0200
> We are trying to install CVS on one of our server. Right now, it's up
> and running and works pretty fine. It runs on a Linux box and we can
> connect to it with WinCvs on our Win2000 workstations.
> The problem is simple : we do web developpement, which means the
> latest version of the files should always be present on the server,
> not only in the cvs repository.
??? Do you really want last versions for all files no matter if they're
buggy or simply they collide one against others I can't believe this.
> Let me explain myself :
> Suppose we're working on a project with some PHP, I don't want to
> install PHP on every programmer's workstations... I'd like them to
> simply checkout their stuff...do their changes..commit it and than
> check (via their web browser) on the server to see if it's right...
1/ Why don't you want PHP to be installed on every desktop? I migth seem
most work for sysadmins, but if correctly planned, it is less, no more,
and have aditional advantages: simply develop a base-image for that
desktops and reinstall those systems. The developer will gain better
control about what he can/can't do, and better knowledge of the system
they're working on, specially if their desktops can run the same OS than
the server. I recently read an article about how java projects are
downloading the quality of code. It went saying that, in the old days,
programmers run their desktop OS as simmilar as possible to the
production OS, so if they were developping for Solaris, they ended up
with a Solaris workstation and the like, whil most java shops had their
server running whatever Un*x flavour that fitted, but the workstations
were mainly windows-based (because of the compile-once-run-everywhere
buzzword). Under those circumnstances, developers didn't know a word
about how the production OS worked, then failing in simple tasks
OS-dependant (that nasty bug with that version of the JVM under that OS)
or about peculiarities of the OS itsel (managing pathes, for instance).
This come because I know about at least one shop (can you imagine which
one?) that fails under this circumnstances too: They develop PHP code
for Apache on Un*x, but they do development on their Win boxes, thus
failing on understanding how Apache works (it's not needed they become
brilliant webmasters, only the basic stuff), or how the underlying OS
manages resources (again it is not needed for they to become gurus, just
usual stuff). As expected, they tend to fail as soon as those kind of
things appear (managing automatic emails, simply moving up and down some
files -"what do you mean with that ../../?" "was it ./ or ../?" "Hmmm...
repeat *that* again: so if I want this file to appear as
http://my.server/virtual_dir/whatever.php, why in hell should I put it
under ../basedir/includes/whatever.php? where ../basedir/virtual_dir/
2/ Your idea about serializing changes (yes: that's what you try, the
last is the best) only works for simple tasks within short development
teams (no more than 3/4 people). Once you go beyond this limits, you
get nigthmares: "Hey, Bob, why database is stopped?" "-No, it isn't"
"Well, my interface can access no more" "Ask Greg" "err... yes, you were
rigth: he is playing with database access files, so I must stop my work
till he becomes with a new functional version" or, "Hey, that menu entry
gives a "document not found" error!" "That's coz Eva has finished his
work with the menu, but Peter has not ended his underlying work yet" or
"Hmmm... I have not the sligthest idea if my new docs are working
properly because Ann still has not introduced the new menu entry to that
part of the web"). Do you think my examples are stupid? They aren't.
They become from the double fact I'm telling you: on one hand pure
serializing is *bad*, on the other, as they work in Win, anything out
from point-and-click provokes in them plain encephalogram.
> What is the best way to do this ? Is there any way to ask CVS to copy
> the changed file at the right place, and this, at each commit ? Since
> we host sites both on Linux and Win2000, will cvs even be able to copy
> the files over the network to another web server ?
Well, if you really want it, you can have that web server to be a
checked out copy of the repo. On the Apache side, I know of a module
(while I didn't test it) that will try for new updates on the TRUNK
branch for a file each time it's accessed. Or you can try a cron job to
do the update each 5minutes, 1minute or whatever fits. Provided there's
connectivity, afaik you can have CVS client on Win2000 too for the same