RE: Revisions of external folders

I am not wanting to put my drive images into the repository so much as to
put them in a central location (e.g. a drive image server). As you
describe, the reference info is what is stored in the repository. Our info
will describe the configuration, but also identify the drive image and
machine used to test and certify the build as ready for promotion to the
next release state (alpha, beta, gamma, final). If necessary, this will
provide a strict "forensic-quality" recreation of a certain software and
hardware state. This is really necessary to minimize heisenbugs
(http://www.hyperdictionary.com/dictionary/heisenbug) in a Windows/VB/COM
development enviroment (I know, don't tell me, your environment/language
doesn't have these problems ;o) ).

Nick Seigal

-----Original Message-----
From: Reinhard Brandstädter [mailto:r.brandstaedter@gmx.at]
Sent: Sunday, January 16, 2005 9:21 AM
To: users@subversion.tigris.org
Subject: Re: Revisions of external folders

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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org