How to properly use svn when developing a web application

views:

122

answers:

How to properly use svn when developing a web application

I just recently started getting familiar with svn and while it seems pretty straightforward for "normal" code development, it leaves me a bit confused about web development.

Web development requires a web server directly interacting with the source in order to test the (often small and very frequent) changes, so I guess the project's document root should be a working copy. But every user is supposed to have his or her own working copy to be merged and committed to the repository, and later exported. This whole cycle is clearly not doable when you have to tweak a style sheet over and over again to satisfy all browsers.

Users clearly can't work on the same working copy (that's the point of svn) and you can't checkout different working copies in the document root for path reasons, so what's the best way to work with svn and web app development? Should every user have a webserver/php interpreter on the client machine?

+2 A:

In a word, yes.

Your development environment needs to be separate from your production environment. Once you've tested a change on your machine, then you can commit it to SVN. To see the changes others have made, you update your working copy.

Then, when you want to make a release, you export from SVN to your production server (or testing server for QA to bang on).

Michael Hackner 2010-02-12 21:08:10

That is not really his question, is it? His question is how to deal with multiple working copies across a team.

Pekka 2010-02-12 21:12:36

That's what I'm saying; the way to deal with it is for each user to test modifications on their own machine, and then the "common" area is the SVN repository. I'm describing the workflow and answering the question of "Should every user have a webserver/php interpreter on the client machine?".

Michael Hackner 2010-02-12 21:31:23

+1 A:

I have always done it where each user has there own webserver/php interpreter, although all you need is your own apachectl that passes the user's specific httpd.conf. Then each user needs their own httpd.conf. So all you need to replicate is the httpd.conf and apachectl, everyone can share the same apache installation.

jacob 2010-02-12 21:09:08

+3 A:

Each developer has a workstation with an IDE, a local webserver and SVN client tools. The webapp is checked out in each workstation so the developers can commit changes back to the repo.

cherouvim 2010-02-12 21:09:09

Depending on team size and structure, wouldn't it be wiser in this case to

Work with the same working copy in this case through the LAN, and employ file-wise locking on OS level

Maintain a "work" repository, into which all changes are committed extremely frequently so others can update their working copies, and a "final" repository into which the team commits at the end of the day, or at reaching some pre-defined point?

A scripted web application usually has no build process. Imagine somebody working on a CSS file, making changes and checking them out in the browser every few seconds. Imagine somebody else working on a related HTML file, doing the same.

If they have their own separate testing environments, they will never be able to see how the other person's changes reflect with their work. And I know how it is with adjusting some CSS detail in the browser - it can take dozens of steps until something gets got right. Depending on the team's structure, that can make interaction horribly cumbersome.

Feel free to correct me if I'm wrong, I don't have that much experience with SVN in a web application development team.

Pekka 2010-02-12 21:14:34

Sharing the same working copy is one of the things svn is supposed to avoid, but it seems the natural thing to do in web dev. Hence my doubts.

kemp 2010-02-12 21:19:49

The 2-repository approach may be the best - one to keep the team in sync, one to make actual commits into. Your people would just have to very frequently commit and update. Conflicts would become immediately visible that way. I've never tried that in practice though.

Pekka 2010-02-12 21:22:21

Of course everyone will be able to see everyone else's changes when they update their working copy. The fact that there's no build process is irrelevant. I don't see any reason to share working copies (shudder) or have multiple repositories.

Michael Hackner 2010-02-12 21:34:00

@Michael Hackner, I didn't say then won't be able to see everyone else's changes. My point is that there are often changes that need to be tested in real-time against someone else's work, sometimes dozens of times. If you do that in your production repository (checkin / test / update / find bug / check in), it's going to look like shit within 24 hours, and it's going to be impossible to trace back any meaningful revision steps. It's impossible to keep a proper checkin log when trying out 10-20 different height values until it finally fits right. That's 10-20 commits for you.

Pekka 2010-02-12 21:43:32

And as I said, this strongly depends on team structure. If the team has very granular tasks, your approach of separate testing environments is likely to work fine. That is in the end something only the OP can answer.

Pekka 2010-02-12 21:44:55

You're right, I don't understand that workflow. If it were me, I would make _one_ commit once I got the height value right, not twenty. And if development is happening at such a frenetic pace that it's likely that, in the meantime, someone else changed something on the page to make my height value wrong again, I would call that a breakdown in communication and division of labor, rather than an improper use of SVN.

Michael Hackner 2010-02-12 21:51:07

@Michael Hackner, I agree with you that that *is* the right workflow. But what if I can't know whether the height value is right before I haven't checked with the HTML guy's changes? *How can I see how my work behaves with what the HTML guy changed without creating a potentially useless revision so the HTML guy can fetch my changes?* If such situations occur frequently, not being able to test the "composed result" without checking in *may* be a problem. Anyway, I think we have both made our points and the OP will decide what suits him best.

Pekka 2010-02-12 22:05:59

+1 A:

There is really nothing different about working with web development, verses any other type of source (like a thick client). They are all the same:

Developers check out a version of the system.
They make changes to what is checked out.
When appropriate (*) they check the changes back into the repository.
Things are tested (to some degree)
The changes are accepted.
The system is checked out (somewhere else), and used to upgrade production.

All software in development should have at least three different instances:

development (for each developer)
test (for each testing group)
production

If you're making 'development' changes directly to your production copy, it is usually considered reckless. It may seem fast, but you're not factoring in the 'risk' correctly (and it will bite you some day). If you're just sharing a web server between server developers in development, you're still asking for trouble.

Each development instance should have it's own "complete" environment to work in. That is, each developer should have their own web server, their own source, their own configs, etc. Use the repository to bring it all together, that's part of its job. The development structure should match the test and production structures "as close as possible". It cuts down on mistakes during installs.

Paul W Homer 2010-02-12 22:02:07

ansaurus

tags:

views:

answers:

How to properly use svn when developing a web application

related questions