On Friday 14 January 2005 23:22, Nick Seigal wrote:
> 1) Treat our own shared libraries as internal releases of separate
> projects. Treat third-party libraries as described in the svnbook Vendor
> Branch section. Link both types to the main development project (the trunk
> or a release branch) via externals.
>
> 2) Treat our own shared libraries and third-party libraries exactly as
> described in the Vendor Branch section of the svnbook. Copy all libraries
> into the main development project (the trunk or a release branch). Collect
> updates in vendor drop and merge them into the main project as needed.
>
> I am leaning towards (1) because it allows me to keep my sanity and reduce
> duplication and merging. We do not plan to modify the code of these
> libraries outside of their own repositories, so we don't need the
> additional redundancy to protect ourselves. The trunk/branch/tag structure
> in the repository for each library provides that security, as well as (in
> tags) all the key points in the past development that we need to be able to
> go back to. I am concerned about some the limitations of externals, but
> believe the design we are considering and the available tools (e.g.
> svncopy) can handle these.
I'm absolutelys with you in this point. Method 2 needs much more effort to
keep track of vendor libs and bears the problem of keeping track of them in a
central location.
If all devel projects use one vendor/internal lib repository via externals
it's easy to check/control which projects use which libs. You could just only
provide read access to exactly one lib so there is no way that different libs
are used by different projects
> To handle the issue of changes to the development/testing environment, we
> are *considering* putting a drive image into Subversion as well, and
> keeping that with the particular release or milestone tag. I am pondering
> whether to store these images in all the trunk/branches/tags or only in the
> release/milestone tags (or something else?). One issue is: whose drive
> should we consider cannonical? It will probably be the primary test drive
> image.
Well I don't intend to store a complete drive-image in the source repository
because of it's binary sizes - although I like the idea in some way.
What we do is getting the test- and build-system specification in a text file
(build log) and save this in the repository. Of course this doesn't work for
all kinds of development (for the Java platform it's quite OK I think)
Cheers,
Reinhard
--
Reinhard Brandstaedter
Wiener Str. 28 phone: 0043 699 12419541
4020 Linz icq: 73059068
Austria email: r.brandstaedter@gmx.at
- application/pgp-signature attachment: stored
Received on Sun Jan 16 18:23:32 2005