This seems like a non-trivial use case. I am in that situation and have
been on every coding project in the last 5 years.
Who doesn't use libraries? Usually we use both our own libraries (modular
programming as a professional standard as well as team logistics requires
this) and those of various third parties.
Who doesn't need to recreate the exact earlier state of an application for
bug fixing? The problem with this is that to be *totally* safe and
identical, one would have to image the development and/or testing
environment at that point too. Different OS versions or patches will lead
to different results, as will versions of related applications (e.g. web
browsers).
I am trying to evaluate the use of one of the following two strategies to
handle these issues:
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.
My solution to Alex's problem is that a tag of my project containing
externals should only be containing externals pointing at other tagged and
unchanging repository codelines. These should never be changed or deleted
(hance the idea of a "tag"), and I can insure this, since we maintain our
own vendor-library and internal-library branches and their policies (see
above). In fact, the discussion of a "read-only tag" seems strange, since
this seems to be the only thing that really seperates a tag from a branch.
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.
These issues *must* come up for the open source community all the time...Am
I making any sense? Any thoughts anyone?
Nick Seigal
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Alex R. Mosteo
Sent: Friday, January 14, 2005 8:58 AM
To: users@subversion.tigris.org
Subject: Re: Revisions of external folders
Reinhard Brandstädter wrote:
(snip)
> If this is the behavior of subversion in the current implementation
> this
> means:
> Definitely "freezing" a repository (meaning checked out tags are always
> identical even if the referenced external repositories change) with
external
> definitions by tagging it only works if external properties are set with
the
> -r option or also freezed tags of the external repositories are used.
Yes.
> A use case:
> We have a repository for a project; If we do a release or beta build
> the state
> of the repository trunk is tagged. Now we use externals pointing to
another
> repository (libraries). If I want to do a rebuild of the tagged project
later
> on I can't ensure that the build based on the checked out tag will be
> absolute the same as tat the time the tag was made since the
lib-repository
> might have changed. This is the case unless you used the -r option on the
> external property or point to a (read-only) tag.
That's exactly what I want. I store versions of my project and want to
be able to check these out and compile out-of-the-box, pulling the
needed libraries at the revision they were when the tag copy was made.
But as I said before, when doing a tag copy I see that the svn:externals
property is missing in the copy. So there's a extra step to do to
migrate the properties. Can someone please confirm this?
I've given a second read to the svn book and I see nothing helpful in
the svn:externals section. The point on vendor branches seems to address
this problem, but I don't want to have several copies of my own
libraries in several repositories :(
Regards,
A. Mosteo.
---------------------------------------------------------------------
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 Fri Jan 14 23:25:36 2005