If you have multiple projects that may edit the shared code I would recommend treating it as vendor code: http://www.visualsvn.com/support/svnbook/advanced/vendorbr/
We do that with multiple in-house projects run by multiple departments and it allows us to share changes via merging. From: John Maher [mailto:jo...@rotair.com] Sent: Tuesday, January 08, 2013 12:37 PM To: C M; users@subversion.apache.org Subject: RE: Advice on handing common code I use the externals property for my common code. http://www.visualsvn.com/support/svnbook/advanced/externals/ ________________________________ From: C M [mailto:cmanalys...@gmail.com] Sent: Tuesday, January 08, 2013 11:43 AM To: users@subversion.apache.org<mailto:users@subversion.apache.org> Subject: Advice on handing common code All, I am setting up a new repository and have a question on how to handle "common" code. Common refers to code which is shared across the multiple systems that we deploy. In addition to the common code, we also have system-specfic software (custom code). Given the typical SVN layout, what's a recommended way to manage this, especially when creating release tags? In this model, we include the /trunk/common_version1/application_1 ../../application_2 ./../application_3 /trunk/system1/application_1 ../../application_2 ../../application_3 /tags/system1/Rel_1 [where this may include the system1 apps plus common_version1/application_1 and application 3] ../system2/application_1 ../system2/application_2 ../system2/application_3 /tags/system2/Rel_1 [where this may include system2 apps plus common_version1/application_1, application_2 and application3]
