I know this is a regular topic, but I've had a look round and can't find
any previous emails that really address the same issue (at least not
easily)
We've got a product suite that contains a number of individual programs,
which can be released individually. Obviously, as with most projects,
there are a number of shared files used by all the products. My problem
is that I'm struggling to determine the best way to organize the
repository in such as way that the branching of the projects is least
painful.
We'd need to cater for the ability to branch some components for an
individual release, and allow developers to easily go back to a previous
version of a specific component for bug fixes. This is made more
complicated by the shared code, which would obviously have to be
branched every time a component was branched.
If the suggested repository structure is followed, then we would have
something such as the following
/svn/repos/root/projectA
.../trunk
.../branches
.../tags
/svn/repos/root/projectB
.../trunk
.../branches
.../tags
/svn/repos/root/shared
.../trunk
.../branches
.../tags
If we release projectA, we would have to branch projectA and also branch
shared, but as they're going to separate destinations, they'd have
different revision numbers. So for a developer to fix a bug, he'd have
to create a top level directory, check out the required branch of
projectA into that and then checkout the required version of shared.
Both would be treated as separate working copies, and I'm not sure this
would really flow with the developer.
The alternative approach would be to place the trunk, branches and tags
directories above the project levels. This would make it easier from a
management point of view, in that everything is controlled from a single
root point. However, you then get the issue (if it is an issue) that
creating a branch for a release of projectA would also include the files
of projectB at that point in time, which could be in any sort of state.
I realise this is a cheap copy, but if a developer were to checkout a
branch for bug fixing projectA, they would also get the unnecessary code
for projectB.
Has anyone got any experiences of dealing with a code structure like
this that can offer some insight to the advantages of different
approaches
Thanks
Jason
IMPORTANT NOTICE
If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to the statement below or contact the sender.
This communication is from Deloitte & Touche LLP. Deloitte & Touche LLP is a limited liability partnership registered in England and Wales with registered number OC303675. A list of members' names is available for inspection at Stonecutter Court, 1 Stonecutter Street, London EC4A 4TR, United Kingdom, the firm's principal place of business and registered office. Deloitte & Touche LLP is authorised and regulated by the Financial Services Authority.
This communication and any attachments contain information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of disclosure, distribution, copying or use of this communication or the information in it or in any attachments is strictly prohibited and may be unlawful. If you have received this communication in error, please return it with the title "received in error" to IT.SECURITY.UK@deloitte.co.uk then delete the email and destroy any copies of it.
E-mail communications cannot be guaranteed to be secure or error free, as information could be intercepted, corrupted, amended, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept liability for any such matters or their consequences. Anyone who communicates with us by e-mail is taken to accept the risks in doing so.
When addressed to our clients, any opinions or advice contained in this e-mail and any attachments are subject to the terms and conditions expressed in the governing Deloitte & Touche LLP client engagement letter.
Opinions, conclusions and other information in this e-mail and any attachments which do not relate to the official business of the firm are neither given nor endorsed by it.
Received on Fri Feb 18 11:13:40 2005