Hi all, I would be interested in your version control - best practises, especially when using Subversion. I have just created a repository and uploaded a Rails-Project. Being new to Subversion I asked myself several questions: - how to handle log files: they shouldn''t be versioned, IMO each checkout should always give empty logs, so one can start working immediately, but they should never be commited to the repository (just makes the repository bigger for no practical reason) - how to handle configs (which are different on public server and localhost, for example database.yml or environment.rb) - how to transfer from the repository to the public server: do you do just a normal checkout (which includes all the .svn-directories), a svn export (which generates a clean directory tree) or a rsync (or other upload-method) from your working copy. IMO svn co would be very fast (only transmits the differences), while svn export and rsync (with --exclude-params) can get rid of the .svn-directories. With rsync it would also be easy to leave out directories like ''test'' which are not maybe not necessary in production. Maybe a matter of taste... What''s your opinion? If you have another tips for efficient version control in RoR-projects, I would also be happy to hear them! Thanks for your suggestions, Michael _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
I''m new to svn as well, but I''ll share the practices I''ve picked up. - Log files: I import empty log files initially, and then just ignore those files when they''re checked out so I never check them in. This could also work with Config files. - Deployment: I use svn export, but only because I''m on a shared host where it''s all the same server. I export to a new directory with the revision number ''app-32'', then change my symlinks if the tests pass. I''m thinking of using Damage Control to automate some of this if I can, but I''m not at that point yet. Oh yeah, trac absolutely rocks. Even if this is not a public app, it helps to have a ticket system integrated with your source. You can create milestones for roadmaps, map tickets to them, and then see how close you are to reaching that milestone. Finally, Tobi has some tips on how he does deployment: http://blog.leetsoft.com/articles/2005/02/14/deployment. I''ve been meaning to use that script for awhile actually. On 4/12/05, Michael Raidel <michael.raidel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi all, > > I would be interested in your version control - best practises, especially > when using Subversion. I have just created a repository and uploaded a > Rails-Project. Being new to Subversion I asked myself several questions: > > - how to handle log files: they shouldn''t be versioned, IMO each checkout > should always give empty logs, so one can start working immediately, but > they should never be commited to the repository (just makes the repository > bigger for no practical reason) > - how to handle configs (which are different on public server and > localhost, for example database.yml or environment.rb) > - how to transfer from the repository to the public server: do you do just > a normal checkout (which includes all the .svn-directories), a svn export > (which generates a clean directory tree) or a rsync (or other upload-method) > from your working copy. IMO svn co would be very fast (only transmits the > differences), while svn export and rsync (with --exclude-params) can get rid > of the .svn-directories. With rsync it would also be easy to leave out > directories like ''test'' which are not maybe not necessary in production. > Maybe a matter of taste... What''s your opinion? > > If you have another tips for efficient version control in RoR-projects, I > would also be happy to hear them! > > Thanks for your suggestions, > > Michael > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-- rick http://techno-weenie.net
Hi! On Tue, 12 Apr 2005, Michael Raidel wrote the following:> - how to handle log files: they shouldn''t be versioned, IMO each checkout > should always give empty logs, so one can start working immediately, but > they should never be commited to the repository (just makes the repository > bigger for no practical reason)use "svn propedit svn:ignore log/" and enter "*.log" to ignore all log files Wolfgang
Hi, Here''re my proposals: "- how to handle log files:" As Rick already wrote, you should just check in empty logfiles into your repository. "- how to handle configs": I handle my differnet configuration files with symbolic links. Let''s say you have to support three different enviroments: dev, test, prod. Then you could have three config files config_dev.yml, config_test.yml and config_prod.yml, but just one symbolic link named config.yml which points to the appropriate enviroment config file. (You can also use a kind of symbolic links (not shortcuts!) on windows with a tool called "Junction Link Magic") "- how to transfer": i don''t know SVN very well, but there should be a "clean" checkout option. Then you could tar this "clean" project for upload, uncompress it (and set the "current" link to this new dir) Cheers Kaan -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.9 - Release Date: 13.04.2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.9 - Release Date: 13.04.2005
- handling configs: This can get tricky. For instance, I checked out the Hieraki source, but it wants to check in any config changes I make, or it includes them in any patches. This also goes for small tweaks made to CSS stylesheets, views etc. I may not necessarily want to contribute my changes to the project (for instance, if I want a custom design). - Deployment: This is a clean checkout option in subversion, it''s called Export. The only thing is, you''re downloading the whole project each time. Doing an update is potentially more efficient (especially if your project has images/flash pieces, etc). On 4/15/05, Kaan Karaca <email-5nOTh4PAjpOELgA04lAiVw@public.gmane.org> wrote:> Hi, > > Here''re my proposals: > "- how to handle log files:" As Rick already wrote, you should just check in > empty logfiles into your repository. > "- how to handle configs": I handle my differnet configuration files with > symbolic links. Let''s say you have to support three different enviroments: > dev, test, prod. Then you could have three config files config_dev.yml, > config_test.yml and config_prod.yml, but just one symbolic link named > config.yml which points to the appropriate enviroment config file. (You can > also use a kind of symbolic links (not shortcuts!) on windows with a tool > called "Junction Link Magic") > "- how to transfer": i don''t know SVN very well, but there should be a > "clean" checkout option. Then you could tar this "clean" project for > upload, uncompress it (and set the "current" link to this new dir) > > Cheers > Kaan > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.9.9 - Release Date: 13.04.2005 > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.9.9 - Release Date: 13.04.2005 > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- rick http://techno-weenie.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rick Olson wrote: | - handling configs: Default config files should be named with a .default extension. Make changes to it that belong in the public repository, but then copy it without the .default extension for your own local use; and then add it to the svn ignore list. That way, svn ignores the copy that has your database password, but does have a generic copy that you can add default values or documentation to. - -- David Morton Maia Mailguard server side anti-spam/anti-virus solution: http://www.maiamailguard.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCX/tjSIxC85HZHLMRAsTvAJ9AgAVh+/ctCn+chMyzQSwzfTvzQACfb2WA IkGJ3vHc5QmbUeun9519Ioc=1Fl0 -----END PGP SIGNATURE-----