[reSIProcate] major directory reorg
Derek
derek at xten.com
Sun Jun 12 16:43:10 CDT 2005
I prefer Proposal one because proposal two has several problems.
First off, repro/dum/etc will not build without installing if they
have includes of the <resiprocate/SipMessage.hxx> style as that path
will not exist in the filesystem. This will greatly slow down
debugging/developing repro & dum; debuggers won't be able to thread
through source code, resiprocate an dum would have to be installed to
run repro with the changes.
On windows, the headers would have to be copied to a directory of the
style <resiprocate/SipMessage.hxx> before repro/dum could be built.
Proposal two would be a major irritation when working on dum/repro or
debugging a core util problem.
--Derek
On 12-Jun-05, at 1:29 PM, Fischl jason wrote:
> After much discussion in Dallas, here is take 2 on reorg plan. The
> previous proposal had an issue where revision numbers could not be
> common across the different projects. Here are two proposals that
> address this. Mostly this involves directory restructuring and
> importing msrp into the same subversion module as the other projects.
>
>
> Proposal 1:
> main/build
> /autotools
> /contrib
> /resiprocate
> /resiprocate/doc
> /resiprocate/test
> /dum
> /dum/doc
> /dum/test
> /rutil
> /rutil/doc
> /rutil/test
> /repro
> /repro/doc
> /repro/test
> /msrp
> /msrp/doc
> /msrp/test
> - this is relatively close to what we have now in that the source
> files are in the first subdirectory. e.g. in main/resiprocate
> - complaint is that the README file, doc and test directories are hard
> to find amongst the source files
> - eliminates the "sip" directory
>
>
> Proposal 2:
> main/build
> /autotools
> /contrib
> /resiprocate/src
> /resiprocate/doc
> /resiprocate/test
> /dum
> /dum/src
> /dum/doc
> /dum/test
> /rutil
> /rutil/src
> /rutil/doc
> /rutil/test
> /repro
> /repro/src
> /repro/doc
> /repro/test
> /msrp
> /msrp/src
> /msrp/doc
> /msrp/test
> - also eliminates the sip subdirectory.
> - requires third party applications to run make install to have access
> to project header files
>
> On 6/12/05, Jay Hogg <jay at 2imagineit.net> wrote:
>
>> Jason,
>>
>> While I welcome the reorg because I think it makes more
>> sense I have a fundamental question. You specifically say
>> 'different repositories' and is where my questions come
>> from:
>>
>> - We now have to track commit versions across 5 repositories
>> to know what is current?
>>
>> - Symlinks are easy when everything is in trunk and fully
>> compatible. How is it going to be handled when RESIP
>> branches and what is required by DUM (and friends) is now a
>> branch in RESIP and "RESIP trunk" isn't compatible the DUM
>> trunk or REPRO trunk?
>>
>> - Is this going to require that ALL new development work be
>> done in a branch and merged at one time so "trunk" is stable
>> through the entire lineage? If I want to work with "DUM
>> unstable" I will checkout RESIP from the top-down then
>> checkout "dum unstable" someplace to work on it?
>>
>> The reason I ask is where I work we've been migrating our
>> CVS and Vss repositories to SVN for about 6 months. We split
>> some things that "obviously needed to be split" and have had
>> some versioning hell between a couple packages and
>> supporting libraries. Part of it is communications and
>> knowing what is happening but it is also hard to syncronize
>> multiple groups with different objectives and deadlines.
>>
>> Just some thoughts...
>>
>> Jay
>>
>> ----- Original Message Follows -----
>> From: Fischl jason <jason.fischl at gmail.com>
>> To: resiprocate <resiprocate-devel at list.sipfoundry.org>
>> Subject: [reSIProcate] major directory reorg
>> Date: Sat, 11 Jun 2005 14:22:05 -0700
>>
>>
>>> While in Dallas we've discussed a major reorg of the
>>> directory structure for resip/dum/repro/msrp. Here's the
>>> plan:
>>>
>>> Current:
>>>
>>> resip:
>>> main/sip/resiprocate
>>> /resiprocate/os
>>> /resiprocate/dum
>>> /resiprocate/dum/doc
>>> /resiprocate/dum/test
>>> /resiprocate/test
>>> /resiprocate/doc
>>> /repro
>>> /contrib
>>>
>>> msrp:
>>> main/src
>>> main/doc
>>>
>>> Proposed
>>> Each of resip, rutil, repro, dum, contrib will be a
>>> different repository. Here's roughly what the intermodule
>>> dependency is. We'll use symbolic links (in svn) to
>>> satisfy the intermodule dependencies. If you check out
>>> repro, it will check out the appropriate dependent modules
>>> through the sym links.
>>>
>>> repro
>>> |
>>>
>>> |---------------|--------------------------|
>>> dum contrib/db
>>> contrib/pcre
>>> |
>>> resip
>>> |
>>> ----------------------------------
>>> | |
>>> contrib/ares rutil
>>>
>>> resip:
>>> main/src/resiprocate
>>> main/src/test
>>> main/doc
>>>
>>> rutil: // resiprocate util
>>> main/doc
>>> main/src/rutil
>>> main/src/test
>>>
>>> repro:
>>> main/doc
>>> main/src/repro
>>> main/src/test
>>>
>>> dum:
>>> main/doc
>>> main/src/dum
>>> main/src/test
>>>
>>> contrib:
>>> main/contrib
>>> main/contrib/ares
>>> main/contrib/db
>>> main/contrib/pcre
>>> main/contrib/dtls
>>> main/contrib/getopt
>>>
>>> Implications:
>>> - break out common utilities into rutil as a separate
>>> library. - Eliminates the os subdirectory -> will require
>>> mods to apps - Moves dum to its own module instead of
>>> subdir of resiprocate -> will require mods to apps
>>> - symlinks are only supported in subversion >= 1.1
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at list.sipfoundry.org
>>>
>>>
>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at list.sipfoundry.org
>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>>
>>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
More information about the resiprocate-devel
mailing list