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_at_freemail.ru) 19.11.2009, <16:01>
>
> Sorry for my terrible english...
>
-------------------------------
Dan Nessett
dnessett_at_comcast.net
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2420115
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-19 18:19:41 CET