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

Need some guidance on architecting subversion directories when project modifies another code

From: Dan Nessett <dnessett_at_comcast.net>
Date: Wed, 18 Nov 2009 10:58:59 -0800

Hello,

I am seeking some guidance on what might be the best way to architect
the subversion repository directory structure in the following
situation. We use the mediawiki code base and modify it for some
special uses. We would like to upgrade to a new version of mediawiki
by creating a patch tool kit that we would then apply to the
continuing MW releases. This tool kit would change for each MW
release we bring over. We plan on retaining our specific
modifications and bug fixes to those modifications in a subversion
repository. However, since we will be bringing over tag versions of
the MW code, the development of our code base will not be continuous.
That is, we will bring over a tag of MW, patch it to add our
modifications, do some bug fixes while this version remains in
production and then (sometime before putting the next release into
production) bring over a new tag of MW. So, there is discontinuity
between our various versions based on the discontinuity between the
MW tag versions.

I can think of a number of ways to organize our repository, but this
seems like a common situation, i.e., following another code
development project and making local modifications to it. So, if
anyone has experience with a similar situation, I would appreciate
any advice how to organize our repository's directory structure. Some
particular questions are:

+ would it be best to have the MW releases at the top level and
create trunk/branches/tags underneath? Or should we use the
traditional trunk/branches/tags at the top and keep parallel project
directories underneath?

+ we will have to import a MW release and then add our changes. Our
patches will remain in our repository alone, so it seems best to
store them in their own directory structure. Is there a best way to
organize our patch toolkit code directory structure in the repository
so merging our modifications into the next release is straightforward?

+ we eventually would like to minimize the modifications we need to
make and move as much of our specific functionality into MW
extensions. So, we will be doing two things at once - modifying the
patch toolkit for the next version and evolve it so we move
functionality out of it into extensions. This sounds like activity
that belongs in branches. However, it is desirable to retain some
relationship between the various versions of the patch code. Keeping
the patch code distributed in the various project directory
structures would seem to make this difficult. Any hints how we might
organize the patch tool kit development directory structure(s)?

These questions may be a bit discombobulated, since I have no clear
picture of a good directory structure to use. Any advice on these
issues and any others that people with experience in a similar
situation would be appreciated.

Dan Nessett

-------------------------------

Dan Nessett
dnessett_at_comcast.net

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2419653

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-18 20:02:22 CET

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.