Forum: Ruby on Rails svn and ruby structure

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Craig W. (Guest)
on 2006-03-10 01:12
(Received via mailing list)
I just set up svn and did a checkout.

When I set up the repository, I did an import of the entire base
directory of the rails application which was great because it allowed me
to do a checkout on to my computer with everything.

Of course, now on my home computer, I've got a changed database.yml and
environment.rb and the log files (because I've been running a copy on my
home system), and I would suspect that I really only want app and public
directories (though the doc and plugins would be nice to manage with
svn).

I am not at all familiar with svn. I've changed some view code and some
controller code and I don't want to 'commit' until I've protected some
of the other files.

Is it better to just create separate repositories for app and public
directories or is there a way to tell svn to exclude config, root level,
and log folders while keeping the whole enchilada? I ask because as I'm
reading the svnbook.red-book.com stuff, nothing is jumping out at me.

Craig
Tom M. (Guest)
on 2006-03-10 01:24
(Received via mailing list)
check in two database.yml files:

config/database.yml.home
config/database.yml.vps

Then, in each environment, symlink to the correct version.

You'll also likely want to investigate svn:ignore to prevent
Subversion from continuously reminding you of the symlink. :-)

--
-- Tom M.
Craig W. (Guest)
on 2006-03-10 01:30
(Received via mailing list)
good - thanks...

I kept looking for 'lock' and 'ignore' sounds much better.

Thanks - that seems to be what I was looking for.

Craig
Erik van Oosten (Guest)
on 2006-03-10 01:57
(Received via mailing list)
You could also consider creating more database configurations in
database.yml.
e.g. development.home, development, test.home, test, etc...

     Erik.

Tom M. schreef:
Tom M. (Guest)
on 2006-03-10 02:03
(Received via mailing list)
Come on, Erik, that's *too easy*. :-)

This is a far smarter plan than what I suggested.

--
-- Tom M.
François B. (Guest)
on 2006-03-10 05:32
(Received via mailing list)
2006/3/9, Craig W. <removed_email_address@domain.invalid>:
> Is it better to just create separate repositories for app and public
> directories or is there a way to tell svn to exclude config, root level,
> and log folders while keeping the whole enchilada? I ask because as I'm
> reading the svnbook.red-book.com stuff, nothing is jumping out at me.

This is a single project, hence it should be a single repository.

Your post prompted me to write a large essay on Subversion usage within
Rails:

http://blog.teksol.info/articles/2006/03/09/subver...

Since you need help with Subversion, would you read it and tell me
what you think ?

Thanks !
Craig W. (Guest)
on 2006-03-10 05:41
(Received via mailing list)
On Thu, 2006-03-09 at 22:29 -0500, Francois B. wrote:
> http://blog.teksol.info/articles/2006/03/09/subver...
>
> Since you need help with Subversion, would you read it and tell me
> what you think ?
----
since I live in fame now on your blog...you betcha

this paragraph is in there twice...
***
The most common problems Rails developers have with versioning their
project are the config/database.yml file and log/ folder. Personally, I
have found that doc/appdoc/ and doc/apidoc/ sometimes gets in the way.
More on that later.
***

where were you 12 hours ago? You actually answered an svn question that
I have asked another list since I didn't want to bother this list with
svn questions.

this looks exactly like what I needed, I may even start over just to
track your page and get a little cleaner with my structures at the very
outset.

It is awesome - I can't give you specific critique until I step through
it which may be this weekend.

thanks

Craig
This topic is locked and can not be replied to.