CODEWITHSUNDEEP
svnversion-controltortoisesvn
Useless Intern
Useless Intern

Reputation: 1302

Version Control For Web Development

I need help with setting up version control for web development. I do it myself (with tortoise SVN) for my own files but I'm having trouble scaling my process. Currently we have two servers, Dev/Test and Production.

My personal process is as follows:

  1. Develop the module on test.
  2. Commit each milestone into my personal repository.
  3. Repeat until finished
  4. Find each file that I modified and manually and move them to Production.

Now my goal is to streamline the process so that we can push to prod from the repository to remove the manual updating.

Unfortunately we use WAMP so we have licencing issues with setting up a virtual machine for each developer to work on. Therefore, all of us work on one server, which I believe will kill this dream.

I keep running into the problem of uploading a bunch of crap to production. I'm finding it difficult to separate file that are ready from crap files to TortoiseSVN to push. I've looked up merging and exporting but they do the whole directory and do not allow me to pick which files I want. Even if each of us had a VM with our environment how could I merge the branch without the crap that comes with the creation process. (Though as I type this it appears to be developer responsibility)

How would I create a workflow to accomplish this?

EDIT I got it to work.

I used batch files,branches, and patches. Each server has it's own branch. As we develop on test, we commit all changes (even crap) to the test branch. When a developer wants to push to prod he uses a batch file that compares the PROD branch to the TEST branch using svn diff, it then applies the patch to PROD using tortoisemerge. This is important because it allows the developer to choose which files to patch. Finally it commits the changes to prod with TortoiseProc.exe and the developer can comment on the changes. We update TEST from PROD using the same process but in reverse.

Upvotes: 0

Views: 74

Answers (1)

Lazy Badger
Lazy Badger

Reputation: 97270

  1. For multi-repository development SVN is, well, Bad Choice, migration to DVCS (don't use Git) will make life somehow easier, but it's offtopic here, in this question, due to the most of tags

Anyway, you can try start with SVN, and this solution (dirty draft, collisions is your headache) may be even scalable to the few developers (you'll get not technical, but organizational problems with mid- or large-size SVN-team)

  1. Create on TEST|PROD|every DEVEL the same repositories, which will share the same UUID (mandatory!!!) - ask your SVN-admin, how to achieve it
  2. Post-commit hooks on TEST|PROD must update local WCs of each environment after commit to repo
  3. Checkout from TEST, develop, commit and test on TEST
  4. On reached stable-point relocate you WC to PROD repository and commit (modified) Working Copy as one squashed giant commit, which will contain all changes made to TEST after previous commit to PROD
  5. Relocate back to TEST

For multi-developers work you'll have to have personal branches for each developer, cross-branch syncing|mering before commit to PROD, maybe something forgotten

Upvotes: 1

Related Questions