Thread

I have been playing with SVN lately and it feels like it is something I should be doing, even if I am working on things solo.  I think I may be totally misunderstanding the best way to use SVN.  I have never worked with a team using SVN before so I have not seen what sort of best practices other people have developed.  Here is my workflow at the moment.

-> On local machine, checkout copy of repository.

-> Make local edits.

-> Commit changes.

-> On test server, run a bash script which does a checkout and rsyncs the changes to the working location.  I do a checkout so that I can just update the codebase and then rsync can be told to ignore the SVN stuff that goes along for the ride in the checkout.

-> As I hit milestones I can tag it, shut down the production version and then run an export.

Here are my problems.

1.  This process has a lot of steps for making small changes (maybe I forgot a semi colon.)  Ideally I would just setup a test instance on a local server and commit the changes only when I have made important code changes rather than fixing stupid mistakes.  The problem with that is I do work with other developers who would not be setting up a local test instance.  They would probably need to commit the smallest changes.

2.  My multiple step process does not work real well for other developers.  I run the update script right from a terminal (via SSH) which is not ideal but fine for me.  So the process is to commit the change, run the update script from the terminal and then check my changes.  This may seem like a huge PITA but it is actually not that bad.  It actually goes really fast and I am not a patient person.  If it were too slow I would have abandoned it long ago.

That leaves two steps that someone without shell access would not be able to handle.  They would not be able to run the checkout or run the update script. 

I could cut out the update portion by symlinking the checked out code but that does not really help.  I have been thinking about setting up a simple protected dashboard page which would have a link to run the script.  Right now I think that is my best bet for my current setup but I am sure there are other more obvious methods which I am not thinking of.

How do you guys handle this?

I’ll answer your last question right off the bat.  I don’t - I always test on my own setup.

The problem is that subversion wasn’t really made for web development.  It was made for old school programming where you can test on your local machine.  I would still suggest doing that.  A solution would be to let each developer have a live environment on a test-server.  That way everyone can test as they like.  Then, when your programming session is over, you commit all your (tested and bug-free) code to the svn.

Most svn commits should not be fixes such as semi-colons, they should be new features that the individual developer has thoroughly reviewed.  Then you can run your script once or twice a day with a cron job, and not have to worry about constantly commiting to test.

Your workflow becomes:

- Checkout newest code
- Upload to chosen testing environment
- Make code changes within this environment
- Test code
- Commit to svn
...
- Cron job runs

That is what I had thought.  Stupid small fixes are a waste on this process.  It felt kind of stupid which is why I asked.  😉 

Thanks for the advice.  I suppose I could still use my “test server” as a staging environment and then setup another server which the developers access directly.

I’m liking these sorts of SVN-related posts I’ve been seeing the past couple of days.

John, would you happen to have any links to tutorials/postings on how to setup a local instance of SVN?  I’ve been mulling over using SVN for my own development, but would love a no-fuss, no nonsense tutorial to lead me along.

Thanks,
-f

We us CVS rather than SVN and we have several developers in the office working on code, sometimes working on the same code at the same time.

We do things a little bit differently because we do not want to have to setup a development environment on each pc.
Instead we have 2 development environments, a linux and windows.
Any project that is going to be run on a linux server is developed on the linuz dev environment and anything that is destined for the trash heap will be on the windows one.

Using CVS we each have local copies of development files and we use Eclipse as our development environment, which a handly little plugin that allows us to sync our changes to another location. so each developer has their changes synced, on save, to the same location on the dev server.
They will check out the code from CVS, make any changes and then check back in, handling any conflicts at that time.

How do we manage the situation where 2 developers are modifying the same file at the same time. Well it does not often come up because we plan what we are doing first so that we generally know who is working on what. If one person needs to make a change in the code another is working on they ask first if it is ok and then make the change. Sometimes this will result in the other person checking in any changes they have made before hand so that there will be no conflicts, sometimes not.

Mostly we are able to manage this fairly well and seldom have any real problems with this approach.

Communication in this case is the key.

As I see it CVS and SVN are good for projects where all of the developers are dispersed, but if they are all working on the same code in the same environment then communication and planning can overcome any issues

We also tend at the start of a project to just check in at the end of the day, or the end of a major piece of functionality, but as the projects progress you will be checking in minor changes all the time.

We use Releases to tag all of the files to a particular version so that we can roll back if required.
And I have no ever used CVS to export the data to the live site, mostly because the code we are often working with is only a part of the code on the site not the entirity and my using something else such as a Syncronising FTP client to upload changes to the live site it is easieer to make sure that everything is released correctly without effecting other parts of the site.

Hi I agree with Inparo. Just a tip: if you want to shortcut the checkout-rsync thing, you can create a SVN hook that will automaticaly `svn export` in the web space.

Have you actually had the SVN hook running properly though? Seems to have lots of issues as to which user SVN and Apache are running as…

My usual workflow:
Check out to local machine
Develop and test on local web server
Commit to SVN
Export to “public” dev server since we’re always having to run changes by people that have no idea. (this bit I still havent sussed easily in terms of getting the hook going)
RSYNC to production server

Well, no. Sorry, I just read that tip in an old post and I found it smart enough to tell everyone. I just use SVN solo locally.
Anyway this tip is too much automation too me: what if you want to commit but not publish yet?

Its a dev server, not even staging, let alone production… Its just the place where the team can see our changes come together so thats sort of its purpose 😊

But yeah we seem to have problems with the user permissions on files etc, spose if it was a shell script i could add the appropriate permission change after

OK, didn’t know about that, this is even far from what I do! I’m not a pro, just testing ideas, or code for fun. I have no real production server.
I’m not a permission guru, but I’d try with a ‘web’ group.

Thanks again for all the info everyone.

I’m liking these sorts of SVN-related posts I’ve been seeing the past couple of days.

John, would you happen to have any links to tutorials/postings on how to setup a local instance of SVN?  I’ve been mulling over using SVN for my own development, but would love a no-fuss, no nonsense tutorial to lead me along.

Thanks,
-f

This really depends on your host/distro that you are using.  Overall, SVN can have a hefty learning curve so I would suggest tackling it in stages.  You can get a free SVN hosting account from Unfuddle and access it using something like Tortoise (Windows.)  That should be an easy way of getting the hang of using SVN.  You can then look into installing it for yourself. 

Right now I have an Accelerator and a shared account with Joyent and they pretty much have an easy press button setup. 

Otherwise you can use the packaging system for your *nix distro which should be pretty easy.  After you have actually used a working SVN setup somewhere else then you will at least have some idea of what you are looking at. 

As for tutorials, I never did find a good one.  I am impatient and much of the SVN tutorials are huge.  There are relatively few commands that you need to know to get started though.  A good client will also make all of this easier for you.  If you are a Windows user then Tortoise makes getting started much easier and also comes with great help files on SVN in general.