I thought I asked this question before, but now I can’t find it! Maybe I
didn’t succesfully navigate a capcha or something. So I’ll try again and
try to make the question simpler and more concise.
Let’s say I have an open source Rails project, being collaboratively
worked on by several developers at several different sites/institutions.
We have a common SVN for the code, of course.
But there are a few config files that are not common. databases.yml,
perhaps environment.rb, perhaps even some fixtures. In my case, I have
unusual other files that are not common, say some stuff in the directory
app/layouts/local. But this could apply even just to the standard Rails
config.
Individual developers at individual sites really want to keep those
'local’files in their own local svn—but still have the bulk of the
code in the main shared svn.
The fact that these files are scattered about the Rails hiearchy doesnt’
help–and the fact that some of them (ie databases.yml) are in a
directory that otherwise needs to be in the shared svn–makes it
downright tricky.
Have other people been in this situation? What solutions do you use? How
do you handle this? Any advice would be welcome!
I am contemplating some horrible rake tasks that assemble all this
‘local’ stuff for you and import/co them from your local svn, but the
details seem terribly complex.
I think you are bumping up against one of the fundamental limits of
svn, paired with a project which was not designed to be used with it.
As I’m sure you know, subversion allows you to do many creative
things–at the directory level. For files, it can get touchy.
First, there is a policy matter. Everyone is running their own
environment, and this environment needs to be portable. Everything
goes in one repository.
You don’t mention if you are *nix or m$. As usual, there is a
workable solution for *nix
Create a directory trunk/local_env. Inside trunk/local_env, create a
directory for every local environment. Depending on corporate
paranoia policy, these directories can be accessible only to their
owners.
Each file which is part of a local environment is made into a soft
link. That soft link in turn goes through trunk/env–a directory link
which is NOT part of the repository. Now anyone can potentially check
out the project with everyone’s environments, and can select which
ever they wish to use, by linking the single directory.
I have no idea what the equivalent might be in m$.
On Sep 24, 12:15 pm, Jonathan R. <rails-mailing-l…@andreas-
That’s interesting, thanks.
I am using Unix.
But I was hoping there was some solution that would allow people to keep
their local stuff in their OWN svn repo, instead of keeping it all in
the central repo.
But I’ll consider the solution you’ve proposed, I don’t entirely
understand it, but it does seem promissing.
Any other hints or suggestions from experience welcome as well.
Jonathan
Student wrote:
I think you are bumping up against one of the fundamental limits of
svn, paired with a project which was not designed to be used with it.
As I’m sure you know, subversion allows you to do many creative
things–at the directory level. For files, it can get touchy.
First, there is a policy matter. Everyone is running their own
environment, and this environment needs to be portable. Everything
goes in one repository.
You don’t mention if you are *nix or m$. As usual, there is a
workable solution for *nix
Create a directory trunk/local_env. Inside trunk/local_env, create a
directory for every local environment. Depending on corporate
paranoia policy, these directories can be accessible only to their
owners.
Each file which is part of a local environment is made into a soft
link. That soft link in turn goes through trunk/env–a directory link
which is NOT part of the repository. Now anyone can potentially check
out the project with everyone’s environments, and can select which
ever they wish to use, by linking the single directory.
I have no idea what the equivalent might be in m$.
On Sep 24, 12:15 pm, Jonathan R. <rails-mailing-l…@andreas-
database.yml is an ERB template, actually. So, you can add a line to
it to check if database.yml.local is present, and load it.
Same story with other configuration files (which are .rb, so it’s even
easier).
Btw, database.yml can look like this:
common: &common
adapter: mysql
encoding: utf8
host: localhost
socket: <%= %w[/tmp/mysql.sock /var/lib/mysql/mysql.sock
/var/run/mysqld/mysqld.sock
/opt/local/var/run/mysql5/mysqld.sock].detect { |f| File.exists? f }
%>
database: petstore_<%= RAILS_ENV %>
username: root
password:
development:
<<: *common
test:
<<: *common
production:
<<: *common
–
Alexey V.
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]
so why not tell the “big” svn to ignore the local_env directory and
let the individual developer checkout his/her local stuff into that
directory. It means having to do separate svn commands, but that
detail could be hidden away in a Rakefile. (I’ve done this with a
“tools” repository checked-out into a directory ignoring a “src”
directory and checking out a separate repository in ./src)
-Rob
On Sep 24, 2007, at 3:15 PM, Jonathan R. wrote:
understand it, but it does seem promissing.
owners.
On Sep 24, 12:15 pm, Jonathan R. <rails-mailing-l…@andreas-
Rob B. http://agileconsultingllc.com
[email protected]
Nice, that’s a good idea, thanks.
That probably solves the ‘individual files rather than directories’
problem nicely.
I still have an issue of having, in my particular application,
multiple ‘local’ directories. One in config, one in views, one in
controllers. But you really want the local people to be able to check
out and update and commit their ‘local’ stuff with one command. At first
I hoped to combine them all in one ‘local’ directory—local/config,
local/controllers, local/models, etc. But, especially with models, at
least in 1.8.4, it’s hard to add on a seperate models directory.
So maybe have a bunch of directories, but write some rake tasks up to
import/checkout/update/commit them all in one go?
Any ideas here?
Thanks very much for everyone helping me think this through.
Jonathan
Alexey V. wrote:
database.yml is an ERB template, actually. So, you can add a line to
it to check if database.yml.local is present, and load it.
Same story with other configuration files (which are .rb, so it’s even
easier).
Btw, database.yml can look like this:
common: &common
adapter: mysql
encoding: utf8
host: localhost
socket: <%= %w[/tmp/mysql.sock /var/lib/mysql/mysql.sock
/var/run/mysqld/mysqld.sock
/opt/local/var/run/mysql5/mysqld.sock].detect { |f| File.exists? f }
%>
database: petstore_<%= RAILS_ENV %>
username: root
password:
development:
<<: *common
test:
<<: *common
production:
<<: *common
–
Alexey V.
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]
SVK might be worth considering:
This way you could all have your own local repos and merge in from the
master
Example with Mephisto:
http://octopod.info/2006/8/19/managing-multiple-local-mephisto-repos-with-svk
On Sep 24, 6:15 pm, Jonathan R. <rails-mailing-l…@andreas-