Hi Guys
I started a small development company a few months back. Up until now we
didn't need any version control, but we've gotten to a point now where it is
absolutely necessary. I want to do something very specific with Subclipse
tailored to our environment, but what we want doesn't seem to work.
We create PHP database driven websites and administration interfaces.
Theoretically we have 2 main lines of development - one for the actual
"client" project itself, and one for our company's base/helper classes. The
base/helper classes are used by all client projects, and consists of things
like a User Login class, database abstraction classes, etc.
Every time we develop a project, the base classes are improved. New features
are added and sometimes older features are improved or even removed. At this
stage the base classes are stored in a central location which all projects
access via a symlink. This is BAD. If we improve a feature in the base
classes (maybe remove a function parameter not needed anymore), we run the
risk that we might break entire projects (because of the symlink projects
always have access to the latest base classes code)
The idea was that we create a repository looking like this:
SVN Repo:
--- BaseClasses
|--- trunk
--- Projects
|--- Client1Project
|--- Client2Project
When a developer creates a new client project, he creates the project in
Eclipse. Using Team->Share Project he commits the initial stuff to the
repository. After that he must be able to check out the base classes into
his working copy, into a directory (like "include" for example). If he makes
changes to the base classes, he should be able to commit those changes back
to the "BaseClasses" directory in the repository - without committing his
entire project. But when he does commit his entire project, the project will
also include the "include" directory. In other words, his committed project
will include the baseclasses as they were at time of development.
The idea is that a year down the line, we can check out the client project
(which will then also check out the "include" directory, which is "old").
The developer can then also check out the latest revision of BaseClasses
into his workspace's "include" and check the diff information to see how
this will affect existing client code.
I want to do things this way because I can see us running into a situation
where ClientProject1 works fine with revision 1456 of the BaseClasses, but
totally breaks with revision 1782 of the Baseclasses. Doing things this way
allows us to mix and match different parts of our develepment cycle, and
allows us to keep "legacy/backward compatible" code down to the minimum in
the BaseClasses.
But unfortunately things doesn't work this way. Since Subclipse binds an
entire project to a location in the repository, you can't just commit 1
directory to a different location.
My question is: is this possible? I'm pretty sure a lot of developers ran
into this situation before, especially if they do DLL development (or just
about any project that uses shared libraries). Is my approach wrong?
I should also mention that I don't know CVS at all, in my searches on this
topic one guy did mention that CVS can be very flexible. Should we switch to
CVS to get what we are looking for?
Thank you for your time (and patience with this long email).
Werner
Received on Sat Apr 21 13:37:32 2007