[EMAIL PROTECTED] on 03/08/2000 10:16:41 AM
>CVS newbie here. Be warned...
OK.
>We are using CVS here for web development.
>
>The normal method of working with CVS is to have a private working
>directory, where we change, test, and when satisifed, commit to the
>(internal) server where others can QA it.
>
>This is a problem: The site is a dynamic one, meaning it's definitely
>not simple HTML. Testing even a simple color change needs an actual web
>server, database connection, PHP installation, and whatnot. Having such
>a setup on each of the developer's computers is redundant - a
>maintenance nightmare.
This is a necessary redundancy. Although the software (eg app server) may not
need to be installed several times, it does have to be configured such that
separate environments are possible. IMHO, this is even more important in web
dev since soooo many people get to see dev mistakes (ie mistakes are even worse
for image on the web).
>My idea was that the working directory should be handled by one
>correctly-configured web server. This means it's in a central place.
>Each of us would edit the file of his choice, return it to the central
>testing area, use a browser to view it from there, and once satisfied,
>pass it on to the middle-tier test server for QA. Or something along
>these lines.
I think you'll wind up stepping on each others toes. It's extremely difficult
(if not impossible) to test something when its not in isolation.
I would suggest configuring your servers such that it supports multiple
development environments. For example, each developer can have their own http
port or application name.
>Problem here is, of course, team collaboration. We need some sort of
>concurrency resolution. But can we use CVS to do that, as well? I see
>several problems here:
No, this is a very complicated communication problem. If something needs to be
built, you'll have to tell everyone to stop working until the build is done.
>1. CVS doesn't support a "draw one file, edit it, return it" approach
> very well. It doesn't have a listing function, as far as I know.
> Do we have to draw each file's name and location from memory?
There's been several solutions to this, one of which is "cvs rdiff -s -r 0 -r
HEAD module-name" or something like that.
>2. How do I do the "major commit" thing? I was thinking of having our
> main (QA) level website on the trunk, and the testing area on a
> branch, and once satisfied, do a branch merge. But a branch merge
> is done completely from the point of branching every time, right?
> And to avoid that you have to branch again, or use changind tags.
> I have to keep in mind that some of our people use Windows and any
> complex command will have to be wrapped for them. And that means
> the tag names have to be hidden, and I think I'm getting over my
> head here. There is no way to just say "merge the most recent
> versions of the testing branch to the trunk from the point of the
> last merge I made" or something like that, automatically, is there?
Take a look at http://www.enteract.com/~bradapp/acme/branching/ for numerous
ways of using branches to achieve different results.
>3. Another solution is to have the exported area (which is used by the
> web server) become the working area for a second CVS repository (or
> a separate module in the same repository). Is there a way to make
> sure that every time I commit a change and it gets exported to the
> "working area", and it is a new file, it will be "added" to the
> other module/CVS, and when I remove something from the first module
> it will be marked for removal on the second module? Is doing a "cvs
> add" from the loginfo file going to deadlock things if the add
> is done to a module in the same CVS repository? On a different
> repository?
This is outside the scope of CVS although I don't see why it can't be done. If
I understand correctly, this solution is logically the same as number 2.
>Does my model have any obvious drawbacks? Is there a simpler CVS-based
>solution to my basic problem (not wanting to do local testing)?
I can't think of any, but, then again, I really don't agree with your primary
goals to begin with. Local testing is the way to go until it's time for
integration testing (which will really still be a kind of local testing).
Noel
