A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I have a question about the best way to organise source control for my projects. I've used subversion for a couple of personal projects but I'd like to introduce it into my workplace now. Basically its for organising web development projects. I am the sole developer at the moment so there will be no crossover or shared source for these.
I have a CMS I've built which forms the basis for every project I do. The CMS is installed for each project and is used to add pages and build the site up. The CMS is often extended in various ways bespoke for each client (for example to add functionality to control products or customer data) but the core of it stays the same except for bug fixes and refactoring.
I've been advised by a friend who uses SVN to set this up as the main project, then branch it off for each separate web project. As the CMS goes along with the website, I'd want to put my web project and a copy of the core CMS into this branch to control the source for the project, then any changes I do to the core CMS code while building one of these websites on a branch, I would want to merge back into the trunk so that I always have the latest version ready to start a new project, or to update the core functions of another site.
I've been trying to set this up but I'm running around in circles and getting lost so if anyone who understands SVN and can understand what I've tried to explain here can guide me I'd be grateful. I'm using SVN on Windows with TortoiseSVN. I'm not familiar with the command line interface.
Any help appreciated
Tuesday, July 12, 2005
I don't think there's anything about what you're doing that's really specific to Subversion. It's just deciding basic repository structure for version control of your projects. What you're describing sounds fine. But you may want to clarify some concepts for yourself by reading Eric Sink's excellent Source Control HowTo, especially the chapters on branching and branch merging: http://software.ericsink.com/scm/
And also take a look at TortoiseSVN's excellent help file, if you haven't already, since that has a good discussion of various ways of structuring repository to accommodate multiple projects.
We're going through the same struggle at the moment -- we've just really started using Subversion "hard-core" after setting it up over a year ago. We decided it was too time-consuming to migrate legacy code from our old VSS repository, so only new projects get added to SVN, and we're finally getting to where some of our "shared" components need to be migrated to SVN.
I don't like the idea of the shared component being the main "trunk" branch with offshoots for each dependent project. It might make sense for your project, but for us it makes no sense with the way we organize things.
An idea I had today (but havent yet tried out) is to keep the shared components in their own branch(es) and "tag" them into each project that uses them. We can keep developing on the shared components (in their own branch), but have a known tagged version in the other dependent projects. When the dependent projects are ready for an upgrade to the latest version of the shared components, we can tag the latest version into the projects (or merge them into the existing tag) tree and use it instead.
I'm not sure it will work, and I don't have time to try until the weekend. I'll post back and let you know how it goes.
Alternatively, because of the way we use our shared components, we don't even really have to deal with sharing the source, as we use functionality direct from the binaries of the shared components and don't need the source. But ... the minute we say we don't need the source, we'll have to make a minor tweak for one single application (isn't that the way it always goes! <Grin>)
I'd recommend you grab a copy of "Pragmatic Version Control with Subversion". It's a short read and covers topics like this.
There's two ways you can approach this particular setup. Both of them assume you've got an independent subversion directory for the code you're going to share. Set this up with the standard trunk / branches / tags layout you would for any other project. Make sure to tag releases of the shared library ( you are doing tagged releases for internal components too, right? )
When you create the project that uses the shared component, do an svn copy to copy the shared project's source into your new project. Start from a tagged release so that you know exactly what you're getting. This just references the orginal files, so you won't be wasting space in the repository.
This layout will not automatically pick up changes checked into the original project. This is generally a good thing if the shared project is churning too. To grab updates to the shared project, use the SVN MERGE command to grab the changes between the version you started with (which is why you really want a tag for the one you started from) and the current release.
The other option is to use what SVN calls an "external". It's essentially a reference to another part of the source tree. Externals aren't automatically updated in working directories, so you'll have to manually do an SVN UPDATE, but it's a quick and easy way to share stuff.
If you only need to share binaries, then have the shared project check in the working versions into a separate "projbin" directory or something. Then do the svn copy or external approach as you desire.
Just go get the book. It explains all this a lot better than I do.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz