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

[Dan Nessett <dn...@comcast.net>]

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@comcast.net

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

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

[Dan Nessett <dn...@comcast.net>]

Hi Andrey,

Thanks for responding.

I actually did read the section on vendor drops before posting to the  
subversion users email list. There are certainly many similarities  
between the example (calc/libcomplex) it discusses and the situation  
we are in. However, I think there are some differences that (may)  
warrant more detailed discussion.

In the vendor drop example, the main code is kept in /trunk and each  
vendor drop is kept in /vendor. When a new libcomplex is released, a  
developer first updates to the most recent version of the main code  
in /trunk and then "tar bombs" the new version of libcomplex on top  
of his working copy. He then makes any necessary changes to update  
the copy of the main code in his workspace to use the new library and  
when that is done, commits his local changes to /trunk.

The situation I am interested in is somewhat different. You can't  
simply tar bomb a working version of the main code, since that would  
wipe out all patches made to it. So, you have to keep the  
modifications separate in some other part of the repository and apply  
them to the newest vendor drop. My question is how to organize the  
repository directory structure to make that as easy as possible.

Here is a concrete example. Suppose you have a vendor code organized  
in two directories a/ and b/. Underneath these directories are  
subdirectories. Let's say underneath a/ are 10 subdirectories,  
sub.a-1, sub.a-2, ..., sub.a-10 and underneath b/ are 2000  
subdirectories sub.b-1, ... .sub.b-2000. Suppose the changes you need  
to make to the vendor code is limited to sub.a-3, sub.a-5, and  
sub.a-9. In addition you need to add some subdirectories to b/, say  
sub.b-2001, sub.b-2002 and sub.b-2003. Furthermore, you have no need  
for most of the subdirectories in b/, so in trunk you eliminate most  
b/ subdirectories and keep only sub.b-6, sub.b-23 and sub.b-306.

For a specific vendor release you import it into /vendor and then  
copy it somewhere (where is one of the questions). You then create  
patches based on the previous vendor release and the changes you have  
made to it. You store these somewhere (again, where is one of the  
questions). You then check out the new vendor release and the most  
recent patches into your workspace and apply the patches. This will  
probably require resolving some incompatibilities between the new  
vendor drop and the patches developed for the previous version. Also,  
you will have to go back and delete all of the subdirectories in b/  
that you don't use.

It is possible to organize the repository directories in several ways  
to support the activity I just described. At the top level you could  
have release versions (say, rel1_1/, rel1_2/, ...) and beneath each  
release directory have subdirectories trunk/, branches/, tags/ and  
vendor/). It also may be useful to have a subdirectory patches/ to  
store the patches made to the release. Another way is to keep the  
traditional top level trunk/, branches/, tags/, vendor/ and perhaps  
patches/. Underneath each of these you would then have subdirectories  
re1_1/, rel1_2/, ...). Or some other organization might be best.

One of my goals is to have the most useful directory organization  
that allows some sort of obvious relationship between the patches and  
also supporting tools such as svn_load_dirs.pl. So, the question is,  
given the usage pattern, what directory organization works best. I  
assume others have run into a similar if not identical situation and  
was hoping to benefit from their experience.

Regards,

Dan Nessett


On Nov 19, 2009, at 5:03 AM, Andrey Repin wrote:

> Greetings, Dan Nessett!
>
>> <snip>
>
> You really should read the http://svnbook.org/
> What you describing is the classic example of what there called  
> "vendor drops".
>
>
> --
> WBR,
>  Andrey Repin (anrdaemon@freemail.ru) 19.11.2009, <16:01>
>
> Sorry for my terrible english...
>



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

Dan Nessett
dnessett@comcast.net

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

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

[Andrey Repin <an...@freemail.ru>]

Greetings, Dan Nessett!

> 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.

You really should read the http://svnbook.org/
What you describing is the classic example of what there called "vendor drops".


--
WBR,
 Andrey Repin (anrdaemon@freemail.ru) 19.11.2009, <16:01>

Sorry for my terrible english...

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].