"Brad Rhoads" <bdrhoa@gmail.com> wrote on 03/12/2007 01:30:24 PM:
> Look up "externals".
>
> On 3/12/07, Luke.Powell@bjservices.com <Luke.Powell@bjservices.com>
wrote:
> > If I have several projects A, B, and C that depend on a common project
Z,
> > is there a way to manage that dependency? I'd like to do a kind of
> > "symlink" where checking out or updating the trunk of Project A would
also
> > check out the current version of the Project Z trunk as a
subdirectory. It
> > seems from the FAQ that that kind of functionality isn't present right
> > now. If that's the case, what kind of conventions and structures are
> > usually used for managing this very common coding idiom?
> >
> > Many thanks,
> >
> > Luke Powell
> > Project Engineer
> > BJ Services
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
Brad, thanks for the pointer, externals look to be the concept that I need
to pursue. How are releases and tags usually handled with the externals
system? If we release software, we want to be able to rebuild from the
same source, but it seems that there's no great way to "pin down" the
external revision without modifying the property manually. Is that what is
usually done?
e.g.
Project A has Project Z as an external. When copying Project A's trunk to
a tags folder, would I normally manually copy Project Z underneath it in
the repository and remove the svn:externals property from Project A?
Alternately I could leave the externals definition and explicitly specify
a revision number in the property. Is one of these the way these tags are
customarily handled?
Thanks again,
Luke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 12 20:22:47 2007