[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: concerning repository storage type

From: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: 2007-10-22 15:31:07 CEST

> -----Original Message-----
> From: nav@ciklum.net [mailto:nav@ciklum.net]
> Sent: Monday, October 22, 2007 6:53 AM
> To: Andy Levy
> Cc: users@subversion.tigris.org
> Subject: Re: concerning repository storage type
>
> Thanks!
> But here is one more question:
>
> there are actually several sites we're going to work on, and
> these sites use some common components.
> Website1 = Solution1 = Project1 + Project2
> Website2 = Solution 2 = Project3 + Project2
>
> here Project2 is some common classes
>
> Taking this into consideration, it looks like both sites
> should reside in the same repository:
> Repository:
> Project1,
> Project2,
> Project3
>

<snip>

We're also using Visual Studio. I suggest that you consider referencing
your shared project as a compiled DLL rather than "sharing" the source.
When you have multiple teams working on the same shared code for
different purposes, one team is likely to break the shared code for
another.

I would create a solution for the shared project that has its own
associated test project(s), and when you need to update the shared code
for a "client" project, dedicate a resource to do so. Test it, build
it, put the DLL in some folder in SVN, and tell the other teams to
update their svn:externals definitions (which should be defined for
specific revisions).

If, despite the coordination durring development another project breaks,
they can fall back to the older version, thus reducing disruptions, and
giving breathing room to resolve those issues in controlled conditions.

I just tested that one can define svn:externals so that multiple sources
can be dumped into a single folder. This means that many shared
projects' DLLs can be dumped into a single library folder per end-state
project. Due to the nature of svn:externals, the decision to put the
common code in the same repository as all the other projects is
subjective (though I would do it that way).

Remember, that when you define the svn:externals property to point at a
specific revision (so you can go back and build at any point confident
that you're getting extactly the same output) and ensure the target
external folder is read-only (not committable by most people).

Good luck

--
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
Received on Mon Oct 22 15:31:30 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.