Okay...
There are two things you can do here:
1). Use externals which allow you to specify a specific release of the
sub-system for your product.
For example, you have a sub-system called "libc" with a URL of
http://subversion/svn/subsys/libc/trunk and a project of
http://subversion/svn/project/foo/trunk.
In this scenario, you'd have a directory
http://subversion/svn/project/foo/subsys. On this, would be a property of
svn:external which would be set to:
libc http://subversion/svn/subsys/libc/tags/REL-1.0
That way, your trunk is using REL-1.0 of this subsystem. When a new release
gets approved, you can change this attribute to point to the next release.
You would never branch your subsys since you're basically keep improving
them and if there is a bug, you grab the latest release.
Notice you don't set svn:external to point to the trunk. This will always
give you the latest version on trunk, but then if you create a tag, your tag
isn't frozen in time since the external will always be pointing to the
latest on trunk. Instead, externals should always point to a tag.
This also assumes that you are releasing the source code and not the
compiled componenent too.
2). Another method is not to use Subversion at all for releasing
sub-systems. Instead, you simply have the pre-built version readliy
available from a release repository. In your build system, you'd go to your
release repository and pull off the correct revision of libc (
http://release/subsys/com/elfdata/libc/1.2) and pull off the latest revision
of libc.
We do this using Nexus which is a Maven release repository. However, we use
this for both Maven and non-Maven projects. We can use the <get> in Ant to
pull off the correct release, or use curl or wget in Makefiles.
We find this an easier way to distrubute built sub-systems (like a libc.so
file) rather than using Subversion for the task.
On Mon, Jun 1, 2009 at 4:14 PM, Theodore H. Smith <delete_at_elfdata.com>wrote:
> OK, let's try to explain this a bit better.
>
> In our software, there are different bits of code.
>
> Some are user interface. Some are sub-systems.
>
> Now... as you can imagine, sub-systems are the kind of thing you
> usually want to have the latest version of, at least if they have well
> defined behaviours. There are behaviours that are simply wrong, or
> that are simply right.
>
> It's sort of like having the latest version of "libc" in your linux
> app. If there's a fix in libc or a new feature to let it malloc
> slightly more RAM or faster or access more file systems... you usually
> want that newest "libc" in, even in an old release of the app.
>
> So, let's say there is a "library" component to our web app that
> should be updated on all branches.
>
> Can that component alone be shared between branches? And be done
> automatically? I mean svn should help us, not become an awkward tool.
>
> Also, what about .htaccess files that must be different across the
> same version, same branch, but we still actually need to track them
> because they are complex?
>
> Or maybe that .htaccess file problem could be solved by pulling out
> the complex and server-consistant stuff and putting it into a file
> that is called by .htaccess?
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2357974
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_subversion.tigris.org].
>
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2358058
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-01 22:37:11 CEST