I started by just writing an application and as I wrote the app I
realized that the search functionality could be extracted pretty
easily. So, I created a Subversion repository for the engine itself
and removed the engine code from my app.
The repository has 2 top level directories:
/indexed_search_engine (the engine)
/searchable_app (a sample application that I use to test and continue
development)
In the searchable_app, I have a symlink from
vendor/plugins/indexed_search_engine up to the top level directory.
This allows me to make changes in either the top level or within the
sample app itself without having duplication.
For my next application that uses the engine, I’ll just treat it like
any other external code by getting the version I want and installing
it.
Not sure if this really answers your question or fits your scenario…
/indexed_search_engine (the engine)
/searchable_app (a sample application that I use to test and continue
development)
In the searchable_app, I have a symlink from
vendor/plugins/indexed_search_engine up to the top level directory.
This allows me to make changes in either the top level or within the
sample app itself without having duplication.
For my next application that uses the engine, I’ll just treat it like
any other external code by getting the version I want and installing
it.
Thanks for the response Lance…
That seems very brittle to me. For instance, I develop across OSX and
XP. Symlinks aren’t too portable, or flexible. Yes I know you can
symlink on NTFS, but I’m kind of trying to avoid it.
Additionally, if you setup your projects like you mention it seems to me
like it’ll be hard to make changes on your next application to the
engine, then bring it back into the first.
And the plugin will be added to your system. The -x flag signifies to do
an
svn:externals on that plugin instead of doing an export and loosing
track of
what revision the central engine repository is at.
Now, whenever you update your project root, it will update the
svn:externals
which are hooked into your plugin.
With tools like Eclipse, and tortoise, if I modify a externals and have
the
same username which is used for the project itself, SVN will update the
externals perfectly. This may be just a benefit of my environment, but
it
should hopefully work the same for you.
For your first ‘engine’ I’d recommend following Jon’s instructions on
the wiki - first, build your application as normal, then move anything
you’ve added to the ApplicationController or ApplicationHelper classes
into modules, and move the files over.
When I’m developing the login and user engines (and our internal
engines), we have a repository for engines, and another set of ‘test
projects’ (similar to what Lance describes) used solely for the
development and testing of the engine. We then use svn:externals to
include the engines in our actual client applications.
While you can certainly make changes to engines and commit them
directly back to the repository (and then update the other project to
merge the changes there), this can get a bit messy, and certainly
wouldn’t be recommended if you started needing to manage versions of
your engine. Here at my company we use SVN tag versions (which
shouldn’t be committed to) in running applications, and only the test
projects have svn:externals links to actual development branches or
the trunk.
While you can certainly make changes to engines and commit them
directly back to the repository (and then update the other project to
merge the changes there), this can get a bit messy, and certainly
wouldn’t be recommended if you started needing to manage versions of
your engine. Here at my company we use SVN tag versions (which
shouldn’t be committed to) in running applications, and only the test
projects have svn:externals links to actual development branches or
the trunk.
Barring my switch to SVN from Perforce, I might try this same approach,
branching my engine into each project, then integrating changes back
into the engine “trunk” when necessary. Good idea.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.