Inland Empire .NET User's Group Forums / Inland Empire .NET User's Group / Speaker and Presentation Topic Suggestions / What do you want to see in the SVN demo? / Latest Posts

RE: What do you want to see in the SVN demo?

MattPenner — Fri, 20 Jun 2008 10:59:37 GMT

There are two typical setups for Subversion.

svnserve server (light weight simple tcp/ip server)
Apache

The creators of Subversion took advantage of a lot of the built-in technology of Apache. (I believe one of the main contributors actually worked on the WebDAV protocol and plug-in for Apache). As such there is no current IIS equivalent. I don't see why there couldn't be but I can't find one anywhere.

There is a svn-iis project (http://www.svniis.org) but it really just just using IIS as a public face to Apache.

We actually don't use Apache at this moment at my work. we only have 3 devlopers internally and don't have any problems with security. We all can access each other's projects without any issue. We also don't do any development offsite. So, using the basic svnserve server is fine for us.

I'll look at trying to show both servers during the demo, but as it is I have a lot to fit into 30 minutes!

Edneeis (6/18/2008)

I'd like to know more about accessing it via the web and is there any IIS hosted solutions for SVN.

RE: What do you want to see in the SVN demo?

MattPenner — Fri, 20 Jun 2008 10:47:15 GMT

I figure I'll just answer some of this now. Lots of questions though! This is great!

One of the best resources is the SVN Book: http://svnbook.red-bean.com/

What is a typical day of a developer using svn

There really isn't a typical day, but a typical process (can be used several times a day).

If you're working on a new project then check out the head.
Otherwise Update your working copy to the head.
Solve any conflicts (if any).
Write your code.
Update your working copy to get the latest changes (if any).
Solve any conflicts (if any).
Commit your changes.

That about it. The mantra I always here is commit small and commit often. If you have 4 small features you're working on, commit each one individually as you complete them.

ready to deploy, export but now bug fixes we should branch kinda thing

Bug fixes depend on your company's strategy. For instance, do you fix it in the current release and force your users to update to the latest release or do you handle patches for several different versions? Sometimes a bug is already fixed in a newer version and you can just tell your users to upgrade. Sometimes you can patch a previous version or two, but it's too costly to go back farther than that. It all depends on the extent of the bug and your support schedule. For instance, maybe your support schedule dictates that you fix bugs in the previous major version, only fix critical errors in the version before that and any prior versions are not supported.

Assuming your working copy is against the trunk and is not the production copy (most likely) this what I believe is the typical strategy:

Create a new folder and check out the tag (release) in question. Let's assume this is 2.0.
Fix the bug.
Create a patch from your working copy against the 2.0 tag. This is what users can use to update their current copy or your developers can wrap in an install to update customer copies.
Commit your changes. If there are several people working on the bug fixes you'll go through the standard update\commit cycle.
If this new "head" is now ready for release (version 2.1 for instance) create a new tag for it.
If the bug exists in the trunk and the patch will apply without any conflict then you can create a new folder, check out the head and simply apply the patch and commit.
If the bug exists, and the trunk code has changed significantly so the patch will not apply, do the same as above but actually code the fix rather than just appling the patch.
When all is done and committed then simply delete the other folders and get back to work on your normal project working copy.

as i mentioned before talking about qit will be lovely.

Will try.

i dont see backup strategy, how do u backup svn repo

You have to make sure that no one is committing to the repository during a backup, otherwise you could conceivably backup the repository with a half commit.

If you want to backup the repository as a whole (as oppose to incremental backups) you can use the svnadmin hotcopy command to copy the repository in a guaranteed consistent state to another folder.

At my work I have a scheduled task that runs a script every night. This script wipes out the “backup” folder and then runs svnadmin hotcopy to duplicate our folder of repositories to the backup folder. Then our backup system backs up the backup folder. This guarantees a good copy every night.

If you’re a single developer you can simply just backup the repository as normal and just take care not to commit during that folder’s backup stage. When I used to be the only one in our department using svn I would simply save my repositories in my My Documents folder. This folder was backed up every night. Since I typically don’t work at 3am this was perfectly fine.

How can you exlude some file types such as dll files or so

This can be done by setting properties on the repository. You simply set patterns to ignore, for instance *.dll or even \bin. You can do this with the command line if you wish. If the folder is already under version control this is pretty easy using TortoiseSVN. Just right-click on the file and select the ignore command. If the file is already being versioned you have to remove it, such as by deleting it. When it is recreated by VS then you can tell TortoiseSVN to ignore it.

volkanuzun (6/18/2008)

scenarios i like scenarios.
for example what is a typical day of a developer using svn ?
come to work check out
do updates checkin
see the conflict bla bla

ready to deploy, export but now bug fixes we should branch kinda thing

as i mentioned before talking about qit will be lovely.
i dont see backup strategy, how do u backup svn repo?
what is the common way of creating repos, one repo for company different repos or per department, per project ? why ?

how can you include your database to the svn ? is there a way to automate scripting the database and updating in the scs ?
how can you exluce some file types such as dll files or so

RE: What do you want to see in the SVN demo?

Edneeis — Wed, 18 Jun 2008 18:31:50 GMT

I'd like to know more about accessing it via the web and is there any IIS hosted solutions for SVN.

RE: What do you want to see in the SVN demo?

volkanuzun — Wed, 18 Jun 2008 13:18:50 GMT

What do you want to see in the SVN demo?

MattPenner — Wed, 18 Jun 2008 10:27:48 GMT

I'll be giving a breif demo (30 min?) on using Subversion source control at the next user group meeting on July 8th.

What would you like to see? Here's a small list I have so far. I'll keep this list updated as requests come in.

What is source control (may skip most of this if everyone is pretty familiar with it)
Why SVN? Do we really need ANOTHER VCS? (basically what SVN is trying to accomplish and how they're different than the "other guys")
SVN lingo
SVN setup for a personal machine
SVN setup for a shop

svnserve
Not planning on showing Apache here, but if that's requested I can do it. Just let me know because it takes some preparation

Using SVN clients

Tortoise SVN
Ankh SVN (don't like it so will just touch on it)
Visual SVN

Hands on

Creating a repository
Creating a repo structure
Committing
Updating
Handling conflicts
Tagging
Branching

Merging branches

Special requests

Distributed svn (svnsync) - I've never worked with this but I'll see what I can find out