Thank you Gary for the detailed notes on SVN. I am going to get my code setup next week with SVN.
On Fri, Jan 8, 2010 at 9:58 AM, Gary McNeel <[email protected]> wrote: > Hi: > > We use Subversion here for all of our repository needs - probably some 100 > plus applications in many languages. The actual file storage structure > changes depending on the language. We do use the trunk, branch, tag > model. For instance, CF folder structure is different from Flex and .NET > structures. If you are working in a team environment using Flex, you do not > want to version the .properties (dot) files, which are workstation user > specific configuration files. You hose your partner in a game of > configuration changes. 'SVN Ignore' them. SVN Ignore any compiled folders, > such as bin-build and bin-debug, etc. We rarely version compiled code, > preferring to just back it up. You also need to keep track of settings for > compilers, etc., that are configured locally. I tend to keep that in a text > file with notes stored in the repository. This allows a future developer to > somewhat recreate your IDE environment to compile the code in the future if > needed. We also keep a snapshot of the db scripts at different points. > > So the structure might look like: > branches > tags > tags\1.0 (version one as released) > trunk > trunk\support > trunk\support\db (holds SQL scripts) > trunk\support\docs > trunk\support\docs\( folders like: code reviews, design, meeting minutes, > misc, requirements, test plans, etc.) > wwwroot (holds the root of the CF code: application.cfc, index.cfm, etc.) > > We use VisualSVN. Works well, easy to maintain and good support. I think > donations welcome. Well worth it. It stores repositories slightly > differently than traditional SVN repositories are typically configured, but > gives you a simple GUI for managing them. Nothing odd, just makes good use > of SVNs capabilities via the auth files. Much less messing with Apache > config files, etc. Once installed, you can choose to use Windows (I did > not see what type of server you are using, assume Windows) or SVN > authentication. > > We installed it to use https. Visual SVN comes with its own Apache build, > etc. so it is self contained and point and click to install. This was nice > as we did not want to make some changes to our servers Apache > configuration for various reasons (mainly to do with version installed). > > As a note: be sure to set it up on a server that would be "first" to be > brought back online in the event of an emergency. Usually, prod is the one > first brought up and most likely to be hosted somewhere safe. Not always, > but often. You want that repository safe and available. > > As another note: SVN should not be treated as a 'backup' tool. Typically, > only version non-binary files unless you have a specific need to version > binaries. They do not take advantage of SVNs ability to store large of > amounts of changed data economically. > > One other pattern that is very good to develop is the SVNUpate before any > SVNCommit. Will stop many of the conflicts, especially in team > environments. I SVNUpdate several times a day and it is important that > teammates tell each other when the commit significant changes. I and > another guy one time spent a lot of time working on the same query, then > conflicted on commits. Better communication would have had working on other > areas. Sad to say, his was better than mine, so he won the conflict > resolution. > > For us, getting everyone on board moving from VSS to SVN was tough, took a > year. Most people could not grasp not 'locking' the file on which you are > working. Eventually people get it and I love SVN style verson control. > Good luck. > > Gary McNeel > > > On Fri, Jan 8, 2010 at 8:12 AM, Mike Demahy <[email protected]>wrote: > >> I have started using subversion. Thanks to Ken Auenson. I have been >> working with him on a project and we are using Subversion to manage the >> code. I can definitely see the benefits of using it. >> >> >> >> I want to set-it-up with my existing projects. And I would like some >> advice on the best practice. >> >> >> >> I have several projects that I maintain. I want to setup each project >> with its own repository. I want to be able to promote my changes to >> production with subversion. >> >> >> >> I currently develop on my laptop then upload to development and finally >> production when ready to release my changes. >> >> >> >> I am thinking of setting up the repository on the development server. I >> can update the code one my laptop, commit those changes to the Development >> server when I am ready to test them. Then when I am ready to release the >> changes to production, I can promote the changes to production from the >> repository. >> >> >> >> Finally my question, is this the best way to set up the Repository? >> >> >> >> I would appreciate any suggestions >> >> >> >> Thanks, >> >> >> >> Mike Demahy >> >> -- >> You received this message because you are subscribed to the "Houston >> ColdFusion Users' Group" discussion list. >> To unsubscribe, send email to [email protected] >> For more options, visit http://groups.google.com/group/houcfug?hl=en >> > > > > -- > Gary McNeel, Jr. > 713-962-0885 > > -- > You received this message because you are subscribed to the "Houston > ColdFusion Users' Group" discussion list. > To unsubscribe, send email to [email protected] > For more options, visit http://groups.google.com/group/houcfug?hl=en >
-- You received this message because you are subscribed to the "Houston ColdFusion Users' Group" discussion list. To unsubscribe, send email to [email protected] For more options, visit http://groups.google.com/group/houcfug?hl=en
