Hi Muhammad,
The short answer is 'each to their own' :)
I adopt the following rules.
1) Projects/modules released together stays together.
This helps in branching tagging etc. For example
a) A project with two modules (Client & Server) that can be
released independently of each other with their own version (tag)
numbers, should reside in their own
repository under a single directory (file system directory).
b) A project with two modules (Client & Server) that are
interlinked and must therefore be released together should be in one
repository with two directories
(svn directories inside single svn repository).
2) Shared Projects/modules in their own project.
a) As a good practise all shared projects/modules must be referenced
using externals from a "Tag".
b) This ensures consistency, supportability and reproducibility of
the dependent module, because the dependent module is referencing a
"tag" that should not be
changed.
c) It is best practise, where possible, to reference common
projects/modules as a library artefact, i.e. dll, jar. etc.
>> the problem in doing this with "CommonFiles" folder is that if I
create a branch of a module then I'll have to create branch of
"CommonFiles"
>> as well and thus will have to update the patch of Common Files to
point to the Branch "CommonFiles" folder. I'll have to do the same when
I re-integrate my branch
>> into trunk.
Your above concern must not arise as creating a branch of Module1
(Module1-branch) would continue to reference the "CommonFiles" in tag as
it should. Creating a branch of Module1 should not require you to create
a branch of "CommonFiles".
If you are changing CommonFiles as part of Moudle1 change then, yes, you
need to branch CommonFiles (CommonFiles-branch) and use
CommonFiles-branch in Module1-branch. When your work is completed you
need to promote the CommonFiles-branch to trunk and tag the new
revision. Refer to the new "CommonFiles-tag" in Module1-branch and test
it. Once testing is completed then merge your Module1-branch to trunk
and tag it. This process is standard practise to manage and promote
shared libraries.
Thanks
Lakshman
________________________________
From: Muhammmad Mateen [mailto:m.mateen_at_udld.biz]
Sent: Thursday, 29 October 2009 7:19 PM
To: users_at_subversion.tigris.org
Subject: Repository Structure
Hi guys,
I had a question about the recommended directory structure of my
repository in SVN. We've developed an ERP system which is composed of 12
modules. Each module resides in its own directory except there is a
shared folder "CommonFiles" which contain files shared by all modules.
It looks like as under:
CommonFiles
Module1
Module2
Module3
......
......
Module11
Module12
If I don't have this shared "CommonFiles" folder then the best structure
would be to index the repository by Project so that I'll have standard
"branch", "tag" and "trunk" folders in each module. But, the problem in
doing this with "CommonFiles" folder is that if I create a branch of a
module then I'll have to create branch of "CommonFiles" as well and thus
will have to update the patch of Common Files to point to the Branch
"CommonFiles" folder. I'll have to do the same when I re-integrate my
branch into trunk.
If I index my repository on branch folder then the problem is that I'll
be creating branch from the trunk for whole repository while need to
work on only one module. The same would be a problem when I need to tag
a release as the releases are done module wise.
I would appreciate if someone could suggest a better approach.
Regards,
_________________________________________
Muhammad Mateen
IT Controller
UDL Distribution (Pvt.) Ltd.
14-H, Block-6, P.E.C.H.S., Karachi-Pakistan
Ph: 111-555-444.
================================================================================================
EMAIL DISCLAIMER
This email and any attachments are confidential. They may also be subject to copyright.
If you are not an intended recipient of this email please immediately contact us by replying
to this email and then delete this email.
You must not read, use, copy, retain, forward or disclose this email or any attachment.
We do not accept any liability arising from or in connection with unauthorised use or disclosure
of the information contained in this email or any attachment.
We make reasonable efforts to protect against computer viruses but we do not accept liability
for any liability, loss or damage caused by any computer virus contained in this email.
================================================================================================
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2412865
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-30 00:47:46 CET