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
Matt Penner  |