[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Suggestions for Repository layout

From: William Nagel <bill_at_stagelogic.com>
Date: 2005-10-14 01:08:45 CEST

Hi Andrew,

> Hi,
>
> This is more of a generalist question to validate my
> proposal for a new repository layout - I hope that it
> is not misplaced.

No, not at all.

>
> I have installed Subversion 1.2.3 using Apache 2.0-
> WebDAV as the repository/server.
>
> I am working on a project that is a relatively complex
> system integration exercise involving a number of
> different vendors' products, and also some custom
> bespoke development. In some cases third party vendor
> products require customisations. The architecture of
> the project is an n-tier web based system.
>
> We want to be able to store vendor releases in the
> repository, so I have proposed having separate
> repositories for each vendor, and using the 'tagging'
> concept described in the Subversion manual to create
> immutable versioned releases.
>
> All customisations and bespoke development work will
> go into a separate repository (call it CUSTOM for
> arguments sake).

So far so good. You wouldn't necessarily need to use multiple
repositories though.

>
> Where there are custom developed components for a
> third party product I am proposing that an SVN
> external definition should be used to reference, and
> incorporate core product artefacts. This would enable
> a local working copy to contain a hybrid of core
> product artefacts and also customisations (the idea
> being that a single deployable unit could be built for
> release).

Makes sense, as long as customizations can be stored separate from
the core product. If the modifications to the core product need to
occur to core product file (or even just in core product directories)
then externals aren't going to work for you.

>
> One issue that I still have to resolve is the fact
> that there are a number of these components that I
> have described above that need to be baselined into a
> single coherent release.
>
> One strategy that I came up with was the concept of an
> integration project within the CUSTOM repository. At
> first I was thinking of using SVN external dependcies
> yet again to point to the various other projects in
> the CUSTOM repository. However now I am not so sure
> whether this is goin a bit over the top, and it would
> be adequate to just perform a copy of each of the
> projects into the integration project.

As long as the proper layout can be created with externals, the
externals will make it easy to create new releases of an integration
project by just changing the revision of each component that is to be
included. That assumes, though, that the integration project can be
created without modifications to the included components. If you're
going to be modifying components after you integrate them
(essentially creating a branch of the component), then copying would
be better. Of course, I wouldn't suggest creating lots parallel
release branch paths for your components anyway. It would be a
nightmare to maintain. So externals are likely the best way to go.

-Bill

>
> I would appreciate any tips/pointers that any people
> might have.
>
> Thanks and regards,
> Andrew
>
>
>
> ____________________________________________________
> Do you Yahoo!?
> The New Yahoo! Movies: Check out the Latest Trailers, Premiere
> Photos and full Actor Database.
> http://au.movies.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 20 21:01:23 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.