RE: development of externals?

> -----Original Message-----
> From: Kenneth Porter [mailto:shiva@sewingwitch.com]
> Sent: Monday, November 26, 2007 1:37 PM
> To: users@subversion.tigris.org
> Cc: Bicking, David (HHoldings, IT); Wolfgang.Stoecher@skf.com
> Subject: RE: development of externals?
>
> On Monday, November 26, 2007 10:45 AM -0500 "Bicking, David
> (HHoldings, IT)" <David.Bicking@thehartford.com> wrote:
>
> > I strongly encourage you to consider a binary compatability
> model for
> > shared code. Manage changes to the code like an
> independant project
> > and release binaries to the projects that use them. Those projects
> > can choose to use the newer version, and fall back if there are
> > problems. Of course, it all depends on how much disruption
> your teams want to accept.
>
> Or specify a repository revision, or use a tag, when
> referring to an external. If someone commits a change to the
> external reference, the explicit revision in the reference
> will "prevent the bookmark from moving".
> The effect is that the external references a known version,
> not the unstable HEAD.
>
> This allows each client project to control which version of
> the shared code it will use, and to upgrade only when it's
> safe to do so.

Specifying a revision is problematic as well
(http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=7016
5). When you commit a change to the external project, then update it,
you "lose" your changes. This is why I suggested the binary references.
At the moment, I feel externals should be used either for read-only
source or for head revision reference with everybody understanding the
consequences.

My feature requests from the referenced message still stand :)

--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org