development of externals?

[Wo...@skf.com]

Hello,

we have several files that are shared among several projects. Currently 
they live in a separate path and are linked to the actual software 
projects in the IDE.
Now I am thinking of using the externals-feature of SVN to make sure that 
everybody has the right (currently always: latest) version of the shared 
files without having to inform everyone, when to update the shared files.
But does this still allow to further develop the shared files from within 
one of our software projects? What is the best practice for working with 
externals, especially when thinking of also further developping the shared 
files? Is there a way of doing this without an additional test-project for 
the shared files?

thank you,

Wolfgang

RE: development of externals?

[Kenneth Porter <sh...@sewingwitch.com>]

On Monday, November 26, 2007 3:26 PM -0500 "Bicking, David (HHoldings, IT)" 
<Da...@thehartford.com> wrote:

> 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.

The issue in the link is ultimately the lack of clue that the external is a 
separate module with its own revision history, and must be managed as such. 
Requiring distribution by binary simply enforces this in a very visible 
way. The linked message thread suggests adding other visual indicators in 
environments (like Tortoise) that allow that to make it more obvious that 
an external is in a separate administrative "compartment" of code and 
should not be messed with piece-meal. Access to the external's source is a 
documentation convenience, not a license to modify it. If the external 
needs customization, it needs to be branched into the client project's 
space.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: development of externals?

["Bicking, David (HHoldings, IT)" <Da...@thehartford.com>]

> -----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)" <Da...@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

RE: development of externals?

[Kenneth Porter <sh...@sewingwitch.com>]

On Monday, November 26, 2007 10:45 AM -0500 "Bicking, David (HHoldings, 
IT)" <Da...@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.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: development of externals?

["Bicking, David (HHoldings, IT)" <Da...@thehartford.com>]

I can speak from the software development standpoint.  Shares, to which
svn:externals are similar, present a high likelyhood that changes made
to shared files will have a negative impact on other projects that share
those files.  This probability can be reduced with very good
communication, but you still run the risk of breaking another
application by changing something it expects to use.  
 
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.
 
--
David 


________________________________

	From: Wolfgang.Stoecher@skf.com
[mailto:Wolfgang.Stoecher@skf.com] 
	Sent: Friday, November 23, 2007 7:54 AM
	To: users@subversion.tigris.org
	Subject: development of externals?
	
	

	Hello, 
	
	we have several files that are shared among several projects.
Currently they live in a separate path and are linked to the actual
software projects in the IDE. 
	Now I am thinking of using the externals-feature of SVN to make
sure that everybody has the right (currently always: latest) version of
the shared files without having to inform everyone, when to update the
shared files. 
	But does this still allow to further develop the shared files
from within one of our software projects? What is the best practice for
working with externals, especially when thinking of also further
developping the shared files? Is there a way of doing this without an
additional test-project for the shared files? 
	
	thank you, 
	
	Wolfgang
	



*************************************************************************
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.
*************************************************************************